Razvoj softvera: integracija turskih e-faktura sa ERP sistemima

Za razvoj softvera i poslovanje u Turskoj, ERP obično mora da podrži e-Fatura i e-Arşiv — a u nekim sektorima i e-İrsaliye — preko Uprave prihoda (GİB), najčešće putem privatnog integratora. ERP kreira dokument u formatu UBL-TR, prodavac ga potpisuje finansijskim pečatom (mali mühür), integrator ga prosleđuje GİB-u, a poreski obveznik sve vreme ostaje odgovoran za čuvanje dokumentacije.

Šta ERP mora da podrži za poslovanje u Turskoj?

Turska elektronsko fakturisanje sprovodi kao sistem kliringa: prodavac kreira dokument, šalje ga ovlašćenim kanalom, Uprava prihoda ga proverava i tek tada dokument dobija pravno dejstvo. Za kompaniju koja poslovanje vodi kroz ERP, to ima posledice na četiri tačke sistema:

• Kreiranje dokumenta. ERP — ili povezani mehanizam — mora da generiše fakture u zahtevanoj strukturi UBL-TR, sa šiframa, identifikatorima strana i podacima po stavkama koje šema zahteva, a ne da štampani obrazac naknadno preoblikuje u XML.


• Digitalno potpisivanje. Dokumenti se potpisuju finansijskim pečatom izdatim poreskom obvezniku; korak potpisivanja mora da bude deo toka, uz upravljanje ključevima koje odgovara načinu čuvanja pečata.


• Dvosmerna razmena. U režimu e-Fatura, status registracije druge strane određuje vrstu dokumenta, a ulazni dokumenti — primljene fakture, odgovori i dozvoljena storniranja — moraju da se vrate u ERP sa izvornim identifikatorima, inače računovodstvo gubi vezu između sistema i zvanične evidencije.


• Arhiviranje i pronalaženje. Izdate i primljene dokumente mora biti moguće pronaći tokom zakonskog perioda čuvanja; da li ih čuva integrator, ERP ili oba sistema odluka je koju treba doneti pre puštanja u rad, a ne nakon zahteva revizije.

Jedna strukturna tačka iznenađuje timove koji se prvi put susreću sa kliringom: faktura nije završena kada je ERP odštampa. Završena je kada se razmena okonča i odgovori vrate, što znači da status fakture u ERP-u mora da obuhvati više od stanja „kreirana“ i „poslata“ — uključujući prihvaćenu, odbijenu i ispravljenu. Kompanije koje ovo preskoče na kraju meseca ručno usklađuju dve verzije istine — svoju glavnu knjigu i zvaničnu evidenciju — upravo posao koji je elektronsko fakturisanje trebalo da ukloni.

Druga tačka odnosi se na vreme. Dokumenti u sistemu kliringa nisu asinhroni na način na koji je to prilog u imejlu: odbijanje stiže dok tim još radi, a ispravka koju zahteva obično se odnosi na matične podatke, a ne na sam dokument. Projektovanje toka tako da osoba koja može da otkloni uzrok bude obaveštena odmah, umesto da ga otkrije u mesečnom izveštaju, razlika je između sistema koji radi i sistema koji zahteva stalno nadgledanje.

Razvoj softvera za e-Fatura, e-Arşiv i e-İrsaliye integraciju

Ko potpada pod koju obavezu određuju pravila i saopštenja GİB-a, koja se menjaju; pragove i sektorska određenja postavljaju nadležni organi i menjaju ih. Ispravna formulacija za kupca je proceduralna: proverite status registracije sa računovođom ili poreskim savetnikom prema važećim pravilima pre projektovanja integracije, a ne prema nekom članku — uključujući ovaj.

Opcije integracije

Model integratora zahteva jedno pojašnjenje, jer se često pogrešno razume: korišćenjem privatnog integratora ne prenose se obaveze poreskog obveznika. Integrator obezbeđuje tehnički kanal, slanje i uslugu čuvanja; pravna odgovornost za dokumente — njihovu ispravnost, izdavanje i čuvanje prema Zakonu o poreskom postupku — ostaje na poreskom obvezniku. Kada prodajna stranica integratora zvuči kao da je problem usklađenosti rešen umesto vas, pročitajte tu rečenicu još jednom.

U praksi se ova podela vidi u malim, konkretnim stvarima. Ako je dokument odbijen zato što je poreski identifikator kupca bio pogrešan u vašim matičnim podacima, sistem integratora je radio savršeno, a grešku morate da ispravite vi. Ako je faktura izdata sa pogrešnom poreskom šifrom, nijedna provera kanala vas neće spasiti. Integrator je infrastruktura; kvalitet podataka koji kroz nju prolazi interna je disciplina, a ERP je mesto gde se ta disciplina ugrađuje ili prepušta navici. Zato kupci koji porede integratore treba da provode manje vremena na spisku funkcionalnosti, a više na pitanjima koja otkrivaju ko šta radi kada nešto pođe po zlu: ko koga obaveštava, u kom formatu i koliko brzo ispravljen dokument može ponovo da se pošalje.

Koraci uvođenja i testiranje

Praktičan redosled integracije na strani ERP-a:

1. Utvrditi obim obaveza. Koji dokumenti važe za kompaniju — e-Fatura, e-Arşiv, e-İrsaliye, e-Defter — potvrđeno prema važećim pravilima sa računovođom kompanije.


2. Izabrati kanal. Većina kompanija bira privatnog integratora; pitanja pri izboru — kvalitet API-ja, dostupnost probnog okruženja, jezik i radno vreme podrške, upravljanje ažuriranjima šeme, reference — zaslužuju sopstvenu vežbu sa užim izborom.


3. Mapirati matične podatke. Kupci i njihovi poreski identifikatori, artikli, jedinice mere, valute i poreske šifre moraju da se mapiraju prema očekivanjima šeme; neusklađenosti su najveći pojedinačni izvor kasnijih grešaka.


4. Projektovati tok dokumenata. Ko šta kreira, kada se primenjuje pečat, šta se dešava pri grešci, kako se izlazni i ulazni dokumenti povezuju sa zapisima u ERP-u i kako se izdaju ispravke.


5. Koristiti probno okruženje. Obe strane nude probno okruženje; svaki tip dokumenta, svaki put greške i svaki scenario ispravke prođite kroz njega pre puštanja u rad, sa istim mapiranjem koje se koristi u produkciji.


6. Tretirati greške kao proces. Odbijanja stižu nakon slanja; neko mora da ih vidi, razume uzrok i ispravi osnovne podatke — sanduče za obaveštenja bez vlasnika način je da kompanija počne da izdaje dokumente sa zakašnjenjem.


7. Planirati arhiviranje i pristup. Gde se dokumenti čuvaju, ko može da ih pronađe i kako se na zahtev revizora odgovara u okviru perioda čuvanja.

Razvoj softvera i pitanja za savetnika u slučaju stranog vlasnika ili nerezidenta

Za kompaniju sa stranim vlasnikom ili onu koja ulazi u Tursku bez potpunog lokalnog finansijskog tima, nekoliko pitanja pripada poreskom savetniku, a ne IT projektu — odgovori određuju dizajn, zato ih postavite pre početka integracije, a ne nakon njega:

• Putanja registracije. Kako kompanija potpada pod obaveze, ko potpisuje prijave i koji predstavnik se priznaje — pitanja poreske registracije, a ne softvera.


• Organizacija pečata. Kako se za kompaniju dobija finansijski pečat i kako se organizuje njegovo čuvanje kada su potpisnici van Turske.


• Predstavnici i potpisi. Ko je ovlašćen da potpisuje koje dokumente i šta ERP mora da beleži o potpisniku za revizijski trag.


• Položaj stranog društva-kćeri. Da li se na kompanije sa nerezidentnim vlasništvom primenjuju dodatni zahtevi i kako se tretira fakturisanje unutar grupe.

Vredi odlučiti i ko je vlasnik odnosa sa savetnikom. U kompanijama u kojima finansije i IT pretpostave da je druga strana postavila pitanje, ove tačke kasno stignu do integracije — obično u nedeljama pre puštanja u rad, kada je tok dokumenata već utvrđen. Imenovani vlasnik sa obe strane i jedan zajednički sastanak pre koraka 3 uvođenja sprečavaju većinu takvih problema.

Uobičajeni problemi

Greške koje se najčešće pojavljuju u ovoj vrsti projekta i na šta svaka obično ukazuje:

• Odbijanja pri proveri. Gotovo uvek su problem mapiranja: poreska šifra, format identifikatora ili polje po stavci koje ne odgovara očekivanju šeme. Ispravite matične podatke, a ne logiku ponovnog slanja.


• Duplirana numeracija. Brojevne sekvence koje generiše više sistema ili se ponovo generišu nakon greške; numeracija mora da ima tačno jednog vlasnika i dokumentovano pravilo oporavka.


• Greške u statusu druge strane. Izdavanje pogrešne vrste dokumenta zato što je status registracije kupca keširan ili pretpostavljen; status proveravajte prema pravilima integratora, a ne prema sećanju.


• Izgubljeni ulazni dokumenti. Dokumenti su primljeni, ali nikada nisu vraćeni u ERP, pa obaveze prema dobavljačima rade sa posebnog ekrana; smer razmene deo je integracije, a ne opcioni dodatak.


• Propuštena ažuriranja šeme. Struktura se vremenom menja; odgovorna osoba mora da zna kada se promenila i kako je promena uticala na mapiranje.


• Preskočeno testiranje zbog roka. Svaki od navedenih problema je jeftiniji u probnom okruženju; pritisak pred puštanje u rad pretvara ih u incidente.

Često postavljana pitanja

Koja je razlika između e-Fatura i e-Arşiv?

e-Fatura obuhvata fakture koje se razmenjuju između poreskih obveznika registrovanih za ovaj režim, kao strukturirani dokumenti između registrovanih strana; e-Arşiv obuhvata fakture kod kojih je kupac van tog režima — maloprodaju i B2C, kao i neke B2B slučajeve — koje kupac obično dobija kao PDF generisan kroz isti zvanični lanac. Koji sistem važi za konkretnu fakturu proizlazi iz statusa registracije druge strane, zbog čega integracija taj status proverava, a ne pretpostavlja.

Da li mi je potreban privatni integrator?

Za većinu kompanija da — to je uobičajen put, a direktan kanal se opisuje kao složen i redak. Privatni integrator obezbeđuje tehnički kanal do GİB-a i uslugu čuvanja; vaše obaveze poreskog obveznika ostaju vaše. Izbor je nabavka: kvalitet API-ja, probno okruženje, podrška i upravljanje ažuriranjima šeme više odlučuju o svakodnevnom radu nego brend.

Šta je finansijski pečat (mali mühür)?

To je digitalni akreditiv poreskog obveznika koji se koristi za potpisivanje elektronskih dokumenata pre slanja; čuvanje i to ko sme da ga koristi praktična su pitanja koja treba rešiti unutar kompanije. Za timove sa potpisnicima van Turske, organizacija toga ko drži i primenjuje pečat jedna je od prvih tačaka za poreskog savetnika.

Može li bilo koji ERP da izdaje turske e-fakture?

Ne. ERP mora da generiše zahtevanu strukturu UBL-TR sa ispravnim matičnim podacima ili da bude povezan sa mehanizmom ili integratorom koji to radi; standardni izgled fakture nije dovoljan. Zato se većina kompanija povezuje umesto da izgrađuje sve iznova — pitanje za dobavljača je koje integratore podržava njegov konektor, šta mapira i gde se nalazi dokumentacija.

Kako da testiram pre puštanja u rad?

Kroz probna okruženja koja obezbeđuju i integrator i zvanična strana, koristeći isto mapiranje matičnih podataka kao u produkciji: svaki tip dokumenta, svaki put odbijanja, svaku ispravku i svaki ulazni dokument vraćen u ERP. Test tretirajte i kao probu procesa greške — neko mora da primi, dijagnostikuje i ispravi odbijanje, a ne samo da vidi zelenu oznaku.

Ko čuva fakture?

Poreski obveznik ostaje odgovoran za čuvanje prema Zakonu o poreskom postupku; integrator obično obezbeđuje tehničko čuvanje, a mnoge kompanije dokumente čuvaju i u ERP-u za svakodnevni rad. Važno je odlučiti o ovom uređenju pre puštanja u rad, znati ko može da dostavi koji dokument u periodu čuvanja i testirati pronalaženje pre nego što revizor to zatraži.

Izvori i standardi

• GİB — Gelir İdaresi Başkanlığı — Uprava prihoda objavljuje pravila, saopštenja i tehničku dokumentaciju za e-Fatura, e-Arşiv, e-İrsaliye i e-Defter; važeće verzije na toj stranici imaju prednost nad svim sažetim navodima na ovoj stranici.
• Status registracije, pragove, sektorska određenja i rokove postavljaju nadležni organi i oni se menjaju; potvrdite ih sa računovođom ili poreskim savetnikom prema važećim pravilima. Ništa na ovoj stranici ne predstavlja poreski savet i za WorldwideTradeX se ne tvrdi odnos sa integratorom, partnerstvo ili sertifikacija.

Povezane stranice

Razvoj softvera · Odoo ERP za trgovinske kompanije · ERP po meri ili kao gotovo rešenje · IT revizija i konsultacije · Zatražite ponudu