@ckrusen For OTF BTO Parts, it’s better to create a separate Part Class (ZBTO) as its a clearing account. If it pointed to inventory, it will cause a reconciliation issue with inventory account as GL will have value but not in-stock status.
@Carson Issue with using Average cost is we may not get a true margin on the sales as one part we might purchase at $100 and another at $500.
Our non Qty Bearing parts are set to last cost.
We have 10000’s parts and this particular part (called recharge) is if we need to buy something specific for the client to be sent with other parts. We don’t want to create another part number for this. We use a part number so that it pushes the product group and part class correctly so the sales people don’t have to choose!
Yes that is what I have seen. I suppose the question is why (we have our non qty bearing parts set to last) does it not pull through the cost to cos (don’t care which account) and why is the transaction set to stk/cus. Surely it should be ukn-cus when it is not qty bearing.
1 Like
@TDudek Thanks Timothy.
We are in fact on Epicor 10.2.400.
I don’t know about why our costing lot size is set to 0, i will give that a try. Our non qty bearing parts are set to Last and our Qty bearing parts are FIFO.
The BTO flag is not set as we don’t always want to order this item for the customer. The sales person will select on the sales order if they will or not. My understanding of this flag on the site, is just a default for the sales order release.
The issue seems to stem from the fact that Epicor set the transaction type to STK-CUS rather than UKN-CUS and as such the posting rules are different.
According to the Inventory Technical Reference, it should be UKN-CUS!
1 Like
We use a specific part class for BTO, with a GLC too.
The issue is that BTO part that has a part entry, will use the STD cost for the part and not the actual cost from.the PO.
If you are purchasing it direct it doesn’t pass through inventory so it doesn’t get averaged with other inventory. It will use the cost on the PO.
1 Like
That is what I would assume but as the transaction type is STK-CUS it doesn’t use the PO cost but does the transaction at zero.
I cannot work out why it does it as STK-CUS and not UKN-CUS.
Wow! I had been confused why this thread was going on so long.
After testing I would say Buy To Order doesn’t cost correctly. (10.2.600) I apologise for adding confusion. 
I looks like there’s supposed to be a different transaction type involved.
I have a customer who creates more than 100 POs monthly for BTO for last 7 years on E9. Conceptually BTO looks simple but its not.
So the trick was that it had to be ‘NonStock’ as well as not Qty Bearing. This will then make the trantype to be UKN-CUS and all works as expected.
1 Like
Good to know. I was always under the impression that the Non-Stock was for planning.
So to be clear…
-
OTF (not in Part table):
- PUK-UKN on receipt
- UKN-CUS on shipment
-
Part entry exists with cleared Qty Bearing, and Non-Stock flags:
- PUR-UKN on receipt, costed at PO price
- STK-CUS on shipment costed at PartCost and Method
-
Part entry exists with cleared Qty Bearing, but checked Non-Stock flags:
- PUR-UKN on receipt, costed at PO price
- UKN-CUS on shipment, costed at PO price
As for that STK-CUS tran that’s not equal to the PUR-UKN cost, does some sort of variance get created?
If no part or part class GLC’s are in play, the PUR-UKN of a BTO part hits Inventory. The STK-CUS does as well.
So if the part has a STD cost of $100, and a PO is placed for one at $125, the PUR-STK debits Inventory by $125. But the STK-CUS would only credit inventory by $100.
I’ve been meaning to follow-up on this. As soon as we clear the Qty Bearing flag on a part, the Cost method switches to STD, and becomes disabled.
How do you set your non-QB parts as LAST cost method?
Many Epicor reports, including the Inv/WIP Recon report, do not show the transaction if the Dr/Cr amounts are zero. There most certainly is a STK-CUS transaction because it was entered on the Pack Slip. The Part Transaction History Tracker tells the ENTIRE story that the Inv/WIP report may not. Since the part is marked as non-qty bearing, the system figures that if you don’t care for it to keep track of the QOH, then there is nothing for it to attach a cost to. The qty shipped will record in the Part Tran History because it has to record what has actually happened, but it doesn’t affect the Running Total, and since you didn’t want it to keep track of the QOH, it doesn’t have to keep track of any costing, either.
So, when the item is received, the cost will hit whatever account is on the PO, Part Class, or default inventory account. But, that cost will never come out because it is not attached to any quantity. Typically, non-qty-bearing parts are expense-type items where the entire cost goes into an expense account. In order for costs to be attributed to a part, it needs to be qty-bearing. My customer also uses a separate GL account to segregate BTO-type items from regular inventory items.
HI @Laurice,
After speaking with Epicor, this is not the case. In fact we have discovered that in order for the costs to come ‘out’ of the Inventory account, the BTO flag must be set on the Part. This it potentially an issue and not the intent of Epicor. We have raised a ticket and the Development team are currently looking at it. The program doesn’t look at the BTO flag on the Sales Order when defining the Tran Type of the transaction and it should. If the Transaction is a UKN-CUS then it will take the cost of the Purchase Order through to the appropriate cost of sales account on the Sales Order.
In the short term, we have created some specific BTO Parts.
1 Like
Has this resolved yet? I’m looking at this and I’m in the same situation.
What process can have PUR-CUS type?
According to the Inventory Transaction Hierarchy, PUR-CUS is “Purchase receipt for Buy to Order parts shipped to customer”
Is it setup in Part maintenance? We have part setup to buy to order, but for some reason transaction go through inventory, PUR-STK then STK-CUS.
There is a Buy to Order checkbox on the Sales Order Release window that triggers that functionality.
According to the system help, “Buy to Order” on the SO Release should be checked automatically if the part is set at the Sites > Detail level.
First step, look at one of the sales orders for that part and see if “Buy to Order” is checked on the Sales Order Release form.