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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

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

Subject: Re: [ubl-comment] How an invoice references a particular version of a Party (ex Question about the BusinessCard object)

Hello Davis,
when it takes to update Party information you should normally reconcile the Party using its Tax ID or other identifier agreed with your partners.
As you are talked baout an Invoice the Tax ID is more relevant.


Il 12/10/2017 20:44, David Goodenough ha scritto:

On Thursday, 12 October 2017 19:29:48 BST JAVEST by Roberto Cisternino wrote:

> Il 12/10/2017 16:46, David Goodenough ha scritto:

> > The only remaining problem is how say an Invoice references a

> > particular version of a Party, but that is a matter for the other

> > thread I opened yesterday.


> Hello David,


> you are right, there is no version for a Party information, we have

> version only in the UBL-BusinessCard that we use to send Party information.


> So the solution is at the implementation profile level. Implementers

> (user groups) must agree a way to update Party information when it's needed.


> There are several choices for that:


> 1) Send a new UBL-BusinessCard (with a new Version)


> 2) Specify in the Invoice implementation profile specification that the

> SupplierCustomerParty information must be used as a first source for

> updating both accounting and invoicing systems. Into this case the

> recipient will be constrained to check any single invoice to see if are

> there any changes in the Party data.


> Of course the (1) is cheaper in terms of time and software efforts.


> Cheers,


> Roberto Cisternino

> UBL ITLSC, chair

The UBL-BusinessCard seems a good approach.


I suppose then you need to ask the question now the receiver of an updated UBL-BusinessCard decided which original UBL-BusinessCard it matches. I suppose that options would be things like the sending address - in my case email address or just the domain part - and then the ID/UUID. The ID is mandatory, but not constrained to be unique globally especially if the party is a sole trader or other unregistered business organization although the combination of email and ID should be unique. The UUID is optional and much more likely to be unique. The other option would be to look at the certificate chains in the signature. Ultimately the mark 1 human eyeball would have to choose, but it would be nice to automate things as much as possible.


One can not assume that a given party will always receive all updates, although if there was a defined ApplicationResponse code which meant "I can not match your Party information to one I know, please either send a BusinessCard to update the Party information or initiate a DigitalAgreement process" then it could flow automatically.



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