[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: drop ship v 8 for discussion
Jamie, Will talk to you later, but I've looked at the Drop Ship Scenario table, with specific reference to the highlighted sections and here's some comments : - "there is no normative rule for generating the names (Authorized Roles)". You've made a statement so I'll attempt to offer a comment. What you have in the table right now seems to me to work, for our explanation purposes. Ultimately relating Auth Roles to a normalized list perhaps is something beyond the scope of our team and perhaps should be referred to the CC team for their opinion ? - "Order fulfillment". Couple of comments. ASN (Advanced Ship Note) is more North American vernacular, from my experience, and in more international circles the term Despatch Advice is used (in EDI). For the 'other side of the collaboration' there can be a Receiving Advice used to notify 'a party other than the receiving party' that a shipment has been received to inventory (see below for a few comments related to transaction trigger timing). Example uses of Receipt Advice include 'proof of delivery'. - "Ship Goods". On "carrier.shipment instruction", today electronic B/L's aren't yet globally done but I am optimistic that with 'isLegallyBinding' in the SpecSchema we can reach the pinnacle of enforceable electronic B/L's; something that will have a **really dramatic effect** (trust me you're talking MEGAbucks of process savings !!) within international shipping and the cross border free flow of goods. Today what happens though is the international carrier will return an 'IFTM contract status' (sorry for the name but that's what it's called in EDIFACT), and for domestic US transport I've usually seen an electronic 'freight bill' (which is almost a B/L). But your table does show the correct business relationship : shipper sends in the shipping instruction to the carrier of goods 'SAID TO CONTAIN' that need to be transported, and the carrier turns these shipper instructions (again 'SAID TO CONTAIN' to avoid cargo handling liabilities) into 'something external' which can be used to cause the carrier at the 'other end of the transport' to surrender the transported goods over to the rightful (new) owner of the cargo. I'll leave the final wording to yourself. For the rest, it all looks good. As one distills the collaborations down thru the transaction level, I've found there is a 'sweet spot' of business process compatibility (or incompatibility !!) that always needs to be explicitly tested; that can cause collaborating processes to "not smoothly function together". In fact it's usally this sweet spot of testing that makes traditional EDI so cumbersome to startup in business practice. I'm specifically referring to the 'trigger points' that occur within the business processes at the transaction level. For example : 1. in Order Fulfillment, in the drop ship scenario, the point of sale occurs when the DSVendor sends back the PO Ack to the Retailer; and not earlier. This may be more of a general business condition on the whole (round trip) transaction itself. 2. in Ship Goods, again in the scenario, the "Shipper.Shipment Instruction" needs to be made well in advance of actual transport of export of goods (well it's supposed to be but the carrier's sales guy might tell you something else if your a big shipper). 3. in Order Fulfillment, with "Shipper.Notify of Advanced shipment", to really get compatible transactions between the 2 parties, it must be clear as to which point in the shipper's process the 'signal' is 'triggered' to inform the Retailer of product shipment. ie. after the product has been picked/packed and shipped which is desirable, or only after the pick list has been printed which can lead to inventory discrepancies and other problems for this business model. The only other point I was wondering about, from a 'document readability point of view', would be to have a formal UML sequence diagram or something like that to help readers thru the 'fine print of the table' <pun intended>. Thanks Dave > -----Original Message----- > From: James Bryce Clark [mailto:jbc@lawyer.com] > Sent: Sunday, March 18, 2001 10:44 AM > To: ebxml-ccbp-analysis@lists.ebxml.org > Cc: Brian.Hayes@Commerceone.com; fineman@arzoon.com; > nsharma@netfish.com; marcia.mclure@mmiec.com; > David.Welsh@nordstrom.com; > jbc@lawyer.com; jdc-icot@lcc.net; nsharma@netfish.com; > linkage@interaccess.com > Subject: drop ship v 8 for discussion > > > Heres' a further refinement, deleting the X12 equivalents and > tweaking a > few names. Still subject to talking to Dave today. Jamie >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC