Purchase exchange orders enable your company to purchase serviceable parts in exchange for unserviceable parts, which are sent back to the supplier.
The unserviceable part will, in one way or another, serve as a portion of the payment for the new serviceable part. The affect on pricing will involve one of the following scenarios.
When you send the exchange component to the supplier, you will use the customer order process. This allows you to reserve, pick, and ship the part and all the documents connected to it. You can send the exchange part to the supplier either before or after receipt of the new part.
Before you can work with purchase exchange orders, you must set up the required basic data. This includes:
You can initiate the purchase exchange flow from three places:
* From the work order requisition.
* From the normal purchase requisition.
* Directly from the purchase order.
When you select the purchase order line that should be handled as an exchange order line, you can also enter all available data about the part that will be handled as an exchange component. However, these additional details are not required at this point. As we are exchanging parts in a one to one relationship, only order lines with a quantity equal to one is allowed in the exchange order flow.
Note that once you have specified that a requisition or order line is an exchange order line, the system will retrieve the exchange price specified for the part if an exchange price has been specified on the part record. If no exchange price was specified, the system will retrieve the normal price for the part.
When you release the purchase order, a customer order is created to handle the delivery of the exchange component to the supplier. That means that a minimum amount of information about the exchange component must be entered before you release the purchase order, so that a customer order can be created.
You can deliver the exchange component either before or after you receive the new part.
When you deliver the exchange component, it will be handled by a normal customer order flow. If the exchange component has a serial or lot/batch number, keep in mind that you will be able to reserve and deliver only the part with that specific serial or lot/batch number.
Also, you will not be able to create a customer invoice for the exchange customer order line.
The receipt and invoice matching for the new part follows the normal purchase order flow.
If you paid a core deposit and you receive a credit invoice for the core deposit amount, register the invoice as a normal credit invoice from the supplier. This will allow you to match the invoice using the normal invoice matching process.
As mentioned above, there are two different pricing methods within the exchange flow. Using the first method, you pay a reduced price for the new part. Using the second method, you pay the full price for the new part, including a core deposit, and you will receive a credit invoice for the unserviceable part from the supplier.
Let's say that the supplier's price list looks like the following. (On this price list, the outright price is the normal price when you purchase a part in the condition indicated.)
Part No | Condition | Outright Price | Exchange Price | Core Deposit |
EXCH-1 | New | 1500 | 1200 | |
EXCH-1 | Repaired | 1200 | 900 | |
EXCH-2 | New | 1500 | 1500 | 300 |
EXCH-2 | Repaired | 1200 | 1200 | 300 |
Using the reduced price method, if you purchase a new EXCH-1 part, you will pay the price listed in the Exchange Price column. The supplier estimates the value of an unserviceable part to be 300, and thus when the unserviceable part is returned to the supplier, the supplier will charge you only 1200 for the new part, rather than 1500 (1500-300 = 1200).
Using the credit invoice method, if you purchase a new EXCH-2 part, you will pay the full price (1500). Then, when the supplier receives the unserviceable part, the supplier should issue a credit invoice in the amount corresponding to the core deposit value (300). The credit invoice can later be matched in the normal supplier invoice matching flow.
The M142 - Exchange Cost in Purchase posting type is used in the exchange flow both at delivery of the exchange part and receipt of the new part into stock.
Since exchange flow transactions affect accounts payable, the M142 posting type is by default connected to the same account as the M10, M14, and M18, delivered not yet invoiced posting types.
Several factors can affect exchange flow postings, but all factors fall under one of the three different scenarios listed and discussed below.
In this scenario, the delivery of the exchange component generates an EXCH-SHIP transaction based on the inventory value of the part.
System Event | Posting Type | Posting Type Description | Debit/Credit | Quantity On Hand |
EXCH-SHIP | M1 | Inventory | Credit | Decrease |
EXCH-SHIP | M142 | Exchange Cost in Purchase | Debit | Decrease |
The arrival of the new part generates an ARRIVAL transaction, which will be split into two system events: one normal ARRIVAL event and one PO-EXCH event. The PO-EXCH event is created to reverse the exchange posting created upon delivery of the exchange part and to post the correct value on M10. The value of the total transaction is: purchase order price + exchange cost. (If the part is standard-cost handled, the total transaction value equals the standard cost).
System Event | Posting Type | Posting Type Description | Debit/Credit | Quantity On Hand |
ARRIVAL | M10 | Receipt with Purchase Order | Credit | Increase |
ARRIVAL | M1 | Inventory | Debit | Increase |
PO-EXCH | M142 | Exchange Cost in Purchase | Credit | Increase |
PO-EXCH | M1 | Inventory | Debit | Increase |
The invoice amount for the new part will be the reduced price, and the invoice will be matched against the ARRIVAL system event (not the complete arrival transaction).
In this scenario, the arrival of the new part generates an ARRIVAL transaction, which will be split into two system events: one normal ARRIVAL event and one PO-EXCH event. The PO-EXCH event is created to reverse the exchange posting, which will be registered upon delivery of the exchange part and to post the correct value on M10. Since the delivery of the exchange part is not yet registered, an estimated value of the exchange component is used. The value of the total transaction is: purchase order price + estimated exchange cost. (If the part is standard-cost handled, the total transaction value equals the standard cost).
System Event | Posting Type | Posting Type Description | Debit/Credit | Quantity On Hand |
ARRIVAL | M10 | Receipt with Purchase Order | Credit | Increase |
ARRIVAL | M1 | Inventory | Debit | Increase |
PO-EXCH | M142 | Exchange Cost in Purchase | Credit | Increase |
PO-EXCH | M1 | Inventory | Debit | Increase |
The invoice amount for the new part will be the reduced price, and the invoice will be matched against the ARRIVAL system event (not the complete arrival transaction).
The delivery of the exchange component generates a EXCH-SHIP transaction based on the inventory value of the part. If the actual inventory value does not equal the estimated exchange cost used upon arrival of the new part, difference postings are created to resolve possible imbalances on the exchange account.
System Event | Posting Type | Posting Type Description | Debit/Credit | Quantity On Hand |
EXCH-SHIP | M1 | Inventory | Credit | Decrease |
EXCH-SHIP | M142 | Exchange Cost in Purchase | Debit | Decrease |
EXCH-DIFF- | M142 | Exchange Cost in Purchase | Credit | No effect |
EXCH-DIFF- | M19 | Price diff Purch, HIGHER PRICE | Debit | No effect |
EXCH-DIFF+ | M20 | Price diff Purch, LOWER PRICE | Credit | No effect |
EXCH-DIFF+ | M142 | Exchange Cost in Purchase | Debit | No effect |
When a core deposit is paid, the arrival transaction will not be affected at all. The delivery of the exchange component will generate a EXCH-SHIP transaction based on the inventory value of the part.
System Event | Posting Type | Posting Type Description | Debit/Credit | Quantity On Hand |
EXCH-SHIP | M1 | Inventory | Credit | Decrease |
EXCH-SHIP | M142 | Exchange Cost in Purchase | Debit | Decrease |
The value posted on M142 will then be reversed upon matching of the credit invoice received from the supplier. The matching process uses M18 instead of M142, just as the normal invoice matching flow uses M18 instead of M10.
System Event | Posting Type | Posting Type Description | Debit/Credit | Quantity On Hand |
APINVOICE | M18 | Purchase | Credit | No effect |
APINVOICE | IP1 | Supplier Debts, Invoice | Debit | No effect |