|
EIDX Distributor Scenario 1
Ship-from-Stock and Debit (SSD), Version 1.0
The purpose of this documentation
is to describe the activities in the Ship-from-Stock and Debit (SSD)
business process, including the flow of documents and high level
data requirements.
Any implementation method should be agreed upon by trading partners.
It is the intent of this documentation to make interpretation of
the models used for SSD more consistent, so that implementations
are based upon common practices.
The SSD process occurs when a distributor's profit margin for
a product drops below a desirable level, due to the fact that the
distributor is holding stock for a component supplier, purchased
from that supplier at a cost based on a resale price that no longer
reflects actual market price. The distributor requests an
after-the-fact price reduction from component supplier in order
that the resale of the product will meet competitors' pricing with
an acceptable profit margin. The component supplier may approve
the request and establish an effective date and expiration date
for the authorization. When the distributor resells stock
that was purchased from the component supplier at the original book
price, the distributor submits a debit claim to the component supplier
to claim the difference between the original book price and the
current quote price; some component suppliers automatically grant
the debit based on sales reports and do not require a claim to be
submitted. If the product is returned to the distributor,
the component supplier may send a credit claim (a/k/a "Bill
up to book") to the distributor to back-out the discount.
Scope: This scenario includes the routine components of the
SSD scenario. Models are created for common exceptions that
are good candidates for automation. Not every possible exception
situation is modeled, because there are events that are too rare
to justify the cost of automation, or too complex to be automated
- they require the intelligence of human beings for resolution.
All business processes touch, or are adjacent to other business
processes. SSD has the potential for connecting to the complex
processes involved in product returns and financial adjustments.
In order to keep focused on the normal SSD events, only the routine
case of a simple product return to the distributor's stock is in
scope for modeling this scenario.
Other processes involving product returns, quality, and financial
adjustments have been or will be modeled separately. For example,
the credit and re-bill exception is out of scope at this time.
Overview (Use Case) Diagram

Click here to view a larger image.
Overview (Use Case) Narration
| Step |
Description |
| 1. |
Pre-Order Model 4: The distributor sends
a meet competition quote to the component supplier. The supplier’s
response may authorize a discount for inventories that the distributor
will purchase for a specified time period and/or for a specified
quantity limit, and may include authorization for SSD debits
applicable to all or part of the distributor's inventories already
purchased from the supplier.
Pre-Order Model 6: The distributor sends a request for a
discrete SSD authorization for inventories already purchased
from the component supplier. The response may approve
or deny a product for SSD, and authorization may cover only
a certain time period and specify effective and expiration
dates.
Pre-Order Model 7 - The component supplier sends a blanket
SSD authorization applying to multiple products.
|
| 2. |
Pre-Order Model 8: (Optional) At any time,
the distributor may request for status of some or all open SSD
debit authorizations. The component supplier sends the
report back in response. The component supplier may
also send the report unsolicited, as agreed with the distributor,
when status changes are made or per a pre-agreed schedule . |
| 3. |
(Optional) The distributor sends point-of-sales
data to the component supplier per the appropriate sales reporting
scenario. This data may be used to validate SSD debit
claims, and to advise of product returns. This step is
optional because the timing of SSD claims and POS reporting
are often different; for example, SSD claims may be sent weekly
and the POS report monthly, or the POS reporting could be daily
and the SSD claims done monthly. |
| 4. |
Debits and Credits Model 5: When the distributor
ships a product that has an SSD authorization, the distributor
submits a debit claim to the component supplier, and the component
supplier sends back a response; the response may approve or
deny a debit claim.
Debits and Credits Model 6: Alternatively, though
it is not a common practice, the component supplier may use
the sales data instead of a debit claim to automatically notify
the distributor that a debit is approved.
|
| 5. |
Debits and Credits Model 7: If the distributor's
customer returns product for which the distributor took an SSD
debit the component supplier may send a credit claim to the
distributor, asking them to back-out the debit. This process
is also known as "bill up to book." The distributor
may send a response if there was a problem with the component
supplier's credit claim - either a business issue such as a
disagreement with the claim, or a technical issue, such as invalid
part number. This should be an exception case, and if
such issues occur, EIDX recommends that the problems be resolved
manually through the normal chain of command.
Debits and Credits Model 8: If the distributor's customer
returns product for which the component supplier had approved
a debit claim, the distributor may back-out the SSD debit
by automatically giving a credit to the supplier.
|
Process Activities
Few companies automate an entire business process all at once.
An SSD business process may be implemented in multiple steps, as represented
by the component business models contained in the scenario.
Some companies may decide not to automate some parts of the process
if an ROI analysis indicates that automating that part is not cost-effective.
Activity Diagram

Click here to view a larger image.
| Step |
Description |
| A. |
At start state A, the
buyer and seller have a pre-established relationship.
|
| 1. |
A distributor's profit margin for a product drops below
a desirable level, due to the fact that the distributor is
holding stock for a component supplier, purchased from that
component supplier at a price that no longer reflects actual
market price. The distributor requests a post-sales
(component supplier selling to distributor) reduction in cost
from component supplier in order that the resale of the product
will meet competitors' pricing; the distributor may send a
discrete request for a debit authorization (Pre-Order
Model 6), a Blanket Request for Debit Authorization (Pre-Order
Model 7), or may include it in a Request for a "Meet
Competition" Quote (Pre-Order
Model 4) sent to get a reduction in pricing for backlog
( the distributor's open orders to the component supplier)
and future orders sent from the distributor to the component
supplier.
|
| B. |
At end state B, the authorization acceptance or rejection
is pending. The distributor should expect a follow-on
response within an agreed, configurable period of time indicating
authorization acceptance or rejection.
Note that the model does not have the "pending"
state trigger the subsequent follow-on response. For
the distributor the sub-process is ended and the buyer waits
for the follow-on acknowledgement. If the supplier has
set the authorization status to "pending," the supplier
should have logic in the back-end process that triggers them
to initiate another instance of the response sub-process when
the cause of the pending status is resolved and sends another
response message with an updated status.
The distributor may launch an exception notice if the supplier's
follow-on response is not received within the agreed, configurable
period of time.
|
| 2. |
The distributor opens
a file or creates a data base to track status of debit authorizations
-both those approved by the component supplier, those where
the request was rejected by the component supplier, and those
where authorization status is still pending. |
| 3. |
The distributor enters
into pre-order negotiations with its customer. |
| C. |
Start state C occurs
when information requested (e.g. from inside sales for a blanket
authorization, different customer, different part, credit/re-bill,
authorization not on file) or distributor wants to perform audit,
or transactions between distributor and customer may trigger
request to confirm authorization status. |
| 4. |
The distributor may
launch a request for an authorization status report, or the
component supplier may send an updated report periodically.
See component model Pre-Order
Model 8 for details. The distributor uses the report
to perform audits, check counts, check expiration dates, etc. |
| D. |
At end state D, no authorization
for a debit exists. The distributor is ineligible for
a debit claim when reselling the component supplier's product. |
| 5. |
The distributor reports
point-of-sales transactions to the component supplier, per the
appropriate sales reporting scenario. Sales may be matched
to debit claims; for product returns, POS triggers reversal
of debit granted to distributor. Timing is important to reconcile
SSD claims with POS data. This step is optional because
the timing of SSD claims and POS reporting are often different;
for example, SSD claims may be sent weekly and the POS report
monthly, or the POS reporting could be daily and the SSD claims
done monthly. |
| 6. |
If eligible, the distributor
may submit a debit claim upon reselling the component supplier's
product. The component supplier will send a response that
confirms or denies the claim. If the debit claim is approved,
the distributor debits the appropriate amount from what the
distributor owes the component supplier for other transactions.
See component model Debits
and Credits Model 5 for details.
Alternatively, since debit authorizations already exist,
after reviewing the POS report, the component supplier may
automatically award a debit claim approval to the distributor
(the distributor does not have to submit a claim). See
component model Debits
and Credits Model 6 for details.
|
| E. |
End state E is reached
if the sales report indicates that no products which the distributor
resold at discounted prices have been returned by the distributor's
customer. |
| 7. |
If, in reviewing point-of-sales
report, the component supplier sees that the end customer has
returned material, the component supplier may send a credit
claim to the distributor to back-out the cost reduction. This
is also know as "Bill up-to-book." The
distributor then adds the credit (to the component supplier)
to the amount owed component supplier from other transactions.
If needed, the distributor may send a response that confirms
or denies the credit claim. See component model Debits
and Credits Model 7 for details.
Alternatively, when the distributor's customer returns products,
the distributor may give a credit to the supplier automatically.
See component model Debits
and Credits Model 8 for details.
|
| F. |
At end state F, the
distributor has accepted the component supplier's claim.
All claims have been processed by both parties and both parties
know the status and disposition of the claims. |
| G. |
At end state G, the
distributor has sent a response as required under the terms
and conditions agreement. All claims have been processed
by both parties and both parties know the status and disposition
of the claims. |
Implementation Options
Basic implementation options apply theoretically, but practical
application has proven to be difficult because of the amount of
information that must be synchronized between distributor and component
supplier. Currently, the most robust technology for SSD is RosettaNet
B2B; however, the specifications are neither mature nor widely deployed.
| Assessment of Technology Options
for Ship-from-Stock and Debit |
| |
Technology Option |
SSD Debit Authorizations |
SSD Claims |
| 1.0 |
Traditional EDI via a VAN |
Recommended Option - See Note 1 |
Recommended Option |
| 2.0 |
Client EDI application with a VAN |
Recommended Option - See Note 1 |
Recommended Option |
| 3.0 |
Integrated B2B via the Internet,
no VAN |
| |
3b |
EDI over the Internet - Point-to-Point (EDIINT) |
Recommended Option - See Note 1 |
Recommended Option |
| |
3c |
RosettaNet XML |
Recommended Option - See Note 2 |
Recommended Option - See Note 3 |
| |
3d |
OAGIS XML |
Don't exist |
Don't exist |
| |
3e |
Other XML |
Unknown |
Unknown |
| 4.0 |
Integrated B2B via 3rd Party (VANs
and ISPs) |
| |
4b |
Legacy EDI formats - ASC X12 and EDIFACT |
Recommended Option - See Note 1 |
Recommended Option |
| |
4c |
RosettaNet XML |
Recommended Option - See Note
2 |
Recommended Option - See Note
3 |
| |
4d |
OAGIS XML |
Don't exist |
Don't exist |
| |
4e |
Other XML |
Unknown |
Unknown |
| 5.0 |
Web Applications |
| |
5a |
Buyer's Web Application (using Web forms),
with or without back-end integration |
|
|
| |
5a1 |
Buyer manages own Web application in own Extranet |
Recommended Option |
Recommended Option |
| |
5b |
Seller's Web Application (using Web forms),
with or without back-end integration |
Recommended Option |
Recommended Option |
| |
5b1 |
Seller manages own web application in own extranet |
Recommended Option |
Recommended Option |
| |
5b3 |
Third-party Web application used, with seller-specific
forms/templates |
Recommended Option |
Recommended Option |
| Emerging Technologies |
| 6.0 |
Collaborative (shared)
Applications |
| |
6a |
Trading Communities - Exchanges, Hubs, etc. |
Not applicable |
Not applicable |
| |
6b |
Collaborative (shared) Web application, with
or without back-end integration |
Still emerging |
Still emerging |
| 7.0 |
Web services |
Still emerging |
Still emerging |
|