EMERALDCUBE BLOG

Manual Rollback Functionality


As an EmeraldCube Application Managed Services Consultant, I get a lot of tickets and questions about incorrect inventory commitments.  And I’ve found that a lot of users are not leveraging the Manual Rollback functionality for F41021 – or maybe are completely unaware of it.

What is the Manual Rollback Process of Item Location (F41021) File (P42210/R42210)?  And when should you use it?  I’ll cover both; let’s get started.

When a transaction error occurs in a Distribution application, all files except the Item Location (F41021) will roll back.  This means that the transaction will be “undone” or removed from the tables such as F4111 Item Ledger, etc.  However, since the rollback is not automatic in the Item Location file, this leads to incorrect commitments in the F41021.

It is common to run the Sales Order Repost (R42995) and the WO Repost (R3190) in attempt to update or correct your commitments.  However, if I have potential rollback records for F41021 hanging out there, I could cause a bigger mess if I don’t deal with those first.  So, before I run either Repost job, I always look in the Work With F42210 Commitments Recover (P42210) for any F41021 records that may need to be rolled back.

For Example:

Item 1144 has a Qty -12 SO Hard Committed.  However, there are no Open SO’s for this item.  I could run the SO Repost (R42995) in attempt to realign the commitments, but I would first have to create a dummy SO for this item to get the system to “see” a commitment, and then later delete that dummy order. ***Unless you are on 9.2 – more on this later…

Instead, l check the Work With F42210 Commitments Recover (P42210) and I find a record I can roll back.

I select the record and Row Exit to “Roll Back.”

Now, I can reinquire on my item in Detailed Availability.  That -12 SO Hard Commitment is gone and my commitments are updated correctly.

*** (9.2 Enhancement) I mentioned earlier that if you ran the SO Repost (R42995) you would need an open SO for that item or you would need to create a dummy order and later delete your order.  What a pain!  On 9.2 and later you can run the Refresh Inventory Commitments (R42990) instead.

The R42990 can be run at the same time you run the R42995.  These 2 UBE’s run over different data sets, so they are mutually exclusive and designed to run in tandem.  The R42990 runs over F41021, F4101, and F4102, refreshing commitments for those items that do not have an active sales order.  The R42995 runs over F4211 and updates commitments for those items on active sales orders.

So, do you want to wait until you notice a discrepancy before looking for records to roll back?  Or do you want to run the F41021 Commitments Recovery (R42210) on the scheduler?  It would be best practice to run the R42210 before you run the reposts,  and it would be best to run all of them while nobody is creating new transactions in the system.

Before you set the R42210 up on the scheduler though, you will want to consider clearing out the F42210 or at least reviewing each record one by one.  There is a possibility that some of those incorrect commitments were cleaned up using SQL.  If so, rolling back the commitment could create a new problem requiring SQL clean up.

Nichole’s Commitment Correction Checklist:

  1. Review P42210 for potential rollbacks.
  2. Research each rollback, and match it to an invalid open commitment in F41021.
  3. Ensure no SQL fixes have been done.
  4. Perform necessary rollbacks, and delete unnecessary ones that have been corrected via other means.
  5. Either schedule or regularly run R42210, followed by SO/WO reposts, to keep your commitments clean.

Follow the above rules, and your users’ commitment issues will be gone forever – well, at least greatly reduced.