Re: [ebxml-bp] Drop-ship example Re: [ebxml-bp] Groups -ebxmlbp-2.0.1-Minutes-112205

[Monica J Martin <Monica.Martin@Sun.COM>]

>green: Regarding the drop-ship example discussion minuted for
>last week's call, I've received a comment on ubl-dev from
>Fulton Wilcox which I have permission to forward (attached
>pdf and see http://lists.oasis-open.org/archives/ubl-dev/200511/msg00006.html )
>
>If it were necessary to change the drop-ship example with
>regard to its model, Fulton's model might be a handy reference. 
>  
>
mm1: Thanks for sending this Stephen.  Mr. Wilcox's details seem 
consistent with what I understand happens in manufacturing, using drop 
ship vendors where appropriate.  Here are a few comments on the UML 
diagrams (page 2-3) and the simplified diagram (page 1).

   1. Page 1:
          * See previous comment.
          * The DropShipVendor provides a notice to the Seller at
            'pick/ship'. Does that realize itself as another
            Notification to the Seller (appears so by the diagram),
            separate and distinct from the ASN?  If so, a Notification
            pattern could be used for a Notification BT.  The diagram
            doesn't specify what that business message is (circle on
            line between Seller and DropShipVendor).  That Notification
            may be valuable to the Seller to be able to move internal
            operations forward and may also result in an early indicator
            to the Buyer (Ultimate Customer).
          * Ship goods or perform services: If there is manual actions
            that occur, that can be quantified, may be good to include
            them in the business process definition. Remember we have
            several implementer hints provides for processing such as
            ExternalDocumentDefRef (for logical business document),
            DocumentSpecificationType (for validation such as use of
            schematron that could be automated for manual operations)
            and ExpressionLanguage (which may be a specific processing
            mechanism chosen by the parties). There is also a section in
            the Appendices that talks about manual operations (Appendix
            C: Manual or Implicit Business Transactions).
   2. Page 2-3:
          * Ensure that OrderResponseSimple is understood to be an Order
            Response nonetheless. It is acceptance or rejection of an offer.
          * Update Order Status (under Forward Purchase Order Accepted
            Notification) typically may be an enterprise process that
            occurs as a result of the collaborative process.
          * In several places (such as under Forward Sales Order Change
            Reject) you have references to acknowledgements. Need to
            differentiate what business signals are used and how they
            figure into the process definition (Assuming this is not a
            reference to an XPath into the business document). 
            Nonetheless, suggest you think about representing the
            business signals in the process definition (even if not
            evidenced in the process diagrams provided). Business
            signals are important for state alignment, such as for
            Forward Order Cancellation Acknowledgement (under Forward
            Order Cancellation Acknowledgement - Notification).  Signals
            usage is also recognized in the patterns matrices.

Thanks to Mr. Wilcox as well for his assistance on ubl-dev. I would have 
cc: him here but don't have a complete email address. Thanks.