Usklađenje dviju evidencija počinje usporedbom istog vremenskog obuhvata, istih filtera i istih jedinica usporedbe. Kontrolni zbroj prijenosa koristan je početni test, ali nije dovoljan dokaz podudarnosti: dvije pogreške mogu dati isti ukupan iznos. Zato uz zbrojeve treba usporediti broj zapisa, identifikatore i unaprijed dogovorena pravila za razlike.
Ovaj postupak vrijedi za prijenos između ERP-a i drugog sustava, između operativne i računovodstvene evidencije te za kontrolu uvoza, izvoza i integracija. Svrha nije samo potvrditi ukupan iznos. Svrha je utvrditi koje su stavke obuhvaćene, tko odlučuje o odstupanjima i kada se rezultat smije prihvatiti.
Naziv izvještaja, datum izvoza ili ukupna vrijednost nisu dovoljni za pouzdanu usporedbu. Dvije evidencije često izgledaju usporedive, a razlikuju se u najmanje jednoj važnoj dimenziji: trenutku nastanka, statusu dokumenta, valuti, organizacijskoj jedinici, vrsti transakcije ili načinu evidentiranja storna.
Prije prvog izračuna treba zapisati usporedni presjek:
Bez ovog presjeka tim može zapravo uspoređivati različite skupove podataka. Tada je i ispravan kontrolni zbroj prijenosa samo slučajna podudarnost.
Kontrolni zbroj prijenosa najčešće obuhvaća broj zapisa i jednu ili više agregiranih vrijednosti, poput količine, neto iznosa, poreza ili bruto iznosa. Za svaku vrijednost treba navesti jedinicu mjere, valutu, pravilo za zaokruživanje i tretman negativnih stavki.
Minimalni skup kontrola može sadržavati:
Agregati brzo pokazuju postoji li problem, ali ne pokazuju nužno gdje je problem. Primjerice, jedna stavka može nedostajati, a druga može biti evidentirana dvaput s istim iznosom. Ukupni iznos tada može ostati jednak, dok sadržaj evidencije nije jednak.
Zato usklađenje integriranih evidencija treba uključiti i usporedbu identifikatora. Koristan je popis identifikatora koji postoje samo u izvoru, samo u cilju ili u oba sustava s različitim ključnim vrijednostima. Ako poslovni ključ nije jednoznačan, prije usporedbe treba dogovoriti složeni ključ, primjerice kombinaciju broja dokumenta, retka, društva i poslovnog datuma.
Vlasnik izvornog podatka potvrđuje obuhvat i dostavlja podatke ili kontrolirani izvoz. Vlasnik ciljne evidencije potvrđuje usporedivi izvoz iz istog obuhvata. Ako sustavi ne mogu proizvesti podatke u istom trenutku, treba evidentirati oba trenutka i procijeniti zapise u prijelaznom razdoblju.
Za ponovljivu kontrolu vrijedi koristiti verzionirani obrazac s nazivom izvora, parametrima izvoza, vremenom izvoza i odgovornom osobom. Takav zapis olakšava ponavljanje kontrole nakon promjene integracije ili poslovnog pravila.
Prije usporedbe treba uskladiti format datuma, oznake valuta, decimalnu preciznost, šifre statusa i pravila za prazne vrijednosti. Normalizacija ne smije prikriti razliku. Svaku transformaciju treba opisati i odobriti vlasnik poslovnog pravila.
Posebnu pozornost zahtijevaju storna, djelomične isporuke, dokumenti s više valuta, korekcije nakon knjiženja i ponovljeni prijenosi. Ti slučajevi često jesu valjane poslovne iznimke, ali moraju imati prepoznatljiv trag u obje evidencije.
Najprije usporediti skup zapisa, a zatim vrijednosti unutar zajedničkog skupa. Rezultat treba razdvojiti na tri popisa:
Ovaj redoslijed sprječava pogrešan zaključak na temelju jednakog zbira. Također otkriva duplikate, pod uvjetom da usporedba uključuje broj pojavljivanja istog identifikatora, ne samo njegovu prisutnost.
Za svaku skupinu razlika treba utvrditi klasifikaciju: očekivano kašnjenje obrade, dopuštena poslovna iznimka, pogreška izvornog podatka, pogreška mapiranja, neuspjeli prijenos, duplikat ili nerazjašnjen slučaj. Klasifikacija nije tehnička pretpostavka. Ona je poslovna odluka s imenovanim vlasnikom.
Hipotetski scenarij: izvor bilježi otpremu u 23:58, a cilj prima poruku nakon ponoći. Ako je usporedni obuhvat kalendarski dan, evidencije se mogu razlikovati iako prijenos nije nužno neuspješan. Pravilo može obuhvatiti vremenski prozor obrade ili takve zapise voditi kao očekivane prijelazne iznimke. Pravilo treba odobriti prije kontrole, ne nakon što se razlika pojavi.
Kontrola završava odlukom, ne samo datotekom s razlikama. Odgovorna osoba treba potvrditi prihvat, odbijanje ili uvjetni prihvat uz otvorene iznimke. Uz odluku treba sačuvati parametre usporedbe, kontrolne zbrojeve, popis identifikatora, obrazloženja iznimki i datum odluke.
Ograničenja u bazi podataka mogu pomagati pri provjeri jedinstvenosti, obveznih polja i veza među zapisima. Primjerice, PostgreSQL dokumentacija opisuje ograničenja poput jedinstvenosti, NOT NULL i vanjskih ključeva: PostgreSQL Constraints .
Takve kontrole smanjuju dio tehničkih rizika, ali ne zamjenjuju poslovna pravila. Baza može provjeriti postoji li partner ili je li ključ jedinstven. Ne može sama odrediti smije li se dokument određenog statusa prenijeti, kako tretirati djelomičnu isporuku ili koje razdoblje pripada određenom obračunu. Ta pravila treba definirati zasebno, uz vlasnika poslovnog procesa.
Prije početka odrediti sljedeće:
Mjeru prihvata treba moći provjeriti iz sačuvanih ulaza i rezultata usporedbe. Izraz poput "razlika je mala" nije kriterij bez definiranog praga, vlasnika odluke i zapisa o iznimci.
Kada se razlike ponavljaju, problem često nije samo u upitu ili izvozu. Potrebno je pregledati trenutak nastanka zapisa, vlasništvo nad podatkom, pravila promjene statusa i put iznimke kroz proces. Screening poslovnog procesa može poslužiti kao strukturirani početak za utvrđivanje tih točaka prije promjene integracije ili ERP evidencije.
Za prvo usklađenje dovoljno je odabrati jedan jasno omeđen tok, zapisati usporedni presjek i provesti kontrolu identifikatora uz kontrolne zbrojeve. Taj rezultat zatim pruža osnovu za odlučivanje o korekciji podataka, promjeni pravila ili prilagodbi integracije.