The Calm Before the Storm

We are officially two weeks away from taking our production instance down and migrating from 11.5.10 to 12.1. You'd think I'd be swamped with problems and issues from every which department, but as of today the only thing I have to work on is documentation (training and validation), and rewriting reports. --Sadly our discoverer reports aren't going to migrate so well since they were built on OPM inventory views.

My mind is going about 2,000 mph trying to see if I've missed any testing or any possible business process that might be affected by the upgrade but so far things look good. I wish I had a little more 'stress free' free time so I could update this blog with things I've learned during the upgrade but I think those entries are going to have to come later.

I will however make a small list of things to consider during your upgrade

• Discoverer reports/workbooks don't migrate, at least that is what Oracle consulting told us. If you are using discoverer before the migration you're going to have to recreate your workbooks after the migration (assuming those workbooks are built on views that get changed during upgrade)
  
• In OPM users are forced to choose an existing lot number when performing move immediates and adjust immediates. In 12.1 users are not forced to choose existing lots. They can enter a new lot any time (subinventory transfers, account alias transactions, inter-org transfers)
  
• This one is random but in 11.5.10 we had routings setup which had resources with a usage of 0. In 12.1 if you have a primary resource assigned to a routing and that primary resource has a usage of 0 then when you run collections, the Recipe which uses that routing will not be collected and it will not show demand for that product/raw materials
  

Those are just a few thoughts, hopefully they might help you out during your upgrade. Well, I have more reports to rewrite, wish me luck.

OPM R12: Migrating Warehouses and Plants

One of the benefits of upgrading to release 12 is that you have the opportunity to 'restructure' your organization setup just a little bit (assuming you are an OPM customer). When you initially setup your OPM wareshouses, you did so by entering a new HR organization but in the name you put 3 to 4 characters and then a ':' to designate this HR organization as a warehouse. When you saved this new HR Organization it created an inventory organization on the discrete side as well as an OPM warehouse.

In the oracle documentation (OPM Migration Reference Guide) it states that you can convert these warehouses you've already setup into subinventories under an existing inventory organization. This is superb because the migration is already converting OPM plants into inventory organizations (if there is a resource warehouse code defined for the OPM Plant then no new inventory organization will be created). So by being able to migrate a warehouse as a subinventory you are reducing the number of inventory organizations you'll have to deal.
There are a few restrictions with this functionality (and unfortunately for me, my company could not migrate as we desired because of these restrictions). These restrictions are, per oracle documentation:

*All the warehouses that are bing mapped as subinventories under a single organization must belong to the same cost warehouse

*Warehouse can only be mapped as subinventories to the OPM Organization to which they belong (you can't migrate a warehouse belonging to plant A as a subinventory under plant B)

Where we ran into issues was that we had each warehouse setup as its own cost warehouse (not sure why, that decision predated my time) and we wanted to map warehouses from other plants all under a single plant. Overall the ability to map warehouses to migrate as subinventories is a good feature, unfortunately we were not able to use it.

If you have any questions or are curious to see our specific example let me know by email or through comments and I can show you how our situation is playing out.