Reverse Purge F4211/F42119 and F4201/F42019

[maher_samet]

Hi list,

I have a user who purged the F4201 and F4211 records when lauching UBE R43800 (Processing Options 6 & 7 in 2nd Tab). The result that the lines "APPARENTLY" were moved from F4211 to F42119 and from F4201 to F42019.
This was a mistake. HOW can we recover these moves ? Is it SAFE to move those lines back (with MS-Access) from F42119 to F4211 and from F42019 to F4201. Is there any "future and hidden" problem that can we encouter ? What are the precautions to make before doing that ? Is there a ready batch "Reverse Purge" that can do that ?

Please respond me quickly, because I have several reports to lauch that are based on F4201 and F4211.

Thanks a lot.

Maher SAMET

Configuration: NT4/SP6a,SQL7/SP3,OW B7332/SP17.1

 

[amwalshjde]

Maher-

What status were are the lines at? If they were all closed (ie next status = 999) then It should be okay to bring back (then again I dont know why you would want to bring them back in that case). If they were open, then you will need to check inventory. When the orders were purged it hopefully removed the committment for all those lines. You might need to run a repost and/or committments (if you are hard committing). Also if you are using transportation, it might have removed the transportation detail for any lines that were on shipments. Also dont forget to look at the F49211 (tag file).

Is that enough to get you going? As I think of anything else I will pass it on.

good luck

 

[Andre_Jille]

You can easily use ms-access to restore those lines, but normally when sales
orders lines are not yet ship confirmed, sales update will perform this when
running in final mode.
So you have to reverse those entries as well, this is may be problem because
you have to reset your on-hand quantities also.
Next you have to reverse the IB-batch created by this sales update.

Kind regards,

Andre Jille

Deloitte & Touche

 

[maher_samet]

Hello amwalshjde,
Thanks to you for your reply. All status are 999. I want the lines back to launch UBE for statistics (amount of lines during a period, ...) and the UBEs are using F4211/F4201 and not the F42119/F42019.
The columns in F4211 and F42119 are the same: OK.
The columns in F4201 and F42019 are the same: Well.
But I found that I have lines of data in the F49219 which is the purge file for the tag file F49211, BUT UNFORTUNATELY, F49211 and F49219 have not the same columns: the first N columns are the same, but after, F49211 have added columns that F49219 have not. HOW to do for this table ? The Put-back lines for F4201 and F4211 are OK, but how about F49211 ? I am blocking at this point now. Can you help me a bit more ?

Maher

 

[amwalshjde]

Maher-

I feel better knowing that all the lines are closed. Otherwise it gets real messy. Here are the things that I have seen the F49211 used for:
Pick Slip/Shipping Release
Cycle billing
some other transportation functions (which I cant remember)

IF (and that is a capital if) that is indeed all it is used for then I'd say bring back the first N part of the record, and then update the audit fields with something that will remind you that this is a "special" record. If you do that I would take the time to load each field with a value (albeit zero or blank. My experience is that JDE and database null's dont play well together)

bottom line is, if the fields that are in the F49211 are not in any history table, then you need either to get the info from a backup, or just load back what you can. If the UBE's that you run are custom then you should know wether the F49211 is needed. I cant really think of why it would be.

 

[maher_samet]

amwalshjde,

After looking to both tables F49211 and F49219, they have the first N columns (from DOCO to EXR1) the same, but after that, only F49211 have 14 columns (from FRDM to ETM) and after, both tables have the remaining columns the same (from TV01 to TDAY).

What will happen if I let F49211 unchanged ? I mean if I will not copy back lines from F49211 to F49219 ?
My UBEs do not need this table (F49211), but the other functionalities can perhaps need it. Is this safe to do like that ? (I say this because the copy back operation is heavy to do).

Regards,

Maher