[ 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!
[ caca1 @ 14.06.2022. 17:46 ] @
Od izmene na efaktura od 10.juna.2022 pri učitavanju xml eFakture na SEF javlja grešku UBLRegistrationCodeDoesNotGoodLength
Da li zna neko gde je problem ?
Pročitala sam ispravke ver. 2,4 koje su uveli ali mi neke tacke nisu jasne kao

2.4 Dodata validacija Matičnog Broja i Poreskog Identifikacionog Broja (PIB) u XML-u
Dodata je validacija Matičnog Broja (MB) i Poreskog Identifikacionog Broja kompanije (PIB) prilikom
slanja fakture putem API servisa. U novoj verziji potrebno je da podaci o Matičnom Broju i Poreskom
Identifikacionom Broju kompanije budu u skladu sa prilagođenom primenom standarda
. Iz tog razloga
potrebno je skrenuti pažnju korisnicima i sistem integratorima da usklade navedene podatke sa
prilagođenom primenom standarda.

28. Izmenjena logika kod generisanja UBL-a za matični broj budžetskih korisnika

Ako neko ovo razume i zna gde mogu da se nadju objašnjenja ili primeri neka podeli znanje.

Hvalaaaa unapred na trudu.
[ djux66 @ 15.06.2022. 06:11 ] @
Mogli su lepo da napišu da umesto JBKJS sada stavljaš matični broj u polje cac:PartyLegalEntity>cbc:CompanyID.
To sam juče provalio, uradio jednu izlaznu fakturu na demo verziji i skinuo xml pa sam video.
[ caca1 @ 15.06.2022. 09:37 ] @
Da, djux66 to je bio problem.
Korigovala sam i xml je prosao na demo. Hvala na trudu.
Kako si skinuo xml sa demo ?. Pokusavala sam da nadjem na ekranu gde se to radi ali mi nje uspelo
Pozdrav
[ zoranix @ 15.06.2022. 10:44 ] @
Što se tiče UBL elementa cac:PartyLegalEntity>cbc:CompanyID u njemu je i pre toga stajao JKBKJS i sada mora da stoji. PURS-ov SEF, čim se referencira na PIB, on može da "povuče" i JKBKJS koji je u vezi s PIB-om, što najverovatnije da čini čim dozvoljava da ga nema u pomenutom elementu.
Koliko sam ja razumeo objavljena je nova UBL specifikacija u "spec-srbdt-ext-en16931-2022-05-27_cir.pdf", a i moji "izvori" mi sugerišu da je promena u načinu zadavanja PIB-a u elementima UBL:
Party / EndpointID i
PartyTaxScheme / CompanyID

Takođe je promena u UBL elementu PaymentMeans / PaymentID, gde je ranije stajalo (model) poziv_na_broj, a sada navodno mora : (modmodel) poziv_na_broj. Dodata dakle ispred modela reč "mod", bez razmaka.

Ima tu još ponekih kozmetičkih izmena, kao što je stroga kontrola matičnog broja i njegove dužine (8, ili 13 cifara) i dr.
[ caca1 @ 15.06.2022. 12:04 ] @
U SEF_ITU_verzija od 10.06.2022_lat.pdf kao i u ranijim verzijama
u BT-47 > UBL cac:PartyLegalEntity>cbc:CompanyID pise da se upisuje mat.broj a ja, a verovatno i drugi, na osnovu primera za fakturu za javne nabavke tu smo unosili jbkjs.
A u polju
BT-46 cac:Party/cac:PartyIdentification/cbc:ID upisuje se "JBKJS:12345". Tako da se na dva mesta iste stvari upisuju, tako da meni ima logike da se u
BT-47 > UBL cac:PartyLegalEntity>cbc:CompanyID unese mat br. budzetskog korisnika.

A sto se tice PIBa u BT-48 >Party/cac:PartyTaxScheme/cbc:CompanyID upisuje se "RS123456789"
a BT-49 ><cac:Party> <cbc:EndpointID schemeID="9948">123456789
a tako je bilo i u ranijim verzijama.

Ako ima promena to nisu sproveli na primerima eFaktura tako da nam bude jasnije sta je pisac hteo da kaze.
[ djux66 @ 15.06.2022. 17:54 ] @
Citat:
caca1:
Da, djux66 to je bio problem.
Korigovala sam i xml je prosao na demo. Hvala na trudu.
Kako si skinuo xml sa demo ?. Pokusavala sam da nadjem na ekranu gde se to radi ali mi nje uspelo
Pozdrav


Uradio sam fakturu na portalu, sačekao dan pa preuzeo id i xml putem api poziva.
Mada je jednostavnije da ti neko pošalje ulaznu fakturu na demo, onda možeš na klik da preuzmeš xml direktno sa portala.
[ Riblja corba @ 14.08.2022. 22:15 ] @
offtopic
Koja se verzija faktura arhivira: pdf ili / i XML?
Obe verzije dobijam na sistemu efaktura. Za sad 2 kom mesecno i isto toliko izdam ali ce to da raste kako se blizi 2023. godina.
[ bokinet @ 16.08.2022. 23:21 ] @
Sacuvati UBL dokument posto isti sadrzi i UBL fakturu i dokument za stampu koji je najcesce u pdf formatu.
Sutra po potrebi se iz toga UBL dokumenta moze uzimati po potrebi sta treba.
[ caca1 @ 30.09.2022. 14:34 ] @
Da li je neko slao eFakturu prema KJS koja nije komercijalna transakcija (inače komerc.trans. moraju biti registrovane u CRF),
već eFakturu koja predstavlja refundaciju i ona se ne registruje u CRF.

U ispravkama 2.5 od 17.06.2022 naznačeno je da nema automatskog slanja u CRF za KJS već mora da se obeleži polje "Pošalji u CRF" ukoliko je neophodno da ide u CRF.
U tim ispravkama su navili i korekciju za API.

Ali kada se preko portala SEF učita xml on automatski obeleži polje "Pošalji u CRF" jer je u pitanju KJS a nije potrebno jer je u pitanju refundacija.
To ne može ni naknadno da se menja.

Gledala sam xml eFakture urađenih ručnim unosom na demo sa slanjem u CRF i bez slanja u CRF i nisam videla nikakvu razliku.

Da li je neko imao ovaj problem i da li ga je rešio.

Hvala unapred.
[ djux66 @ 30.09.2022. 20:05 ] @
Ja šaljem fakture koje nisu za CRF, i koristim API, jer jedino tako možeš pomoću boolean parametra da definišeš da faktura nije za CRF. Format xml-a fakture se ne menja.
Upload xml-a sa portala odmah šalje fakturu, po difoltu i u CRF, i to ne možeš da promeniš.

[ caca1 @ 01.10.2022. 07:58 ] @
Hvala djux66.
To znači da treća varijanta, učitavanje xml preko portala SEF, ne fukcioniše za eFakture prema KJS a ne treba da ide u CRF.
[ sticve89 @ 04.10.2022. 10:20 ] @
Molim za pomoc.
Nejasan mi je API poziv POST /api/publicApi/sales-invoice/ubl

mandatory polje u query-u je requestId.
Kako ja da znam koji je requestId kada sam tek napravio novu fakturu? Da li je to mozda PIB mog duznika?

Hvala.
[ Riblja corba @ 04.10.2022. 12:23 ] @
sticve89,

Pouzdan prenos podataka - strana 3.
https://www.efaktura.gov.rs/ex...irna-spec-API-2021-09-01-c.pdf

procesljaj ceo PDF, nema mnogo a bice ti jasnije.

*Nije PIB jer to ne moze bit "unique" (jedinstvena) oznaka za fakturu. Moras proveravati da li je bilo ranije sa tim brojem/oznakom.
[ sticve89 @ 05.10.2022. 09:04 ] @
Hvala @Riblja Corba
Saznao sam da requestId mora biti unique, i da za taj identifikator moram sam voditi racuna o inkrementu, tj. do mene je pod kojim ID-jem cu ga voditi (001, 002, itd ili 100-001, 100-002, itd)

Jos jedno pitanje: gde mogu naci specifikaciju obaveznih neobaveznih polja za upload izlazne fakture, avansne fakture, KO, KZ, i sl? U tehnickoj specifikaciji su opisani pozivi ka api metodama, ali nazalost nema nigde opisano skup polja, tipova polja, kardinalnosti i sl. Hvala unapred
[ faraon83 @ 13.10.2022. 19:08 ] @
Da li je moguce preko API-ja prikazati zaglavlje i stavke ulazne fakture? purchase-invoice


[ djux66 @ 14.10.2022. 09:35 ] @
Piše ti sve u tehničkoj dokumentaciji, ili odeš na https://efaktura.mfin.gov.rs/swagger/index.html

Moraš da preuzmeš ubl tj xml da ga parsiraš da bi video te detalje.
[ faraon83 @ 14.10.2022. 10:19 ] @
Znam za xml. Nadao sam se da mozda moze da se dobije json.
Hvala!
[ sticve89 @ 14.10.2022. 16:47 ] @
Da li neko zna sta moze biti ova greska prilikom uvoza izlazne xml osnovne fakture:
Error Code: VatPointDateTypeNotAllowedForChosenDocumentType / Nepoznata greška se desila. Molimo vas da pokušate ponovo.
[ jauser @ 10.12.2022. 01:08 ] @
Zna li neko kako izgleda xml kod kada jedan konačni račun zatvara više avansnih računa. Unapred hvala.
[ dragancesu @ 17.01.2023. 09:29 ] @
Pozdrav svima i molba administratorima da eFakture otvore kao novi forum, ovako je vezano za programski jezik, lično ne koristim Javu pa mi je malo bezveze da pišem ovde,
ono što nisam našao da se piše je Posebna obaveza elektronskog evidentiranja obračuna PDV-a - pojedinačna i zbirna evidencija
zaista nigde nisam našao kako pripremiti te podatke za slanje

konkretno mislim na https://www.youtube.com/watch?v=4ITY84Xlas8 na 21 minutu

objašnjeno je samo unos pojedinačno što nema mnogo smisl, zar ne može neki xml, json ili slično? i preneti sve jedenom nedeljno/mesečno
[ SASA M. @ 17.01.2023. 15:23 ] @
Meni je ovaj klip bio zanimljiv i informativan


[ dj90 @ 18.07.2023. 17:13 ] @

radim za jednu firmu i hteo sam da platim jednu uslugu u kešu da ne čekam narudžbenice, potpise itd itd pogotovo što je sitna para a treba mi što pre
i kažu mi kao svakako će ići e faktura na moju firmu pa im ti onda reci da je to plaćeno da ne plaćaju dva puta
na kraju sam odustao da ne bude neki problem

zanima me kako to funkcioniše, zašto nisu mogli da mi daju normalan račun bez e fakture

[ djux66 @ 19.07.2023. 06:19 ] @
Ne razumem, ako si hteo odmah da platiš, onda su mogli da ti izdaju avansni račun na firmu, i konačni račun sa iznosom 0 kad ti završe uslugu, sve preko sistema eFaktura (skr. SEF).
Ili ako neće keš, da ti daju profakturu, prebaciš pare i opet izdaju avansni račun pa fakturu, preko SEF-a.
Po zakonu transakcije između pravnih lica, privatnih ili državnih, moraju da se prijave na SEF elektronski, ali zakon ne zabranjuje da ti i odštampaju tu fakturu, avansni račun i sl...
Obaveza izdavanja eFakture postoji i po osnovu naplate avansa za budući promet po osnovu kojeg se izdaje elektronska faktura.
Drugo je ako rade maloprodaju, onda mogu da ti izdaju fiskalni račun sa pozivom na PIB tvoje firme, i onda ne postoji obaveza prijave na SEF.
Verovatno je u pitanju nesporazum ili žele isključivo pare da idu preko računa.
[ Crni.Beli @ 05.08.2023. 20:02 ] @
Pozdrav
Ako neko može da mi pomogne

Da li može da se kreira u excelu konekcija prema sefu gde će da prikaže izlazne ili ulazne račune u excelu fajlu.
Praktično da se napravi pregled dokumenata sa Sef-a u excelu.
( br dok , datum slanja, status, klijent ,iznos itd)
Hvala unapred
[ zoranix @ 06.08.2023. 08:23 ] @
Davno (od 2005.) ne koristim Excel, pa nisam siguran da može. Ako se ne varam negde sam pročitao da se Visual Basic - makro jezik za Excel, može dopuniti .NET tehnikom, pa pretpostavljam da onda može. Ako je tako onda se u C# može iskoristiti REST API sa sistema eFaktura.
Za to Vam potrebno znanje C#, što pretpostavljam da je možda problem. Bez C#, JavaSript i Java tehnologijom, teško da ima rešenja. Ja sam u svoj ERP integrisao API za SEF, ali i za Moj-eRačun (DocLoop) u Java SE tehnologiji uspešno, kao i uvoz (automatsko knjiženje!) eFaltura u ERP. Za sve ovo Vam je potreban projekat i "alat" kojim će te to da realizujete.
Tabelarni programi, poput Excel-a, Calc-a i sličnih, su namenjeni više struci (ekonomskoj) da mogu veoma brzo da dođu do rezultata u svom radu, sa ograničenim mogućnostima za ozbiljno programiranje.
[ Crni.Beli @ 06.08.2023. 22:25 ] @
Hvala vam na informacijama !
[ sticve89 @ 06.08.2023. 22:44 ] @
Pozdrav,
Ja sam developer, i upravo radim na dodvanju excel dodatka koji bi bio u mogucnosti da pozove sef, i dovuce i insertuje podatke u sheet koji vama trebaju. Kontaktirajte me ako ste zainteresovani da vam pomognem. pozdrav.
[ Crni.Beli @ 07.08.2023. 17:17 ] @
sticve89
Hvala na javljanju
Pošaljite mi molim vas privatnu poruku sa kontakt telefonom pošto ja nemam mogućnost trenutno da je pošaljem
[ skybeast @ 07.12.2023. 11:36 ] @
Da li ste uspeli nesto da odradite na ovu temu preuzimanja podataka o ulaznim/izlaznim fakturama u excelu_