[OASIS Issue Tracker] (UBL-103) SequenceNumberID and LineStatusCode

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/UBL-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65941#comment-65941 ] 

Kees Duvekot commented on UBL-103:
----------------------------------

Here we are talking about the following process diagram: (taken from http://docs.oasis-open.org/ubl/os-UBL-2.1/art/UBL-2.1-OrderingProcess.png)
 


And there you see that Order and OrderChange are deliberately different documents, and therefore have different fields and contents.
Also for the receiving party they should handle OrderChange in a different way then the  Order Document …
There is also a relation with a potentially received (or even issued) OrderResponse(Simple) document … that will provide context also.


There are more than just those two mentioned fields difference between the Order and OrderChange documents: (7 differences in total on the maindoc level) and there is NO difference on the OrderLine level, so LineStatusCode is already the same in both documents.

cbc:SequenceNumberID [1..1]  Only in OrderChange
	This is an indication for the receiving party so they can either process all the OrderChange documents in the right sequence, or determine that they already has processed a later sequence then currently received and correctly respond to that.

cbc:OrderTypeCode [0..1]    Only in Order
	The OrderTypeCode is contained in a different element in the OrderChange document (cac:OrderReference .. see later)

cac:OrderReference [1..1] Only in OrderChange
	This is reference to the original Order document. So the cbc:ID of the Order Document is the cbc:ID in this OrderReference. Also the other fields in this OrderReference are taken 1 for 1 from the original OrderDocument to provide the link between the Order and OrderChange documents. Potentially this can be even enriched with the details received in the OrderResponse(Simple) documents from the Supllier, like the Suppliers SalesOrderID etc)

cac:OrderDocumentReference [0..*] Only in Order
	This is a reference to ANOTHER order that relates to this Order document, not the Reference to a specific Order you want to change.(ie .. possible use might be to link an order for the return of goods to the original order for the purchase of those goods)

cac:CatalogueReference [0..1] only in Order
	This is a reference to a specific Catalogue that was used to provide item/price/location details contained in this order. Because an OrderChange references this Order document there is no need to repeat this in OrderChange. The details in OrderChange might have been changed so there is no real link back to the catalogue anymore. You could argue that you want to also in the OrderChange so you can change that reference if that is still valid.

cac:ProjectReference [0..*] Only in Order
	Also here the reference to a related Project is on in Order, and via reference can be derived in the OrderChange. But if you want to change the project reference of an order you have no possibility. So this might also be added to OrderChange in order to allow changing this on an Order.

cac:AccountingSupplierParty [0..1] Only in OrderChange
	This is a reference of the party that is doing the accounting for the SupplierParty. Because you don’t know (or have to know) this information when placing the Order this is not contained in the Order document. The Supplier can provide these details in the related OrderResponse(Simple) documents and then the BuyerParty has these details (this is the party that will send the invoice for this order) and can provide them back in the OrderChange document just for reference.

The biggest difference is in the use in the process. Because each document that is send should have a unique independent ID the cbc:ID of the OrderChange by definition is different for each change to an Order. So that means that if you want to merge the two documents (which I am not advising) then you should be aware that this element is no longer the “OrderID” in the updated Order document and therefor you should look at the OrderReference element to find the actual OrderID, even for the first document. This is a major difference in approach, and also means that people have to know this even for orders where you are not making a change on.

Also keep in mind that the whole ordering process can even start without an Order document. The Supplier can initiate an OrderResponse with the details received via another channel (maybe via telephone, or during an online checkout process) and the all the details in the OrderChange\OrderReference element is related to the details received in the OrderResponse.

So … there are possibly more reasons to keep the documents separate, and not merge them together because the use and processing is different for both documents.

Want I want to know is: “ what is the reason they don’t want to use the OrderChange document? “



> SequenceNumberID and LineStatusCode
> -----------------------------------
>
>                 Key: UBL-103
>                 URL: https://issues.oasis-open.org/browse/UBL-103
>             Project: OASIS Universal Business Language (UBL) TC
>          Issue Type: Improvement
>         Environment: UBL 2.2
>            Reporter: Ole Madsen
>            Assignee: Ole Madsen
>            Priority: Minor
>
> Add SequenceNumberID and LineStatusCode from UBL OrderChange to UBL Order



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)