cbudoris
Active Member
Just something I noticed, thought I'd pass it along.
We have our ASN extraction UBE R47032 scheduled to run periodically throughout the day. Some of the runs were not extacting data, even though there should have been- shipments were at status 30, orders at 575. The weird part was that these runs were extracting nothing, even in proof mode, but when you used data selection to process one of the shipments, you got your data.
So I ran a debug log for R47032. Those logs are 90% garbage, but in this case I actually found something. For some reason when it began section F47UI001 - All Columns, the Hierarchical Configuration was blank. Not sure why, because the processing options were setup to run the S O I config.
What happened is that the previous section, Join - F4211 and F4216 for use, initially processes all of the data based on the data selection. The program then filters out records that are not setup to produce ASN's. I thought that meant that there was a valid value in the Hierarch Config F4215/XHHLCF field. But somehow, shipments with no XHHLCF were infiltrating the program. One of them was the last record to process in the section, thus its Hier Config was used to pass down to the F47UI001 section. It was blank, and thus all the work records stored in the utility file WITH a configuration were not processed.
The mystery was, why did the program let the shipment with no configuration get so far into the processing? Seemed odd that it should do that. One thing I noticed with these records is that the trading partner field, XHPNID, WAS filled in, even though XHHLCF was blank. So I looked at the event rule code, and indeed found an If statement that allowed the shipment to process thru as long as it had a value in the PNID field.
I checked the Customer Master, and it appeared to be setup correctly. The Customer Ship Notice tab was all blank, with the Default Configuration set to None. Orders for this customer shouldn't have been producing a value in the XHPNID, but for some reason they were. I checked other non-ASN customers that were not producing the XHPNID, and they appeared to have the identical setup.
Finally I looked at the F03012 in DBU (we're an AS/400 shop) and noticed that for the customer that was screwing up my ASN's, the AICFDF Default Configuration field in the customer master was set to blank, while the customer who was not producing a value in the trading partner field was set to 0 (zero). You can't tell that from looking at it thru JDE- had to look behind the scenes.
I've got to think there is some failing in the shipment creation code somewhere that allows a blank value to produce this error. I've decided to fix the data though; a simple mass update of the F03012 will suffice, then I'll change the default records our customer service department uses to create new A/B records.
Oh, another thing I know about ASN's (EDI 856).. you shouldn't try to process more than one set of Hier Config in one run. Design separate runs of S O I, S P O I or whatever else you have using the UBE's data selection, probably parent number is your best bet. Even if the previous run's shipments are set to 50, the order status is still 575- they will infiltrate your current run's process and cause chaos. Instead of no ASN's, I'd see ASN data duplicated multiple times, each set of duplicates having a separate batch number, but having been produced by the same run.
Very weird stuff- just remember that data selection is your friend!
If you have any further questions about ASN or other EDI related stuff, drop me a line in this thread, I'll check back occassinally. If this post helped you out, give me a shout out!
Chris
We have our ASN extraction UBE R47032 scheduled to run periodically throughout the day. Some of the runs were not extacting data, even though there should have been- shipments were at status 30, orders at 575. The weird part was that these runs were extracting nothing, even in proof mode, but when you used data selection to process one of the shipments, you got your data.
So I ran a debug log for R47032. Those logs are 90% garbage, but in this case I actually found something. For some reason when it began section F47UI001 - All Columns, the Hierarchical Configuration was blank. Not sure why, because the processing options were setup to run the S O I config.
What happened is that the previous section, Join - F4211 and F4216 for use, initially processes all of the data based on the data selection. The program then filters out records that are not setup to produce ASN's. I thought that meant that there was a valid value in the Hierarch Config F4215/XHHLCF field. But somehow, shipments with no XHHLCF were infiltrating the program. One of them was the last record to process in the section, thus its Hier Config was used to pass down to the F47UI001 section. It was blank, and thus all the work records stored in the utility file WITH a configuration were not processed.
The mystery was, why did the program let the shipment with no configuration get so far into the processing? Seemed odd that it should do that. One thing I noticed with these records is that the trading partner field, XHPNID, WAS filled in, even though XHHLCF was blank. So I looked at the event rule code, and indeed found an If statement that allowed the shipment to process thru as long as it had a value in the PNID field.
I checked the Customer Master, and it appeared to be setup correctly. The Customer Ship Notice tab was all blank, with the Default Configuration set to None. Orders for this customer shouldn't have been producing a value in the XHPNID, but for some reason they were. I checked other non-ASN customers that were not producing the XHPNID, and they appeared to have the identical setup.
Finally I looked at the F03012 in DBU (we're an AS/400 shop) and noticed that for the customer that was screwing up my ASN's, the AICFDF Default Configuration field in the customer master was set to blank, while the customer who was not producing a value in the trading partner field was set to 0 (zero). You can't tell that from looking at it thru JDE- had to look behind the scenes.
I've got to think there is some failing in the shipment creation code somewhere that allows a blank value to produce this error. I've decided to fix the data though; a simple mass update of the F03012 will suffice, then I'll change the default records our customer service department uses to create new A/B records.
Oh, another thing I know about ASN's (EDI 856).. you shouldn't try to process more than one set of Hier Config in one run. Design separate runs of S O I, S P O I or whatever else you have using the UBE's data selection, probably parent number is your best bet. Even if the previous run's shipments are set to 50, the order status is still 575- they will infiltrate your current run's process and cause chaos. Instead of no ASN's, I'd see ASN data duplicated multiple times, each set of duplicates having a separate batch number, but having been produced by the same run.
Very weird stuff- just remember that data selection is your friend!
If you have any further questions about ASN or other EDI related stuff, drop me a line in this thread, I'll check back occassinally. If this post helped you out, give me a shout out!
Chris
