Produkcijska kontrolna lista

Vjerodajnice

• API klijent je vezan uz ispravan profil izdavatelja i OIB.
• Dodijeljene su samo potrebne ovlasti.
• client_secret je u sustavu za čuvanje tajni, ne u izvornom kodu.
• Dogovoren je postupak rotacije i hitnog opoziva.

Zahtjevi

• Svaka mutacija ima stabilan, poslovno jedinstven Idempotency-Key.
• Integracija ne generira novi ključ samo zato što je HTTP poziv istekao.
• OIB dobavljača i operatora u izvornom UBL-u odgovara vjerodajnici.
• Lokalno čuvate svoj identifikator dokumenta, invoiceId sustava Klik Račun, operationId i konačni sažetak.

Asinkroni ishodi

• 202 Accepted se ne tretira kao izdani račun.
• Operacije se prate do terminalnog statusa.
• ACTION_REQUIRED aktivira ručno usklađenje, ne automatsko ponovno slanje.
• Obrada poštuje Retry-After kod 429 odgovora.

Ispravci i avansi

• P10/384 XML ide isključivo kroz pregled i potvrdu.
• planId se ne sprema kao trajni predložak; kratkotrajan je i jednokratan.
• Konačni račun ne pokušava zaobići storno iskorištenog avansa.
• Nakon izdavanja preuzimate efektivni UBL ako je Klik Račun dodao sustavske BG-3 reference.

Plaćanja

• Iznos, valuta, datum i metoda dolaze iz stvarnog poslovnog događaja.
• Poništenje koristi /void; ne briše povijesni zapis.
• AP evidenciju ne tumačite kao dobavljačev AR izvještaj Poreznoj.

Tehnička proba

1. Dohvat tokena s najmanjim potrebnim ovlastima.
2. Strukturirani nacrt bez izdavanja.
3. Nacrt iz izvornog UBL-a i usporedba SHA-256 sažetka.
4. Validacija bez izdavanja.
5. Izdavanje i praćenje operacije.
6. Djelomično plaćanje i poništenje u testnom okruženju.
7. Pregled ispravka koji se namjerno potvrđuje sa zastarjelom inačicom i mora vratiti 409.
8. Provjera da klijent druge organizacije dobiva 404, ne podatke dokumenta.