E-računi Fawtara v Omanu leta 2027: kaj potrebujejo sistemi ERP in POS po meri

Oman papirnate račune in račune v PDF nadomešča s strukturiranimi e-računi v XML, ki gredo prek akreditiranega ponudnika storitev in se sporočajo omanski davčni upravi (Oman Tax Authority, OTA). Program se imenuje Fawtara. Davčni zavezanci z letnimi dobavami nad 5 milijonov OMR začnejo 1. aprila 2027. Vsi drugi zavezanci, registrirani za DDV, začnejo 1. oktobra 2027.

Najbolj zagrize v maloprodaji. Prodaja potrošnikom je zajeta od istega dne kot prodaja podjetjem, vsaka posamezna prodaja pa potrebuje svoj e-račun. Če so bili vaša programska oprema za blagajne, ERP ali sistem za obračun razviti v lastni režiji ali močno prilagojeni, je delo ustvarjanja teh dokumentov vaše.

Datumi in kateri velja za vas

Vir so pogosta vprašanja OTA o Fawtari, nazadnje posodobljena 31. avgusta 2026. Merilo je jasno zapisano. Uvedbo izvedete od 1. aprila 2027, če velja kar koli od tega:

• vaše dobave od 1. aprila 2026 do 31. marca 2027 presegajo 5.000.000 OMR ali
• vaše pričakovane dobave od 1. aprila 2027 do 31. marca 2028 presegajo 5.000.000 OMR.

„Če ni izpolnjen noben od pogojev, morate e-račune uvesti od 1. oktobra 2027.“

Kaj šteje v znesek: obdavčljive dobave brez osnovnih sredstev, blaga in storitev po mehanizmu obrnjene davčne obveznosti ter dobav znotraj GCC. Skupina za DDV se presoja na ravni skupine, ne po posameznih članih. Nerezident šteje le dobave, opravljene v Omanu.

Bodite pozorni na drugi pogoj. Podjetje, ki raste proti 5 milijonom OMR, lahko v aprilsko skupino pristane že samo zaradi svoje napovedi. Če ste blizu meje, računajte na april.

OTA ponuja orodje za preverjanje uvajanja, ki sprejme vaš VATIN ter trenutni in pričakovani razred dobav in prikaže možno obdobje uvedbe. Označeno je kot orodje samo za ozaveščanje in pripravo, zato njegov odgovor obravnavajte kot vodilo, pogosta vprašanja pa kot pravilo.

Časovnica se je že enkrat premaknila

Lastna stran OTA s pogostimi vprašanji v HTML še vedno opisuje starejši načrt: sto velikih podjetij od avgusta 2026, vsa velika podjetja od februarja 2027, vsi drugi od avgusta 2027. PDF te datume nadomešča z aprilom in oktobrom 2027. Za prvo skupino izbranih velikih zavezancev (Rollout 1) ostaja uradni datum začetka avgust 2026, s prehodnim obdobjem do konca oktobra 2026 v okviru pilota.

En stavek v časovnici PDF pravi, da obvezna skladnost nad 5 milijoni OMR velja od „April 1st 2026“. Vse drugo v istem dokumentu navaja 1. april 2027, vključno s podrobnim odgovorom o obsegu, navedenim zgoraj. Videti je kot spodrsljaj, je pa dober razlog, da delate po primarnem dokumentu in ne po povzetku kogarkoli, tudi našem.

Kako deluje Fawtara

Fawtara teče na omrežju Peppol po modelu petih vogalov:

1. Vogal 1: vi, prodajalec, izdate račun.
2. Vogal 2: vaš akreditirani ponudnik storitev (ASP) ga preveri glede na omanska pravila in ga posreduje naprej.
3. Vogal 3: ponudnik storitev kupca ga prejme.
4. Vogal 4: kupec.
5. Vogal 5: OTA, ki od ponudnikov storitev prejme davčne podatke.

Format je XML, zgrajen po specifikacijah PINT Oman, ki jih objavlja OpenPeppol (v času pisanja Billing Process različice 1.0.1). Pogosta vprašanja so neposredna: „A PDF invoice is not an e-invoice“, račun v PDF ni e-račun. Papir lahko še vedno tiskate, za davčne namene pa je veljaven le e-račun.

Tri podrobnosti iz pogostih vprašanj oblikujejo inženirsko delo:

• Ponudnik preverja, odgovornost ostane vaša. ASP vsak račun preveri glede na omanska pravila schematron, vendar „the responsibility for invoice compliance remains with the taxpayers“, odgovornost za skladnost računa ostaja pri zavezancih.
• Naenkrat ste povezani z enim ponudnikom. Povezavo zahtevate prek portala Fawtara in jo pozneje lahko zamenjate.
• Standardnega API za zavezance ni. Po besedah pogostih vprašanj povezava zavezanca „is not standardized and will vary depending on the service provider's system“, torej ni standardizirana in se razlikuje glede na sistem ponudnika. Vaš ERP komunicira z vmesnikom vašega ponudnika, ne z OTA.

Ko je kupec potrošnik ali podjetje, ki še ni v omrežju, vaš ponudnik davčne podatke vseeno sporoči OTA, stranka pa račun dobi tako kot danes. Izvoz gre od vas k vašemu ponudniku in do OTA.

Kdo je že pokrit

Če je vaš ponudnik ERP ali POS sam akreditirani ponudnik storitev ali dobavlja konektor do enega od njih, večina tega članka ni vaša težava. Pogosta vprašanja pravijo, da sisteme ERP „can be retained based on the arrangement taxpayers have with their accredited service providers“, torej jih je mogoče obdržati glede na dogovor z akreditiranim ponudnikom storitev, pri paketnem sistemu pa ta dogovor zagotovi ponudnik. Vaše delo so matični podatki in testiranje.

Lahko postanete tudi sami svoj ponudnik storitev. Merila za akreditacijo vključujejo omanski vpis v trgovinski register z dejavnostmi IT, najnižji vplačani kapital, zgodovino poslovanja in certifikat ISO/IEC 27001, pogosta vprašanja pa dodajajo še uspešno opravljena testna nabora Peppol eDelivery in PINT OM. To ustreza podjetjem za programsko opremo. Za trgovca ni bližnjica.

Ta članek je za vse druge: podjetja, katerih računi nastajajo v ERP po meri, v lastnem blagajniškem sistemu, v sistemu za obračun, pritrjenem na staro bazo podatkov, ali v poslovalnici, ki račune še vedno piše ročno.

Kaj se mora spremeniti v vaši programski opremi

Preslikajte podatke o računih na PINT Oman

Navodilo pogostih vprašanj za preslikavo je ena vrstica: uporabite omanske specifikacije PINT. V semantičnem modelu gre večina truda v polja, značilna za Oman (s predpono BTOM):

• UUID za vsak dokument (BTOM-002). Biti mora RFC 4122 različice 5, ki temelji na imenu. Izpeljite ga iz nečesa stabilnega, na primer iz pravne osebe, poslovalnice, blagajne in številke dokumenta, pa bo ponovna oddaja ustvarila isti UUID namesto drugega računa.
• Vrsta transakcije računa (BTOM-001). To je niz z 20 mesti, v katerem je vsako mesto oznaka: polni davčni račun, poenostavljeni davčni račun, samofakturiranje, tretja oseba, izvoz, domnevna dobava, uvoz storitev z obrnjeno davčno obveznostjo, ureditev marže, e-trgovina, uvoz blaga, dobava v posebni coni, predplačilo in drugo. Nastavljenih je lahko več oznak. Vaš sistem mora vedeti, katere veljajo za posamezni račun, večina ERP pa tega nikoli ni hranila.
• Identifikatorji prodajalca in kupca s kodo sheme: vpis v trgovinski register, davčna identifikacijska številka, osebna izkaznica, potni list, carinski ID uvoznika ali številka licence za posebno cono.
• Valuta. Valuta računa, valuta obračuna DDV, menjalni tečaj med njima in skupni DDV v valuti obračuna imajo vsak svoje polje.
• Seznami kod za oprostitve DDV, razloge za ničelno stopnjo, vrste storitev in podenote države.

Pričakujte, da se bodo vrstice računa preslikale gladko, matični podatki pa ne. Zapise o strankah brez VATIN, manjkajoče številke vpisa v register, razloge za oprostitev v prostem besedilu in naslove brez kode regije je treba počistiti pred prvim računom v živo.

Vsaka prodaja je dokument

To je pravilo, ki spremeni sisteme POS: „Consolidated invoices are not allowed for B2C transactions. An E-invoice must be issued separately for every invoice.“ Zbirni računi za B2C niso dovoljeni, e-račun je treba izdati za vsak račun posebej. Brez povzetka ob koncu dneva. Trgovina, ki na dan zabeleži 3.000 prodaj, na dan pošlje 3.000 e-računov.

Pogosta vprašanja za oddajo B2C dajejo 24 ur, oddaja B2B pa poteka v realnem času. Za blagajno to pomeni:

• POS v trenutku prodaje sestavi XML (ali prodajo preda storitvi, ki to stori), skupaj z UUID. Za B2C obstaja ločeno polje za UUID potrdila (BTOM-004).
• Vrsta za shranjevanje in posredovanje (store-and-forward) hrani dokumente, ko omrežje ali ponudnik ne deluje, in jih izprazni v 24 urah.
• Nekdo dobi opozorilo, ko je dokument po nekaj urah še vedno neposlan, ne po triindvajsetih.

Preden podpišete, cene ponudnika preverite glede na svoj obseg. Pogosta vprašanja pravijo, da vsak ponudnik določi svoj model, ki „may include subscription fees, transaction-based fees, or other pricing arrangements“, torej lahko vključuje naročnine, nadomestila na transakcijo ali druge cenovne dogovore. Pri maloprodajnih obsegih je nadomestilo na dokument postavka v proračunu.

B2B v realnem času

Pri poslovnih računih oddaja poteka v realnem času. Vaš ERP račun pošlje, ponudnik ga preveri in rezultat se vrne. To potek izdajanja računov spremeni na dva načina. Napake preverjanja se zdaj pokažejo v trenutku knjiženja, zato nekdo v financah potrebuje zaslon, ki prikaže zavrnitev in omogoči popravek. Številčenje računov, UUID in logika ponovnih poskusov pa morajo biti pravilni od prvega dne, saj časovna omejitev, ki ji sledi slepo ponovno pošiljanje, ustvari podvojene račune.

Tok teče tudi v drugo smer. Ko ste kupec, e-računi dobaviteljev, ki so že na Fawtari, prihajajo prek vašega ponudnika kot XML, oddelek obveznosti do dobaviteljev pa potrebuje način, kako jih prevzeti.

Kode QR na natisnjenem računu

Kodo QR ustvarite vi (vogal 1), ne ponudnik. Obvezna je za vse transakcije B2C, polne ali poenostavljene, in se pojavi na človeku berljivem računu, ne v XML. OTA jo namerava uporabljati za preverjanje računov prek mobilne aplikacije. Glede vsebine pogosta vprašanja napotijo na Prilogo D dokumenta Peppol Oman Architecture (različica 1.0.2): pridobite to prilogo, preden kdorkoli na novo oblikuje račun za kupca. Predloge računov in gonilniki tiskalnikov so del tega projekta.

Dobropisi, vračila in popravki

Ko je e-račun izdan, se popravi z izdajo elektronskega dobropisa ali bremepisa. Specifikacija ima polji za UUID izvirnega računa in kodo razloga (BTOM-031 in BTOM-032), zato mora vračilo denarja na blagajni znati najti izvirno prodajo.

Uvoz in samofakturiranje

Uvoz blaga in storitev se sporoča kot samofakturirani računi. Če vaš nabavni potek uvoz knjiži brez kakršnega koli dokumenta, se tam pojavi nov korak.

Arhiviranje

Hramba ostane vaša. Pogosta vprašanja navajajo, da OTA zavezancem podatkov o računih ne bo vračala, Peppol pa dokumentov ne hrani. Potrjeni XML, odgovor ponudnika in natisnjeno različico hranite skupaj, v skladu s pravili o hrambi iz zakonodaje o DDV.

Načrt nazaj od roka

Pogosta vprašanja navajajo, da OTA udeležence uvajanja kontaktira vsaj šest mesecev pred njihovo vključitvijo. Za aprilsko skupino je to zdaj.

Če začnete 1. aprila 2027:

1. Oktober 2026: s preverjevalnikom uvajanja in merilom iz pogostih vprašanj potrdite svojo skupino. Naštejte vse sisteme, ki izdajajo račune: ERP, vsak POS, zaključek nakupa v spletni trgovini, obračun najema ali naročnin in vsako ročno knjigo računov.
2. November 2026: izberite ponudnika. Pred podpisom zahtevajte dokumentacijo API in testno okolje ter vprašajte o obsegu B2C, ceni na dokument, delovanju brez povezave in obliki odgovorov preverjanja. Povezavo zahtevajte prek portala Fawtara.
3. December 2026 do januar 2027: gradnja. Preslikava polj, ustvarjanje UUID, logika vrste transakcije, vrsta na POS, kode QR, potek dobropisov, prejeti računi. Omanska pravila schematron iz paketov PINT Oman poganjajte v lastnem testnem cevovodu, da se napake pokažejo v razvoju in ne pri ponudniku.
4. Februar 2027: celoviti testi v testnem okolju ponudnika z resničnimi vzorci vsake vrste transakcije, ki jo dejansko izdajate, vključno z nerodnimi (izvoz, vračila brez računa, tuja valuta).
5. Marec 2027: generalka v produkciji z eno poslovalnico ali poslovno linijo, načrt prehoda in razpored podpore za prve tedne.

Če začnete 1. oktobra 2027, je zaporedje enako, premaknjeno za šest mesecev: ponudnik izbran do konca prvega četrtletja, gradnja v drugem, testiranje končano do avgusta. Rezerve ne zapravite. Čiščenje podatkov vedno traja dlje, kot kdorkoli oceni.

Kaj je še negotovo

Datumi so se že enkrat premaknili in se lahko spet. Načrtujte po PDF z dne 31. avgusta 2026 in dokumente OTA preverjajte vsak mesec, namesto da se zanašate na novice. Pravna podlaga je Odločba 189/2026, ki spreminja izvršilni pravilnik k zakonu o DDV. Pogosta vprašanja navajajo, da bodo z začetkom obveznosti veljale kazni po zakonodaji o DDV, zneskov pa ne navajajo, zato jih ne navajamo niti mi.

Tudi specifikacije imajo različice. Trenutni paket PINT Oman na spletni strani Peppol nosi datum izdaje 29. julij 2026. Določite različico, po kateri gradite, in spremljajte opombe ob izdajah.

Kje dobiti pomoč

Gradimo konektor med sistemom, ki ga dejansko uporabljate, in formatom, ki ga zahteva obveznost: preslikavo polj, logiko UUID in številčenja, vrste na POS, preverjanje v vašem cevovodu in integracijo z izbranim ponudnikom. Naša storitev integracije e-računov pokriva to delo, kadar pa je ovira sam ERP, se začne pri posodobitvi ERP.

Če ste v aprilski skupini in ponudnika še niste izbrali, pišite na office@c9group.dev.