E-fakturisanje Fawtara u Omanu 2027: šta treba ERP i POS sistemima po meri

Oman zamenjuje papirne i PDF fakture strukturiranim XML e-fakturama koje prolaze kroz akreditovanog pružaoca usluga i prijavljuju se Poreskoj upravi Omana (OTA). Program se zove Fawtara. Obveznici sa godišnjim prometom većim od 5 miliona OMR počinju 1. aprila 2027. Svi ostali obveznici registrovani za PDV počinju 1. oktobra 2027.

Najteže pogađa maloprodaju. Prodaja potrošačima obuhvaćena je od istog dana kao i prodaja firmama, a svaka pojedinačna prodaja traži sopstvenu e-fakturu. Ako su vaš softver za kase, ERP ili billing engine razvijeni u kući ili jako prilagođeni, posao proizvodnje tih dokumenata je vaš.

Datumi i koji se odnosi na vas

Izvor su pitanja i odgovori o Fawtari OTA-e, poslednji put ažurirani 31. avgusta 2026. Kriterijum je jasno postavljen. Primenjujete od 1. aprila 2027. ako važi bilo šta od sledećeg:

• vaš promet od 1. aprila 2026. do 31. marta 2027. premašuje 5.000.000 OMR, ili
• vaš očekivani promet od 1. aprila 2027. do 31. marta 2028. premašuje 5.000.000 OMR.

„Ako nijedan uslov nije ispunjen, dužni ste da uvedete e-fakturisanje od 1. oktobra 2027."

Šta ulazi u iznos: oporezivi promet bez osnovnih sredstava, robe i usluga po mehanizmu obrnutog obračunavanja i prometa unutar GCC-a. PDV grupa se procenjuje na nivou grupe, a ne član po član. Nerezident računa samo promet ostvaren u Omanu.

Obratite pažnju na drugi uslov. Firma koja raste ka 5 miliona OMR može da završi u aprilskoj grupi samo na osnovu svoje projekcije. Ako ste blizu granice, pretpostavite april.

OTA nudi alat za proveru faze uvođenja koji uzima vaš VATIN i vaš trenutni i očekivani raspon prometa i prikazuje mogući period primene. Označen je kao alat samo za informisanje i pripremu, pa njegov odgovor tretirajte kao smernicu, a pitanja i odgovore kao pravilo.

Raspored je već jednom pomeren

HTML stranica sa pitanjima i odgovorima same OTA-e i dalje opisuje stariji plan: sto velikih kompanija od avgusta 2026, sve velike kompanije od februara 2027, svi ostali od avgusta 2027. PDF te datume zamenjuje aprilom i oktobrom 2027. Za prvu grupu odabranih velikih obveznika (Rollout 1) avgust 2026. ostaje zvanični datum početka rada, sa prelaznim periodom do kraja oktobra 2026. u okviru pilota.

Jedna rečenica u odeljku PDF-a o vremenskom planu kaže da obavezna primena iznad 5 miliona OMR važi od „April 1st 2026". Sve ostalo u istom dokumentu kaže 1. april 2027, uključujući detaljan odgovor o obuhvatu naveden iznad. Liči na omašku, ali je dobar razlog da se radi prema primarnom dokumentu, a ne prema nečijem sažetku, uključujući i naš.

Kako Fawtara radi

Fawtara radi na Peppolu, po modelu sa pet uglova:

1. Ugao 1: vi, prodavac, izdajete fakturu.
2. Ugao 2: vaš akreditovani pružalac usluga (ASP) je validira prema omanskim pravilima i prosleđuje dalje.
3. Ugao 3: pružalac usluga kupca je prima.
4. Ugao 4: kupac.
5. Ugao 5: OTA, koja od pružalaca usluga prima poreske podatke.

Format je XML, napravljen po specifikacijama PINT Oman koje objavljuje OpenPeppol (Billing Process verzija 1.0.1 u trenutku pisanja). Pitanja i odgovori bez okolišanja kažu da „PDF faktura nije e-faktura". I dalje možete štampati na papiru, ali za poreske svrhe važeća je samo e-faktura.

Tri detalja iz pitanja i odgovora oblikuju inženjerski posao:

• Pružalac validira, odgovornost ostaje vaša. ASP svaku fakturu proverava prema omanskim schematron pravilima, ali „odgovornost za usklađenost fakture ostaje na obveznicima".
• Istovremeno ste povezani sa jednim pružaocem. Vezu tražite preko portala Fawtara, a kasnije možete da promenite pružaoca.
• Ne postoji standardni API za obveznike. Rečima iz pitanja i odgovora, povezivanje obveznika „nije standardizovano i razlikovaće se u zavisnosti od sistema pružaoca usluga". Vaš ERP komunicira sa interfejsom vašeg pružaoca, a ne sa OTA-om.

Kada je kupac potrošač ili firma koja još nije na mreži, vaš pružalac i dalje prijavljuje poreske podatke OTA-i, a kupac dobija fakturu kao i danas. Izvoz ide od vas do vašeg pružaoca i do OTA-e.

Ko je već pokriven

Ako je dobavljač vašeg ERP-a ili POS-a i sam akreditovani pružalac, ili isporučuje konektor ka nekom, najveći deo ovog teksta nije vaš problem. Pitanja i odgovori kažu da ERP sistemi „mogu da se zadrže u skladu sa dogovorom koji obveznici imaju sa svojim akreditovanim pružaocima usluga", a kod gotovog sistema taj dogovor treba da isporuči dobavljač. Vaš posao su matični podaci i testiranje.

Mogli biste i sami da postanete pružalac usluga. Kriterijumi za akreditaciju obuhvataju omansku registraciju privrednog društva sa IT delatnostima, minimalni uplaćeni kapital, istoriju poslovanja i ISO/IEC 27001 sertifikat, a pitanja i odgovori dodaju i prolazak kroz test pakete Peppol eDelivery i PINT OM. To odgovara softverskim kompanijama. Za trgovca na malo nije prečica.

Ovaj tekst je za sve ostale: kompanije čije fakture izlaze iz ERP-a po meri, iz kasa sistema razvijenog u kući, iz billing enginea nakalemljenog na staru bazu podataka ili iz poslovnice koja fakture još piše ručno.

Šta mora da se promeni u vašem softveru

Mapirajte podatke o fakturi na PINT Oman

Uputstvo o mapiranju u pitanjima i odgovorima staje u jedan red: koristite omanske specifikacije PINT. U semantičkom modelu najveći deo truda odlazi na polja specifična za Oman (sa prefiksom BTOM):

• UUID za svaki dokument (BTOM-002). Mora da bude RFC 4122 verzija 5, koja se izvodi iz imena. Izvedite ga iz nečeg stabilnog, kao što su pravno lice, poslovnica, kasa i broj dokumenta, pa će ponovljeno slanje proizvesti isti UUID umesto druge fakture.
• Vrsta transakcije na fakturi (BTOM-001). To je niz od 20 pozicija u kome je svaka pozicija oznaka: puna poreska faktura, pojednostavljena poreska faktura, samofaktura, faktura u ime trećeg lica, izvoz, pretpostavljeni promet, obrnuto obračunavanje pri uvozu usluga, oporezivanje marže, e-trgovina, uvoz robe, promet u posebnoj zoni, avans i druge. Može biti postavljeno više oznaka. Vaš sistem mora da zna koje se odnose na svaku fakturu, a većina ERP sistema to nikada nije čuvala.
• Identifikatori prodavca i kupca sa šifrom šeme: registracija privrednog društva, poreski identifikacioni broj, lična karta, pasoš, carinski ID uvoznika ili broj licence za posebnu zonu.
• Valuta. Valuta fakture, valuta PDV obračuna, kurs između njih i ukupan PDV u valuti obračuna imaju sopstvena polja.
• Šifarnici za oslobođenje od PDV-a, razloge za nultu stopu, vrste usluga i administrativne jedinice.

Očekujte da se stavke fakture mapiraju čisto, a matični podaci ne. Zapisi o kupcima bez VATIN-a, nedostajući CR brojevi, razlozi oslobođenja u slobodnom tekstu i adrese bez šifre regiona moraju da se srede pre prve fakture u stvarnom radu.

Tretirajte svaku prodaju kao dokument

Ovo je pravilo koje menja POS sisteme: „Zbirne fakture nisu dozvoljene za B2C transakcije. E-faktura mora da se izda posebno za svaku fakturu." Nema dnevnog preseka. Prodavnica koja otkuca 3.000 prodaja dnevno šalje 3.000 e-faktura dnevno.

Pitanja i odgovori za B2C slanje daju 24 sata, a za B2B slanje stvarno vreme. Za kasu to znači:

• POS pravi XML (ili prodaju predaje servisu koji ga pravi) u trenutku prodaje, sa njegovim UUID-om. Za B2C postoji posebno polje za UUID računa (BTOM-004).
• Red tipa „sačuvaj i prosledi" drži dokumente kada mreža ili pružalac ne rade i prazni se u okviru 24 sata.
• Neko dobija upozorenje kada je dokument i dalje neposlat posle nekoliko sati, a ne posle dvadeset tri.

Pre potpisivanja uporedite cene pružaoca sa svojim obimom. Pitanja i odgovori kažu da svaki pružalac sam određuje model, koji „može da obuhvati pretplate, naknade po transakciji ili druge cenovne aranžmane". Pri maloprodajnom obimu naknada po dokumentu je stavka u budžetu.

B2B u stvarnom vremenu

Za poslovne fakture slanje je u stvarnom vremenu. Vaš ERP knjiži fakturu, pružalac je validira i rezultat se vraća. To menja tok fakturisanja na dva načina. Greške u validaciji sada isplivavaju u trenutku knjiženja, pa nekome u finansijama treba ekran koji prikazuje odbijanje i omogućava ispravku. A numeracija faktura, UUID i logika ponovnih pokušaja moraju da budu ispravni od prvog dana, jer timeout praćen slepim ponovnim slanjem je upravo način na koji nastaju duplirane fakture.

Tok ide i u drugom smeru. Kada ste kupac, e-fakture dobavljača koji su već na Fawtari stižu preko vašeg pružaoca kao XML, a službi obaveza prema dobavljačima treba način da ih preuzme.

QR kodovi na odštampanom računu

QR kod generišete vi (ugao 1), a ne pružalac. Obavezan je za sve B2C transakcije, pune ili pojednostavljene, i pojavljuje se na fakturi čitljivoj ljudima, a ne u XML-u. OTA planira da ga koristi za proveru faktura preko mobilne aplikacije. Za njegov sadržaj pitanja i odgovori upućuju na Dodatak D dokumenta Peppol Oman Architecture (verzija 1.0.2): pribavite taj dodatak pre nego što iko preradi izgled računa. Šabloni računa i drajveri štampača su deo ovog projekta.

Knjižna odobrenja, povraćaji i ispravke

Izdata e-faktura se koriguje izdavanjem elektronskog knjižnog odobrenja ili zaduženja. Specifikacija ima polja za UUID izvorne fakture i šifru razloga (BTOM-031 i BTOM-032), pa povraćaj novca na kasi mora da može da pronađe izvornu prodaju.

Uvoz i samofakturisanje

Uvoz robe i usluga prijavljuje se kao samofaktura. Ako vaš tok nabavke knjiži uvoz bez izdavanja ikakvog dokumenta, tu se pojavljuje novi korak.

Arhiviranje

Čuvanje ostaje vaše. Pitanja i odgovori kažu da OTA obveznicima neće vraćati podatke o fakturama, a Peppol ne čuva dokumente. Validirani XML, odgovor pružaoca i odštampanu verziju čuvajte zajedno, po pravilima o čuvanju iz propisa o PDV-u.

Plan unazad od roka

Pitanja i odgovori kažu da OTA kontaktira učesnike faze uvođenja najmanje šest meseci pre njihovog uključivanja. Za aprilsku grupu, to je sada.

Ako počinjete 1. aprila 2027:

1. Oktobar 2026: potvrdite svoju grupu alatom za proveru i kriterijumom iz pitanja i odgovora. Navedite svaki sistem koji izdaje fakturu: ERP, svaki POS, proces plaćanja u e-prodavnici, naplatu zakupa ili pretplata i svaku knjigu ručnih faktura.
2. Novembar 2026: izaberite pružaoca. Pre potpisivanja tražite API dokumentaciju i sandbox i pitajte za B2C obim, cenu po dokumentu, rad bez veze i izgled odgovora validacije. Vezu zatražite preko portala Fawtara.
3. Od decembra 2026. do januara 2027: izrada. Mapiranje polja, generisanje UUID-a, logika vrste transakcije, red na POS-u, QR kodovi, tok knjižnih odobrenja, ulazne fakture. Omanska schematron pravila iz paketa za preuzimanje PINT Oman pokrećite u sopstvenom test pipelineu, kako bi se greške pojavile u razvoju, a ne kod pružaoca.
4. Februar 2027: testovi od početka do kraja na sandboxu pružaoca, sa stvarnim primerima svake vrste transakcije koju zaista izdajete, uključujući i nezgodne (izvoz, povraćaj bez računa, strana valuta).
5. Mart 2027: proba u produkciji sa jednom poslovnicom ili poslovnom linijom, plan prelaska i raspored podrške za prve nedelje.

Ako počinjete 1. oktobra 2027, redosled je isti, pomeren za šest meseci: pružalac izabran do kraja prvog kvartala, izrada u drugom, testiranje završeno do avgusta. Ne trošite rezervu. Čišćenje podataka uvek traje duže nego što iko proceni.

Šta je još neizvesno

Datumi su se jednom pomerili i mogu ponovo. Planirajte prema PDF-u od 31. avgusta 2026. i proveravajte dokumente OTA-e svakog meseca, umesto da se oslanjate na vesti. Pravni osnov je Odluka 189/2026, kojom se menja Izvršni pravilnik uz Zakon o PDV-u. Pitanja i odgovori kažu da će se kazne primenjivati po propisima o PDV-u kada obaveza počne, ali ne navode iznose, pa ih ne navodimo ni mi.

I specifikacije imaju verzije. Aktuelni paket PINT Oman na sajtu Peppola nosi datum izdanja 29. jul 2026. Fiksirajte verziju prema kojoj gradite i pratite napomene uz izdanja.

Gde potražiti pomoć

Gradimo konektor između sistema koji zaista koristite i formata koji obaveza traži: mapiranje polja, logiku UUID-a i numeracije, redove na POS-u, validaciju u vašem pipelineu i integraciju sa pružaocem koga izaberete. Naša usluga integracije e-fakturisanja pokriva taj posao, a kada je prepreka sam ERP, modernizacija ERP-a je mesto odakle se počinje.

Ako ste u aprilskoj grupi i još niste izabrali pružaoca, pišite na office@c9group.dev.