Dupli događaji integracije ne smiju automatski otvoriti drugu narudžbu. Sustav treba prepoznati je li riječ o ponovnom prijenosu već zaprimljene poslovne predaje ili o novoj, opravdanoj narudžbi istog kupca. Ključ nije samo tehnički identifikator poruke, nego poslovni identifikator i jasno pravilo obrade.
Integracija često prenosi događaj koji predstavlja narudžbu, promjenu narudžbe, otkazivanje ili drugi poslovni zahtjev. Prijenos se može ponoviti zbog ponovnog slanja iz izvornog sustava, prekida veze, vremenskog ograničenja odgovora ili ručne ponovne obrade. Sam dolazak iste poruke drugi put nije dokaz nove poslovne namjere.
Ako ERP svaki primljeni događaj tumači kao novu narudžbu, posljedice su operativne: dvostruke stavke za proizvodnju ili isporuku, netočni otvoreni iznosi, pogrešno rezervirane zalihe i dodatni posao računovodstva. Suprotna krajnost također nosi rizik. Preširoko pravilo za prepoznavanje duplikata može odbiti legitimnu drugu narudžbu kupca.
Zato pitanje nije samo: "Je li poruka ista?" Potrebno je pitati: "Predstavlja li ova predaja isti poslovni zahtjev koji je već prihvaćen u službenoj ERP transakciji?"
Za jedinstvenost poslovne predaje potreban je identifikator koji izvorni poslovni proces prepoznaje kao stabilan. To može biti broj narudžbe iz web trgovine, CRM-a, EDI poruke ili drugog izvornog sustava, uz oznaku izvora kada broj nije globalno jedinstven.
Dobar poslovni identifikator ima tri svojstva:
Identifikator poruke služi drugoj svrsi. On može razlikovati dva pokušaja dostave, zapis obrade ili tehnički zahtjev. Ako se pri svakom ponovnom slanju stvara novi identifikator poruke, on ne može sam spriječiti nastanak druge narudžbe.
Kombinacija poput kupac + datum + ukupni iznos nije pouzdana zamjena za poslovni identifikator. Isti kupac može istoga dana poslati dvije narudžbe jednakog iznosa. Takav zapis treba ostati druga narudžba ako izvorni proces potvrđuje dvije odvojene poslovne predaje.
Prije izrade ERP narudžbe integracija treba pronaći postojeći zapis prema dogovorenom poslovnom ključu. Uobičajeni ključ može sadržavati oznaku izvornog sustava i vanjski broj narudžbe. Točan sastav ključa ovisi o procesu i mora imati poslovnog vlasnika.
Praktični tok može izgledati ovako:
Važno je unaprijed odrediti što znači "isti zahtjev". U nekim procesima isti poslovni identifikator uz nepromijenjen sadržaj znači ponovljeni prijenos. U drugima isti identifikator uz promijenjene stavke može predstavljati izmjenu, novu verziju ili neispravan ulaz. Integracija ne bi smjela samostalno pretpostaviti poslovno značenje promjene.
Pretpostavimo da kupac pošalje narudžbu s vanjskim brojem WEB-4581 . Integracija je zaprimi, a ERP otvori službenu narudžbu. Izvorni sustav ne primi potvrdu o odgovoru i ponovno pošalje isti događaj.
Drugi događaj nosi novi tehnički identifikator poruke, ali isti izvor, isti vanjski broj narudžbe i sadržaj koji poslovno predstavlja istu predaju. Rezultat treba biti evidentiranje ponovljenog prijenosa, ne druga ERP narudžba.
Kasnije isti kupac pošalje novu narudžbu s vanjskim brojem WEB-4582 , čak i ako su kupac, artikli i iznos jednaki prethodnoj narudžbi. To je zasebna poslovna predaja. Sustav treba otvoriti novu narudžbu jer poslovni identifikator razlikuje zahtjeve.
Ako za WEB-4581 stigne sadržaj s promijenjenom količinom, odluka ovisi o dogovorenom procesu. Može biti riječ o izmjeni, nedopuštenom prepisivanju već prihvaćene narudžbe ili pogrešci izvora. Taj slučaj treba imati zasebno pravilo, a ne završiti ni slijepim stvaranjem nove narudžbe ni tihim odbacivanjem.
Ograničenja podataka korisna su za provedbu dijela kontrole. Mogu provjeravati jedinstvenost, obvezna polja i veze među zapisima. PostgreSQL dokumentacija opisuje ograničenja poput UNIQUE , NOT NULL , primarnih i stranih ključeva: PostgreSQL Constraints .
Primjerice, jedinstveno ograničenje nad kombinacijom izvornog sustava i vanjskog broja narudžbe može spriječiti dva zapisa s istim poslovnim ključem u odabranoj evidenciji. Ipak, baza ne zna sama treba li promijenjena predaja ažurirati postojeću narudžbu, otvoriti novu verziju ili završiti u iznimci. To su poslovna pravila.
Takva podjela odgovornosti smanjuje nejasnoće:
Za stabilan proces nije dovoljno navesti polje "broj narudžbe". Potrebno je dokumentirati vlasnika svakog ključnog ulaza i odluke.
Posebno obradite barem sljedeće slučajeve:
Svaka iznimka treba imati vlasnika, očekivanu radnju, zapis razloga i pravilo nastavka obrade. Bez toga se odluke sele u poruke, osobno pamćenje i naknadna usklađenja.
Kriterij prihvata nije opća izjava poput "sustav obrađuje duplikate". Treba opisati ulaz, očekivanu radnju i provjerljiv dokaz. Primjeri:
Mjera prihvata može biti pregled rezultata dogovorenog skupa testnih predaja: broj stvorenih ERP narudžbi, broj evidentiranih ponovljenih predaja, broj iznimki i mogućnost povezivanja svakog ishoda s izvornim događajem. Početne i ciljne vrijednosti treba odrediti vlasnik procesa prije testiranja, ne naknadno prema rezultatu.
Prije promjene integracije okupite vlasnika prodajnog ili narudžbenog procesa, ERP odgovornu osobu, integracijski tim i računovodstvo ako narudžba utječe na financijske dokumente. Zajedno definirajte poslovni ključ, životni ciklus izmjene i iznimke na stvarnim vrstama predaja koje proces prima.
Ako poslovni ključ ili odgovornost nisu jasni, Screening poslovnog procesa može poslužiti kao strukturirani početak za razdvajanje podatkovnih ograničenja od poslovnih pravila. Tek nakon te odluke vrijedi tehnički ugraditi jedinstvenost poslovne predaje u integraciju i službene ERP transakcije.