Simptom

Korisnik je u Odoo-u na fakturi dobavljača UF/26/05/0003 (partner: JP ELEKTROPRIVREDA FBIH, ref: 40402-1217057-30046) pokrenuo akciju “Generiši plaćanja”. Generisano je plaćanje PBNK2/2026/00101 s ispravnim partnerom i iznosom, ali polje ref na samom plaćanju je ostalo prazno.

To znači da kasnije, kod izvoza naloga prema banci (UniCredit B2B, Procredit, ASA, Sparkasse PDF, itd.), poziv na broj zaduženja je išao prazan i banka ili nije znala povezati uplatu, ili je morao ručno biti dopisan.

Uzrok

Wizard journal.payment.wizard u modulu l10n_ba_payments_journal je referencu plaćanja gradio na sljedeći način (datoteka wizards/journal_payment_wizard.py):

def _get_payment_reference(self, partner, lines):
    jp_fields = self._parse_jp_fields(partner.comment)

    if jp_fields:
        date_from, date_to = self._get_jp_period()
        return self._build_payment_reference(jp_fields, date_from, date_to)

    descriptions = [line.name for line in lines if line.name]
    return ', '.join(descriptions) if descriptions else ''

Dvije bube u jednoj funkciji.

Bug #1 — kriva detekcija “javnih prihoda”

Provjera if jp_fields: ulazi u JP granu ako je bilo koje JP_* polje prisutno u napomenama partnera. To je previše labavo.

Ključno polje koje stvarno definiše plaćanje javnih prihoda (porez, doprinos) je JP_VRSTA_PRIHODA (npr. 712112 za doprinos za PIO/MIO, 711211 za porez na dohodak…). Bez tog polja nije ni javni prihod.

Dodatno, partner “JP ELEKTROPRIVREDA FBIH” ima prefiks “JP” u nazivu — ali to znači “Javno Preduzeće”, a ne “Javni Prihod”. Elektroprivreda je obična režija, ne porez. Wizard se zato nije smio voditi prefiksom imena.

Bug #2 — ref se nije čitao sa fakture

Za sve ne-JP partnere kod je čitao line.name sa payable linije temeljnice (display_type=payment_term). Ideja je bila da modul l10n_ba_payment_reference na write() sinhronizuje move.ref → term_line.name, pa da onda wizard “vidi” ref preko linije.

Problem: taj sync radi samo na write() kada ref ili payment_reference budu u vals — ne i na create(). Bilo kakva faktura kreirana s ref-om već postavljenim u kreaciji (npr. preko bill_draft_ocr_processing OCR import-a, migracije iz starog sistema, ili API import-a) nije imala sinhronizovan term_line.name. Rezultat: prazan descriptions, prazan ref.

Fix

packages/bringout/odoo-bringout-l10n_ba_payments_journal/l10n_ba_payments_journal/wizards/journal_payment_wizard.py:

def _get_payment_reference(self, partner, lines):
    """Build payment reference.

    Javni prihodi are detected by presence of JP_VRSTA_PRIHODA in
    partner notes. For all other partners use the source bill's
    payment_reference / ref, falling back to line descriptions.
    """
    jp_fields = self._parse_jp_fields(partner.comment)

    if jp_fields.get('JP_VRSTA_PRIHODA'):
        date_from, date_to = self._get_jp_period()
        return self._build_payment_reference(jp_fields, date_from, date_to)

    refs = []
    for move in lines.mapped('move_id'):
        move_ref = move.payment_reference or move.ref
        if move_ref and move_ref not in refs:
            refs.append(move_ref)
    if refs:
        return ', '.join(refs)

    descriptions = [line.name for line in lines if line.name]
    return ', '.join(descriptions) if descriptions else ''

Šta je promijenjeno

1. JP grana se aktivira samo ako partner ima JP_VRSTA_PRIHODA u napomenama. Bez te šifre, partner nije javni prihod, bez obzira na “JP” u nazivu ili na druga JP_* polja.
2. Za sve ostale partnere ref se gradi iz move.payment_reference or move.ref direktno sa izvorne fakture. Više se ne oslanjamo na line.name sync hook iz l10n_ba_payment_reference.
3. Ako se generiše grupno plaćanje za više faktura istog partnera, ref-ovi se spajaju zarezom (deduplicirano).
4. Stari fallback na line.name ostaje kao zadnja linija odbrane.

Rezultat

Za fakturu UF/26/05/0003 s ref 40402-1217057-30046:

Prije	Poslije
payment.ref = '' (prazno)	payment.ref = '40402-1217057-30046'

Za stvarne uplate javnih prihoda (npr. partner “Federalno ministarstvo finansija” s JP_VRSTA_PRIHODA: 712112 u napomenama) ponašanje ostaje isto — ref se i dalje gradi po Halcom/UPP standardu (JP_OD:…, JP_DO:…, JP_POZIV:…, JP_POREZNI_BROJ:…, JP_BUDZETSKA:…, JP_VRSTA_PRIHODA:…, JP_OPCINA:…).

Deploy

python scripts/upgrade_production_nix_service.py --modules l10n_ba_payments_journal

Wizard verzija sada 16.0.2.1.0 na produkciji (odoo-bringout-1).

Pouka

Kod sinhronizacijskih hook-ova koji rade samo na write() (a ne na create()), nikad se ne oslanjati na cilj sinhronizacije kao “izvor istine”. Uvijek čitati izvorni atribut direktno — u ovom slučaju move.payment_reference or move.ref umjesto term_line.name. Sync hook ostaje koristan za prikaz u listi knjiženja, ali ne smije biti jedini put do podatka.

Napomena

Generisano od strane Claude 🤖

---

Ernad Husremović, hernad@bring.out.ba