Re: [ubl-comment] What is the recommended policy on Party data changes?

[JAVEST by Roberto Cisternino <roberto.cisternino@javest.com>]

Hello David,

Il 11/10/2017 17:43, David Goodenough ha scritto:

From time to time a business party's Party data will change. They might

get a new phone line, change their domain name, move office or merge.

This will (one hopes) be reflected in the Party data they send out

in the next UBL object they send out. The question is what does the

receiving party do about these changes.

A new address in a paper invoice or electronic one may be noted by the recipient or not at all...
This is outside of scope for UBL. Business parties should agree not only on syntax but also on semantics and process details.
A process description can mention several information, pre/post-process conditions and other business rules (semantic rules).
It could be that an invoice recipient could be mandated to check the Supplier address each time to ensure accounting systems are aligned.
Or conversely it could be part of the Billing process the exchange of a UBL-BusinessCard document to update all parties with relevant data such as addresses, financial accounts, VAT codes, so on.

 

The real question is when does a difference in Party details need

a renegotiation of the DigitalCollaboration/Agreement, and when can

they simply be accepted. Which also asks the question which identifier is

fundamental to a contracted party. Where there are formal contracts

then the contract should have defined how succession occurs, but many

business relationships have no formal contract.

a DigitalAgreement needs to be renegotiated when a new Process/Transaction is added or existing are changed (e.g their version)
Normally it could means a ProfileID or a CustomizationID is changed.

 

It is of course important to make sure that a business relationship is

not hijacked by an impostor, so we can not be too permissive.

 

Hopefully if signed requests are used then the certificates to ensure

that the data is validly being updated, but then we have to allow for

certificate replacement (either timed or due to breach) - presumably

a new DigitalCollaboration/Agreement conversation, although quite

how this is done when the old certificate has been breached is more

complicated.

The DigitalCapability and DigitalAgreement can be signed and counter-signed, this is possible for any UBL document.

 

There are also questions about what happens to documents in transit

or workflows in process while a DigitalCollaboration/Agreement version

conversation happens, none of the other root objects seem to reference

the version of the Agreement that they were built from. I have not

come across anything in the non DigitalCollaboration/Agreement root

objects that refers to the agreement, and in particular to the version

of the Agreement that was in effect when it was constructed.

 

A DigitalAgreement is in summary composed by a collection of processes and transactions that two or more parties are going to implement and run in production.  each DigitalProcess has a ProfileID BIE that should match with the ProfileID on the business transactions (document instances).

The ProfileID is available on each UBL document in the root.
Also on each DigitalService there is a CustomizationID that will have to match the CustomizationID on each business transaction (document instance).

***It could be that in the future we will add a DigitalAgreementID on each UBL document to immediately reference the overall digital agreement that is governing a business transaction.***

David

Cheers,

Roberto Cisternino

UBL ITLSC, chair