Hello everybody–I hope everyone is doing well and keeping busy.

I have started a new contract and am driving to it each week.  As I drive, I go past a town named “Covert” and  I think it is funny that there are signs telling me where to exit to find the town.  One would think that they would want to keep that town hidden…

Anyway, when I started this project it reminded me of some traps that one comes across during a project.  In one memorable case, I was working on a project with many other consultants; one day, a financial consultant decided to turn off multi-currency.  As my fellow JDE consultants may know, with multi-currency turned on, you have to enter the currency code when dealing with prices and advanced pricing setup; if multi-currency is turned off, you do not get the choice to enter the currency code.

Now the fun begins.  While multi-currency was turned on, the pricing team was entering advanced price adjustments.  They continued entering adjustments when multi-currency was turned off.  So what was the issue?  Some of the adjustments had currency codes and the rest had no currency code–it was blank.

The fun really started when the pricing team started entering orders to test their pricing setup. In sales order entry, they could see all the adjustments when using the Price History row exit, but they could not see all the adjustment details when trying to edit them (via the Price Adjustment Detail form).  After spending most of a day, we discovered that during the sales order process, the pricing functionality equates the blank currency code with the company’s currency code–in our case, they were entering the pricing for a USA branch, so USD and blank were considered the same currency codes; however, the P4072 (Work With Adjustment Detail) considers them as different currency codes.

We are able to fix this, but I can not remember if we used SQL to delete the adjustment details, or we turned off multi-currency, deleted the adjustment details that we could see (the ones with a blank currency code), then turned on multi-currency and strongly suggest to the financial consultant to never touch the multi-currency setting again.

If this happens to you, be diplomatic with the financial consultant–or they might get angry and delete branch “ALL.”  Then, as a distribution or manufacturing consultant, you will see some really bizarre errors.

But I might save that for another post.

Hello all.  This is my first post, and welcome to it.  I hope everyone has a merry Christmas and a happy and prosperous New Year.

I want to share with you how I used Advanced Pricing in Procurement for the first time.  As many of you know, one can use Advanced Pricing in Procurement in J.D. Edwards EnterpriseOne; however, for years I never came across a client that needed to use Advanced Pricing in Procurement.  That changed when I had a client going live on 8.12 and had the following situation:  The client had several suppliers that would ship directly to the client’s customers.  No big deal–the SD/OD process works.  The twist was that some of these suppliers would charge my client a different amount based on how far the product had to ship–basically burying the freight costs into the purchasing costs.

With me so far, I hope?  Good.  Now, I solved this by using Advanced Pricing for Procurement.  I set up the adjustment to be by item group and by ship-to customer.  I used one of the item’s category codes to indicate that the item was subjected to this pricing; the ship-to’s were the customers that received the drop-shipped items (or direct-shipped items if you prefer).  In the adjustment details were the ship-to customer number and the supplier’s cost for delivering the item to that customer.

As a side note:  since there were not many cases of this, I used the ship-to customer number.  If there had been a lot of these, I would have worked out a way to use a ship-to customer group for easier maintenance.

The nice thing about this was the ease of updating the costs.  Also, do not forget that when creating an SD and an OD at the same time, the SD’s cost comes from the OD.  This means that the cost the supplier is charging comes onto the OD from Advanced Pricing then is sent to the SD for its cost.

This functionality is nice since if you or your client bases the SD price on the SD’s cost (like forcing a profit margin or doing a cost plus calculation), then you are set.  Of course, your customer would notice that their price is changing on each order and may wonder why, so as a word of caution:  You may want to discourage your client from combining the setup I mentioned with the OD cost/price if they do the price on the SD based on the cost.

I hope this helps someone that might have the same type of requirement.  Please let me know if you have any questions.

As I blog, you will notice that I will talk mostly about the Distribution Suite as that is my strong suit.  If you have a subject you want to see me talk about, please let me know.

Thank you.