How to get initial entries of sales orders to go into CDHDR/CDPOS

[bruce_hartley]

When a sales order is first created and saved, we do not get an entry in CDHDR and/or CDPOS for it.

People have suggested looking at ERDAT and ERZET, but I have found that those entries may be false - especially if a person doesn't press save for a while.

A followup question to this is that when I use SE16N to look at field CHNGIND in table CDPOS, one of the possible values is J. It appears to work just like E does for deletes, but I cannot find a way to turn it on. I have been successful in using SCDO to turn on values for deletes which I needed ( thus turning the D's into E's ). A "J" appears to be an insert with the value of the field.

Is there some transaction in the system which will force the system to log the initial creation and thus assign it a change number ? I have a workaround of using a user exit to create an entry in a table, but I hate to have to do that if I don't have to. And what do I use to get the system to log the individual values on inserts ? It would help immensely if we had the values on the fields when they are inserted as a lot of logic is going towards determining those values.

[bruce_hartley · Accepted solution]

To anyone who reads this thread.

We ended up adding code to userexit_save_document in MV45AFZZ to create records in a custom table with a field that indicates that the entry needs to be processed. It got us around the date issue in the fact that the query looks for unprocessed entries and thus avoids the whole buffering thing. The only fields we had in the table were VBELN, POSNR, and a single character processing flag ( initial if not processed, 'X' if processed ).

There definitely is some kind of buffering going on so that our date/time went by and got missed.

I never did find any answers to my last two questions - if I ever do I will post it here. If anyone else finds out the answers, please post and I will award credit.