EIDX Home  
  About EIDX  
  Benefits of Membership  
  Business Process  
Current Projects
Clickable Business Models
Business Model Navigational Help
Business Model Development Methodology
Business Model Legends
  Education  
  Guidelines & Standards  
  Technology  
  Reference Materials  
  Meetings & Events  
  Discussion Forums  
  Community  
  Presentations  
  Work Groups  

LOGIN
PASSWORD
remember my login
forgot my password

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



home | about CompTIA | events | press room | members only | certification | initiatives | contact us

© 2004 The Computing Technology Industry Association, Inc.
All rights reserved.