[ zoranix @ 27.10.2021. 09:03 ] @
Da li je neko u Javi radio implementaciju XML-a i REST-a za Sistem Elektronskih Faktura (SEF)?

Takođe:
Da li je u opšte neko radio bilo kakvu implementaciju za SEF, ili za nekog posrednika prema SEF?
[ p_sasko @ 27.10.2021. 09:31 ] @
>
[ p_sasko @ 27.10.2021. 09:32 ] @
Mi smo zavrsili kompletno resenje sa integracijom ka vecini drugih
ponudjivača usluga.
Recite, Kako vam mozemo pomoci?
[ zoranix @ 27.10.2021. 23:44 ] @
Čuo sam, priča se...
[ jauser @ 18.02.2022. 04:50 ] @
Kod upload-a e-fakture u XML formatu, kada je faktura za budžetskog korisnika, javlja se greska CIR call failed. Saljem e-mailove podrsci, ne odgovaraju mi. Pa sam se okrenuo forumu. MOžda ovde nadjem resenje. Može li neko da mi kaže gde je problem . Unapred hvala
[ vbbojan @ 03.04.2022. 10:42 ] @
Jel zna neko stanje ažurnosti demo API?

Primeri iz konačne API specifikacije i primeri konačnih .xml ne rade kako sam očekivao.

Na primer:

Poziv /api/publicApi/get-unit-measures samo javi status 200 OK, ništa ne vraća nazad, ni da bekne.

Upload primera iz konačne api specifikacije ili upload primera iz objavljenih konačnih .xml isto ne prolaze.
Poziv /api/publicApi/sales-invoice/ubl/upload gde šaljem njihove konačne primere faktura vraća grešku):
Code:
"Message":"Invoice line tax amount is not defined","FieldName":"InvoiceLine.TaxTotal","ErrorCode":"UBLTaxAmountNotDefined"


WTF?




[ zoranix @ 03.04.2022. 20:36 ] @
Konkretno taj API nisam implementirao, pa ne mogu o njemu...
Ovde bih hteo da izrazim svoje nezadovoljstvo republičkom timu za razvoj API servisa, ako ima nekog ko ovo čita uopšte, ili mi ovde samo trošimo "struju" i "zujimo" bez veze.

Pomenutom timu, preko oglašenih e-mail adresa na sajtu PURS-a, samo poslao oko 20-tak mejlova i dobio samo jedan odgovor, ne znam nakoji tačno mejl, jer nisu raadili "reply", nego napisali novi mejl bez citiranja. Inače problem sa ULOAD XML datoteke imam od 01.11.2021. godine. I ako mi je XML dobar, odnosno prolazio je UBL 2.1 kontrolu, a i direktno preko "swager" platforme sam ga slao PURS-u, preko API koji je objavljen nisam uspeo do danas da ga pošaljem.
Definitivno sam odustao od podrške PURS-u i punu implementaciju API servisa sam završio za jednog od posrednika u sistemu elektronskih faktura, još u decembru 2021. godine.

Sada vidim da je PURS izdao novu specifikaciju, počev od 01.03.2022. godine, gde je praktično odustao od primene standarda u nekim delovima (u XML TAG-u "InvoiceLine"). Naravno odmah je reagovai i moj informacioni posrednik, tako da su se i oni odrekli pomenutih XML TAG-ova, uglavnom vezanih za PDV. Naravno sve to 60 dana pre odložene primene Zakona. Sve ove izmene trebalo je da budu gotove najkasnije do početka leta 2021. godine, jer je Zakon o eFakturama donet poodavno.

Imam utisak da ljudi koji prave API su sastavljeni od par beogradskih firmi, koji su posao, po svoj prilici dobili na tenderu, bez jasne tehničke dokumentacije i bez jasnih tehničkih ciljeva, za razliku od tima koji je radio na fiskalizaciji. Softver za fiskalizaciju, tehnička specifikacija za ceo postupak, je do tančina dobro dokumentovana, što ovde nikako nije slučaj. Imam utisak kao da se neko namerno nije potrudio oko ovoga da stvar ne bi uspela! To može da vidi svako ko je radio i na podršci za fiskalizaciju i za eFakture.

Po meni je tim za tehničku podršku eFaktura, ispred PURS-a (Poreska uprava Republike Srbije!), trebalo da izbaci po nekoliko primera u različitim jezicima za pristup pomoću API (Java, C++, C#...), barem za najkritičnije API i time izbegne situaciju da pre početka rada sistema ima plaikacija koje još ne podržavaju rad sa eFakturama.

Srećom su se posrednisci u sisitemu elektronskigh faktura potrudili i ogranizovali dobro svoje tehničke timove, čime su većim delom pridobili korisnike, koje su developeri usmeravali na informacione posrednike. Kao da je to bio dogovor... mada znam 100% da nije, jer se i posrednici žale na PURS-ovu podršku, više nego mi, ostali developeri.

Tako evo skoro 30 dana pred početak eFaktura, nemam još direktnu podršku za PURS po pitanju slanja XML dokumenta, mada mi sve drugo funkcioniše što sam imao u planu da koristim kod PURS-a. Konkretno servis ni API sa jedinicama mere nisam ni planirao da koristim, pa nemam iskustva s njim, ali zato imam sa svim drugim ostalim. Savetujem ti da ga i ti izbegneš:

„ /**
* Komnertuje jedinicu mere u UBL jedinicu mere
*
* @param jmere jedinica mere iz SQL baze
* @return UBL jedinica mere
*/
private String konvertujJMere(String jmere) {
String mera;
switch (jmere.toUpperCase()) {
case "KOM":
mera = "H87";
break;
case "KGR":
case "KG":
mera = "KGM";
break;
case "GR":
case "G":
mera = "GRM";
break;
case "T":
case "TN":
mera = "TNE";
break;
case "M":
case "MET":
mera = "MTR";
break;
case "M2":
case "KV":
mera = "MTK";
break;
case "M3":
case "KUB":
mera = "MTQ";
break;
case "LIT":
case "LTR":
case "L":
mera = "LTR";
break;
case "SAT":
case "ČAS":
case "H":
mera = "HUR";
break;
case "MIN":
case "MNT":
case "MN":
mera = "MIN";
break;
case "DAN":
case "DN":
case "D":
mera = "DAY";
break;
case "MES":
case "MESECI":
case "MESECA":
case "MESEC":
mera = "MON";
break;
case "GOD":
case "GG":
mera = "ANN";
break;
case "KWH":
mera = "KWH";
break;
case "KW":
mera = "KWT";
break;
default:
mera = "H87";
}
return mera;
}“
[ vbbojan @ 04.04.2022. 07:46 ] @
Hvala na opširnom opisu situacije. Ništa novo kod nas, business as usual = teška sramota.
Sad bar znam na čemu sam i da samostalno teško možeš nešto da uradiš.

Ne kontam baš kako su informacioni posrednici spremni, oni u principu samo prepakuju podatke i šalju ih tom istom SEF.
Ili oni možda imaju poseban tretman i pristup nekoj drugoj dokumentaciji i da za njih postoji poseban API?

Tako da da, slažem se, sve mi liči kao da je ovo što je objavljeno tek reda radi i da nije bitno da li će uoptše uspeti.
Ovim praktično (namerno ili ne - sve jedno) teraju vodu na vodencu informacionim posrednicima.

Što se tehničkog dela tiče, implementacija samog API nije komplikovana, ja (koji sam u ovu priču pao s'Marsa) sam za utrošenih sat vremena našao način da iz swaggera pomoću kod generatora napravim funkcionalnog REST API klijenta (c#).
Ko je više u tim vodama računam da bi ovo završio za 3 minuta.

Da li ti je problem da mi navedeš šta je to sve drugo što funkcioniše kod PURS-a što koristiš (jel si to testirao na njihovom demo API)?

Ako može na private, za kog si se inf. posrednika odlučio?

Hvala još jednom i pozdrav.










[ zoranix @ 04.04.2022. 08:44 ] @
DocLoop DOO Beograd (Moj - eRačun)!
Imaju dobar tim za podršku, što PURS nema. S njima sam u kontaktu nejviše van radnog vremena (tada obično imam vremena da se posvetim problemima...) i to im ne paravi nikakve probleme... barem za sada.

Što se tiče tvog primera ne znam da li mogu puno da pomognem jer radim u Java jeziku, zato je i tema otovorena na Java forumu. S obzirom na mnogobrojne sličnosti sa C# možda ti mogu pomoći.
Za početak kad pošalješ GET zahtev, da li nakon ispitivanja ResponseCode imaš nešto poput ovog ispod?

Code:
      
        if (http.getResponseCode() == 200) {
                try {
                    isr = new InputStreamReader(http.getInputStream());
                } catch (IOException ex) {
                    System.err.println("Problem sa getInputStream --> " + ex);
                    return;
                }
                BufferedReader br = new BufferedReader(isr);
                StringBuilder sb = new StringBuilder();
                String line;
                while ((line = br.readLine()) != null) {
                    sb.append(line).append(CR);
                }
                System.out.println("odgovor = " + sb.toString());
        }
[ vbbojan @ 04.04.2022. 20:45 ] @
Tnx na odgovoru.

Ja sa API komuniciram na "višem" nivou.

Nema potrebe da se direkt baviš http pozivima, ima odličnih alata koji iz opisa API generišu vrlo upotrebljivog klijenta, te ne gubiš vreme na baktanje sa http, parsiranju rezultata, exceptionima, itd, itd, - code generator sve to uradi za tebe za 3 minuta - besplatno. Sve je strong typed, sve je tačno u zarez sa opisom API (dobro ne baš u zarez, promašio mi je type za upload fakture, umesto byte array u .net treba poslati FileStream, nije ni previše bitno, ispravi se za 3 minuta).
Generisani nazivi su malo rogobatni, no za pola sata refaktoringa imaš sve cakum pakum.

Bukvalno copy/paste definiciju API u code generator i dobiješ source koji se kompajlira na keca. Bonus, dobiješ i readme sa instukcijama za kompajliranje i primerima za korišćenje.

Ja sam to ovako uradio - možda još nekom posluži (Ima još načina, Visual Studio isto može da generiše REST klijenta):

Odeš na https://demoefaktura.mfin.gov.rs/swagger/public_v1/swagger.json
Klikneš na Raw Data i kopiraš opis API.

Zatim odeš na online swagger editor i tu paste raw API opisa.
U menu ideš na Generate Client opciju, izabereš jezik i voila - imaš ceo API lepo zapakovan u lepu biblioteku.

Bukvalno sam za sat vremena imao komplet test okruženje spremno za inicijalno testiranje, kad ono cvrc - objavljeni demo API nema veze s'mozgom... j' ga :-(

Generiši ga za Javu i pogledaj, mislim da ti može biti od koristi, a naročito ako budu nešto menjali - copy/paste generate i opet si aktuelan.
[ zoranix @ 05.04.2022. 08:28 ] @
Kako ja to trenutno vidim, a i po tvojim rečima @vbbojan, to je sve jednostavno, što i ja mislim da jeste.
Primer sam Vam skinuo je sa Interneta inače, samo da pokušam da pomognem...
Inače uobičajeno nemam vremena da pomažem bilo kome, osim onima koji mi lično potraže pomoć, pa i tada to činim nerado, jer se sve to odražava na moju štetu. Iz tog razloga ne bih da ulazim u polemiku oko tehničkih detalja, jer vidim da ste Vi njima ovladali i da sam Vas pogrešno procenio, kao nekog kome bi moja pomoć nešto značila.

Što se tiče "swager-a" i ostalog u vezi API sa PURS-ovog sajta, stavio sam tačku na to još u septembru prošle godine (2021.) i osim slanja sve drugo funkcioniše sa PURS-om. Možda ću i to rešiti onog momenta kad im programeri prestanu s izmenama, koje su toliko česte, da se dovodi u pitanje 01.05.2022. i početak rada eFaktura tog dana. Sve ove informacije imam od tehničkog tima posrednika s kojim radim, pa se trenutno uopšte ne angažujem oko toga.

Vašu želju za odlazak na "swager" portal PURS-a sam realizovao još u septembru 2021., barem 100-tinak puta i kao što rekoh sada više nemam vremena za to. Želim Vam što pre da zavšite Vašu implementaciju.

Moj pozdrav, dragom kolegi @vbbojan-u!
[ vbbojan @ 05.04.2022. 17:16 ] @
@zoranix - Hvala puno na izdvojenom vremenu, informacije koje sam dobio su dragocene - štede vreme i živce.

Možemo konstatovati da implementacija ovoga "čuda tehnike" ne bi bila nikakav problem da majstori koji ovo prave za PURS rade svoj posao profesionalno.

Ako bude bilo nekog progresa, javljam.
[ dragancesu @ 06.04.2022. 07:47 ] @
(Moj - eRačun i Kancelarko su možda dobro rešenje, ne znam koje su im tarife ali koji su krenuli sa njima kažu da su korektni, u najavi je još posrednika

kao i mnogo puta do sada, na papiru deluje jednostavno ali se iskomplikuje na neki bezvezan način
primeri sa sajta rade, napravim slično, prođe kontrolu, ne prođe u onom demo sistemu! i šta raditi?

ovi posrednici omogućavaju prihvat podataka u dogovorenom formatu i šalju dalje, onaj deo sa PURS oni odrađuju
cena je po broju faktura, izlaznih i ulaznih

možda se neko neće složiti sa mnom, ovo je moje mišljenje


[ zoranix @ 06.04.2022. 08:27 ] @
Usluge posrednika se naplaćuju, koliko i kako, ne bih o tome, jer je taj deo pokriven poslovnom tajnom.

Ono što svi zaboravljaju je uključenje usluge čuvanja faktura. To korisnike oslobađa obaveza u slučaju da pogube fakture iz ranijih perioda i za to plate kaznu, koja je veća nego usluga čuvanja za to vreme. Svi znamo šta se događa u slučaju virusa, greške u hardveru, ili otkaza opreme. Pošaljete disk na servis, ili na proveru, a oni Vam ga vrate formatiran bez ičega na njemu, a Vi ste samo mislili da pogledaju da li je sve u redu s njim.

Osim ovoga posrednik pribavlja i podatke (PIB-ove, telefone, kontakte, e-mail adrese....) učesnika u prometu faktura i razmenjuje ih sa korisnicima. Njihova služba za kontakt i podršku korisnicima je mnogobrojna i stalno dostupna.
S programerske strane napravite XML, smestite u njega originalni račun u PDF, napravite razmenu putem API-ja i mislite sada je gotovo! Nije.
Problemi tek počinju, i ako je sve ispravno urađeno. Nedostaju e-mail adese za kupce, nema ubačenih PIB-ova, ili su netačni, ima nekih znakova u nazivima koji "kvare" XML, pa ne prolazi... Mislite da će to Vaši korisnici sami rešiti? Neće, i ako mogu!
Odmah Vas zovu da pogledate o čemu se radi i uvek sumnjaju na Vaš softver, i ako se posle par meseci pokaže da ni jednom nije bilo problema u softveru, ipak ostaje sumnja koja se ne retko završi nerazumevanjem problema. Sve ovo govorim iz iskustva.

O svemu ovome na sajtu PURS-a ne možete ništa da pročitate, osim što ćete u sekciji za programere odgledati nekoliko prezentacija, (vebinara) na osnovu kojih ništa ne možete zaključiti, gde možete videti da su njihovi developeri u haosu i da nemaju odgovore na postavljena pitanja. To sa posrednicima nije slučaj...
S druge strane imate eFiskalizaciju, koja je u startu maestralno urađena sa tehničke strane. Kao da je PURS bacio akcenat na eFiskalizaciju, a eFakture zapostavio, da li je tako?

Sve me navodi na to da poverujem u to da su PURS-ove eFakture zapostavljene:
• ne odgovaraju na pozive;
• ne odgovaraju na mejlove, ili ako odgovore to bude zakasnelo;
• nemaju specifikaciju UBL standarda koja odgovara našoj (srpskoj) implementaciji, na koju se pozivaju izbacivanjem pojedinih UBL XML tagova, pa ne znate da li su svi UBL XML tagovi podržani, ili ne;
• nemaju forume sa otvorenim diskusijama o problemima;
• nemaju programske primere na zastupljenijim programskim jezicima za rad sa njihovim API-ima....
• često menjaju zahteve i API, a da ne govorimo o problemima usklađenosti UBL XML srpskog standarda sa zakonskom regulativom, gde neke stvari, poput odobrenja, ili zaduženja, koja su oporezovana i koja su na nivou fakture, a ne na nivou stavke nemaju uporište u srpskoj verziji UBL-a.

Sve ovo samo otežava "stvar" i posrednicima, ali i programerima. Posrednici preko "burazerskih" kanala ipak dođu nekako do PURS-ovih programera i razmene informacije, ali mi smrtnici nikako, osim ako nismo iz Beograda i ako nam komšija, ili stariji (mlađi) brat ne radi u PURS-ovom programerskom timu.

Eto muke i jada.
[ bokinet @ 06.04.2022. 10:20 ] @
@zoranix eFiskalizacija nije maestralno odradjena. Radovi i dalje u toku. Onaj ko od pocetka prati to zna sta je sve (bio) problem.
Dodatno oko eFiskalizacije,
PURS nema svoj razvojni tim vec su angazovali (citaj platili i kupili resenje od) DTI gde se dobar deo tehnicke podrska posebno na L2 i dubljem nivou zavrsava sa ljudima iz DTI a ne sa podrskom PURS.
[ zoranix @ 06.04.2022. 11:44 ] @
Ne bih sada o eFsikalizaciji @bokinet. Po mom mišljenju, koje i dalje zadržavam, bolje urađena eFiskalizacija, nego eFakture.

Ako to nije PURS-ov tim, koji oni plaćaju i s kojim najverovatnije imaju obligacioni ugovor o tom poslu, onda ne znam čiji je! Po svoj prilici deluje da je ničiji... Ne radi se ovako posao, barem ga ja za ovih 35. godina rada tako nikada nisam radio.

Amaterizam!