[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: EU Directive towards giving EU public procurement a new Standard for e-invoices
Hi Tim I looked at BII, as you suggested. It has a fairly 'closed' data model which allows for a relatively simple calculation model. If that is what the EU Standard will define then not such an issue. I just thought the wording of the Directive was moving towards a more 'open' data model. By that I mean, it seems to suggest a syntax can vary in its data model as long as it includes X, Y, Z. So it would allow a subset A, B, X, Y, Z and subset A, B, C, X, Y, Z but not subset A, B, C, D, X, Z. If that is how it will be then a calculation model for the Standard might ignore A, B, C and D and focus purely in X and Y and if Z is irrelevant to calculations then ignore it. My warning is that if A and B are relevant to the calculation models of the first three subsets then the Standard's calculation model might not work for them. ---- Stephen D Green On 25 March 2014 10:10, Stephen D Green <stephengreenubl@gmail.com> wrote: > Thanks Tim > > I take it you think my concerns are unfounded. > > I'm still not sure. I don't get it from the Directive that they just > want something like BII. I'm thinking beyond CEN to the > end-implementers complying with the Directive (especially local > authorities and those from whom they procure, which might be more an > important aspect of this Directive than it was with BII). > > Cheers > > Steve > ---- > Stephen D Green > > > On 25 March 2014 00:48, Tim McGrath > <tim.mcgrath@documentengineeringservices.com> wrote: >> I can see where you are going with this discussion but it is based on an inaccurate premise and the assumption this is something that has not been done before. >> >> As you say the EU 'core' invoice is just that, an EU 'core' invoice. The standardization needs to happen at the European level through something like a CEN committee. >> >> There is no suggestion that we need 'core' XML schema from UBL. The EU standard invoice data model (when it is developed) will be mapped onto syntaxes such as UBL using the same methodology the same way as BII does it now. >> >> There is no problem with the current UBL Invoice schema being use this way (either 1.0, 2.0 or 2.1) as has been proven by the large number of software vendors and implementers using it for large scale implementaionts such as PEPPOL and e-PRIOR and other e-sens projects. The biggest test of any theory is when it is applied and I think we can claim that this is a proven approach. >> >> I suggest you dig deeper into the work of BII and that may explain some of the concerns you have. >> >> >> On 24/03/2014, at 11:45 PM, Stephen D Green wrote: >> >>> Of course, I always did hope that one day UBL TC might produce an >>> Invoice with just the 'core' in and nothing else - 'CoreInvoice' or >>> the like. The subset concept was always a concessionary second-best in >>> my own mind but I felt it was the only thing likely to get traction >>> other than just going with the flow and allowing invoices to be huge >>> and all-encompassing. If there were a CoreInvoice document defined by >>> the TC along the lines of the EU core it would be great (once >>> standardised) for the EU acceptable syntax list - albeit that's a >>> risky thing to say - there's no guarantee of any kind it would ever be >>> accepted onto such a list, I guess. Wouldn't it solve a lot of >>> problems though. Doesn't solve the problem of taxes being different >>> around the world for outside of EU though. Maybe a concession towards >>> a more 'universal' document appropriate to UBL would be to add the >>> extra tax entities such as are now in UBL 2.x, but little if anything >>> more than that I would hope. >>> ---- >>> >>> Stephen D Green >>> >>> ---- >>> Love the Lord your God with all your heart, and with all your soul, >>> and with all your strength, and with all your mind. >>> >>> >>> >>> On 24 March 2014 15:25, Stephen D Green <stephengreenubl@gmail.com> wrote: >>>> 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 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >>> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >>> >> >> ----------------- >> Regards >> Tim McGrath >> tim.mcgrath@documentengineeringservices.com >> Fremantle, Western Australia >> http://www.documentengineeringservices.com >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]