OASIS Universal Business Language (UBL) TC

As part of the work that is being done to map the new European Invoice norm to the UBL syntax the UBL TC received two requests that are related to each other.

UBL-468: Allow the ID of the order - issued by the buyer - be optional
UBL-470 :Making LineIDs optional

So these are two changes that touch on a fundamental building block for a large number of UBL documents.

UBL-468:
The core use case/requirements for UBL-468 come down to this: How do you specify on an invoice (or other documents) that you do not have an Order id from the customer, but only an identifier to something that the seller has created. This is a valid use case where the customer did not issue an order but instead just called the supplier to place an order, or completed the order via the website of the supplier without issuing its own order in its own systems or any other way where no formal order from the supplier was created (and there can be many many ways)

so I agree that this is a use case that we must support in a proper way in UBL. What we have found is that in the previous mapping of the 2017 European invoice norm a "work around" was introduced instead of asking the UBL TC how to properly fix this. The work around that used in the European norm was:

so .. this all takes place at the cac:OrderReference element of UBL. 

this "workaround" of entering a dummy value in the cbc:ID element of the cac:OrderReference is in my view a clear violation of this UBL rule:

The use of this "NA" value is clearly a way to work around the required element by entering "NA" that is basically devoid of content.

UBL-468 is now asking to have the cbc:ID element under the cac:OrderReference to be made optional in order to "fix" this workaround for a valid situation where there is no known Order from the customer.

In my opinion we should not do that. From the semantic model of UBL the OrderReferrence is clearly intended to be used to point to an Order that was created in the systems/process of the customer. By making the ID that points to that Order optional you are basically stripping the whole OrderReference from its semantic meaning.

If you look at the description of OrderReference in the model it says:

A class to define a reference to an Order.

The use of the capital O in Order is meaning full .. because that indicates that it is pointing to the actual Order

The other elements under OrderReference also use this and also strengthen the semantic meaning to specifically mean an order issued by the buyer because of the definition of the mandatory element. And in the other elements the word Order is in capitals again pointing to the actual Order.

By making the ID optional the whole use of this element becomes unclear because now suddenly it can mean two things : a pointer to an Order assigned by the buyer OR a pointer to an Order assigned by the seller.

So if we implement this change we are actually diminishing the usefulness and meaning of the element and in my view UBL as a whole.

So instead of changing the semantic meaning of this very fundamental element I would propose a different approach.

there is a clear need for a pointer to the actual order in the systems of the seller in the absence of one from the buyer. So that would mean we could introduce a "SupplierOrderReference" element to make a clear distinction between the two.

cbc:ID [1..1]     An identifier for this order reference, assigned by the supplier.

cbc:UUID [0..1]     A universally unique identifier for this order reference.

cbc:IssueDate [0..1]     The date on which the referenced SupplerOrder was created.

cbc:IssueTime [0..1]     The time at which the referenced SupplerOrder was created.

cbc:OrderTypeCode [0..1]     A code signifying the type of the referenced SupplerOrder.

cac:DocumentReference [0..1]     A document associated with this reference to an Order.

cac:OrderReference [0..1]     An identifier for this order reference, assigned by the buyer.

That way in the absence of an Order from the buyer this element can be used instead. And to avoid confusion we should deprecate cbc:SalesOrderID in the OrderReference and add the new SupplierOrderReference to it.

and I propose to add the new SupplierOrderReference in most places where the current OrderReference is used as an optional element.

We should also update the documentation to show this use case of an order without starting from the buyer. And show how this can tie back into the whole UBL exchange around order. When doing that we might see that there is a need for a seperate new document that needs to be exchanged from the Supplier to the Buyer .. that is different but potentially similar to the "OrderResponse" so the supplier can inform the buyer about the details of the order that was created in the systems of the supplier. The Buyer can process this document in their own systems and then issue a "OrderChange" document to inform the seller about the OrderReference from the buyer side and the circle is complete again. The Buyer can even issue OrderChanges later on or even send an OrderCancelation .. just like the Supplier can send additional OrderResponse documents to indicate his changes to the order.

Because this is a fairly large undertaking (this new document from supplier to buyer) I propose to postpone that to UBL 2.6 but still already add the new SupplierOrderReference in UBL 2.5.

Now the next request is kind of related : Making LineIDs optional

if applied to the OrderLineReference it is basically the same use case. How to reference a line in a supplier order in the absence of a buyer initiated order. Also here there will be a semantic confusion if the LineID in OrderLineReference is made optional. So that would mean a similar construction and add a SupplierOrderLineReference