What is the recommended policy on Party data changes?

[David Goodenough <david.goodenough@broadwellmanor.co.uk>]

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.

 

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.

 

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.

 

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.

 

David