Anyone ever try to figure the value of transfers with a BAQ?
(We use standard costing in both sites, but different standards.)
First challenge:
The normal fields (like MtlUnitCost and ExtCost) in PartTran work on outbound (like STK-PLT). But inbound, it’s wrong.
Inbound transactions (like PLT-STK) show the MtlUnitCost as the oubound cost as if that’s what goes to the receiving site, and it’s not, ultimately; it’s their standard. (Outbound cost is what goes in and out of the In-Transit account, though. So I guess that makes sense.)
It seems to me that for inbound, you have to use BegMtlUnitCost or AfterMtlUnitCost (they are identical, I guess) and add up the pieces and multiply by the quantity.
Second challenge:
Matching up MFG-PLT transactions to corresponding PLT-STK transactions. MFG-PLT doesn’t reference the pack number. So how to see the outbound vs. inbound costs? I guess no one cares in the aggregate. Totals are fine.
I think this makes sense. Just talking through it and seeing if anyone has any experience with this.
Have you looked at the Erp.PlantTran table to see if any of the information in there helps? We use the same standard costs for all of our Sites, so I can’t say for sure that this table would have the right cost(s). We also don’t use MFG-PLT, but PlantTran has a FromJobNum field that I would imagine gets filled in with the source job.
But your problem is that you have a cost for the Part in B, that doesn’t equal the value in WIP when it’s “received” into B?
What cost methods are being used in each site?
Also, I ended up making a BPM to prevent TO Shipments when the unit cost of any parts was zero. Because we had a bad habit of entering the TO shipment prior to receipt into inventory.
No, that’s OK. I mean, yes, they do not equal, but that’s the biz. We use standard in both sites. If we didn’t like the results, that’s just too bad. We should use FIFO or something.
My issue was just seeing the received costs relative to the MFG-PLT transaction. I didn’t have a link to the from Site A cost (at that moment in time!) to Job to shipment to receipt (cost) at that moment in time. Now I think I have a path forward.
Right. And that’s OK. It’s conceivable that one site routinely buys the same part for less than the other site does. (But usually it’s just an oversight.)
Well, yeah, it would be a lot more straightforward as far as querying goes. But direct jobs are nice because you can see WHY you made the part. It wasn’t for stock on the shelf for building trucks - it was specifically to supply the service center.
Here is the BAQ I came up with. It’s pretty simple, once I learned about PlantTran.
Some caveats:
“Directional Cost” is what I used for the values in a PivotTable. I included Outbound and inbound cost in there also, but that was really just for troubleshooting.
I chopped off the plant IDs at 3 characters. That’s all I needed.
“Period” is just a way to filter by month. It’s not a true accounting period.
This shows the net value of the shipment and receipt. If you, like us, ship something, unship it and then reship it, this BAQ grabs only the last value (that’s how PlantTran is set up). This is great because it gives a simple, clear assessment of the value of the transfers. BUT, keep in mind if you try to reconcile the numbers to the Inv-WIP Recon Report, you’ll have to subtract off the value of those unship-reship transactions.
Holy “#$#@” We have exactly the same problem and I was trying say that we are just getting ahead of ourselves and it needs to be policy to receive all before anything happens. Clearly we are not the only ones with the same problem.
FWIW - Our inventory people treat TO’s like they are regular Inventory Transfers. It’s amazing how many TO Receipts happen just minutes after the TO Shipment. To get the product halfway across North America, they must have a secret wormhole in each warehouse.
It’s the opposite here. I can walk to the other site. And at first we had to beg people to receive the transfers. “It’s not automatic?” There was a lot “in transit” that first couple months.