While working on planning for next weeks install of a new Power 7 an issue with automated order creation from inbound EDI data popped up.
I was informed that about three months ago Sears order processing started taking up to six hours to complete. This is unusual since we process thousands of Wal-mart orders a day with no visible issues. One difference with Sears verses other EDI partners is that the BEG segment of the EDI order Sears contains two different PO numbers. The first five digits are the only difference between the PO numbers, one for the store and one for the DC. This is how Sears avoids having to use SDQ segments in the EDI detail to determine the mark for store.
The programs are coded to use the DC PO number as key to the detail from the header. In this case we end up with many orders with the same PO (ship and bill DC). Without going into a lot of detail the programs were growing the detail file exponentially incorrectly. One order with nine lines was creating 999 detail lines. There are several programs that massage the same file so in the end a batch detail file that originally and should contain 3000 records grew to hundred of thousands detail records. All this code was originally put in to handle Wal-Mart type 73 SDQ orders, ship to mark for. So what is working well for Wal-mart is not working for Sears. This programming is supposed to be generic.
It is so frustrating to see how a EDI translator packages are not used to there full capabilities. In my last position I saw the same thing happen. EDI translators are just that, translators. Many people don not take the time to fully under stand the translator capabilities. So what happens is data is translated into work files and then many programs are developed to convert the trading partner data to local values before creating orders. This can be extremely difficult to manage when you have many trading partners as you have to keep changing your order processing code for every little change a trading partner makes.
The right way is to use the translation map for each trading partner to handle all the conversions such as customer numbers, item numbers, pricing, ship to locations. This way you only have to work with a particular trading partner map to change processing without affecting all you’re trading partners. Once the order creation program is written you should not be changing unless you really need to. At Pylon I did just that, once created I never had to change the main order processing program and did not have any post translation programs. There are instances where you may have post processing and SDQ is one of them and is acceptable. This is where EDI translators like Extol really shine.
After spending several hours digging in to the ten different post processing programs I found where the problem is. I was able to use the document number instead of the PO number to link the header and detail. After a few hours of testing the change with all the trading partners I was able to reduce the six hour processing time to one hour. During the analysis I determined that three other programs have the same problem, just not as bad. I believe I can cut the processing time down to 20 minutes by redoing the entire process. It was determined to put it aside for now and focus on the upgrade next week. After the upgrade we will come back and revisit the entire process.
I love being on the hunt and solving problems. It is tremendously satisfying to be able to have such an effect like saving five hours of processing. And best of all they pay me for this!
~Richard
I was informed that about three months ago Sears order processing started taking up to six hours to complete. This is unusual since we process thousands of Wal-mart orders a day with no visible issues. One difference with Sears verses other EDI partners is that the BEG segment of the EDI order Sears contains two different PO numbers. The first five digits are the only difference between the PO numbers, one for the store and one for the DC. This is how Sears avoids having to use SDQ segments in the EDI detail to determine the mark for store.
The programs are coded to use the DC PO number as key to the detail from the header. In this case we end up with many orders with the same PO (ship and bill DC). Without going into a lot of detail the programs were growing the detail file exponentially incorrectly. One order with nine lines was creating 999 detail lines. There are several programs that massage the same file so in the end a batch detail file that originally and should contain 3000 records grew to hundred of thousands detail records. All this code was originally put in to handle Wal-Mart type 73 SDQ orders, ship to mark for. So what is working well for Wal-mart is not working for Sears. This programming is supposed to be generic.
It is so frustrating to see how a EDI translator packages are not used to there full capabilities. In my last position I saw the same thing happen. EDI translators are just that, translators. Many people don not take the time to fully under stand the translator capabilities. So what happens is data is translated into work files and then many programs are developed to convert the trading partner data to local values before creating orders. This can be extremely difficult to manage when you have many trading partners as you have to keep changing your order processing code for every little change a trading partner makes.
The right way is to use the translation map for each trading partner to handle all the conversions such as customer numbers, item numbers, pricing, ship to locations. This way you only have to work with a particular trading partner map to change processing without affecting all you’re trading partners. Once the order creation program is written you should not be changing unless you really need to. At Pylon I did just that, once created I never had to change the main order processing program and did not have any post translation programs. There are instances where you may have post processing and SDQ is one of them and is acceptable. This is where EDI translators like Extol really shine.
After spending several hours digging in to the ten different post processing programs I found where the problem is. I was able to use the document number instead of the PO number to link the header and detail. After a few hours of testing the change with all the trading partners I was able to reduce the six hour processing time to one hour. During the analysis I determined that three other programs have the same problem, just not as bad. I believe I can cut the processing time down to 20 minutes by redoing the entire process. It was determined to put it aside for now and focus on the upgrade next week. After the upgrade we will come back and revisit the entire process.
I love being on the hunt and solving problems. It is tremendously satisfying to be able to have such an effect like saving five hours of processing. And best of all they pay me for this!
~Richard
No comments:
Post a Comment