OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-ccbp-analysis message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC