[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ubl-dev] Delivery address/party in the Order
Magnus,
From a process perspective, your scenario is often described as a "drop
ship." A distributor/reseller "A" (to use your label) sells widgets to buyer
"B" and, in the "normal" supply chain flow, "A" would pick and ship those
widgets from stock to fulfill "B's" orders. In turn, "A" sends orders to its
own source ("C") to buy more widgets for stock. Widgets flow "C"-> "A"->
"B". Orders flow from "B"->"A"->"C".
An important point is that A, B and C represent the supply chain process and
associated "master data" in their respective internal systems. What is
critical is to take the perspective that UBL documents exist merely to
synchronize transaction data between internal systems.
As you noted, your company ("C") has no direct relationship with "B", and
indeed it often is a major business objective NOT to have such relationships
represented within "C's" internal system. More specifically, the master data
in C's internal systems and B's internal systems are probably NOT
synchronized, because each is separately synchronizing with the entity in
the middle, "A". For example, if "C" is a manufacturer, "A" is a
distributor, and "B" is a large end user enterprise, the fact that the end
user enterprise has in A's systems dozens of separate customer accounts and
perhaps many more deliver-to's is probably not replicated in "C's"
distribution system.
Nevertheless, for what usually are physical logistics considerations, the
intermediary "A" may instruct its source "C" to ship directly to end
customer "A", presumably to avoid double handling, cross-docking, additional
freight expense, delay, etc. In today's world, such "drop ships" may be an
occasional request (e.g., the end customer "B" has ordered several metric
tons of what it usually buys in five kilo quantities) or a standing request,
because "A" is a "virtual" intermediary.
In either the drop ship scenario, the widgets move C->B, bypassing A.
Even so, note that from customer service, pricing, legal, regulatory and tax
perspectives, the flow is unchanged - still C->B->A. Therefore, regardless
of physical delivery routing, information exchanges should flow normally
between C->A and between A->B. Hybrid transactions (e.g., the end customer
"B" sends "an order" to both the intermediary "A" and the ultimate source
"C" usually are infeasible because the three see each other in very
different levels of granularity, specific data conventions, etc.
Therefore, from an "integration" perspective - meaning information
integration across the supply chain, your company "C" and "A" should
exchange orders, ship advices, etc. exactly as would be the case if buyer B
were buying for inventory for later resale. The same is true for "A" and
"B".
The informationally-real "Destination Party" is your (C's) direct customer
"A", even though physically the address is that of a facility owned by "A's"
customer, "B".
The answer to your question is critically dependent on how "C's" internal
processes and master data conventions represent drop ship recipients such as
"A".
Within "C", the people defining C's internal sales and distribution process
presumably have created master data conventions for drop ships and drop ship
recipients. The three fundamental options are: 1) set up "dummy" customer
accounts for drop ship entities, 2) set up "deliver-to" accounts parented to
the "real" (paying) customers "sell-to" account, or 3) having customer
service people override deliver-to information "on the fly". (If you are
unlucky, the internal processes will be some situational unplanned mix).
In all three cases, mapping that output to corresponding UBL transactions
will not be hindered by UBL document design, because the ship to address
supplied probably has suitable verbiage within the address structure (TO:
Company "B" on behalf of Company A) or the dummy customer accounts maps more
or less normally.
The end customer "B" in the C->A->B handoff is not "real" to "C", so while
the widgets can jump from C to A, the informational transactions should not
jump. That is, B should not send purchase orders to C (C probably does not
know or want to deal with A's pricing, terms, etc.), C should not send
shipping advices to for B to upload, etc. This statement has nothing to do
with UBL limitations, but rather with the more fundamental question of
business relationships and master data synchronization between trading
partners.
Although eBusiness standards-setting is replete with attempts to be
autonomous problem-solvers, realistically questions about how to populate a
given transaction is governed by enterprise business practice and master
data conventions. Adding new eBusiness transactions, features, conventions,
etc. rarely suffice to bridge gaps. Therefore, what is critical to the
"integrator" is to look deep into the data conventions in both parties ERPs
(or like system or non-systems, if not automated) and to either leverage
what is being done or get sufficient change made to assure success.
Fulton Wilcox
Colts Neck Solutions LLC
-----Original Message-----
From: Sylvia Webb [mailto:swebb@gefeg.com]
Sent: Friday, February 24, 2006 10:17 PM
To: 'Magnus Palmer'; ubl-dev@lists.oasis-open.org
Subject: RE: [ubl-dev] Delivery address/party in the Order
Magnus,
Thank you for your comments.
You are correct. Destination Party does not exist at the header level of
Order. The UBL Procurement Subcommittee had considerable discussion about
various party roles and whether they should be at the header level, detail
level, or both. Where we didn't have specific use cases, we tended to place
certain roles at the detail level.
Please submit your comments to
http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ubl and the
Procurement Subcommittee will consider your request as part of our review of
all comments on the UBL 2.0 draft package.
Regards,
Sylvia Webb
-----Original Message-----
From: Magnus Palmer [mailto:magnus.palmer@alfalaval.com]
Sent: Tuesday, February 21, 2006 8:03 AM
To: ubl-dev@lists.oasis-open.org
Subject: [ubl-dev] Delivery address/party in the Order
Dear all,
Looking at the Delivery (UBL-CommonAggregateComponents-2) used in the order
message I have a question.
A common scenario for us is to receive an order from Company A and then make
the delivery to Company A's customer Company B with whom we do not have a
business relation with.
All the lines are to be delivered to the same destination.
I am comparing with the information we need to get in our EDIFACT ORDERS
(NAD+DP) today. (DP= Delivery party(3144) Party to which goods should be
delivered, if not identical with consignee.
What I'm missing is the DestinationParty on a header level, either directly
under the Order or under the Order.Delivery.
The Order.OrderLine.LineItem.DestinationParty would in my opinion be I'm
just thinking that there is a Order.Delivery.OriginatorParty so to me it
would feel natural to have a Order.Delivery.DestinationParty or an optional
Order.DestinationParty.
I could of course use the Order.Delivery.Delivery_Address.ID or the first
Delivery_Address.Address Line and feel happy about that, or even use the
DestinationParty on the first line.
Any thoughts regarding this would be appreciated.
Mvh/Brgds,
Magnus Palmér
Integration Competence Center, CI-IS-ICC
----------------------------------------------------------------------------
----------------------------------------
Alfa Laval Lund AB, PO Box 74, SE-221 00 Lund, Sweden Visiting address:
Rudeboksvägen 1 (GXB2), Lund Tel switchboard: +46 46 36 65 00 Tel direct:
+46 46 36 67 29, Mobile: +46 46 36 67 29, Fax: +46 46 15 71
05
E-mail: magnus.palmer@alfalaval.com
Website: http://www.alfalaval.com
----------------------------------------------------------------------------
------------
---------------------------------------------------------------------
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@lists.oasis-open.org
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@lists.oasis-open.org
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]