Re: [ubl-dev] Ordering process activity diagram

[Миљан Ушћумлић <miljan.miljan@gmail.com>]

Dear Ken,

Thank you very much for your detailed answer! You certainly shed some bright light on these topics, and with your explanations enabled me to better understand UBL specification.


Thanks again,
Miljan


On 14.4.2018 16:17, G. Ken Holman wrote:
> At 2018-04-14 12:44 +0200, Миљан Ушћумлић wrote:
> > I am pretty new to the UBL and e-invoicing world in general
>
> Welcome!
>
> > and I am kindly asking for a help in understanding of Ordering process business flow depicted on the page 51 of the UBL-2.2.pdf specification.
>
> Before you read too much into these process diagrams, it is important to note the first paragraph of this section:
>
> http://docs.oasis-open.org/ubl/cs01-UBL-2.2/UBL-2.2.html#S-BUSINESS-OBJECT-OVERVIEW
>
> The process diagrams are only normative to the extent of documenting the context of why the committee chose to create particular document types.  The process diagrams are not and never were meant to be implementation guidelines.  It was always expected that user communities would formally define the process diagrams they would use when using UBL documents.
>
> For example, in Europe, there are two CEN TCs, 434 and 440, who are responsible for defining the swim lanes and process semantics for the use of UBL in their jurisdiction.  In Australia there is the DBC.
>
> All users are expected to do the same, and they are not expected to be implementing the illustrative processes found in the UBL documentation.  These are not meant to be complete, nor even entirely consistent, as they are sufficient only to justify our inclusion of a particular document type.
>
> It was Jon Bosak's vision that UBL be usable around the world in any business context that needs the document types the committee has made available.  This is not possible if the committee were to attempt to define those process contexts as normative ... because business runs differently around the world some groups would be disenfranchised.  And so none of the process descriptions are normative beyond simply illustrating the role that a particular document can play when the committee decided to include it.
>
> > My main confusion is mainly in regard with a Seller Party's swim lane of this activity diagram.
>
> Which may be incomplete or not entirely consistent.
>
> > My questions are:
> >
> > 1. For activity flow: Place Order -> Receive Order -> process order -> Add Detail there are no guards on outgoing activity edges of the "Add Detail" activity. So, when is appropriate to go in one direction sending Order Response, and when to go in the other by invoking "Accept Order" activity?
>
> Whenever you dictate it should be.  In your community's formal use of UBL you should be creating your own agreed-upon process flows and dictating the use of UBL business objects within those contexts.
>
> > As I understood it, when the Order is modified Order Response (in which the change is reflected) have to be sent to the Buyer Party.? Activity edges are mutually exclusive so going to "Accept Order" activity instead, we are in the position to send only Order Response Simple (which does not contain any Order amendments).
>
> You are allowed to send any document at any time based on your requirements. lease do not feel constrained by the illustrative process diagrams.  From the quoted section above: "The processes described ... should not be construed as limiting the application of those schemas".
>
> > 2. For activity flow:Â  Place Order -> Receive Order -> process order -> Accept Order what would be an example when the guard [response required] is true, and what [response is not required]?
> > Does it mean that response is always required when the Order is accepted so the Buyer Party MUST be notified of that acceptance of the Order enabling the activity flow to end in the "order accepted" final node?
>
> There is no "MUST" in UBL regarding how UBL is used, only in the cardinality of business objects in the document types and the conformance clauses.  Only a user community can define such a "MUST".
>
> > And, I am puzzled that after "Accept Order" activity (when the order is accepted by the Seller Party?) following the edge guarded with [response not required], the flow ends in the "order canceled" final node. I am reading this as a situation when the Order has been accepted but still afterwards cancelled solely by the Seller Party not notifying Buyer Party about it at all. And I am certain that I am badly missing something here.
>
> You are missing only that the UBL process flows are illustrative for documentary purposes only and do not constrain anyone's implementation of UBL.
>
> > Any help and guidance to better understand Ordering process is highly appreciated.
>
> I hope, Miljan, this explanation has allayed your concerns about any confusion or contradictions in the UBL process diagrams.  We hope the documentation inspires users in their specification of their own business processes that will leverage the use of UBL syntax.
>
> Now of course there may be members of UBL Dev that can offer you recommendations on how you would shape your own processes using the illustrative ones as a starting point.  That is something I, personally, am ill-equipped to do.
>
> Good luck in your project and in your user community!
>
> . . . . . . . Ken
>
> --
> Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/u/ |
> Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
> Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |