Another article on our upgrade

After writing the two articles for OAUG Insight about our upgrade to release 12 I was contacted by SearchOracle.com to see if I would be willing to write a similar high level summary for their website. Well, that summary is finished and can be found HERE. It is basically just the process we went through to upgrade our system to release 12. If you have any specific questions about that process feel free to contact me (I'll respond to any comments I see on this post).

Making Progress With MES

It's been a little bit since I've posted anything about our MES project so I thought I ought to try and give an update as to where we currently stand. Back in April I talked about how the hardware that we had was making it extremely difficult to get the scales integrated and functioning with Oracle. There were a couple reasons for that:

1st: The Mettler ID30 product that we own is considered and marketed as a complete dispensing solution and as such Mettler makes it extremely difficult to use the ID30 in any way other than as an end to end dispensing solution. We tried for a couple of weeks to figure out how to send and receive messages from the ID30 but in the end it would have taken much more effort than we felt it was worth. One example showing the difficulty of using the ID30 is, without going into too much detail, the ID30 uses an activeX control to communicate with the scales, in order to pass commands from Oracle to the scale you would have to use the existing activeX commands which meant we would have to develop our own internal application to send and receive information.

2nd: The WMS module is something that wasn't available to OPM customers until release 12 so there was definitely a learning curve on our side as to how setup a device to communicate with Oracle. So in my post back in April I mentioned the possibility of working with Kepware to help us get MES setup but as we looked into their product offering a little more we realized that it didn't make much sense to continue down that path. The reason for this is that the basic request to weigh a product would initiate from an Oracle form via a button push or something like that. Once the button is pushed a request is sent to WMS that essentially says 'talk to the scale'. WMS sends a message to the scale and then receives the response and then that response is entered back into the Oracle form. Well, regardless if you're using WMS or Kepware the process is exactly the same and since we are only sending 1 request (read the scale weight) it seemed really foolish to spend a couple thousand dollars to have a company do that for us.

Those were two of the big issues we've had to deal with as we've moved down this MES path. What we decided to do to get around the ID30 is we've gone ahead and purchased a new indicator (the hardware that is used to view the output from the scales and which connects to the netword) from Mettler Toledo, the model we purchased is the IND780. It's much more user friendly because it was designed to send and receive messages from other sources. We just recently received this product so I'm in the process of setting it up to communicate with the scales and with WMS in a TEST instance.

Hopefully we can get this TEST instance up and running quickly, we are pretty anxious to get the solution in place and replace the formweigh system we currently are using for dispensing.

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.

How MAC data and mappings gets migrated into the SLA

If you've read any of my previous posts you know that I'm by no means an expert on OPM Cost Accounting. However, for the last two weeks the majority of my time has been spent on becoming an wanna-be expert in this area. Hopefully I can break down what I think I've learned in a way that's understandable and that doesn't reveal my limited accounting knowledge.

In 11.5.10 OPM customers use the MAC to define how transactions and events will be mapped to the subledger and then on to the general ledger. This mapping can be very generic (when sub-event 'X' occurs use account number 'Y') or it can be very specific (when sub-event 'X' occurs in Whse 'A' with a reason code of 'B' and account title 'D' and a GL Item Category of 'C' then use account 'Y'). The question, then, is how does this mapping get migrated into R12?

--Please understand that the following opinion and explanation is based on my personal experience which means it might not be 100% correct--

In order to explain how MAC data gets migrated into SLA I first should explain just a titch about how the SLA works in comparison to the MAC. In MAC you have events, subevents, account titles, and account mapping attributes which you use to define account mappings. These same things exist in R12 they are just re-named so:

• event = event entity
  
• sub-event = event class
  
• account titles = journal line types
  
• account mapping attributes = sources
  
• account mapping = account derivation rules

In release 12 your bottom level is your journal line types and your account derivation rules. A new mapping tool is introduced in 12 and it's called Journal Line Definitions. You use journal line definitions as the place were you select what account derivation rule you want to use to for each journal line type per event class.

Lets take the event class Miscellaneous Transaction as an example. This event class has two journal line types assigned to it, 'INV' (inventory valuation) and 'IVA' (inventory adjustment expense). With a journal line definition you are basically saying when event class miscellaneous transaction occurs for journal line type 'INV' use accounting derivation rule 'X'. Journal line types exist across multiple event classes so the journal line definition allows you use different derivation rules per event class. So, for the event class Batch Material Transactions, I can associate account derivation rule 'A' to journal line type 'INV' through the journal line definition and.


The journal line type will migrate without any problem because it is essentially just a copy of your existing account titles in 11.5.10. Account derivation rules is where OPM users are going to affected. Account derivation rules are created for every unique combination of: account title, set of books, and account segment. My company has a six segment accounting flexfield in R12 after migration I'll haves six account derivation rules per journal line type.

Our accounting flexfield is XX-XX-XXXX-XX-XXX-XXX so my accounting derivation rule (ADR) for journal line type 'INV' will be like this:

• ADR1 XX
  
• ADR2 XX
  
• ADR3 XXXX
  
• ADR4 XX
  
• ADR5 XXX
  
• ADR6 XXX

So the one mapping rule in 11.5.10 comes across as 6 different rules in Release 12. Obviously you don't need 6 different rules to define every journal line type every time. But, this post is about how things migrate so I'll have to go over that another time.

I'm a little short on time right now but hopefully this helps explain a little on how the data and account mapping that existed in 11.5.10 gets mapped over the release 12 during migration.

OPM and SLA

This week's task is tryng to get my hands completely around how to switch from using the OPM MAC to the Oracle SLA module. I hoped that since we were upgrading from 11 to 12 that maybe our business logic would migrate over for cost accounting but unfortunately that wasn't quite the case (some of the logic did migrate but most of it did not).

Now comes the fun part of trying to get the SLA up and running in a way that will jive with our cost accounting department. While there's plenty of documentation out there on how to implement SLA, there isn't quite as much about what needs to be done in order for SLA to function properly with OPM. However, today I did find a jewel on metalink that helps quite a bit, its Doc ID 822303.1. This doc goes through a step by step setup process, including screen shots, of how to get the SLA correctly configured to function with OPM.

The other helpful document I found last week dealing with this topic is a case study done by Satyam Computer Services which outlines a migration from MAC to SLA in R12 for an OPM company. You can also find this on metalink under Doc Id 562601.1.

Hopefully by the end of this week I'll be an expert on OPM and SLA.

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.