Hello David,
the DigitalAgreement is built from DigitalCapabilities information and exchanged with your partner for acceptance, if not accepted an Applicationresponse is sent back, if accepted the DigitalAgreement is usually counter-signed or just sent back for acceptance.
The diagram on the UBL specification is just one example of the digital agreement scene.
Implementation communities should design a specific profile for it with full details of the process and transctions involved as well as pre-post conditions and any relevant business rule.
UBL TC do not limit its usage, and we only provide the possibility to include the actual VersionID and PreviousVersionID so that the recipient can evaluate the new version.
Anyway it depends if digital signatures are involved.
You cannot change a signed document, so the best is to send the Agreement to the other party and hope they will counter-sign it and send it back, otherwise the process must be restarted. a negative ApplicationResponse may trigger a new DigitalAgreemnt is exchanged with a new version and new signature.
I hope it helps,
Cheers,
Roberto
Il 27/02/2018 12:52, David Goodenough ha scritto:
the DigitalAgreement is built from DigitalCapabilities information and exchanged with your partner for acceptance, if not accepted an Applicationresponse is sent back, if accepted the DigitalAgreement is usually counter-signed or just sent back for acceptance.
The diagram on the UBL specification is just one example of the digital agreement scene.
Implementation communities should design a specific profile for it with full details of the process and transctions involved as well as pre-post conditions and any relevant business rule.
UBL TC do not limit its usage, and we only provide the possibility to include the actual VersionID and PreviousVersionID so that the recipient can evaluate the new version.
Anyway it depends if digital signatures are involved.
You cannot change a signed document, so the best is to send the Agreement to the other party and hope they will counter-sign it and send it back, otherwise the process must be restarted. a negative ApplicationResponse may trigger a new DigitalAgreemnt is exchanged with a new version and new signature.
I hope it helps,
Cheers,
Roberto
Il 27/02/2018 12:52, David Goodenough ha scritto:
to be the same as the ID that it is responding to. If so this should perhaps be documented somewhere (if it is currently I can not find it), if not then how are the two DigitalAgreements connected, other than by their being about the same parties.
Also are there any rules/guidance notes as to how much of the DigitalAgreement sent in response to the DigitalCapabilities can be changed in the second DigitalAgreement? My instinct says that things may be added (importantly a counter signature) but that as each party "owns" its own data the response can only add data about the responder, not change data about the originator.
David
--
Best regards
Best regards
 |
Roberto
Cisternino
e-Business Consultant, JAVEST by Roberto Cisternino |