Does anyone know how to force Epicor (10.1.500) to look up the unit price of a returned item based on the actual part number returned rather than whatever part was on the order line? This situation is better explained with an example.
Assume we sell fully-assembled Mr. Potato Head figures and a customer buys three of them @ $100 each. My sales order line is $300. Suppose the customer returns just the noses, each of which we sell separately for $15.00
So we do an RMA, changing the part number on from MRPH (Mr. Potato Head) to NOSE. The customer sends back three noses and we receive three noses.
Now we want to create a credit memo for the noses. However, when create the credit memo, the part number is correct (NOSE), the quantity is correct (3), but the Unit Price is wrong. The Unit price is $100, the unit price of MRPH, not $15, the unit price of NOSE. The system is looking up the unit price based on the original order line, not based on the number of the part that was actually returned.
When processing the DMR, there is a checkbox that says “use current costs” which brings in the correct cost. There is no similar checkbox on the credit memo.
And a related point… The InvDtl table records the cost of the entire sales line (3 MRPH). If we are going to do margin reporting out of the InvDtl table, this is really going to mess up our reporting.
Sam, if the order is still open, could you add the component part as a separate line as if you’d shipped an additional product (in comments can explain that a kit component was returned) and accept the return-memo as payment for it? Then it could be shipped and “invoiced” on a separate packer. If you were going to use miscellaneous shipments/invoices as a workaround, would the documentation have an acceptable appearance for Finance? Best, …Monty.
I think we would still run into a mismatch, just of a different kind. Am thinking that we might need to create either a BPM (about which I know nothing at the moment) to automatically update the InvDtl with the correct cost OR an updatable BAQ where we could manually update InvDtl. Not crazy about either solution; I really think the system should populate the CM based on the actual part…
Am going to submit to Epicor and see what they say. Someone has figure out this is a problem with DMRs because there is a checkbox there to address it. Why they didn’t extend that to the CM, I don’t know.
And the Epicor answer is … “working as designed” per the developers. Does anyone know how to get someone at Epicor with an accounting background to look at this? It just doesn’t make sense that the system would pull in a cost that is not the cost of the part.
This problem must have been identified for the DMR process because the DMR panel has a checkbox that says “use current cost.” Checking this box forces the system to go get the current cost of the part that is actually being returned.
If the system is not going to work correctly (at least from an accounting perspective), it seems like the user should have some mechanism to make it work correctly. We do margin reporting based on the InvDtl table and these items either have to be completely excluded or manually adjusted. Not ideal.
Does anyone know if there is a way to escalate beyond the “working as designed” answer?
Would creating a miscellaneous credit be a workaround for your situation? Our company works mainly in custom products and we’ve used that in the past to return an item that is not getting put back into inventory but still needs to be credited.
We were trying to maintain the link to the original sales order and line. I might just use an updatable BAQ to change the value to the correct one (assuming I can update that value). That seems easiest right now.