Subject: What is the recommended policy on Party data changes?
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
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.