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.