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)

Registered companies have a registration ID, so that is fine. Large partnerships and other unincorporated bodies in the UK have no registration number (they do not have to be registered as entities) might be registered for VAT (if their turnover is over the threshold) and any VAT registered company must put its VAT number on its invoices, so we would have a VAT number, but sole traders and individuals below the turnover threshold do not have to register for VAT and have no registration number in the UK. Yes they have a personal tax number, but that is not something that would every be disclosed to a trading party - in fact for security reasons the government tell us not to disclose it. In the UK there are no identity cards.


The overriding problem here is that what I am trying to do is to create a general system that can be used without any kind of prior agreement. It will be open source software that anyone can download and use. My motivation is purely selfish, I am fed up typing invoices into my accounting system, and as a farmer even our sales invoices are self-billed in general. I want something that is as simple to use as the paper equivalent, with similarly few rules associated with it as the paper version.


I look to the UBL standard to define these things - that way I can easily inter-operate with other implementations. That is why I care about getting everything that reasonably can be define set into UBL rather than relying on peer or "community" agreements. From my perspective the need for private agreements are an admission of failure in standardization




On Thursday, 12 October 2017 21:08:03 BST JAVEST by Roberto Cisternino wrote:

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]