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

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