[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
Many thanks, Tim, I think, if I understand you correctly, I agree with you on all of your points. best regards Steve ---- Stephen D Green On 27 March 2014 02:32, Tim McGrath <tim.mcgrath@documentengineeringservices.com> wrote: > If I follow you on this, then this is not really a question for the UBL community - it is a question to the yet-to-be-established EU standards committee tasked with creating the model for european e-invoicing. > > In the broader UBL context then communities creating implementation guidelines for using UBL will design their own calculation models using the subset they require. > > However, as we expect UBL to be one of the short listed syntaxes then it is helpful to discuss opinions about the European development. To target your views more directly to the people responsible you may be also want to put your concerns to the UK Electronic Invoicing Forum and potentially (if it happens) the re-instated UK branch of the multistakeholder forum on e-invoicing. > > In my view the issue is about derivable values. Using your example, it may be that in one syntax only has A and B but these can be use to derive X. So a 'syntax' may have an extended calculation model. This does not mean it does not comply with the semantics of the standard. Nor does it mean the standard model is 'closed'. > > So I suspect the European community will end with something like option 2. But it will not be a CoreInvoice syntax - it is a core model (XML and EDI syntax independent). That will be the Standard. The policy of the Directive is to define semantics only - not syntax. Personally I believe that the majority of implementations will use the UBL 'subset' mapping of this (because it already has the greatest traction) - but no-one is going to mandate that, it will be driven by market requirements. > > On 27/03/2014, at 12:23 AM, Stephen D Green wrote: > >> Without wishing to go too far into this, two options appear obvious: >> >> 1) Standard NOT define a calculation model - but list the subsets as >> syntaxes and let their own calculation models apply >> >> - this might have some issues though which limit the achievement of >> interoperability goals between subsets >> - plus it might not be in keeping with a possible preference for >> listing standards as syntaxes rather than listing subsets >> >> 2) let there be a CoreInvoice syntax (not need for subsets) just X, Y, >> Z so that if the Standard provides a calculation model for X and Y (Z >> being irrelevant) there is no risk of any A, B, C or D appearing in >> any instances (so the calculation model always applies) >> >> >> ---- >> 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 26 March 2014 15:36, Stephen D Green <stephengreenubl@gmail.com> wrote: >>> 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 >>>>> >>>>> >> >> --------------------------------------------------------------------- >> 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]