Maksājumu salīdzināšana ar rēķiniem jāsāk ar maksātāja un dokumentu identificēšanu, pēc tam jāpārbauda summas un atlikumi. Ja viens pārskaitījums sedz vairākus rēķinus, sistēmai vajag saglabāt sadalījumu pa dokumentiem. Ja ar to nepietiek, rēķina neapmaksātā daļa paliek atvērta. Savukārt neskaidru maksājumu nedrīkst piesaistīt pirmajam rēķinam ar līdzīgu summu. Automatizācijas uzdevums ir droši apstrādāt pierādāmas sakritības un sagatavot pārējos gadījumus cilvēka lēmumam. Tālāk aprakstītais modelis palīdz finanšu vadītājam definēt šīs robežas pirms integrācijas pasūtīšanas.
Kāpēc maksājuma summa nav pietiekams identifikators
Vienam klientam var būt vairāki vienādas summas rēķini. Maksājuma mērķī var būt ierakstīts līguma numurs, vecs rēķins vai tikai uzņēmuma nosaukums. Arī precīza kopējās summas sakritība vēl nepierāda, ka klients apmaksājis tieši sistēmas atlasīto dokumentu kombināciju. Vairāku atvērtu rēķinu gadījumā vienu summu reizēm iespējams iegūt dažādos veidos.
Tāpēc pirms automātiskas sasaistes jānosaka, kādu informāciju uzņēmums uzskata par pietiekamu. Skaidri norādīti rēķinu numuri kopā ar zināmu maksātāju dod citu pamatojumu nekā tikai summa un līdzīgs nosaukums. Ja maksā trešā persona, piemēram, grupas uzņēmums, attiecība ar rēķina saņēmēju jāpārbauda atsevišķi. Līdzīga juridiskā nosaukuma daļa nav drošs aizstājējs šai pārbaudei.
Šī ir šaurāka problēma nekā visas darba plūsmas no pieteikuma līdz rēķinam izveide. Rēķins jau pastāv un nauda ir saņemta. Jānosaka, kuras saistības maksājums sedz un kas pēc tā paliek neskaidrs.
Maksājumu salīdzināšana ar rēķiniem: kādus datus sasaistīt
Projektēšanā ieteicams nošķirt bankas darījumu, rēķinu un attiecinājumu. Bankas darījums glabā saņemto summu, valūtu, datumu, maksātāja informāciju un ārējo identifikatoru. Rēķinam ir savs identifikators, klients, valūta un aktuālais atvērtais atlikums. Attiecinājums savieno abus ierakstus un pasaka, kāda maksājuma daļa izmantota konkrētajam dokumentam.
Šāds modelis ļauj vienam maksājumam segt vairākus rēķinus un vienam rēķinam saņemt vairākus maksājumus. Lauks “apmaksāts” vien šīs attiecības nepaskaidro. Bez sadalījuma vēlāk ir grūti saprast, vai atlikums radies daļējas apmaksas, kļūdainas sasaistes vai atcelta darījuma dēļ.
Pirms noteikumu izpildes jāsaņem aktuāls rēķinu atlikumu stāvoklis. Ja grāmatvedis tikko sasaistījis maksājumu uzskaites sistēmā, integrācija nedrīkst izmantot agrāk nolasīto atlikumu kā nemainīgu patiesību. Vienojieties, kura sistēma ir galvenā katram ierakstam un kurā vietā drīkst mainīt attiecinājumu. Šis lēmums saistīts ar galvenā datu avota izvēli integrācijās.
Prasībās vajag paredzēt arī informāciju, kas sistēmā trūkst. Ja bankas izraksts nedod uzticamu klienta identifikatoru, tas jāpieraksta kā ierobežojums, nevis jāaizvieto ar nepamatotu minējumu. Sākotnējo maksājuma mērķi saglabājiet līdzās normalizētajai versijai, lai grāmatvedis varētu pārbaudīt, ko saņēma sistēma un ko tā no teksta izsecināja.
Lauku kartē blakus katrai vērtībai ierakstiet tās izcelsmi un pārbaudi. Maksājuma datumam precizējiet, kuru bankas sniegto datumu izmantojat. Rēķina numuram saglabājiet arī sistēmas iekšējo identifikatoru, lai attēlojamā numura labojums nepazaudētu saikni. Summām nošķiriet sākotnējo dokumenta vērtību no pašreizējā atlikuma. Tukšs lauks jāparāda kā trūkstošs, nevis klusējot jāpārvērš par derīgu vērtību.
Arī statusu nosaukumiem vajag vienotu skaidrojumu. “Saņemts”, “piedāvāts attiecinājums” un “apstiprināts attiecinājums” ir atšķirīgi darba stāvokļi. Lietotājam jāzina, kurš no tiem jau ietekmē rēķina atlikumu. Ja ārējā sistēma rezultātu vēl nav pieņēmusi, saskarnē to nevajag rādīt kā pabeigtu apmaksas sasaisti. Šo robežu parādiet arī atskaitēs, ne tikai tehniskajā žurnālā.
Noteikumu secība: no skaidras atsauces līdz cilvēka pārbaudei
Sāciet ar dokumenta atsauci, maksātāja saikni ar klientu un valūtu. Tad pārbaudiet, vai atsaucēs minētie rēķini ir atvērti un vai maksājums jau nav izmantots citā attiecinājumā. Tikai pēc tam izvērtējiet summas. Precīzā prioritāte jāapstiprina uzņēmuma finanšu atbildīgajam, jo maksājumu ieradumi atšķiras.
Automātiski apstrādājamā grupa jādefinē šauri. Piemēram, tajā var iekļaut maksājumu ar skaidrām rēķinu atsaucēm, apstiprinātu klienta atbilstību, vienādu valūtu un pilnīgu norādīto atlikumu segumu. Šajā piemērā nav jāmēģina uzminēt, kuru rēķinu klients domājis. Atliek pārbaudīt, ka norādītie dokumenti un summas joprojām atbilst.
Ja trūkst atsauces, sistēma drīkst sagatavot priekšlikumu ar iespējamiem rēķiniem un atlases pamatojumu. Priekšlikums vēl nemaina apmaksas statusu. Neieviesiet universālu noteikumu “vecākais rēķins vispirms”, pirms nav pārbaudīts, vai tas atbilst vienošanās nosacījumiem un uzņēmuma apstiprinātajai kārtībai.
Arī labi izskatīgs ticamības rādītājs nevar aizstāt trūkstošu pamatojumu. Operatoram jāredz, kuri dati sakrita, kuri nav pieejami un kāpēc konkrētais gadījums nav apstiprināts automātiski. Ja sistēma izmanto teksta atpazīšanu vai MI, šādu ieteikumu nevajag pielīdzināt pierādītai maksātāja gribai.
Piecu maksājumu demonstrācija ar atlikumiem
Iedomāsimies klientus Alfa un Beta. Zemāk redzamie identifikatori un summas ir izdomāti demonstrācijai. Katras rindas rēķini ir atsevišķi, tāpēc tabulu var izmantot kā nelielu pieņemšanas testu kopu. Visi maksājumi un rēķini ir EUR, nav komisiju, kredītrēķinu vai valūtas pārrēķina.
|
Maksājums un tā pamatojums |
Atvērtie rēķini pirms apstrādes |
Ieteiktais sadalījums |
Kas paliek un kurš lemj |
|
M1: Alfa maksā 900 EUR, atsaucē R1 un R2 |
R1: 600 EUR; R2: 300 EUR |
R1 piešķir 600 EUR, R2 piešķir 300 EUR |
Abi atlikumi 0 EUR; automātiski tikai pēc pārējām atbilstības pārbaudēm |
|
M2: Alfa maksā 200 EUR, atsaucē R3 |
R3: 500 EUR |
R3 piešķir 200 EUR |
R3 paliek 300 EUR; daļēja apmaksa |
|
M3: Alfa maksā 550 EUR, atsaucē R4 |
R4: 500 EUR |
R4 piešķir 500 EUR |
Maksājumā paliek 50 EUR; grāmatvedis noskaidro tālāko attiecinājumu |
|
M4: Alfa maksā 300 EUR bez rēķina atsauces |
R5: 300 EUR; R6: 300 EUR |
Neko neattiecina |
300 EUR paliek nesadalīti; vajadzīgs precizējums |
|
M5: Beta maksā 400 EUR, atsaucē norādīts Alfas R7 |
Alfas R7: 400 EUR |
Neko neattiecina |
400 EUR paliek nesadalīti; jāpārbauda maksātāja saikne un pamatojums |
M1 parāda vienu maksājumu vairākiem rēķiniem. M2 nodala saņemtā maksājuma pilnīgu izlietošanu no rēķina pilnīgas apmaksas. M3 nav pamats automātiski pārcelt pārmaksu uz nākamo dokumentu. M4 un M5 demonstrē gadījumus, kuros pat precīza summas sakritība nedod pietiekamu atbildi.
Pārbaudiet arī tabulu pretējā virzienā. Atverot rēķinu, jāvar atrast tam piesaistītos maksājumus un summas. Atverot bankas darījumu, jāredz visi saņēmēji un vēl neattiecinātā daļa. Abu skatījumu summām jāsaskan. Tas palīdz atklāt situāciju, kurā rēķina statuss ir mainīts, bet saikne ar bankas darījumu nav saglabāta.
Daļēja apmaksa, pārmaksa un starpības nav viena darbība
Daļējas apmaksas gadījumā paliek prasījuma atlikums. Pārmaksa atstāj nesadalītu maksājuma daļu, kurai vēl jānosaka pamatojums. Komisija, atlaide, kredītrēķins vai valūtas starpība savukārt prasa citu izskaidrojumu. Visas atšķirības automātiski norakstot, sistēma var iegūt glītu nulles atlikumu, bet pazaudēt saimnieciskā darījuma jēgu.
Odoo 19 bankas saskaņošanas dokumentācija ilustrē atšķirību: mazāks maksājums var atstāt atvērtu rēķina daļu, bet lielākam maksājumam var saglabāties nesaskaņots atlikums. Tas ir konkrēta produkta piemērs. Jūsu sistēmas funkcijas un nepieciešamie grāmatojumi jāpārbauda ar tās piegādātāju un grāmatvedi.
Arī poga, kas atzīmē dokumentu kā pilnībā apmaksātu, nav tikai vizuāla ērtība. Odoo daļēju maksājumu aprakstā šāda izvēle var radīt starpības grāmatojumu. Uzņēmuma noteikumos skaidri nodaliet atlikuma saglabāšanu no tā dzēšanas ar pamatotu uzskaites darbību.
Ja nepieciešama noapaļošanas pielaide, definējiet tās valūtu, pamatojumu un apstiprināšanas tiesības. Vienu skaitlisku robežu nedrīkst klusējot attiecināt uz jebkuru valūtu un darījuma veidu. Šis raksts nenosaka grāmatošanas vai nodokļu risinājumu konkrētai starpībai; tas palīdz formulēt sistēmas prasības, lai lēmums netiktu pieņemts nejauši.
Neskaidro maksājumu rinda, kurā iespējams strādāt
Izņēmumu sarakstā nepietiek ar paziņojumu “nav sakritības”. Ieteicams parādīt bankas darījumu, sākotnējo mērķi, atrastos rēķinus, pieejamos atlikumus un bloķēšanas iemeslu. Atbildīgajam jāvar ātri atšķirt trūkstošu rēķina numuru no klienta neatbilstības vai novecojuša atlikuma.
Piešķiriet lietai īpašnieku un nākamo darbību: precizēt ar klientu, pārbaudīt uzskaiti vai gaidīt dokumentu. Saglabājiet saņemtā skaidrojuma atsauci un lēmuma autoru. Klienta atbilde e-pastā var palīdzēt atrisināt vienu maksājumu, bet tai nevajadzētu automātiski pārvērsties par vispārīgu noteikumu turpmākajiem darījumiem.
Kad cilvēks apstiprina sadalījumu, sistēmai vēlreiz jāpārbauda atlikumi. Citādi divi darbinieki var vienlaikus izmantot vienu un to pašu maksājuma daļu. Ja stāvoklis mainījies, apstiprinājums jāaptur un jārāda jaunā situācija, nevis jāpielāgo summa klusējot.
Saglabājiet arī iespēju labot kļūdainu attiecinājumu ar izsekojamu atcelšanu. Iepriekšējās saiknes izdzēšana bez pēdām apgrūtina pārbaudi. Vajadzīgs pamatojums, kurš ieraksts atcelts, kas izveidots tā vietā un kurās sistēmās izmaiņa jau atspoguļota.
Piekļuves tiesības projektējiet atbilstoši šīm darbībām. Darbiniekam, kurš pievieno klienta paskaidrojumu, nav obligāti jāvar norakstīt atlikumu vai mainīt automātiskās apstiprināšanas noteikumu. Noteikumu maiņai paredziet atsevišķu izvērtējumu un saglabātu versiju. Pretējā gadījumā nebūs skaidrs, kāpēc līdzīgi maksājumi dažādos datumos apstrādāti atšķirīgi.
Izņēmuma atrisinājumu nevajag pazaudēt garā brīvā teksta laukā. Pierakstiet izvēlēto rēķinu, attiecināto summu, pamatojuma atsauci un turpmāko rīcību ar atlikumu. Brīvais komentārs var paskaidrot situāciju, bet pārbaudāmo sadalījumu saglabājiet strukturēti. Tad cits darbinieks var turpināt darbu, nepārlasot visu saraksti un neuzminot iepriekšējā lēmuma nozīmi.
Kā pārbaudīt integrāciju pirms automātiskas statusu maiņas
Sāciet ar anonimizētu bankas un rēķinu izlasi, kur pareizos sadalījumus jau apstiprinājis grāmatvedis. Vispirms ļaujiet sistēmai tikai piedāvāt attiecinājumus. Salīdziniet priekšlikumus ar šo pārbaudīto rezultātu un pierakstiet kļūdaino izvēļu iemeslus. Liels automātiski apstrādāto ierakstu īpatsvars nav labs rezultāts, ja tajā ir nepareizi apmaksāti rēķini.
Pieņemšanas pārbaudē iekļaujiet atkārtotu viena izraksta ielādi, rēķina atlikuma maiņu pirms apstiprināšanas un divus vienlaicīgus operatora mēģinājumus. Atsevišķi pārbaudiet bojātu vai nepilnīgu importu. Sistēmai jāpaskaidro, vai tā nav saņēmusi datus, nav atradusi attiecinājumu vai nav spējusi saglabāt jau apstiprinātu rezultātu.
Pārtraukums saglabāšanas brīdī ir īpaši svarīgs. Pirms atkārtotas darbības jānoskaidro, vai uzskaites sistēma iepriekšējo pieprasījumu jau izpildīja. Dublikātu novēršana pasargā no atkārtotas sasaistes, taču joprojām neatbild uz jautājumu, vai sākotnēji izvēlēts pareizais rēķins. Abas pārbaudes ir vajadzīgas atsevišķi.
Kontroles skatā salīdziniet saņemto, attiecināto un vēl nesadalīto summu katrā valūtā. Pievērsiet uzmanību ilgi neatrisinātiem izņēmumiem un labotām automātiskām sakritībām. Šie gadījumi parāda, kuri noteikumi jāprecizē. Tie nav pamats samazināt pierādījumu prasības tikai tāpēc, lai saraksts kļūtu īsāks.
Izmēģinājuma noslēgumā izvēlieties arī gadījumus, kurus turpmāk apzināti atstāsiet cilvēkam. Rets sarežģīts maksājums var neprasīt atsevišķa automātiska noteikuma izstrādi. Svarīgāk ir to laicīgi pamanīt un nodot darbiniekam ar saprotamiem datiem. Lēmumu par automatizācijas paplašināšanu pieņemiet pēc konkrēto kļūdu un manuālā darba analīzes, ne pēc vēlmes sasniegt pilnīgi tukšu izņēmumu sarakstu.
Ar ko sākt uzņēmumā
Pirmajam izvērtējumam sagatavojiet anonimizētu datu paraugu ar skaidrām sakritībām, daļējām apmaksām un neskaidriem maksātājiem. Blakus katram ierakstam norādiet pašreizējo grāmatveža lēmumu un vajadzīgo pamatojumu. Pārbaudiet, vai esošā sistēma spēj saglabāt sadalījumu un izņēmumu vēsturi, pirms izvēlaties jaunu platformu.
Ja nepieciešama palīdzība, biznesa procesu automatizācijas izvērtējumu var sākt tieši ar šādu paraugu. Mērķis ir vienoties, ko drīkst apstiprināt automātiski un kam vajadzīga cilvēka pārbaude. Tikai pēc tam ir jēga noteikt integrācijas tehnoloģiju un ieviešanas apjomu.