DSauve
Legendary Poster
ESU\'s for EO89
We've just upgrade our Development environment to EO89, and are about to begin the task of retrofitting our modifications. Before doing that, however, I went out to the KG to find ESU's for EO89 which might affect us. I found over 500 of them, and after reviewing the contents, found about 85 which applied to us.
I have comments on two of these ESU's:
PF628 is for SAR 6925493. If you use Bills of Material, you'll want this ESU applied BEFORE you run table conversions. They've changed the BOM component line # to a new field, and added an extra decimal point, so line #'s can now be in the form 20.76. The trouble is, the R893002F conversion didn't multiply the existing line # by 10, so what was line 3.1 would show as line 0.31 after the table conversion. Apply this ESU to prevent this from happening. Of course, it's nothing that a simple SQL statement couldn't fix.
I've also logged a call and received SAR # 7086433, so that ECO Population (R30510) will take advantage of the new 2nd decimal place. I figure why bother with a 2nd decimal place if ECO processing isn't going to use it!
The second ESU for comment is PF1429. It had some fixes for PO receipts and receipt routing, so I applied it. The problem is, it broke our full package build many times over, referencing objects that didn't exist, etc. So for now, I'll be backing out this ESU and waiting for a fix later.
Just a quick note from the EO89 front...
We've just upgrade our Development environment to EO89, and are about to begin the task of retrofitting our modifications. Before doing that, however, I went out to the KG to find ESU's for EO89 which might affect us. I found over 500 of them, and after reviewing the contents, found about 85 which applied to us.
I have comments on two of these ESU's:
PF628 is for SAR 6925493. If you use Bills of Material, you'll want this ESU applied BEFORE you run table conversions. They've changed the BOM component line # to a new field, and added an extra decimal point, so line #'s can now be in the form 20.76. The trouble is, the R893002F conversion didn't multiply the existing line # by 10, so what was line 3.1 would show as line 0.31 after the table conversion. Apply this ESU to prevent this from happening. Of course, it's nothing that a simple SQL statement couldn't fix.
I've also logged a call and received SAR # 7086433, so that ECO Population (R30510) will take advantage of the new 2nd decimal place. I figure why bother with a 2nd decimal place if ECO processing isn't going to use it!
The second ESU for comment is PF1429. It had some fixes for PO receipts and receipt routing, so I applied it. The problem is, it broke our full package build many times over, referencing objects that didn't exist, etc. So for now, I'll be backing out this ESU and waiting for a fix later.
Just a quick note from the EO89 front...
