Simptom

Prilikom slanja plaćanja javnih prihoda kroz “Generiši plaćanja” akciju u wizardu UniCredit B2B (ebaPlus), banka je počela odbijati naloge s HTTP 500 i porukama:

<nalogResponse>
  <errorList>
    <halcomError><errorInfo>Nalog br. 1</errorInfo>
      <errorText>Neispravan parametar: Poziv na broj zaduzenja</errorText></halcomError>
    <halcomError><errorInfo>Nalog br. 1</errorInfo>
      <errorText>Neispravan parametar: Poziv na broj odobrenja</errorText></halcomError>
    <halcomError><errorInfo>Nalog br. 1</errorInfo>
      <errorText>Neispravan parametar: Datum</errorText></halcomError>
  </errorList>
  <odbijeniNalozi>1</odbijeniNalozi>
  <zaprimljeniNalozi>0</zaprimljeniNalozi>
</nalogResponse>

Tri greške, zapravo dvije različite bube.

Bug #1 — JP metapodaci završavali u <pozivZaduzenja>

Za uplate javnih prihoda (tipDokumenta=1, model 12) polje <pozivZaduzenja> mora biti prazno. Stvarni JP poziv na broj ide u zasebno polje <pozivNaBroj> zajedno s ostalim JP podacima (porezOd, porezDo, sifVrstePr, sifMjesta, budzetOrg, brPorezObv).

U wizardu smo ranije gradili pozivZaduzenja iz payment.ref. Ali baš kod JP plaćanja, payment.ref već sadrži cijeli niz JP metapodataka (JP_OD:…,JP_DO:…,JP_POZIV:…,JP_POREZNI_BROJ:…,…) — pa su ti podaci završavali u polju gdje banka očekuje čist broj ili ništa.

Prije fixa

<modelPozivaZaduzenja>12</modelPozivaZaduzenja>
<pozivZaduzenja>JP_OD:01.04.2026,JP_DO:30.04.2026,JP_POZIV:0000000000,JP_POREZNI_BROJ:4218025900006,JP_BUDZETSKA:0000000,JP_VRSTA_PRIHODA:711211,JP_OPCINA:077</pozivZaduzenja>

Poslije fixa

<modelPozivaZaduzenja>12</modelPozivaZaduzenja>
<pozivZaduzenja></pozivZaduzenja>

JP podaci se normalno prenose u za to namijenjena polja na kraju naloga:

<tipDokumenta>1</tipDokumenta>
<brPorezObv>4218025900006</brPorezObv>
<sifVrstePr>711211</sifVrstePr>
<porezOd>010426</porezOd>
<porezDo>300426</porezDo>
<sifMjesta>077</sifMjesta>
<budzetOrg>0000000</budzetOrg>
<pozivNaBroj>0000000000</pozivNaBroj>

Bug #2 — vikend kao valutni datum

U modulu postoji pravilo: ako se nalog generira poslije 14:00, <datum> (valutni datum) i <pozivOdobrenja> pomiču se na sljedeći dan. Razlog — UniCredit cut-off za obradu istog dana je 14:00.

Samo — stari kod je dodavao +1 dan bez provjere radnih dana. Generisanje plaćanja u petak poslije 14:00 proizvodilo je:

<pozivOdobrenja>25-04-2026</pozivOdobrenja>  <!-- subota -->
<datum>250426</datum>                         <!-- subota -->

Banka, naravno, ne prihvata subotu/nedjelju kao valutni datum → Neispravan parametar: Datum i Poziv na broj odobrenja.

Popravka

effective_date = today + timedelta(days=1) if now.hour >= 14 else today
# Monday=0 ... Saturday=5, Sunday=6
while effective_date.weekday() >= 5:
    effective_date += timedelta(days=1)

Nakon +1 dan pomak, dok god je datum vikend — pomjeri se još jedan dan naprijed. Petak poslije 14:00 → ponedjeljak.

Gdje je fix

• Fajl: packages/bringout/odoo-bringout-l10n_ba_bank_unicredit/l10n_ba_bank_unicredit/wizard/unicredit_payment_wizard.py
• Verzije: 16.0.3.2.3 (prazan pozivZaduzenja), 16.0.3.2.4 (vikend → radni dan)

Deploy:

python scripts/upgrade_production_nix_service.py --modules l10n_ba_bank_unicredit

Napomena za računovođe

Ako vam je u payment.ref upisan cijeli JP niz (JP_OD: …, JP_VRSTA_PRIHODA: …, …) — ne brinite, tako treba. To je ulazni izvor iz kojeg modul parsira sva JP polja (i može ih nadjačati default vrijednosti iz internal notes partnera). Do ovog fiksa, međutim, taj isti niz je curio u pogrešno polje XML-a.

Također, ako šaljete plaćanja petkom poslije 14:00 — od sada će automatski dobiti ponedjeljak kao valutni datum, bez ručne intervencije.

Napomena

Generisano od strane Claude 🤖

---

Ernad Husremović, hernad@bring.out.ba