![]() (Get the STO list by it_array at beginning of array_read in 1st call.) Finally, the secret is revealed. ConclusionĪfter finishing this dump analysis and go back to check the related STO at the system. (It’s not 5000 pieces of 1 PO item!) Yes, it could be a general number for a giant company like Amazon but if that really happens then the inputs of RVV50R10C will be an inappropriate setting. Just imagine how scary the number is, it means 5000 PO items are transferring between two different plants intra-company (not for customers) in less than one day. So very few cases users have a big backlog of delivery due specific for STO which Shipping Data for Stock Transfer of Purchasing Document Item entries more than 5000! ![]() It could be set as a background job that runs more frequently like twice even more per day. The due delivery program will be called daily for a specific site/plant to generate delivery. I know it’s little chaos and confusion to catch up with but couldn’t figure out a better way to explain from a technical point of view unless debugging with me as it’s extremely rare : P Unless this is the only item number of this STO due for delivery, otherwise dump will list the first STO with the item number which is duplicated. Cause delivery due is for this specific STO specific item, but the previous mt-data fetched only for the first item of all Due delivery related STO. Now fetching from EKPV happens again without considering the specific item number! It leads to duplicated keys for sure when insert to TABLE me ->mt_data. Then comes the real issue now: lt_input contains only 1 STO with 1 item number, and it did not exist at me ->mt_data. Table me ->mt_data contains less than 5000 now, for this specific STO item from it_array (loop of due delivery), if it’s not existed in me ->mt_data which get from 2nd round call with shrunk item numbers. Below is a good place to set a breakpoint to understand the big loop. The above 2 rounds call of ‘array_read’ is performed for all STO as a whole! When comes to the 3rd call, all due-to delivery data has already been fully prepared include delivery number but has not been submitting&commit so there do not exist physically yet.Īt this moment inside the big loop perdue delivery, this method ‘array_read’ has been called for the first STO delivery with a specific item number as it_array. 3, Third call of method ‘array_read’ per delivery which haven’t been created yet for STO We get all entries from lt_input (one order with only one item) and fetched again from EKPV which has much fewer results compared to 1st run for me->mt_data (6000+), as this select using EBELP as a filter! me->reset( ).ĪND ebelp = lt_input-ebelp. Me->array_read( EXPORTING it_array = lt_array "1864606ĬLEAR: me->mt_data, me->mv_iter. ![]() IF et_data IS SUPPLIED AND me->mv_iter LE 1. * do array read only up to 2 interation cycles ![]() READ TABLE me->mt_data WITH TABLE KEY ebeln = -ebeln INSERT LINES OF lt_data INTO TABLE me->mt_data. READ TABLE lt_input WITH KEY ebeln = -ebeln READ TABLE et_data WITH TABLE KEY ebeln = -ebeln IF sy-subrc GT 0 OR lines( me->mt_data ) EQ 0. INSERT LINES OF it_array INTO TABLE lt_input. * Stelle sicher, dass nur das noetigste von der DB-gelesen wird * if there are more than 5,000 entries -> refresh and start fresh Lt_array TYPE STANDARD TABLE OF ekpo_key WITH DEFAULT KEY, Lty_t_input TYPE SORTED TABLE OF ekpo_key * Read shipping data by using array operation
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |