GS1 - Globalni jezik poslovanja
The Global Language of Business

Elektronski račun v praksi

Elektronski račun je podatkovna struktura, ki omogoča preslikavo in prenos podatkov o računih med poslovnimi partnerji.

Elektronski račun je eden od pomembnejših elektronskih dokumentov, a ga je zaradi svoje kompleksnosti, raznolikosti in pravno-finančnih zahtev težko integrirati v svoje poslovno okolje. Prava funkcionalnost elektronskega računa se izkaže takrat, ko lahko posamezne postavke računa povežemo ("po parih") s predhodnimi poslovnimi dokumenti: naročilnico, dobavnico, prevzemnico ... . Takrat je proces najzanesljivejši in najhitrejši.

Vsakič, ko v proces elektronskega poslovanja dobimo dodatne operacije, kot so različne kontrole, poizvedbe, potrdila, priloge sporočil, obdelave, ..., je del funkcionalnosti računa izgubljen. Zato je pomembno, da je podatkovna struktura elektronskega računa dovolj bogata, da lahko vanjo umestimo tudi najbolj kompleksne račune, a hkrati dovolj enostavna, da je programersko, človeško in procesno obvladljiva.

V poslovnem svetu se uporablja več rešitev; vsaka je dobra za nekatere in nezadostna za druge procese. Zelo težko je predpisati en standard, en protokol, eno rešitev v svetu, polnem raznolikosti, dinamike, ki zahtevajo hitre spremembe in prilagoditve. Še težje pa je narediti sistem, ki je dober tako za velike poslovne sisteme kot za male nezahtevne uporabnike. V GS1 trdimo, da imamo prav takšen sistem.


Elektronsko poslovanje je eden od temeljev sistem standardov GS1. Sistem sestavljata dva standarda: 

Vsak od navednih standardov vsebuje vse možne poslovne dokumente (naročilnico, dobavnico, …) in seveda tudi račun. Oba omogočata večsektorsko uporabo, kar pomeni da nista omejena zgolj na procese O2C (Order to cashOd naročila do računa), temveč podpirata tudi vse ostale procese, kot so logistika, finance, planiranje … Poglej primere eRačunov v GS1 XML (BMS)

Kaj pa je format eSlog?

eRačun v GS1 XML (BMS)

Elektronski račun je lahko enostaven, vendar je praviloma zelo kompleksen dokument. Zato mora podatkovna struktura GS1 podpirati vse elemente tako v podatkovni bazi kot v elektronskem sporočilu oziroma pripadajoči shemi. Podatkovne baze oziroma programska oprema za izdajo računov je praktično brez izjeme dodelana tako, da zadošča zakonskim pogojem, posledično pa vsebuje vsa ustrezna podatkovna polja. A pri elektronskih sporočilih je zahteva mnogo večja, saj morajo zadostiti potrebam zelo različnih poslovnih procesov, zakonodajam v različnih državah, jezikovnim specifikam in podobno.

Zato so sheme elektronskih sporočil vedno mnogo širše kot so naše dejanske potrebe. Posledično potrebujemo lokalizirana navodila, prilagojena domačim razmeram, kar je eno od del in nalog nacionalnih organizacij GS1.

Zaradi kompleksnosti računa in njegovih možnih oblik smo vam pripravili navodila po tipih računov.

S pojmom "elementarni" smo označili najenostavnejši račun brez vsake posebnosti. Pri enostavnih oblikah poslovanja je večina računov takega tipa, kjer obračunavamo blago ali storitve, zaračunamo davek in določimo pogoje plačila.

V nadaljevanju je na voljo primer, ki ima naslednjo vsebino:

Primer prikazuje preslikavo tega računa v XML in nekatera pravila, ki pri tem veljajo.


Kartični račun: Primer 0

PDF

XLS

XML

BMS-Invoice-Primer-0_v1

GS1-BMS-Primer-0-Racun

GS1_MIG_Invoice_Primer-0

 

Račun, s katerim obdelamo nakupe s kreditno kartico oziroma neko drugo vrsto kartice zaupanja, je praviloma zbirni račun, ki ga pošiljamo periodično. Na njem moramo obdelati vse dogodke po datumu in kraju, zato je njegova struktura precej bolj zahtevna, kot pri običajnem računu.

Vidimo, da ima ta račun vedno zbirni del, v katerem se določi zbirne vrednosti posameznih postavk.

Poleg tega mora struktura računa predvideti, da ima prejemnik več nosilcev kartic - pri istem podjetju je več uporabnikov te vrste kartic, podjetje pa od izdajatelja kartic vsak mesec dobi račun za vse dogodke pri vseh nosilcih katice.

Struktura ima torej več možnih oblik, definitivno pa ima več dimenzij.

Med obdelanimi primeri v dokumentaciji je nekaj od možnosti, ki jih lahko uporabimo. Kot uporabnejši model, priporočamo Primer 1C.


Kartični račun: Primer 1

PDF

XLS

XML

BMS-Invoice-Primer-1A_v1

GS1-BMS-Primer-1A-KarticniRacun

GS1_MIG_Invoice_Primer-1A

GS1_MIG_Invoice_Primer-1A_DespatchAdvice

BMS-Invoice-Primer-1B_v3

GS1-BMS-Primer-1B-KarticniRacun

GS1_MIG_Invoice_Primer-1B

BMS-Invoice-Primer-1C_v1

 

GS1_MIG_Invoice_Primer-1C-GlavniRacun

GS1_MIG_Invoice_Primer-1C-Specifikacije

BMS-Invoice-Primer-1D_v1

GS1-BMS-Primer-1D-KarticniRacun

GS1_MIG_Invoice_Primer-1D-GlavniRacun

GS1_MIG_Invoice_Primer-1D-Specifikacije

Veleprodajni račun je tip računa, kjer partnerja uporabljata s pogodbo dogovorjene nakupne pogoje. Na vsakem računu morajo biti izpostavljeni številka pogodbe, številka dobavnice in nekateri podatki iz dobavnice (kraj dobave, ime prevzemnika ...). 

Pomembna razlika med enostavnim in veleprodajnim računom je v specifikaciji pogodbe ter natančni referenci na dobavnico, za katero velja ta račun. V poslovni praksi ni nobena redkost, da se račun nanaša na več dobavnic, se pravi, da se posamezne postavke nanašajo na različne dobavnice. Takemu računu pravimo zbirni račun in se običajno uporablja enkrat na mesec oziroma periodično. Pri zbirnih računih so tudi vmesne - sintetične - zbirne postavke, ki omogočajo natančnejšo specifikacijo računa.

V nadaljevanju so primeri za tri tipe veleprodajnega računa:

  • Običajni veleprodajni račun
  • Zbirni veleprodajni račun z zbirnimi postavkami
  • Zbirni veleprodajni račun brez zbirnih postavk

Veleprodaja: Primer 2

PDF

XLS

XML

BMS-Invoice-Primer-2_v1

GS1-BMS-Primer-2-VeleprodajniRacun

GS1_MIG_Invoice_Primer-2A

BMS-Invoice-Primer-2B_v1

GS1-BMS-Primer-2B-VeleprodajniZbirniRacun

GS1_MIG_Invoice_Primer-2B

BMS-Invoice-Primer-2C_v2

GS1-BMS-Primer-2C-VeleprodajniZbirniRacun

GS1_MIG_Invoice_Primer-2C

Pri dobavi plina je obdelanih nekaj scenarijev, pri katerih dobavitelj plina periodično ali po potrebi dobavlja plin drugemu podjetju na več njegovih odjemnih mest, nato pa periodično izstavlja račun za dobavo v časovnem intervalu.

Takšen račun je razmeroma kompleksen, saj vsebuje specifične podatke o dostavah - odjemnih mestih, številke števcev, različne postavke...

Račun vsebuje tudi zbirne postavke, ki vsebujejo dobavljene kumulative oziroma vsoto vrednosti za vsako nastopajočo postavko.

Seveda imajo taki računi več možnih scenarijev, a med primeri sta obdelana samo dva: prvi za posamezno merilno mesto, drugi za več merilnih mest.


Obračun plina: Primer 3

PDF

XLS

XML

BMS-Invoice-Primer-3A_v1

GS1-BMS-Primer-3A-MerilnoMestoPlin

GS1_MIG_Invoice_Primer-3A-Varianta1

GS1_MIG_Invoice_Primer-3A-Varianta2

BMS-Invoice-Primer-3B_v2

GS1-BMS-Primer-3B-MerilnoMestoPlin-ZbirniRacun

GS1_MIG_Invoice_Primer-3B

Račun za elektriko ima gotovo eno najbolj zahtevnih struktur med vsemi računi. Vsebuje ločene podstrukture, vmesne vsote, hierarhične specifikacije postavk (podpostavke) in lahko tudi zbirni del. Vsebuje lahko več vrst davkov, več merilnih mest, več števcev pri posameznem merilnem mestu...

Prednosti standarda GS1 XML so prav tukaj izrazite, saj je preslikava tudi tako kompliciranega računa v elektronsko sporočilo relativno enostaven poseg.

 

Med primeri je za sedaj obdelan en scenarij računa za električno energijo, ki ima naslednjo obliko:


Obračun električne energije: Primer 4

PDF

XLS

XML

BMS-Invoice-Primer-4A_v2

GS1-BMS-Primer-4A-Elektrika

GS1_MIG_Invoice_Primer-4A

Na žalost je tako, da marsikateremu računu sledi še en, še bolj nezaželen: račun za obresti. Ta račun ima specifične postavke, v katerih se referencira na neplačane račune in na časovne intervale, v katerih velja ista obrestna mera.

Struktura računa je zato nekoliko specifična:

Na računu, kot je obdelan v primerih, velja scenarij, da je na istem računu za zamudne obresti lahko vključenih več računov, na katere zaračunavamo obresti. To pomeni, da je številka zamujenega računa del postavke.


 

Obračun zamudnih obresti: Primer 5

PDF

XLS

XML

BMS-Invoice-Primer-5A_v3

GS1-BMS-Primer-5A-Obresti

GS1_MIG_Invoice_Primer-5A

GS1_MIG_Invoice_Primer-5A2.xml

Format eSlog

V Sloveniji se trenutno največ uporablja format e-računa eSLOG, ki temelji na standardu GS1 EANCOM in se vanj lahko tudi (bolj ali manj) vedno preslika nazaj. 

Z lanskim letom je postala obvezna različica 2.0. Ta je mnogo bolj univerzalna kot je bila prejšnja različica 1.6, ki je imela veliko funkcionalnih in vsebinskih pomanjkljivosti. Različica 2.0 je v osnovnih dokumentih (vse razen računa) najverjetneje 100% skladna s standardom GS1 EANCOM (vendar validacija te združljivosti ni bila narejena). Izdelava specifikacij za račun pa je narejena na osnovi EDIFACT, kar tudi zagotavlja večinsko združljivost z GS1 EANCOM razen nekaterih specifičnih podatkovnih elementov.

Več o eSLOG 2.0 je na straneh Gospodarske zbornice, Center za elektronsko poslovanje.

Od naročila do računa

Najpogostejši poslovni proces poteka od naročila preko dobave do računa. Ta postopek je seveda lahko bolj ali manj kompliciran, odvisno od natančnosti dogovora med posameznimi partnerji.

Najbolje je, če vse teče brez posredovanja človeka, kar ni nek abstraktni ideal, temveč dejstvo, ki ga lahko dosežemo s standardi GS1.

Naročanje je lahko samodejno, saj lahko informacijski sistem prepozna zmanjšanje zaloge in prav tako samodejno pripravi naročilo in ga odpošlje dobavitelju. Dobavitelj prejme sporočilo in informacijski sistem prav tako natančno ve, kakšni so pogoji dobave in plačila, zato lahko samodejno pošlje potrdilo naročila in podatke o dobavi, ko je blago pripravljeno. Kupec prejme dobavnico in je že pripravljen na prevzem blaga na določen dan, ob določeni uri na določenem mestu prevzema.

Ko se pošlje še potrdilo prevzema blaga, lahko dobaviteljev informacijski sistem samodejno odpošlje tudi račun.

Seveda je za takšen proces potrebna sinhronizacija podatkov o poslovnih partnerjih, prodajnih enotah in pogojih poslovanja.


Elektronsko poslovanje - od naročila do računa (brošura)
Nazaj na vrh