CompTIA EIDX Supporting Documentation for Business Model Scenarios

Consignment Base Model and Variations
There is a basic, traditional “Seller Consigns to Buyer” business process. EIDX’s Consignment Scenario 1 deals with this basic process.  Most consignment business processes are a variation of the base process, and can work off of this base model. EIDX business models are needed for core, commonly used variations.

Variation may have to do with —

• Contractual terms
• Combining consignment with different replenishment, sales reporting, financial business, and/or other business processes

Variation in Contractual Terms - The contract between parties using a consigned inventory process may specify that transfer of ownership takes place, e.g. when buyer physically moves parts from seller’s stores or when at post-deduct. This does not change the base model, but rather the timing of events.

Variation in Business Process Combinations  - Consignment simply defers the transfer of ownership of and payment for goods, and can be combined with almost any other business process.  For example: If consignment is used in combination with an invoice-less payment model, the buyer’s system may be set up for pay-on-consumption (compare to pay-on-receipt), and the seller does not need to send an invoice.  Report of usage may be embedded in a forecast or payment transaction, instead of being sent in a discrete transaction/message. Such variations do change the base model.

Three Party Models - Three-party models are more often than not composed of a series of two-party models.  Some models that appear to be multi-party at first may really be two-party models; the difference may be that the two parties need to make reference to a third-party in the data that is exchanged.

Why Consignment?
Consignment processes are initiated for business reasons decided between trading partners. EIDX will make no recommendations as to whether/when consignment should be used. However, EIDX will recommend guidelines for business models and transactions/messages to be used in support of consignment processes in order to clarify processes for implementing consigned inventory programs, resulting in decreased implementation cycle time. 

The reasons given for engaging in consignment processes include:

• Deferring transfer of title/delay payment for inventory
• Assurance of supply
• Minimize transportation costs by shipping from distributed consignment warehouses
• Optimization of manufacturing process, economies of scale
• Can focus on core competency
• Minimize risk of obsolescence (for the buyer)
• Payment can be contingent upon completion of final product (postpone transfer of title until finished good passes quality testing or is shipped/sold)
• Facilitate the delivery of product closer to the consumer
• Can facilitate more rapid inventory turns

Roles Participating in Consignment Processes
Consignment processes can involve any type of organization.

• Service Contractor/Provider
  • Repair Center
  • Contracted to perform a service
• Contract Manufacturer
• Supplier
  • Component Manufacturer
• Manufacturer, including OEM
• Buyer
• End-customer
• Contract Manufacturer
• Distributor
• Reseller
• Value-Added Reseller
• Retailer
• Logistics Provider (3PL/4PL/Forwarder/Carrier)
• Inventory Management provider
• Third-party warehouse
• Government
  • Customs, etc.
• eMarketplace/Auction house
• Consolidator
• Broker/Agent
• Floor Plan Financer

Considerations
There are going to be a variety of ways that information is transferred in consignment processes.  How usage is reported and replenishment is triggered may depend on which Order and/or Forecast/Planning Model is being used in conjunction with a Consignment Scenario, as well as upon contractual terms agreed between trading partners.

What makes consignment processes complex is not so much the flow of data, but rather the contractual issues and the application interfaces and other factors.  The following need to be considered when implementing a consigned inventory process.

1. What is "possession"?
   1. Based on contract between parties
   2. Define what's consigned inventory vs. allocated inventory
   3. What about in-transit inventory?
2. Who manages inventory?
3. What are the terms of liability for the inventory in the case of loss or destruction?
   1. What can the inventory owner bill the inventory possessor for?
4. How will the inventory owner access the inventory for audits?
5. What method of cycle counts and what frequency?
6. What are the terms of payment?
7. How will consignment impact on Replenishment planning?
8. What is the inventory aging process?
   1. Will the terms include terms for stock rotation?
9.  What will the start-up process be?  How will the initial stocking of the consignment warehouse be handled?
10. Are there any hazardous materials issues to consider?
11. Which messages/business documents will be used to communicate info (XML, EDI, fax, etc.)
12. Are there any issues regarding Taxation of consigned inventory?
13. Are there any issues with cross-border/customs clearance, inventory traveling in bond, or other import/export issues?
14. Is inventory being passed to or from a free-trade zone?
15. Does the consignment program involve inventory for service and/or repair where the repair service provider never takes ownership?

Inventory Audits and Reconciliation
Inventory needs to be accounted for when it is physically located in one party’s warehouse (may be buyer’s warehouse or third party’s warehouse) but owned by another party (e.g. seller). For example, the consignee (buyer) may need to show inventory data on their system so they can report it to the consignor (seller), but the consignee does not want to show that inventory on their books. Conversely, the consignor needs to show inventory on their books that is not physically located on the consignor’s property.

Back-End Applications and Consignment
A typical problem that occurs when a consignment process is implemented is that it is discovered that back-end applications, especially legacy applications, are lacking sufficient functionality.  The buyer's application may not be set up to track inventory by supplier and order number.  For consignment, the following is needed:

• The supplier's application needs to show inventory that's on the books but not in possession:
  • Inventory quantity by customer and by location
  • Where the inventory is located
  • The purchase order number associated with the inventory
  • Inventory is not available, including not available as allocation for future shipment
• The buyer's application must show inventory that's in possession but not on the books:
  • Inventory quantity by supplier and by order number
  • The consignment warehouse location
  • The purchase order number associated with the inventory

Reconciliation Mechanisms
Consigned inventory processes must have a reconciliation mechanism of some kind. In all business models for consigned inventory processes, an optional step for inventory reporting is included. Inventory reporting is done for audit purposes, inventory balancing, and reconciliation. This inventory reporting supplements physical audits which the consignor (owner of the inventory) performs on inventory physically located at the consignee’s facility.

As part of setting up a consignment process, partners should discuss how inventory audits and reviews are going to be handled, including the following:

• How  are inventory quantities are determined? By physical count of individual components, by container, by weight, etc.?
• How is clerical accuracy ensured/audited?
• How is consigned inventory stored?  In the same stores as non-consigned inventory or a separate stores?
  • If the same item is consigned by more than one supplier, can the inventory be distinguished both physically and in the inventory management system?
• How is damaged or lost consigned inventory dispositioned? Is it tracked separately from non-consigned inventory?

Inventory Activity and Transfer of Ownership (TOO)
As mentioned above, the contractual agreement between trading partners may specify what event triggers transfer of ownership, and therefore triggers the billing/payment cycle.

Just as the buyer's application may not be set up to track inventory by supplier and order number, the back-end application may also not have functionality already built-in to know when the Transfer of Ownership has occurred and therefore when notification should be sent to the inventory owner.  It is desirable to make the transfer-of-ownership event configurable, so that the buyer has the flexibility to have different transfer-of-ownership events with different suppliers.

The following is a non-exhaustive list of points at which transfer of ownership might take place.

Inventory activities that may trigger transfer of ownership but typically do not trigger transfer of ownership of consigned inventory:

• At shipment from seller to buyer
• At notification of receipt of goods from buyer
• When Ship Notice is issued by seller
• When product moves from buyer’s receiving dock to seller’s warehouse at buyer’s plant

Inventory activities that can trigger transfer of ownership of consigned inventory:

• When product moves from seller’s warehouse at buyer’s plant to buyer’s stockroom
• When product moves from buyer’s stockroom to buyer’s shop floor (to WIP)
• When product moves from buyer’s shop floor (WIP) into buyer’s finished goods
• When product shipped to end-customers from buyer’s finished goods

Reporting Inventory and Transfer of Ownership Events
There is more than one option for reporting inventory and  transfer-of-ownership events because reporting an event that triggers transfer-of-ownership in a consignment process very often means using a business message that is already being exchanged, and may or may not require the addition of a data element or two. 

There is often confusion between Consignment and Supplier-Managed Inventory (SMI) because the same choice of business messages used to report inventory events that may be used to trigger replenishment.  Frequently, trading partners engage in programs that combine Supplier-Managed Inventory and Consignment.  This is really not as complex as it sounds if one realizes that the former is about deferring planning of inventory replenishment, and the latter is about deferring billing and payment.  When replenishment needs are evaluated, it is the inventory in the consignment area that is evaluated.  When the transfer of ownership occurs, that inventory is no longer part of the consignment stores and needs to be replenished.

• In Consignment with Consumption-based SMI (Consignment Scenario 2), reporting of usage (consumption or resale) may trigger both billing and replenishment.
   
• In Consignment with Forecast-based SMI (Consignment Scenario 3), reporting of usage is not the primary trigger for replenishment.  The Consumption Schedule (Forecast Model 3) is the primary consumption trigger, but the buyer may report inventory consumption or resale activities that have occurred so that the supplier can monitor the activity.  This activity may be included in the Consumption Schedule, or may be sent separately if this activity needs to be reported more frequently than the consumption schedule in order for the supplier to keep inventory continually replenished in between iterations of the Consumption Schedule.

The following are the options for reporting inventory activities and transfer-of-ownership events.

1. If the consignee (usually a buyer in 2-party consignment) is already sending an inventory report to the consignor (usually a supplier in 2-party consignment) per Inventory Management Model 1, that may be used to report inventory activities and transfer-of-ownership events (most commonly used triggering event is buyer's in-house consumption).  Reporting of usage does not automatically trigger replenishment in most Consignment and Replenishment Scenarios, but may trigger Replenishment. 
    
2. If the consignor needs consumption of inventory reported separately from or more frequently than a consumption schedule or a standard inventory report, a report containing only consumption events may be used (Inventory Management Model 4).
   1. Inventory Management Model 4:  Consignee reports usage to trigger transfer of ownership and Billing/Payment cycle.  Usage is in-house consumption.  Reporting of usage does not automatically trigger replenishment in most Consignment Scenarios.
       
3. If the consignee is already sending a point-of-sales report to the consignor, that may be used to report transfer-of-ownership events (most commonly used event is resale of goods).  The Sales Reporting Scenario used depends on how many tiers of supply chain partners are involved in the reporting.
   1. If the buyer is required to report details about end-customers, use Inventory Management Model 2.
      1. Inventory is physically located at consignee’s facility. Consignee reports resale or transfer to trigger transfer of ownership and Billing/Payment cycle.  Consignee may report detail (names/locations) of sold-to/ship-to, and/or ship-from parties. Reporting of usage does not automatically trigger replenishment in most Consignment Scenarios.
   2. If the buyer is not reporting details about end-customers, such as in retail sales of fast-moving consumer goods, use Inventory Management Model 3.
      1. Inventory is physically located at consignee’s facility. Consignee reports usage (in-house consumption or transfer/resale) to trigger transfer of ownership and Billing/Payment cycle.   The consignee does not report details about end customers, but may report details about inventory activity.   Reporting of usage does not automatically trigger replenishment in most Consignment Scenarios.
4. If the consignee is already sending a supplier-managed inventory forecast (Consumption Schedule) (Forecast Model 3 component of Replenishment Scenario 4), the consumption data may be included along with the other inventory data, and can be used to trigger billing.