OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: EU Directive towards giving EU public procurement a new Standard for e-invoices


Hi again UBL-Dev,

Related to last comments, if anyone is looking at the new Directive
for the EU for e-invoices, text approved by The EU Parliament here
[http://www.europarl.europa.eu/sides/getDoc.do?type=TA&language=EN&reference=P7-TA-2014-0198]
I get the impression UBL 1.0 Invoice might just fit but not sure about
UBL 2.x Invoice because of several entities having a possible affect
on invoice total calculations, etc, which are outside of what EU want
to call 'core'. Anyone know what I mean?

When UBL TC was working on UBL 1.0 Invoice I had some influence and I
was being charged by my public sector colleagues with keeping it
possible to have a core in the invoice such that other entities
outside the core could feasibly be ignored. As such we didn't have
much (if anything) outside the core which would affect core
calculations (taking a typical view of what such a core would be from
experience handling paper invoices). In UBL 2 there was a lot added
and I was not so much involved but I didn't know whether the 'core'
idea was getting any traction anyway, so maybe the 'core' idea with
ability to ignore non-core entities and still have an invoice which is
acceptable got broken. Now the EU seems to me to want to standardise
this type of 'core' architecture and maybe UBL 2.x doesn't fit. I
think it's a 'core' idea like the above - it mentions in arcticle 6
"The core elements of an electronic invoice are, inter alia:..." and
that 'inter alia', together with other documentation I've seen about
it, suggests the idea that the invoice can have other elements present
besides the core but the invoice is accepted because the core is
present and adheres to the Standard semantics. That last part is where
things might go wrong - the semantics might ignore anything except the
core when it comes to the calculations of totals, etc. This gives, I
think, UBL 1.0 Invoice the advantage over UBL 2.x Invoice in that it
has much less that might fall outside the core but might affect
calculations. Does that makes sense?

----
Stephen D Green


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]