Focus and Happiness

Just read an article that I really enjoyed. The article, Will Focus Make You Happier, talks about how when someone is focused on a task they tend to be happier than when they are kind of floundering. I found this article to describe my mood at work to a T. When I am focused/invested/engaged in what I'm doing I find that I am much happier than when I'm not. It's interesting, though, that I often find it very difficult to get myself engaged in a new project. It's hard to find the energy to get things started but after reading this article is seems like by not investing my energy and focus into projects I'm keeping myself from being as happy at my job. Overall, just kind of a really interesting article.

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).

How Will You Measure Your Life: An article from a Harvard Professor

I read an incredible article this past week in the Harvard Business Review that outlines ideas on how to live your life. Its a completely refreshing view about how there is so much more to life than simply climbing to the top of the 'ladder' and collecting gobs of cash along the way.

I particularly enjoyed the authors view on allocating your personal resources appropriately and consciously creating a culture in your personal life instead of letting circumstances and lack of attention create a culture for you.

I highly recommend reading this article.

How Will You Measure Your Life

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.

Our Upgrade Story

This past year I was contacted by the publisher of OAUG Insight magazine and was asked if I would be willing to write an article about our experience upgrading from 11.5.10 to R12. My original article was to long and so the editor asked if we could split it into two parts. Part one covers how USANA went about upgrading to Release12 and part two details some of the functional issues to watch out for after migrating.

Part One: Page 18

Part Two: Page 15

Integrating Scales: Not That Easy

Here we are about 5 weeks since MES got approved and purchased and I have good news and bad news.

Good News: It was pretty easy to get the basic features of the product up and running in the application. Pretty much you run a couple concurrent requests, setup a few items as dispensable, setup a dispensing area and a dispensing booth and there you go. Okay, maybe its a little more complex then that but not by much.

Bad News: We use scales from Mettler Toledo. A few years ago we purchased their ID30 weigh station solution which is essentially a scale, a monitor, what they call an 'indicator', and a little pc. The monitor runs their ScaleXplorer software which uses an ActiveX control to communicate with the scales.

This week I spoke with Mettler about how to use their scales with MES and the answer is that we still have to use their ELO box (which is the indicator and the little pc) but in order to use them on a network we would have to write a listening app and install it on each ELO box and then also write an app that would use the ActiveX control to communicate with the scales. (FYI I'm not a developer nor do I do much with networks so I'm definitely pushing past anything I know and understand).

So here we are today. We have some internal developers who could probably create these two apps for us but they are swamped with other projects right now and probably wouldn't be able to get to it for another couple months. Next option is to check out a product offered by Kepware which an Oracle developer recommended that apparently is an all in one solution for integrating devices with MES. If that doesn't work or is too expensive I guess I go back to Mettler and see what they can offer.

Wish me luck.


Interesting Article on the different philosophies of Oracle and SAP pertaining to manufacturing execution systems.

My Oracle Support Community...

During an OPM SIG conference call (held monthly to discuss different issues or topics that the group is facing) Russ Bayless got on and suggested that we all check out this 'cool new' Oracle Support Community feature found on metalink...I mean found on 'My Oracle Support'. He said the intention was to create a forum (much like it.toolbox) where users would be able to help each other not only with technical questions that you'd normally submit to oracle support but also with setup and operation questions that might be specific to each company.

I liked the idea of this, especially since the Process Manufacturing Community is so small, so I created a profile and signed up for some of the 'communities' on the site. Well, it's been a month and a half now and I'm definitely not impressed. I think the biggest problem is that users don't know about this feature and so there are very few people reviewing questions and forums (ie there is not much participation). I've submitted 7 different questions and have had 0 usable responses so far.

I'm writing this blog post to vent a little I guess but also to make others aware of this feature offered by Oracle. If we can get more people on board it will definitely increase participation. For me, IT Toolbox has been a great resource for very technical oracle issue but not such a good resource for day to day usage like creating approver groups in AME, or finding help understanding supply tolerancing. My hope is that somewhere, either on IT Toolbox or on My Oracle Support Community, I can find a forum where I can get more participation and answers to operational questions.

Here is the link to 'My Oracle Support Community'. You do have to have a user name and password to log in but its the same as you would use to log into metalink.

A Quick Oracle MES Implementation Update

The past two weeks I've been working to get a quick setup done of MES so that I can show the MFG departments what to expect, unfortunately my expectations were a bit unrealistic in terms of the simplicity of the setup. I had only minor issues getting the module to work in the application but now we are getting to the device integration and that has turned out to be a rather complex process.

Let me walk you through a little bit of the problem we are facing. Last June we had an Oracle employee come out and look at our scales and how they were hooked up to see if we would need to change anything when we got to the point of implementing MES. His findings were that things looked good and the transition would be very smooth.

Fast forward nine months and it turns out our scales can't communicate via TCP/IP. I had a phone call with Oracle to get a better understanding and what I think I learned is that in order for a scale (or any device) to communicate with MES it has to be assigned its own IP address. The device setup must mimic the setup required for a device to function in WCS (there is a white paper from July 2006 called Oracle Warehouse Management System Warehouse Control System (WCS)/Material Handling Equipment (MHE)that goes over the requirements and the setup process). Basically the communication goes from the database to a middle tier which they reference as the 'Carousel Bridge' or Carbri which then communicates with the device simulator and in order for that communication to take place Carbri must know 'where' it needs to send its messages thus the need for an IP address.

So our current scales come from Mettler Toledo, we use the ID30 weigh system which connects a scale and a monitor via what they call an ELO box. The connection from the scale to this box isn't via a serial cable or usb connection, its hardwired which makes our transition to MES a little more difficult because I can't simply unplug the scale from the ELO box and plug it into something else.

Anyway, the next week or so I'm hoping we can figure out the setup and integration of these scales so we can move forward with the MES project as a whole.

--The minor issue we had with setting up the MES module was that when we tried to select an item for dispensing the system said the lot status was invalid even though it was not. We worked with Oracle for about a week and they came up with patch 9472114 which resolved the issue.

MES Made it Through

Our board has finished reviewing the budget/projects for 2010 and the great news is that MES (Manufacturing Execution System) has made it through (thats a big win,they were leaning towards cutting it because we couldn't find anyone in the US that has implemented this module but I guess things changed). We have a meeting on Friday to start implementing our project plan.

Phase 1 consists of replacing a third part pre-weigh system in all our dispensing rooms and Phase 2 will be to switch over completely to a paperless batch record.

In order for this to work we have begun working on the setup of ERES and AME. Both of those really need to be in place in order for us to fully utilize the MES module.

Anyway, I'll make sure to keep you updated on how the project goes.

Unwanted Planned Orders in ASCP

I love it when oracle support deems the solution to all your problems is simply upgrading to the latest CU patchset. Don't mind the fact that we just performed an upgrade from 11.5.10.2 to 12.1.1 less than two months ago, obviously our code level is extremely outaded already.

When we launch a plan from ASCP everything works fine except that the calculation for projected available balance isn't recognizing on hand inventory. Awesome! Because of this when we view the output of the plan in the workbench, we have a planned order for every item in our forecast for tomorrow regardless of whether there is sufficient onhand inventory to meet the next two months worth of demand or not.

We brought this up with support, we have Sev2 ticket open and they say they found the error in the code and have provided a one off patch to resolve the problem but.....we have to apply a 2.3GB Consolidated update patch as a pre-req for our little 28K one off.

I understand that its tough to provide fixes for all these different code levels, I guess I just assumed that by upgrading to 12.1.1 we would be on a pretty darn current version so we would be able to get fixes without having to go through a couple weeks of testing before we validate the affects of applying this huge CU3.

Anyway, hopefully by getting to CU3 and then applying this little one off we get the problem of unwanted planned orders resolved.

Account Derivation Rule for Using PO Charge Account

Cost accounting has enjoyed the new SLA module since we upgrade to R12. Overall they find it much simpler to maintain and troubleshoot. Being able to view exactly which entries were invalid and why they were invalid during the creation of a subledger really reduces the troubleshooting they were doing in 11i. However, they did have one issue with the way we originally setup the account assignments.

--Quick review of how SLA is setup--
Essentially you create account derivation rules for each journal line type. These derivation rules are pretty much a 'where' clause that you would use when writing SQL. An example would be 'when journal line type is EXP and operating unit is XYZ set the segment ACCT to 4567'. You can also have the ACCT segment assigned based on a source (when you create a physical count you have to put in an account number so you could have the account derivation rule use that account number, whatever it is, as the acount that gets posted in the subledger)
--Back to my post--

Originally we were assigning a constant value for journal line type of EXP but the accountants wanted to be able to pull in the charge account that was entered on the PO. This was our first attempt at using a value type of source in the account derivation rule.

To make a long story short if your using OPM and want to use the charge account that is entered during the creation of the PO select a source of 'Transaction Account' in the account derivation rule. We played around with this for a while trying the distribution account (the column in the database table where this information is stored was called something like distribution account id) and a couple others but the solution was 'Transaction Account'.

Onhand vs Lot Status in Release 12

One of the biggest issues we've had since our upgrade is trying to reconcile the difference between lot status and material onhand status. In 11i OPM used lot status which meant that all of a lot was either accepted or not. In R12 a new feature, called material status, is introduced. The feature as a whole is excellent because it allows you to determine the status of a lot + a location (onhand). The benefit of this is that if a portion of a pallet is crushed you can seperate the pallet into two parts and assign the bad crushed part a status of 'throw away' while assigning the good portion an acceptable status.

This feature is great except that the status only persists as long as you have inventory onhand. Once your inventory goes to 0 for a certain lot or location the status no longer exists. Most of the time that is completely acceptable but where we run into problems is when you issue material to a batch (and that issue 0's out the onhand quantity) and then find that you need to perform a wip return for a portion of that quantity. Since the onhand was 0 because the wip issue consumed it all the previous status no longer exists so when a wip return happens and inventory is put back into the location from which it was issued the status defaults to whatever status is setup in the item master for that organization.

For us, this means that whenever an item is returned it defaults back to a status of 'QUAR' which is a status that does not allow wip issues. Since our quality department is the only team who can update that status each time a wip return occurs as described above we have to alert them and they have to go verify that indeed its okay to change the status to acceptable for mfg use.

In 11i the lot status persisted even if the quantity were 0 and so if a return was performed the returned material would be assigned the status of the lot. In R12, everything goes back to the default status setup in the item master. After discussing this with Oracle it seems like our only solution is going to be through customization, at least for the next year or so.

Unwanted Planned Orders in ASCP

I love it when oracle support deems the solution to all your problems is simply upgrading to the latest CU patchset. Don't mind the fact that we just performed an upgrade from 11.5.10.2 to 12.1.1 less than two months ago, obviously our code level is extremely outaded already.

When we launch a plan from ASCP everything works fine except that the calculation for projected available balance isn't recognizing on hand inventory. Awesome! Because of this when we view the output of the plan in the workbench, we have a planned order for every item in our forecast for tomorrow regardless of whether there is sufficient onhand inventory to meet the next two months worth of demand or not.

We brought this up with support, we have Sev2 ticket open and they say they found the error in the code and have provided a one off patch to resolve the problem but.....we have to apply a 2.3GB Consolidated update patch as a pre-req for our little 28K one off.

I understand that its tough to provide fixes for all these different code levels, I guess I just assumed that by upgrading to 12.1.1 we would be on a pretty darn current version so we would be able to get fixes without having to go through a couple weeks of testing before we validate the affects of applying this huge CU3.

Anyway, hopefully by getting to CU3 and then applying this little one off we get the problem of unwanted planned orders resolved.