R42995 - Update Commitment fields

We are having some trouble with item availibility. The units shown in 'committed' are not right. The quantity shown is higher than the quantity in sales orders, caused by integrity issues.

We are using R42995 to update the commitment fields. As far as I know the basis of R42995 is selecting the open sales orders to update the commitment fields.
In some cases the item does not have any open sales orders, so the quantity in the field 'committed' should be zero.

The items are not updated because there is no open sales order.

Does anybody have any suggestions? Does anybody have experience with modifications in R42995 to slect from the item branch/plant.

Thanks in advance.
Dirk Dijkstra

Hi Dirk!

We have solved this by clearing out all the commitments (LIPCOM, LIHCOM) prior to running R42995. The commitments are cleared using a SQL statement run from the scheduler (AS/400). On a NT-site this could be a SQL statement stored/run on the SQL server.
We chose this method in stead of modifying the OneWorld UBE and it has served us well.

Regards..

Aarto's solution is both brutal and elegant. One would think that this is what R42995 should have been doing in the first place.

We ran into this problem early on after our first go live with OW. It didn't happen often because usually, if a commitment bucket has been corrupted, there is an open order that has played a role in the corrupting. When it did happen though, we just had the order desk enter an order for the affected item/branch and immediately cancel it. When R42995 ran that night, the cancelled order in F4211 would trigger recommitment. As long as you are not purging cancelled lines from F4211 before running R42995, this should work.

Dirk,

What can cause the commitment procedure to go wrong depends unfortunately on many things.

A known issue is for instance when a connection error occurs (especially between multiple countries/sites). An order is then created WITH a lot attached, but without a commitment. Or of course cancelled without cancelling the commitment.

The best way to check if a commtment is correct (besides the integrity reports) is the item ledger. Just check which order is open.

Another element is HOW you close orders. Often status codes are simply (manually) changed till 999 WITHOUT removing the lot number. This also keeps the commitment intact.

If you have any questions please let me know.

Kind regards,

Martijn Groeneveld

Hi,

1.- you should run the R42995 carrefuly and create as many version as you change the PO 2nd Tab.
Don't run it with more than 1 calculation at a time.
The best thing is not to have any user connected (or to prevent them of using any progrs that can commit or reserve an order) .

2.- You should also have as many version as you have B/P,
if you can in the data selection have an article restriction (on the category code for ex), in order to prevent the systems for running hours and hours .....

3.- Also check, if the item lot nr is not released, what was previous said about manually canceled line...

Keep us informed

Fred

Yes...HenryP has it. We encountered the same issue and found that the repost ONLY reposts to the F41021 where there is an open order in the F4211. So...a simple solution is to enter a sales order with the part number causing problems, run the repost for that item only, then cancel the sales order.

A good answer was posted recently for this. Run a job every night to clear
the commitment fields for all items, then run the repost. Then you won't
have the problem
of items with no sales orders being skipped--because the commitments would
have already been cleared.

Andy Klee
www.JDEtips.com




Andy Klee
www.JDETips.com

Is there any job that will clear
the commitment fields for all items?

Best Regards//Maths

For what its worth, here is the PL SQL we run each night to set the commitment values correctly for our usahe.

UPDATE PRODDTA.F41021 i
SET i.lifun1 =
(CASE
(SELECT COUNT(p.wmuorg) FROM PRODDTA.F3111 p, PRODDTA.F4801 w
WHERE p.wmcpit =i.liitm AND p.wmcmcu = i.limcu AND p.wmlocn = i.lilocn AND p.wmlotn = i.lilotn
AND p.wmdoco = w.wadoco AND w.wasrst < '90' AND p.wmuorg <> 0 AND p.WMCOMM IN ('S',' ') AND p.WMQNTA < 99999999999999
AND PRODDTA.JDE2Date(P.WMDRQJ) <= (SYSDATE + 999))
WHEN NULL THEN 0
WHEN 0 THEN 0
ELSE
(SELECT SUM(p.wmuorg - p.wmqnta) FROM PRODDTA.F3111 p, PRODDTA.F4801 w
WHERE p.wmcpit =i.liitm AND p.wmcmcu = i.limcu AND p.wmlocn = i.lilocn AND p.wmlotn = i.lilotn
AND p.wmdoco = w.wadoco AND w.wasrst < '90' AND p.wmuorg <> 0 AND p.WMCOMM IN ('S',' ') AND p.WMQNTA < 99999999999999
AND PRODDTA.JDE2Date(P.WMDRQJ) <= (SYSDATE + 999))
END);

COMMIT;

UPDATE PRODDTA.F41021 i
SET i.lipcom =
(CASE
(SELECT COUNT(s.sdsoqs) FROM PRODDTA.F4211 s
WHERE s.sditm = i.liitm AND s.sdmcu = i.limcu AND s.sdlocn = i.lilocn AND s.sdlotn = i.lilotn
AND s.sdnxtr > '529' AND s.sdnxtr <= '560' AND s.sdnxtr <> '541' AND s.sdlttr < '980' AND NOT(s.sddcto in('SQ','MS'))
AND PRODDTA.JDE2Date(s.sdpddj) <= (SYSDATE + 999))
WHEN NULL THEN i.lifun1
WHEN 0 THEN i.lifun1
ELSE i.lifun1 +
(SELECT SUM(s.sdsoqs) FROM PRODDTA.F4211 s
WHERE s.sditm = i.liitm AND s.sdmcu = i.limcu AND s.sdlocn = i.lilocn AND s.sdlotn = i.lilotn
AND s.sdnxtr > '529' AND s.sdnxtr <= '560' AND s.sdnxtr <> '541' AND s.sdlttr < '980' AND NOT(s.sddcto in('SQ','MS'))
AND PRODDTA.JDE2Date(s.sdpddj) <= (SYSDATE + 999))
END);
COMMIT;

If you are on 9.2, there was an enhancement ESU that helps clean up the commitments - R42990 -----

ISSUE: What If No Actives Sales Order Exists Prior to Running the Repost Active Sales Orders (R42995)?

An enhancement is available in EnterpriseOne 9.2. The Repost Inventory Commitment (R42990) has been introduced to address this scenario. See 2230896.1

Problem: When running Repost Active Sales Orders (R42995) for locations that have hard/soft committed buckets filled but no open orders in the Sales Order Detail (F4211) exist, commitments will not be cleared for those Item Locations in the F41021 file.

Solution 1) A "dummy" order must be entered for that specific item so the program will correctly repost the quantities and amounts. The "dummy" order can then be cancelled after running the Repost Active Sales Orders (R42995) program.

Solution 2) Clear the commitment buckets in the Item Location (F41021) prior to running the Repost Active Sales Orders (R42995). This process is more efficient if numerous items need to have the quantities and amounts reposted but do not have an open order in the Sales Order Detail (F4211). This process eliminates the need to create and delete what could be many individual "dummy" orders. Note: This process does require altering data within the file and is not supported by Global Support Centers. If assistance is needed with this process, please contact your Engagement Manager.