Update F41021 Table

Samukelo

Member
Hi,

I am a junior Developer in JDE and I am having trouble with updating F41021. I followed the documentation I read on Oracle support on how to go about updating a record in JDE. I ran the report with the below ER Code, the report runs successfully but doesn't update the table as required and doesn't show an error. What am I doing wrong or missing in my approach? Any suggestions will be highly appreciated.

VA rpt_QuantitySoftCommitted_PCOM = 1
VA rpt_QtyHardCommitted_HCOM = 1
VA rpt_QtyOnFutureCommit_FCOM = 1
//
F41021.Select
/*VA rpt_IdentifierShortItem = BC Item Number - Short (F41021)(ITM)
VA rpt_CostCenter = BC Business Unit (F41021)(MCU)
VA rpt_Location = BC Location (F41021)(LOCN)
VA rpt_Lot = BC Lot/Serial Number (F41021)(LOTN)*/
// Showing the mapping of the Select
F41021.Fetch Next
While SV File_IO_Status is equal to CO SUCCESS
VA rpt_No_Of_ReturnedRecords = [VA rpt_No_Of_ReturnedRecords]+1
F41021.Update
/*VA rpt_IdentifierShortItem = BC Item Number - Short (F41021)(ITM)
VA rpt_CostCenter = BC Business Unit (F41021)(MCU)
VA rpt_Location = BC Location (F41021)(LOCN)
VA rpt_Lot = BC Lot/Serial Number (F41021)(LOTN)*/
// Showing how the key was followed
//
F41021.Fetch Next
// This is to check if the records have been updated.
End While



Thanks,
Samukelo
 
You need to look into table handles. You will most likely need two handles. One to loop your result set and the other to do the update. Or learn C and C BSFNs... all of this stuff is more straight forward in C.
 
could possibly have made a no update report (I've accidentally done this before)
 
Hi Samukelo,

as a general rule: it's NOT correct to have custom piece of software updating F41021 table since it's storing on-hand and various inventory buckets (soft commit quantity, hard commit quantity ... etc.).

In other words: F41021 numbers should come from transactional tables like F4111 / F4211, and you are running the risk to have them out of sync.

If you really have a business case where you need to update F41021 (for example I'm currently playing on moving back hard-committed F4211 lines into soft-committed lines) I would suggest to use standard F41021UpdateQuantities (B4101370) Business Function.

Kind regards,

Carlo
 
Hi ccornagg,

Thanks for the reply.

The idea behind the report is to reverse/correct false commits. This is a two part report where the first part checks for false commits by checking transactional tables (F4211/F4111) data. The first part works correctly/as intended but the second part doesn't. I will try the suggested business function.

Thanks and Regards,
Samukelo
 
Hi Samukelo,

I would also suggest to have a look at Oracle Support site, for example:

E1: 40: Manual Rollback Process of Item Location (F41021) File (P42210/R42210) (Doc ID 625445.1)

There is a standard procedure in order to have F4211 (and other transactional tables) consistent with F41021 by activating "transaction processing" with UDC 00/AT.

False commits for F41021 table are included in F41021WF table and can be processed by standard programs P42210/R42210.

Kind regards,

Carlo
 
I think Sales Re-post (and purchase order repost, etc.) is a delivered UBE that is supposed to fix F41021. Having said that, there is a big deficiency in the delivered process in that it only fixes F41021 records for which there is a sales order line. If you roll your own, the BSFN is probably the better route to go because in reality you should also be using the JDEBASE locking APIs for this table as well (which the BSFN should be using).
 
As Brian pointed out there ARE existing UBEs which purport to fix this but have some issues.
We rolled our own SQL script (actually its not very complicated) to correct/update commits in F41021 and have used it since XE with some minor mods along the way.
 
Hi,

we have many custom F41021 updates being performed by various processes and are in the process of reverting these back to standard. This means using either the B4101370.F41021UpdatePrimaryLocation for soft commits on primary or the B4101370.F41021UpdateQuantities for hard commits. JDE do updates outside of Transaction Processing boundaries and so there are some recommended guidelines specifically for F41021 that is valuable reading. Normally the more custom code you do with F41021 then the bigger the risk of your balances getting screwed due to concurrency issues, which is ok in some circumstances as repost will fix, but not always. So if your site has heavy volumes and many users I would definitely read carefully the recommended documentation on F41021 update control.
 
Back
Top