Stephen,
I'm sending a PowerPoint that I hopes clarifies the essentials of the "drop
ship" process. The principal change from your diagram is that the "seller"
in the center "swim lane" between the buyer on the left and dropship vendor
on the right.
Even in "drop ship" situations, the buyer and seller will conduct normal
buy/sell transactions directly - sales order acceptance, advanced shipping
notices, invoices, updates on status, etc. If buyer/seller communications
have been set up as a UBL trading relationship, there typically would be no
change in the XML documents exchanged for a transaction involving "drop
ships."
If, for example, the City of Bristol buys PCs and servers within a UBL
trading relationship from a local office supply distributor, perhaps most
often the distributor fulfills orders from stock. If, however, the City of
Bristol needed an unusually large number of PCs, servers, and associated
gadgets for some project (e.g., to predict the weather in the vicinity of
Bristol), the City would send an order to the distributor, which would
accept the order, but in turn would send an order to the manufacturer to
drop ship some or all of the items ordered directly to Bristol's chosen
point of receiving. Again, if the trading relationship between the
distributor and its supplier is highly automated, the only notable
difference is that the ship-to address would be that of the City of Bristol
rather than the distributor's warehouse.
As this hypothetical case illustrates, the main business objectives of "drop
shipment" are 1) to minimize double handling, 2) to minimize supply chain
stock levels, and 3) to avoid the need for buyers to set up rarely used
trading relationships with some distant manufacturer or other source. At an
extreme, the "seller" could go "virtual" and have no stock at all although
more commonly there will be some Pareto relationship involved - e.g., the
20% of outlier or hard-to-handle orders will be dropped shipped.
I hope that this explanation and diagram are of assistance.
Regards,
Fulton Wilcox
Colts Neck Solutions LLC
-----Original Message-----
From: Stephen Green [mailto:stephen_green@xxxxxxxxxxxxxxxxxxx]
Sent: Monday, November 21, 2005 9:21 AM
To: fulton.wilcox@xxxxxxxxxxxxxxxxxxxxxx; ubl-dev@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [ubl-dev] A reasonable example of drop-ship
UBL1.0orderingprocess?
Fulton
Many thanks for these detailed comments. Do you have
any suggestions as to how the process diagram could be
changed? My own knowledge of drop-ship is very limited
and I'm relying a bit on the fact that this example is just
an example and no more (focusing on the illustration of
ebBP 2.0.1). I mostly know about simple buyer-to-seller
scenarios and, of course, about how to use UBL for that.
One possibility I'm advised might help would be to remove
the possibility of a modification by the Seller to the Order
(using the UBL Order Response) and only allow simple
acceptance in full or denial (with the UBL 'OrderResponseSimple').
I gather from your comments that it might also improve
things to only have the Drop Ship Vendor forwarding
the documents. Would that be correct?
All the best
Stephen Green
>>> Fulton Wilcox <fulton.wilcox@xxxxxxxxxxxxxxxxxxxxxx> 17/11/05 19:42:49
>>>
Steve,
As you requested, below are some comments on what I understood.
Overall, I think the diagram overstates the role of the fulfilling company
in most drop ship commercial arrangements, because almost all
decision-making regarding the buyer's transaction should be in either the
buyer column (which you labeled "ultimate consumer") or the seller column.
As an example, contractual, credit, regulatory and tax matters are all
between those two entities. T go step-by-step"
Step 1. The buyer transmits a purchase order to the seller.
Step 2. The seller processes the buyer's order like any other order. Note
that it would not be uncommon that a buyer's order intermix "drop ship" and
"direct ship" items. For example, if the order is for some machine plus a
start kit of related consumables plus a service contract, the machine might
be the drop ship item whiil the consumables and intangibles go direct. To
address all of the above considerations, the seller puts the order through
normal order acceptance - e.g., customer master lookup, credit validation,
tax status, regulatory review, lead-time/available to promise review, etc.
(In more advanced implementations, the seller's system may do SOA web
services calls to the drop ship party to support available to promise and
pricing).
If the seller accepts the buyer's order, the seller's ERP (or some manual
process) will initiate a transaction to the drop-ship trading partner. That
dispatch advice will at a minimum include deliver-to shipping instructions -
e.g., send one dozen widgets part #12345 to this buyer and buyer address.
(If both the seller and the "drop ship" entity use OASIS ciq-compliant
ship-to data, this would be helpful).
In response to the drop-ship deliver-to instruction, the drop-ship company
has to execute at least two processes. One is to set in motion whatever
processes areneeded to pick and ship the goods to the buyer (or sent service
people, etc.). Second, and not shown on your diagram, the drop ship entity
needs to process the transaction through its own sales acceptance process,
because the shipment is in effect two concurrent sales transactions. From
the perspective of the drop-ship company, the seller is its buyer, and it
need to check terms and conditions, credit worthiness, etc. just as it would
any other customer.
Exception conditions - the order is rejected, the accepted order cannot be
fulfilled, invoicing complaints etc. would normally be between the buyer and
seller. The drop ship entity would get involved only to defend itself to the
seller or, in a worst case, to process returns.
There are of course many variants, but the preponderant use of drop ships is
as I described.
Regards,
Fulton Wilcox
Colts Neck Solutions LLC
-----Original Message-----
From: Stephen Green [mailto:stephen_green@xxxxxxxxxxxxxxxxxxx]
Sent: Thursday, November 17, 2005 12:02 PM
To: ubl-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [ubl-dev] A reasonable example of drop-ship UBL 1.0ordering
process?
It seems the attachment for ubl-dev didn't make it
through my mailgate. In case this is a general problem affecting others it
should be available at
http://lists.oasis-open.org/archives/ubl/200511/gif00001.gif
Steve
>>> "Stephen Green" <stephen_green@xxxxxxxxxxxxxxxxxxx> 17/11/05 16:54:26
>>>
Greetings UBL TC/UBL-DEV (cc ebBP TC)
I'm looking at an example definition of an ebBP 2.0.1 business
process for a fictitious UBL 1.0 dropship trading scenario,
based on the example the last ebBP spec included in
Appendix A (developed by J. Dean E. P. Hemopo) and I've
treid to change it a bit to bring it more in line with the details
of UBL 1.0.
Would anyone like to comment on the attached diagram.
It isn't supposed to be exactly accurate (it demonstrates
ebBP more, probably, than UBL 1.0) but if it does miss
the mark for UBL good practise please let us know. The
parts in red are those I've particularly amended. This
version just covers ordering (the original deals with fulfillment
and billing too, providing examples of complex choreography).
I'd be interested in any comments too on how actual,
expressly usable business process definitions could be
created for UBL 1.0 for later addition to an ebBP package
or supplementary package. My own ideas so far are:
1. just use a simple buyer-seller scenario but try to make
the defintions so modular that they can be combined
somehow for use by drop-ship vendors if necessary
2 distinguish full UBL from UBL SBS so that either can be
specified
3 base definitions on usage of each document or set of
related documents so that some can choose to adopt
one or a few documents only and get use out of the
definition(s)
4 possibly allow for includes of the definitions within other
defintions
(All this would be using ebBP 2.0.1)
Maybe this could be developed a little more on ubl-dev.
Many thanks
Stephen Green
---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/
---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/
---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL
OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@xxxxxxxxxxxxxxxxxxxx
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/
Attachment:
dropshipUBL1.ppt
Description: MS-Powerpoint presentation
|
