We have yet another JDEdwards Enterprise One curiosity. This one is a rare manifestation of the remarkable recursive log.
I know a baker who is technologically astute. He runs his bakery on JD Edwards EnterpriseOne ERP software, because EnterpriseOne features Advanced Pricing, which can handle sweet discounts on doughnuts and tiered pricing on cakes.
Using the EnterpriseOne manual, my friend the baker has figured out how to properly set up his pricing hierarchies and schedules. He has also figured out how to price a baker’s dozen of doughnuts. He simply sets up a list price and a discount pricing adjustment with Basis Code “5” (add on amount), Factor Value Unit of Measure “BDZ” (13 EA [each] == 1 BDZ [baker’s dozen]), and Price Partials = “0” (no). The discount is equal to the price of one doughnut, so that each time someone orders thirteen doughnuts, he receives the discount and pays only for twelve. Similarly, if he orders 26 doughnuts, the thirteenth and twenty-sixth are free. The price partials flag makes order entry simple because EnterpriseOne is smart enough to know that the customer gets the discount only after reaching the whole baker’s dozen.
Now, my friend the baker has a challenge. Continue reading
J shared with us this crazy error message, which demonstrates that it is possible to crash the system so hard that it cannot even finish writing its own error message. It just gives up, grabs the rod and reel, and walks out.
During an upgrade to JDE EnterpriseOne you will need to list any changes that have been made to your data dictionary, and using SQL or even a UBE, most developers would have no problem coming up with a way to compare the pristine data dictionary with the latest version. We thought, however, it might be nice to give those with less experience in this line a jump start. So here is some SQL that could be used to detect new data dictionary items and changed alpha descriptions. Continue reading
I know since we posted the JDE date to real date function, everyone has been wondering where the real date to JDE date function is. Well, “ask and you shall receive.”
As long as we are discussing JD Edwards running on DB/2. Here’s another potentially useful function. This one converts a value from one unit of measure to another based on the F41002 table. It does this by converting the FromUOM to the primary UOM and thence to the ToUOM.
During nine years of blackguarding the J. D. Edwards date format (also known as JDate, also misnamed Julian Date), I have resisted learning to write DB/2 stored procedures because the need to use them while developing OneWorld applications is minimal and OneWorld is the only context in which I have encountered DB/2. Well, I have finally encountered that special confluence of necessity and available time that produces a tool — in this case a function. I broke down, I learned, and I wrote that JDate to DB/2 Date function. Here is that code, in case you should find it useful:
If you have ever used the JDEdwards cross-reference facility in an attempt to find where a certain table column is used, you understand that it can be difficult, especially when the alias for your column is common.
Let’s say you have a custom table [F550001] that has a column [URRF], and you need to find all programs that use the F550001.URRF. Well, you may have 50 custom programs that use F550001 and there may be 250 programs, native and custom, that use the alias URRF. You can see the difficulty in searching through 50 programs to find 5 that reference F550001.URRF.
If, however, you take the 50 custom programs that reference F550001 and export them to the spreadsheet program of your choice and then export the 250 programs that reference the URRF to another spreadsheet, you can filter the 50 references to F550001 down to only those programs that also reference URRF. Now, you still may have a few extra programs in your list — programs that don’t reference F550001.URRF — but you now have a much smaller list to work from.