Uvod

U prethodnom članku opisali smo dva modula za poravnanje bankovnih izvoda — reconciliation_match_bank_in_bill (ulazni računi) i reconciliation_match_bank_out_invoice (izlazni računi). U produkciji se ubrzo pokazalo da postoji praktičan slučaj koji nije bio pokriven: kupac plati prije nego što se kreira izlazni račun, dok u sistemu postoji samo potvrđena prodajna narudžba (PROD/26/05/0219).

Stara verzija je u takvom slučaju ostavljala bankovnu stavku u prelaznom kontu sa pogrešnim partnerom (banka često ne prepozna ispravnog kupca kada uplata dolazi sa dijeljenog računa, npr. državnih agencija). Verzija 16.0.2.2.0 modula reconciliation_match_bank_out_invoice rješava taj scenarij.

Šta je novo u v16.0.2.0.0

Dugme “Match Invoice” u OCA pregledu poravnanja sada pretražuje i izlazne račune i prodajne narudžbe.

Redoslijed pretrage

1. Prvo izlazni računi (kao i ranije) — out_invoice, stanje posted, payment_state u not_paid ili partial. Format imena: IF/26/01/0019.
2. Zatim prodajne narudžbe — sale.order u stanju:
   • sent (ponuda poslana kupcu e-mailom)
   • sale (potvrđena prodajna narudžba)
   • Format imena: PROD/26/05/0219.

Iste dvije strategije za oba tipa zapisa

Za svaku vrstu dokumenta koriste se identične strategije:

1. Reference matching — naziv dokumenta (npr. PROD/26/05/0219) sadržan u polju payment_ref bankovne stavke.
2. Account number matching — pretraga partnera koji su ranije koristili isti broj žiro računa, zatim filtriranje otvorenih dokumenata tih partnera prema iznosu (sa tolerancijom — predefinisano 1.00 KM).

Za izlazne račune nema datumskog filtera — uplata može stići sedmicama ili mjesecima nakon izdavanja računa.

Za prodajne narudžbe postoji starosna granica (parametar Max Sales Order Age (days), predefinisano 90 dana) — narudžbe starije od tog perioda se ne pretražuju. Razlog: stare neporavnate narudžbe rijetko bivaju plaćene; obično su zaboravljene ili otkazane, a širi opseg pretrage donosi više lažnih podudaranja nego korisnih. Korisnik može povećati ili smanjiti granicu u wizardu prije pretrage.

Djelimična uplata po prodajnoj narudžbi (avans)

Drugi parametar — Allow Partial Payment for Sales Orders (predefinisano isključeno) — proširuje pretragu na narudžbe gdje je bankovni iznos manji od ukupnog iznosa narudžbe. Tipičan slučaj: kupac uplati avans od npr. 100 KM po narudžbi od 393.12 KM, prije izdavanja računa.

Pravila pretrage kada je opcija uključena:

• Egzaktno podudaranje — |narudžba_total − bankovni_iznos| ≤ tolerancija (kao i ranije)
• Djelimično podudaranje — bankovni_iznos > 0 i bankovni_iznos < narudžba_total − tolerancija

Djelimična podudaranja označena su narandžasto u tabeli rezultata i imaju oznaku Partial, tako da računovođa vidi da bankovni iznos ne pokriva cijelu narudžbu.

Predefinisano je opcija isključena jer pretraga na osnovu samo donjeg iznosa značajno povećava broj kandidata (svaka starija narudžba sa većim iznosom postaje potencijalno podudaranje). Uključuje se selektivno kada se uplata stvarno vodi kao avans.

Primjena različita za izlazni račun i za prodajnu narudžbu

Kada korisnik označi pronađeni dokument i klikne “Apply Match”, ponašanje zavisi od tipa zapisa:

Izlazni račun (postojeća logika)

Puno automatsko poravnanje:

1. Postavlja partnera na bankovnoj stavci iz računa
2. Mijenja prelazni konto u konto potraživanja kupca (kupac, npr. 2110)
3. Čisti porezna polja na bankovnom zapisu
4. Poravnava stavke konta potraživanja računa i bankovnog zapisa
5. Označava bankovnu stavku kao poravnatu

Prodajna narudžba (novo)

Prodajna narudžba nema stavku konta potraživanja — taj zapis nastaje tek kada se kreira izlazni račun. Stoga modul ne pokušava poravnanje, nego priprema bankovnu stavku za kasnije poravnanje:

1. Postavlja partnera na bankovnoj stavci iz prodajne narudžbe
2. Mijenja prelazni konto u konto potraživanja partnera (kupac, npr. 2110) — konto se uzima iz partner.property_account_receivable_id
3. Čisti porezna polja na bankovnom zapisu
4. Ne poravnava — bankovna stavka ostaje otvorena na kontu potraživanja, čeka kreiranje računa

Korisnik nakon toga kreira izlazni račun iz prodajne narudžbe (dugme “Kreiraj fakturu” na formi narudžbe) i ručno poravna otvorene stavke kupca.

Praktičan primjer

Banka primi uplatu od kupca AGENCIJA ZA PRIVATIZACIJU u iznosu od 393.12 KM. U sistemu postoji potvrđena prodajna narudžba PROD/26/05/0219 sa istim iznosom, ali nije izdat račun.

Stari tok rada (do v16.0.1):

1. Bankovna stavka stoji u prelaznom kontu sa pogrešnim partnerom (banka)
2. Računovođa ručno traži narudžbu u sistemu
3. Ručno mijenja partnera, konto, kreira fakturu, poravnava

Novi tok rada (v16.0.2.2.0):

1. Klik na “Match Invoice” → wizard nudi PROD/26/05/0219
2. Klik na “Apply Match” → partner postavljen, konto promijenjen u 2110

3. Kreira se faktura iz narudžbe, a poravnanje stavki potraživanja je trivijalno (oba zapisa su na istom kontu, isti partner, isti iznos)

Tehnički detalji

Polja u rezultatima pretrage

Da bi match.invoice.wizard.line mogao držati i račun i narudžbu, polja su generalizovana:

• record_type — selekcija invoice / sale_order
• invoice_id — Many2one na account.move (popunjeno za račune)
• sale_order_id — Many2one na sale.order (popunjeno za narudžbe)
• record_name, record_date, record_amount — generička polja za prikaz

U tabeli rezultata redovi prodajnih narudžbi su istaknuti plavo (decoration-info).

Zavisnosti modula

'depends': [
    'account',
    'account_reconcile_oca',
    'sale',  # novo u v16.0.2.0.0
],

Verzija

• Stara: 16.0.1.0.0
• Nova: 16.0.2.2.0

Napomena

Generisano od strane Claude 🤖

---

Ernad Husremović, hernad@bring.out.ba