Default Unit Price for 2-Step (Warehouse to Warehouse) Transfers

Hi ​@Michaelh 

Were you able to find any other solution? We are facing the same issue when doing Transfer orders due to custom requirements we need to have pricing. I am leaning towards editing report so it will pick prices from Sales Price tables. 

Thank you!

Ishara

Thank you ​@Michaelh ! 

I am trying to understand the solution here , is the solution regarding Custom Report to a Project? ​@Michaelh . Do you mind sharing some screenshot for understanding , thank you !!

The problem was that Customs needed to know what the cost of the item was for DUTY calculations. A Sales Order of type TR does not hold that value. So you can’t just grab the data nicely.

The solution (for me) was to bind the Sales Order Lines (SOLine) InventoryID’s to the Stock Items (InventoryItem), which hold my current costs that Customs needs. 

HI  ​@Michaelh  , by saying bind the Sales Order Lines (SOLine) InventoryID’s to the Stock Items (InventoryItem), are you referring to GI ? I tried but no result on TR

Sorry, I wasn’t clear in the exact solution. I bound to my inventory Item to get things like my HTS Code which I store as an attribute.

Option A (Your vendor costs are semi-static):

To get the last known Vendor Cost, you can bind to this table: InventoryItemCurySettings this has a field called LastStdCost and this holds the last known vendor cost for the item. I will warn you though, that this can give you bad information as it is possible your company has changing costs with the vendor (if the cost has changed between applying duty and purchasing).

Option B (always right, but you likely need a helper field):

If you have moving vendor costs, your best bet is to tie back to the Purchase Order “PO” as this is ALWAYS correct. You would need an identifier to know which PO this is. So maybe have your team store the PO Number or some other identifier on the header of the Sales Order (SO of type TR). You can make a User Defined Field (UDF) for this. Now you would be able to bind to the Purchase Order Lines (POLine) using the PO Number and the Inventory ID. The POLine holds the unit cost that is always right, but it is a bit more work to track because you would need a UDF built and maintained by your staff.

My Specific Scenario (just in case this is what you’re needing):

I did mine in Report Designer so I could pull in sub-totals etc. We track duties by the Shipping Container so my use-case is rather complex since I am accounting for multiple PO’s on a single shipping container and need to know the duty applied per container. We store the Container number on our PO’s and on our SO’s of type TR, which is the identifier I use for linking. We also have multiple lines with the same item on a PO (each line representing a different customer’s supply), so I had to use grouping and aggregates. None of these play very nicely in GI’s, which is why I used the report designer for my solution. This method requires multiple UDF’s to be maintained.

Thank you ​@Michaelh  for the explanation. The goal of finding a solution is to avoid manual entry for our team on SO Type TR for inter‑warehouse transfers. While the solution you shared is helpful, I believe it may not be applicable in this case. It appears that addressing this requirement would require additional implementation through coding. 

Yeah this area still needs work from the Acumatica Devs. The first method doesn’t require any extra maintenance/fields, but does have the risk that your pricing changed from the time of purchase to the time of applying duty.

You are not alone in grumbling at this one my friend!