9. Evidencija prihoda i rashoda↵

Evidenciju ostvarenih prihoda i primanja i izvršenih rashoda i izdataka, sistem vrši analizom ispostavljenih platnih naloga u okviru sistema platnog prometa kojeg vodi Uprava za trezor,u korist i na teret računa za izvršenje budžeta JLS, odnosno njihovih pripadajućih javnih uplatnih računa. Svaka JLS ima po jedan račun za izvršenje budžeta sa sledećom strukturom: 840-xxxxxxxxxx640-kb .

nalog_za_prenos

9.1 Evidencija prihoda i primanja↵

Svi prihodi JLS imaju karakter javnih prihoda i njihova naplata vrši se preko pripadajućih uplatnih računa grupe 843 i 845. Evidenciju prihoda sistem vrši analizom ispostavljenih platnih naloga u okviru sistema platnog prometa kojeg vodi Uprava za trezor, u korist računa za izršenje budžeta JLS, a na teret pripadajućih uplatnih računa JLS.

Poslovna pravila za evidentiranje prihoda JLS:

  • svi prihodi evidentiraju se na samo jednom JBKJS a to je JBKJS Tip KJS – 0.
  • struktura računa iz grupe 843 je 840-xxxxEEEEEE843-kb gde je EEEEEE šifra ekonomske klasifikacije prihoda ili primanja

ek-kl * na osnovu ekonomske klasifikacije prihod se evidentira na prihodnoj aprorpijaciji na trecem nivou ekonomske klasifikacije.

Korekcija prihoda

Ukoliko imamo pogrešno ili više uplaćenih javnih prihoda na javni uplatni račun, JLS donosi rešenje o preknjižavanju ili povraćaju. Rešenje izvršava UT. Evidenciju korekcije prihoda sistem vrši analizom ispostavljenih platnih naloga u okviru sistema platnog prometa kojeg vodi Uprava za trezor, na teret pripadajućih uplatnih računa JLS, a u korist računa koji nisu račun izvršenja budžeta JLS.

Sistem iznos korekcije prihoda evidentira na odgovarajućoj ekonomskoj aproprijaciji sadržanoj u strukturi javnog uplatnog računa, čime se umanjuje iznos ostvarenog prihoda.

Prepoznavanje uplata iz platnog sistema↵

Uplate kada je u nalogu račun odobrenja = račun izvršenja budžeta (840-xxxxxxxxxx640-kb).

  1. Prihodi:

    • Račun zaduženja 840-0000xxxxxx843-kb. Gde xxxxxx predstavlja prihodnu ekonomsku klasifikaciju.
    • Šifra plaćanja 261
    • PBO = KB00000xxxxxx00000
    • Prihod se evidentira se na prihodnoj aproprijaciji za ekonomsku klasifikaciju iz PBO xxx (na trećem nivou), za izvor 01 JBKJS-a (tip 0) kome pripada račun izvršenja budžeta. Kolona Prispeli iznos se povećava za iznos iz naloga. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Prispeli iznos i dodaje koloni Ostvareno.

  2. Pražnjenje računa 845

    • Račun zaduženja 840-0000xxxxxx845-kb
    • Šifra plaćanja 263
    • PBO = xxxxxx (ekonomska klasifikacija)
    • Prihod se evidentira na prihodnoj aproprijaciji za ekonomsku klasifikaciju iz PBO xxx (na trećem nivou), za izvor 01 JBKJS- (tip 0) kome pripada račun izvršenja budžeta. Prispeli iznos se povećava za iznos iz naloga. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Prispeli iznos i dodaje koloni Ostvareno.

  3. Refundacije

    • Račun odobrenja = račun zaduženja = račun izvršenja budžeta.
    • Šifra plaćanja 246
    • PBO = KB_JBKJS_FUN_PROG_PROJ_IZ_EKKLAS
    • PBZ = KB_JBKJS_FUN_PROG_PROJ_IZ_EKKLAS
    • Aproprijaciji koja se identifikuje elementima iz PBZ se povećava Rezervisano za iznos iz naloga, a samim tim se smanjuje Raspoloživo. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Rezervisano i dodaje koloni Izvršeno.
    • Aproprijaciji koja se identifikuje elementima iz PBO se u kolonu Prispeli iznos upisuje iznos iz naloga. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Prispeli iznos i dodaje koloni Korekcija rashoda. Na taj način se povećava Raspoloživo.
    • Obe aproprijacije moraju da postoje
    • JBKJS u PBZ i PBO mora da bude isti

  4. Povraćaji rashoda

    • Račun zaduženja ne sme biti račun izvršenja budžeta. Može biti račun “840” ili račun bilo koje poslovne banke.
    • Šifra plaćanja može biti bilo koja osim 261
    • PBO = KB_JBKJS_FUN_PROG_PROJ_IZ_EKKLAS
    • Kada EKKLAS u PBO počinje sa "49" (transferi) uzimaju se sledeće tri cifre da bi se odredila koja je tačno ekonomska klasifikacija u pitanju
    • Za aproprijaciju ekonomske klasifikacije EKKLAS vrši se korekcija rashoda. Iznos iz naloga se upisuje u kolonu Prispeli iznos. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Prispeli iznos i dodaje koloni Korekcija rashoda. Na taj način se povećava Raspoloživo.

  5. Neprepoznate uplate

    • Najčešće se odnose na slučaj 4, kada je u nalogu PBO iz koga ne mogu da se identifikuju elementi budžetske linije JBKJS, funkcija, program, projekat, izvor, ekonomska klasifikacija.
    • Potrebno je omogućiti funkcionalnost povezivanja naloga neprepoznate uplate sa odgovarajućom prihodnom apoprijacijom na kojoj treba izvršiti korekciju.

9.2 Evidencija rashoda i izdataka↵

Izvršenje rashoda i izdataka vrši se ispostavljanjem naloga na teret računa za izvršenje budzeta JLS do visine odobrenih aproprijacija.

Prilikom ispostavljanja naloga za placanja organi JLS su dužni da u pozivu na broj zaduženja upisu podatak sledeće strukture:

Poslovna pravila za evidentiranje rashoda JLS:

  • svi rashodi evidentiraju se na jednoj od aproprijacija koje su učitane u sistem, što znači da JBKJS ne može biti Tip – 0
  • PBZ uvek mora biti po modelu 97 a struktura PBZ je sledeća:
Rb Naziv Broj karaktera
1 kontrolni broj 2
2 JBKJS 5
3 funkconalna klasifikacija 3
4 Program 4
5 PA/Projekat 4
6 Izvor finansiranja 2
7 Ekonomska klasifikacija 3
  • Ekonomska klasifikacija mora biti na trećem nivou ekonomske klasifikacije

Na osnovu ekonomske klasifikacije iz strukture poziva na broj zaduženja, sistem rashod evidentira na pripadajućoj rashodnoj aproprijaciji na trećem nivou ekonomske klasifikacije. el-kl Ako sistem prilikom analize utvrdi da ne postoji aproprijacija navedena u pozivu na broj zaduženja, može da obustavi njegovo izvršenje.

Ako sistem prilikom analize utvrdi da je iznos sredstava iz platnog naloga veći od raspoloživih sredstava na odgovarajućoj aproprijaciji, evidentira neusaglašenost i može da obustavi njegovo izvršenje.

Korekcija rashoda

Korekcija rashoda podrazumeva povraćaj više ili pogrešno isplaćenih rashoda/izdataka. Radi se o direktnim uplatama na račun izvršenja budžeta JLS (grupa računa 640). JLS uplatiocu dostavlja instrukciju za uplatu: * Uplata se vrši u korist računa izvršenja budžeta JLS (640) * PBO mora imati sledeću strukturu:

Rb Naziv Broj karaktera
1 kontrolni broj 2
2 JBKJS 5
3 funkconalna klasifikacija 3
4 Program 4
5 PA/Projekat 4
6 Izvor finansiranja 2
7 Ekonomska klasifikacija 3

Analizom naloga u okviru sistema platnog prometa kojeg vodi Uprava za trezor, u korist računa za izvršenje budžeta JLS, sistem vrši korekciju rashoda na odgovarajućoj aproprijaciji, čime se povećava iznos raspoložive aproprijacije (umanjuje izvršenje).

Ukoliko nalog za prenos nema sve navedene elemente iz instrukcije PBO, takva uplata se evidentira kao neprepoznata stavka u sistemu. Sredstva nisu na raspolaganju JLS sve dok se ne utvrdi svrha uplate.

Prepoznavanje isplata iz naloga platnog prometa↵

Isplate kada je u nalogu račun zaduženja = račun izvršenja budžeta (840-xxxxxxxxxx640-kb) <> račun odobrenja

  1. Rashod

    • PBZ = KB_JBKJS_FUN_PROG_PROJ_IZ_EKKLAS
    • Kada EKKLAS u PBZ počinje sa "49" (transferi) uzimaju se sledeće tri cifre da bi se odredila koja je tačno ekonomska klasifikacija u pitanju
    • Aproprijacija ekonomske klasifikacije EKKLAS mora da postoji i da ima Raspoloživo >= Iznos iz naloga
    • Za aproprijaciju ekonomske klasifikacije EKKLAS se za iznos iz naloga povećava Rezervisano. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Rezervisano i dodaje koloni Izvršeno.

  2. Prinudna naplata

    • Šifra plaćanja
      • 253 - kada je banka računa odobrenja "840", a partija se završava sa "843" (računi za uplatu javnih prihoda)
      • 290 - za ostale osnove prinudne naplate
    • PBZ = KB_JBKJS_FUN_PROG_PROJ_IZ_483(5)xxx trebalo bi da bude ove strukture. U praksi se izvršava plaćanje direktno sa računa izvršenja budžeta i u PBZ obično stavlja JBKJS vlasnika tog računa, tako da nije moguće identifikovati JBKJS za koga je izvršena prinudna naplata i njegovu aproprijaciju. Ovi nalozi će biti tretirani kao neprepoznati sve dok korisnik kroz aplikaciju ne izvrši njihovo povezivanje sa odgovarajućom aproprijacijom.
    • Svrha plaćanja PN999xxxxxxxxxxx

  3. Povraćaji prihoda

    • Račun zaduženja je račun izvršenja budžeta
    • Račun odobrenja - 840-0000xxxxxx843-kb. Gde xxxxxx predstavlja prihodnu ekonomsku klasifikaciju (računi za uplatu javnih prihoda)
    • Šifra plaćanja 264
    • PBZ = KB_JBKJS_EKKLAS_xxxxxxx
    • Prihod se umanjuje na prihodnoj aproprijaciji za ekonomsku klasifikaciju iz PBZ (na trećem nivou), za izvor 01 JBKJS-a (tip 0) kome pripada račun izvršenja budžeta. Prispeli iznos se povećava za iznos iz naloga. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Prispeli iznos i oduzima od kolone Ostvareno

  4. Nalozi tarife

    • Račun zaduženja je račun izvršenja budžeta
    • Šifra plaćanja 298
    • PBZ = KB_JBKJS_FUN_PROG_PROJ_IZ_EKKLAS
    • Aproprijacija ekonomske klasifikacije EKKLAS mora da postoji i da ima Raspoloživo >= Iznos iz naloga
    • Za aproprijaciju ekonomske klasifikacije EKKLAS se za iznos iz naloga povećava Rezervisano. Na kraju obradnog dana, ukoliko se ovaj nalog nalazi u izvodu, iznos se oduzima od kolone Rezervisano i dodaje koloni Izvršeno.
    • Po trenutnom načinu rada PBZ je u formi (PBZ = KB_JBKJS_EKKLAS_xxxxxxx) gde nije moguće identifikovati na koju aproprijaciju se plaćanje odnosi, tako da ova vrsta plaćanja ulazi u kategoriju neprepoznatih isplata.

  5. Neprepoznate isplate

    • Kada je u nalogu PBZ iz koga ne mogu da se identifikuju elementi budžetske linije JBKJS, funkcija, program, projekat, izvor, ekonomska klasifikacija.
    • Potrebno je omogućiti funkcionalnost povezivanja naloga neprepoznate isplate sa odgovarajućom rashodnom apoprijacijom na kojoj treba izvršiti korekciju.uzima od kolone Ostvareno

9.3 Integracija platnim sistemom Uprave za trezor↵

Integracija sa platnim sistemom Uprave za trezor realizuju se korišćenjem 2 servisa:

  1. PPKontrolaNaloga
    Postojeći SOAP servis preko koga se ostvaruje kompletan unos i kontrola JAFIN naloga. U sklopu integracija sa KIBJLS, ovaj servis je izmenjen tako da sprovodi identifikaciju naloga koji pripadaju JLS i njihovu kontrolu koristeći KIBJLS-Rest.
  2. Jafin2KIBJLS
    Novi neinteraktivni servis koji periodično ili na poziv proverava status naloga u JAFIN sistemu koji pripadaju JLS. Jednom kada je nalog uspešno realizovan, ovaj servis koristeći KIBJLS - Rest vrši ažuriranje naloga i aproprijacija u KIBJLS.

9.3.1 Integracija sa PPKontrolaNaloga↵

Web servis PPKontrolaNaloga identifikuje naloge JLS tako što im je račun odobrenja ili zaduženja sledeće strukture:

  1. Banka = 840
  2. Poslednje tri cifre partije 640

PPKontrolaNaloga radi kontrolu upotrebom KIBJLS-Rest servisa. Koristeći endpoint /api/payment/register-payments KIBJLS-Rest servisu se prosleđuje niz naloga u JSON formatu koji će biti registrovani ili odbijeni u sistemu KIBJLS. Format JSON objekata koji se prosleđuju servisu je:

{
  "payments": [
    {
      "amount": null,               // Iznos naloga
      "creditAccount": "",          // Račun odobrenja
      "creditAccountName": "",      // Naziv računa odobrenja
      "creditAccountPlace": "",     // Mesto računa odobrenja
      "creditModel": null,          // Model poziva na broj odobrenja
      "creditReferenceNumber": "",  // Poziv na broj odobrenja
      "debitAccount": "",           // Račun zaduženja
      "debitAccountName": "",       // Naziv računa zaduženja
      "debitAccountPlace": "",      // Mesto računa zaduženja
      "debitModel": null,           // Model poziva na broj zaduženja
      "debitReferenceNumber": "",   // Poziv na broj zaduženja
      "paymentBasis": "",           // Svrha plaćanja
      "paymentCode": ""             // Šifra plaćanja
    },
    ...
  ]
}

Napomena

Svi elementi JSON objekta za plaćanje podležu sintaksnim pravilima definisanim od strane Narodne Banke, a tiču se formata elemenata na nalogu za prenos.

Odgovor KIBJLS-Rest servisa je niz JSON objekata (koji odgovara poslatim elementima za plaćanje) od kojih svaki sadrži 2 JSON objekta - paymentModel i paymentError pri čemu je drugi null ukoliko za dato plaćanje nema grešaka i tada je plaćanje uspešno registrovano.

{
  "paymentResponse": [
    {
      "paymentModel": {},
      "paymentError": null
    },
    ...
  ]
}

PaymentModel sadrži iste elemente kao i Payment i dopunjen je elementima paymentType i status koji određuju tip plaćanja kojem nalog pripada i njegov status u sistemu KIBJLS. Nalog se upisuje u tabelu KIBJLS@JAFIN i prosleđuje dalje u platni sistem. Iz naloga tj. iz njegovog PBO ili PBZ se može identifikovati da li je u pitanju rashodna ili prihodna apropijacija. Rezultat uspešne registracije naloga je sledeći:

  1. Za rashodne aproprijacije u sistemu JLS se kolona Rezervisani iznos povećava za iznos iz naloga.
  2. Za prihodne aproprijacije u sistemu JLS se kolona Prispeli iznos povećava za iznos iz naloga.

Nalog će biti odbijen ukoliko za odgovarajuću rashodnu aproprijaciju ne postoji dovoljan raspoloživ iznos.

9.3.2 Integracija sa Jafin2KIBJLS↵

Servis Jafin2KIBJLS u konfigurabilnom vremenskom intervalu ili na manualni poziv prolazi kroz sve naloge u tabeli KIBJLS@JAFIN koji su registrovani u KIBJLS kao plaćanje.

Za sve ove naloge servis proverava status izvršenja u JAFIN preko atributa StatusNaloga, koji se dobija iz različitih baza podataka u odnosu na operativni dan naloga u KIBJLS tabeli. Operativni dan može biti:

  1. Isti kao tekući operativni dan JAFIN sistema
    Status izvršenja naloga je u tabeli tPrometna@JAFIN
  2. Različit u odnosu na operativni dan JAFIN sistema
    Status izvršenja naloga je u tabeli u tPrometna_GGMMDD_1@DBJAFINARH za operativni dan GG.MM.DD.

Jafin2KIBJLS pokušava da ažurira izvršene naloge iz KIBJLS tabele koristeći KIBJLS-Rest endpoint /api/payment/update-payments. Endpoint-u se prosleđuje niz naloga u JSON formatu (Payment) dopunjen podatkom za reklamaciju - referenceNumber.

{
  "payments": [
    {
      "amount": null,               // Iznos naloga
      "creditAccount": "",          // Račun odobrenja
      "creditAccountName": "",      // Naziv računa odobrenja
      "creditAccountPlace": "",     // Mesto računa odobrenja
      "creditModel": null,          // Model poziva na broj odobrenja
      "creditReferenceNumber": "",  // Poziv na broj odobrenja
      "debitAccount": "",           // Račun zaduženja
      "debitAccountName": "",       // Naziv računa zaduženja
      "debitAccountPlace": "",      // Mesto računa zaduženja
      "debitModel": null,           // Model poziva na broj zaduženja
      "debitReferenceNumber": "",   // Poziv na broj zaduženja
      "paymentBasis": "",           // Svrha plaćanja
      "paymentCode": "",            // Šifra plaćanja
      "referenceNumber": ""         // Podatak za reklamaciju
    },
    ...
  ]
}

Kao i kod integracije sa PPKN, odgovor KIBJLS-Rest servisa je niz JSON objekata (koji odgovara poslatim elementima za plaćanje) od kojih svaki sadrži 2 JSON objekta - paymentModel i paymentError pri čemu je drugi null ukoliko za dato plaćanje nema grešaka i tada je plaćanje uspešno ažurirano. U tabeli KIBJLS@JAFIN se ažurira status naloga koji je dobijen u odgovoru servisa KIBJLS-Rest. Rezultat uspešnog ažuriranja naloga je sledeći:

  1. Za rashodne aproprijacije u sistemu JLS se od kolone Rezervisani iznos oduzima iznos iz naloga i dodaje se koloni Izvršeno.
  2. Za prihodne aproprijacije u sistemu JLS se od kolone Prispeli iznos oduzima iznos iz naloga i dodaje se koloni Ostvareno.

Odgovor KIBJLS-Rest servisa se beleži u atribut KIBJLS_Result da bi se pokušalo sa ponovnim slanjem u slučaju grešaka, ili da bi se greška dalje analizirala u slučaju semantičkih problema. Ultimativno, svi zaostali nalozi će posle konfigurisanog vremenskog perioda prestati da se obrađuju jer se greške ne mogu srediti bez intervencije, te se markiraju posebnim statusom.

9.3.2.1. Odložena realizacija naloga za prenos↵

Status izvršenja JAFIN naloga se prati putem kolone StatusNaloga@tPrometna. Izvršeni nalozi imaju StatusNaloga = 1.

Nalozi u JAFIN mogu imati više statusa koji im odlažu realizaciju, na primer:

  • Likvidnost
    Nalozi koji zadužuju nelikvidne račune u tabeli tPrometna@JAFIN imaju StatusNaloga = 2. JAFIN stored procedura periodično pokušava da realizuje ove naloge do kraja opeativnog dana nakon čega oni prelaze u neizvršeni status. Lista svih mogućih statusa je u tSifPROMStatusNaloga@JAFIN.
  • Strana banka
    Nalozi u kojima je račun odobrenja od strane banke (u JAFIN terminologiji domaća banka koja nije Trezor) stoje sa StatusNaloga = 6 dok ne stigne potvrda iz RTGS-a i tek ih onda "pušta" procedura SWIFTPrijem.

Za sve naloge u tabeli KIBJLS@JAFIN koji nemaju StatusNaloga = 1 potrebno je u toku tekućeg operativnog dana periodično proveravati da li je StatusNaloga "prešao u 1" i ako jeste, ovaj status treba upisati u tabelu KIBJLS kao marker da dalje provere nisu potrebne. Ukoliko opeativni dan JAFIN nije tekući, potrebno je samo jednom proveriti ove naloge u JAFINArh bazi.

9.3.3 Dijagram integracije↵

integracija_jafin.puml.svg