Multiple stk-plt transactions for one TF shipment

Hello!

We have ran into a rather odd issue with transfer order shipments regarding the part transactions. If we look at a specific pack in PartTran we see:

Also - when I go into the Transfer Order Shipment Entry, the order shows as not shipped, but the ‘Shipped To Date Quantity’ is showing as twice the original amount.

image

How can we fix this, and does anyone know what could have caused this? Can we fix this without a datafix?

running PartBin QOH From Part Tran and the Refresh Part Quantities and Allocations processes does not fix the issue

MFG-STK lets you also do Negative Transactions… I wonder if you can do a negative TO? The SysTime’s are different, could it be the button to submit or something was pressed multiple times.

I cant do a negative to :frowning: , or a manual inventory adjustment. This shipment was inputted via our integration api calling the Epicor BOs, which makes it even harder to reproduce. We had many packs with this issue on only one day, and the problem has not happened again.

Are the QOH values wrong? And if so, are there matching extra PLT-STK transactions from the source plant? You could correct the problem with a couple of transfer orders in the opposite direction

Also, doesn’t the Qty shipped on the TO shipment indicate how many have shipped against the original TO, and not the Qty by this TO shipment.

And do those three STK-PLT transaction. Have the same TO Packer number?

Hey Calvin, the QOH values are wrong and there are no matching plt-stk transactions. Simply somehow, our integration API marked these packs as shipped multiple times. I’ll test tomorrow doing a tf in the opposite direction! That’s a good idea. The 3 stk-plt transactions do have the same pack num

Don’t forget to change the plant in Part Tran History, before looking for the PLT-STK trans.

Did the shipment actually occur? If it was just a paper transaction, is that TO shipment available to be received in the other plant.

I assume if you mark the current TO shipment as SHIPPED, it would take another 2100 out of stock. (Which woukd make your problem even worse)

And one last thing, those part tran records are all with the same sign, correct? I ask because I’ll often see 3 trans of the same type when a user: ships, then “un-ships” by changing status from Shipped, then “re-ships” by changing it back to shipped. That middle transaction would have the same qty, but with opposite sign.

What do the TOShipDtl records loom like for that TO?

1 Like

The shipments did actually occur. Here is another example:
In PartTran:
image

In TfShipDtl:

On the transfer order shipment for this part:

image

cannot unship as it has been received in

There are matching PLT-STK trans for the extra STK-PLT transaction. So at least that balances.

You could create a TO to ship the “extra” back to the source plant. This would remove the phantom extra QOH in the original destination plant, and offset the QOH that’s “missing” from the original source plant.

The 4 STK-PLT PartTran records are all identical, except for TranNum, SysTime, SysRevID and SysRowID?

Can you give us any details on your: “integration api calling the Epicor BOs” ??

1 Like

Thanks Calvin for all of your assistance. I ended up just updating the PartTran transactions to negative via the PartTran business object

Hi Jeff
Could you solve this issue? I have same scenario with the native process of Epicor. Every day I need to request a datafix to delete extra PartTran registers and then run Refresh PartBin QOH from PartTran process.