We have a Sales Order that is for Non-Qty Bearing parts. The releases are set to Buy To Order. There are multiple lines with multiple releases. The PO Release was receipted and then the Sales Order line was Packed and Shipped.
When I view the transactions, the Customer Shipment was done at zero cost and so the costs are still sitting in the account that it was receipted to and not moved through to COS. Any ideas??
How do you have STK-CUS trans if it’s not Qty Bearing?
Any chance the Part’s Plant sheet is still set as Qty Bearing?
When we ship a BTO item, it creates a UKN-CUS transaction.
We have a parts class (with GLC) for BTO so when it’s received it hits a special acct. Without the GLC, it would hit our regular inventory.
Edit
Also, make sure the packer line references the SO line and release.
Based on Epicor 9 experience, I could suggest to use part on the fly for BTO parts. If its maintained in Part Maintenance, cost will be picked based on part cost. Since it is a non qty bearing part, cost method will be std, which ends shipped without cost. I used a Part Class for BTO Parts and its part of month end reconciliation.
That reminds me … There is a BTO flag on part master in E10. Maybe this needs to be set for a Part in the part master in order to act like an On The Fly BTO part would.
Hi,
I can absolutely confirm that both the Part.QtyBearing is off and the PartPlant.QtyBearing is also off. No idea how we have a STK-CUS transaction!
@prash172 we use the Receipt Entry (for the PO Receipt) and Customer Shipment Entry for the shipping.
@traceyash
Give it a try with Drop Shipment Entry
Material Management -> Shipping / Receiving -> General Operations -> Drop Shipment Entry
GL account should be assigned for the context “Drop Shipment”
@ckrusen It would seem as though this STK-CUS rather than the UKN-CUS is the issue. When doing a STK_CUS then it takes the cost of the item (which is zero) but the UKN-CUS takes the BTO cost… Not sure why this has happened. The PO is definitely linked to the Sales Order.
The receipt is against this release and the customer shipment is also against it.
This is the Part screen
and the Site screen
@traceyash
Customer shipment entry does no have any reference to the PO which is booked against the sales order. It ships from the inventory which results in “STK-CUS”.
If you use “Drop Shipment Entry” one screen does both the receipt and the shipment. Both SO and PO will have direct relationship.
You are correct that Drop Shipment works even for parts on inventory. If its part on the fly, it work from Customer Shipment entry as well. Many customers prefer receiving goods and then ship instead of Drop Shipment.
BTO flag is available in E9 as well. It doesn’t work well for stock parts as cost is always picked from the part instead of PO due to which we loose the ability to know the true margin. Drop Shipment works well.
Did the qty on receipt and packer exactly match the order release?
Yes.
Why do you have the parts set as Non-Qty bearing? For buy to order parts I would expect them to be:
Qty Bearing = True
Non-Stock = True
Costing = Average
Based on the settings you have part will be received at the cost of the PO and shipped at whatever the current standard cost is.
Well … while doing some tests I found something pretty strange…
The PartTran.Plant field for a UKN-CUS doesn’t populate. The UKN-CUS tran was created from a packer that was marked shipped, referencing Order lines with BTO release. (see 1st and 3rd rows of a BAQ on parttran)
I did the test twice (one in site MfgSys and again in GUTH) The top two rows are the Packer and the Receipt for GUTH.
If I run the Inv/WIP Recon report with “Current Site” selected, it does not show those UKN-CUS transactions. Only the PUR-UKN appear.
Clearing the “Current Site” option on Inv/WIP Recon, yields:
If I created an Invoice (and run the Capture COS/WIP), the COS would go from the A/R Clearing to the specific COS (based on Prd Grp)
BUT
Only the OTF BTO part shows any ___-CUS trans?
While the Part Tran History shows:
(sorry for it being dim)
There is definitely a STK-CUS tran that doesn’t show on the Inv/WIP Recon
Ahh… I think I know why the two parts (ZZ-8000 and ZZ-8001) don’t show on the Inv/WIP Recon. It’s because it uses the STD cost (which is zero in my case), and zero cost part trans don’t create GL trans, so they won’t appear on the Invw/IP Recon
edit
So in my opinion … don’t make Part entries for BTO parts.
I think all of the following is correct:
-
OTF (On the Fly) parts processed as BTO:
- Creating a Order automatically defaults to Make To Order release. You must manually change to BTO.
- Create PUR-UKN upon receipt - Debiting the Inventory GL unless another GL specified (directly on PO or via GLC on Part Class)
- Shipping that OTF part (and referencing the Order Line) creates a UKN-CUS - Crediting the Acct from the PUR-UKN, and Debiting AR Clearing or COS
- The PO unit cost is used for all above trans
-
Part entry that’s non-QB, and non-BTO:
- Creating a Order automatically defaults to neither “Make To Order” nor “BTO” release. You must manually select BTO.
- Creating a PO ( and entering Order and Line info) automatically defaults to Buy For OTHER.
- Receiving the PO line creates a PUR-UKN tran using the PO cost.
- A Bin must be specified. It defaults to the default bin of the warehouse.
- Shipping the line creates a STK-CUS
- A Bin must be specified. It default to blank. Not sure if it must match the bin rcv’d to.
- the STD cost is used for the STK-CUS tran.
-
Part entry that’s non-QB, and BTO:
- Works just like a part entry that’s non-QB, and non-BTO, except the SO release automatically gets marked as BTO.
I assume a Variance transaction would be created for eith of the BTO parts that have a part entry. How else would the cost from the PUR-UKN (from the PO), reconcile with the cost from the STK-CUS(from the STD cost)?
Two things stand out to me on the screen shot for your Part Set-up Screens:
- Why is your Costing Lot Size set to 0.00? You should make that at least 1.00
- Why is your Buy To Order checkbox not checked in Default Site Parameters?
It’s been a long time since I’ve dealt with E9; but also wondering if part should be checked as Non-Stock as well.
Typically speaking, the Site Parameters should reflect how the part is to be processed. By having the mismatch between the part record and how the PO/Sales Order were set-up; it might have prevented Epicor from going through the proper costing logic during the transactions.
Of course, various versions of E9 were a bit buggy, so I would play around with different configurations in a test database until the transactions occur the way you want them to. Sometimes it’s a bit of trial and error; but I have always found that if the Part Record isn’t set up properly, you’ll commonly find transactions not behaving properly. Posting Rules typically rely on both Configurations and Transaction types in their logic. I have also discovered that sometimes Posting Rules themselves need to be adjusted. However, verify that the parts, purchase orders and sales orders are configured properly, and transacting properly, first, before even looking into possible issues with the posting rules.