cancel
Showing results for 
Search instead for 
Did you mean: 

Does Setup table gets filled in Ascending order of Sales Document Numbers?

Former Member
0 Kudos

Hello,

I am filling up the setup table for Sales Orders (11) after deleting the entries in LBWG.  The job ran for around 40 hours and loaded around 20 million records.  But it got failed now with an error "Sales organization  does not exist (document 800309563)".  So, I am now planning to skp this Sales document alone and load the remaining documents to the setup table.  While filling up setup table for the second time now, i am planning to give the Sales document range From value = 800309564 and To value = 900218926.  But i wanted to know, when the setup table is getting filled, will it be filled in the ascending order of Sales document number or in random.  If the setup table will be filled in the ascending order of Sales documents, then i can fill it up giving the range thati have mentioned above.  If the setup table will be filled randomly, then though i give the range, there are chances for duplicate records to be filled in setup tables which i dont want to happen.  I cannot delete the setup table and schedule a job again as the process will take another 40 hours to run through

I tried looking for a similar question in SDN but did not find anything helpful.  Please clarify my doubt and let me know if the above can be achieved in any other way.

Regards,

Aravind

Accepted Solutions (1)

Accepted Solutions (1)

karthik_vasudevan
Active Contributor
0 Kudos

Hi Aravindhan

You will never know if you have few more documents like this and it is not a good idea to refill the setup table for ignoring one document.

As the job has failed, you need to do this again, i understand but it should not fail for the same reason.

And its always best to fill setup table in small chunks.

My suggestion would be, get the sales org for that document and fill the setup table by giving few salesorg at a time.

Say if you have 20 salesorg totally, give 5 per job excluding the one for that document (so all problematic documents will be ignored by this way)

Hope this helps!

Regards

Karthik

Former Member
0 Kudos

Hello Karthik,

Thanks for your response.

My Database table has data since 2005 but i am loading only June 2015 to till date data.  Hence, loading setup table with Sales Org restriction will not help.

I am not planning to delete the setup table and reload it again completely.  Since the setup table is almost filled up to around 20 million records already, i am thinking to load only the remaining Sales Doc numbers leaving behind the error Sales Doc.  That is why i am planning to give the range as mentioned in my initial question.  But before doing that, i wanted to confirm if the setup table loading will be done in  ascending order of sales document or not.

Thanks & Regards,

Aravindhan

karthik_vasudevan
Active Contributor
0 Kudos

Hi Aravindhan

Understood now. I don't have a direct answer to your question. I am not sure if anyone could help you in this, but you could do a test and identify yourself.

As the setup table is filled with 20 million records now, in RSA3 extract checker, you could give some documents in your range and see if it fetches some data. If it doesn't then it might be filling in ascending and you could go ahead with your approach.

You could give some document numbers before that range as well just to make sure.

Hope this helps

PS: If you are filling only for few months, you would get help from functional team and get the documents numbers or range for the specified time period. I think you cant do this now as you are in half way. But next time, when you have this requirement consider this point.

Regards

Karthik

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Aravind,

1.) While you are filling up setup tables you can look into SE16 table MC11V_0ITMSETUP or you can choose F4 on MC11*. It will show you how the sales orders are filling up.

2.) There wont be duplicates.

3.) Try to load setup tables by Sales Org if you have the option.

Thanks,

Bala.