F4211 lines being deleted - and F4111

[johndanter]

Hi guys

Does anyone know of any reasons or UBEs etc in E1 E900 that may delete a SO F4211 line?

We had an issue here yesterday and on investigation we noted that a SO started at LNID 3 and 4. 1 + 2 seemed to have disappeared.
No trace of them on F42119 either

Also we've noticed a few F4111 lines seem to have gone missing too. Could be linked, not sure

We did debate could it be they were never created in the first place?

How could we check this?


Thanks

John

 

[Chan Rana]

Easy way would be if you refresh your Prod data to CRP or any other environment you can compare. I dont think changes in Sales Order would affect an inventory cardex.

Chan

 

[craig_welton]

Perhaps check F42199 (sales ledger) to see if they were created prior.

 

[Larry_Jones]

John,

one thing I've learned in 30+ years of working in IT is that Users Will Lie or leave out "unimportant details".

Its easy in P4210 to either:
a) Assign your own line numbers when creating a SO
-or-
b) Delete lines (such as your lines 1 & 2). When entering a new SO the row exit "Bypass New Line" can be used to remove lines that haven't been saved yet.

Net, net I'm suggesting that the user did it.

 

[BOster]

Net, net I'm suggesting that the user did it.

Probably the most likely scenario, especially since you have some of the lines on the order and not the entire order missing and it appears to be the first few lines and not the last lines (very weird).

Not sure of your business processes or what applications are creating the orders (P4210, P42101, EDI, BSSV, etc.) which may have a lot to do with it. Do your users ever create just an order header then go in later and add the lines? If so, I would look at transaction processing. PK violations on F42199 have a nasty way of causing the entire order to NOT be created or any changes to an order (but I guess that still doesn't explain why lines 3&4 are saved but not 1&2...). Of course it can be other tables as well causing TP rollbacks. I tracked down several pristine bugs on other tables that were causing transaction rollbacks and fixed them - code that relied on a PK violation as part of logic flow (if error inserting record do an update instead kind of logic). For F42199 we finally just dropped the PK at the database level and replaced it with a non-unique key over the same fields. Granted we have some weird mods in place that can occasionally cause an order to be saved and then, on rare occasions, be re-edited immediately so our F42199 headaches were somewhat self-induced - in other words the F42199 PK issues may not apply in your situation.

 

[johndanter]

Brilliant info, cheers guys. It was an EDI originated SO

Looking at F42199, lines 1 and 2 did exist at one point in time.......so ?

F42199 is great for showing they DID exist but it won't store who deleted the line will it?

 

[BOster]

F42199 is great for showing they DID exist but it won't store who deleted the line will it?

That almost makes it more confusing. I have never seen anything actually delete F4211 records, rollback a transaction and not write anything related to the order/line to begin with - yes. But not simply write the F42199 record and not the F4211 record and certainly not delete the actual record. I don't believe there is any pristine business logic that would delete a F4211 record once it's created and the fact that there are records in F42199 seems to indicate that there was a F4211 record at some point.