Showing posts with label Oracle. Show all posts
Showing posts with label Oracle. Show all posts
Friday, August 20, 2010
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).
Friday, August 6, 2010
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.
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.
Tuesday, August 3, 2010
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
Part One: Page 18
Part Two: Page 15
Wednesday, April 28, 2010
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.
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.
Wednesday, March 31, 2010
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.
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.
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.
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.
Friday, January 29, 2010
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'.
--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'.
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.
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.
Thursday, December 31, 2009
(Upgrade + Interfaces) = (Potato Chips + Bubble Gum)
Well, we have been live on R12.1 for a full month now. We made it through our first month end and now we are days away from closing out the year. While no upgrade is void of significant issues I would have to say ours has played out better than I could have hoped. Really, from an operations standpoint, the only major issues we had were getting our custom interfaces to work properly (which brings me to the topic of this post).
My new personal opinion is that (Upgrade + Interfaces) = (Potato Chips + Bubble Gum). What I mean is that the upgrade by itself is a very good thing and our custom interfaces by themselves really are superb but when you combine them together its like chewing bubble gum while eating potato chips, they just don't go well together.
We have three major interfaces that we maintain, all on the operations side. Two of the three interfaces were created to link a third party solution into oracle applications. In those two cases we were only able to test that information was put into and taken out of the interface tables the same way it was before the migration. As much as you try and replicate these interfaces without being able to test the process all the way through from beginning to end it becomes very difficult to verify that your solution will process correctly post upgrade. To complicate matters even more, our two third parties didn't have test instances available in which we could validate our code pre migraiton.
Here we are now, four weeks later and we are hoping that we've gotten the last 'glitch' resolved with our interfaces. It's been a hectic and very busy month essentially 'testing' our updated code in our production instance but we might finally be on our way to wrapping things up.
The lesson learned: things are sure easier when you don't have custom interfaces. To me it drives home the idea that its better to have a single fully integrated ERP system then it is to have a multiple systems trying to interface with each other. Granted, the price is very different between the cost of those two solutions unless you add in the cost of hiring developers to maintain and constantly monitor your code. For me, I'm taking the integrated system any day of the week.
My new personal opinion is that (Upgrade + Interfaces) = (Potato Chips + Bubble Gum). What I mean is that the upgrade by itself is a very good thing and our custom interfaces by themselves really are superb but when you combine them together its like chewing bubble gum while eating potato chips, they just don't go well together.
We have three major interfaces that we maintain, all on the operations side. Two of the three interfaces were created to link a third party solution into oracle applications. In those two cases we were only able to test that information was put into and taken out of the interface tables the same way it was before the migration. As much as you try and replicate these interfaces without being able to test the process all the way through from beginning to end it becomes very difficult to verify that your solution will process correctly post upgrade. To complicate matters even more, our two third parties didn't have test instances available in which we could validate our code pre migraiton.
Here we are now, four weeks later and we are hoping that we've gotten the last 'glitch' resolved with our interfaces. It's been a hectic and very busy month essentially 'testing' our updated code in our production instance but we might finally be on our way to wrapping things up.
The lesson learned: things are sure easier when you don't have custom interfaces. To me it drives home the idea that its better to have a single fully integrated ERP system then it is to have a multiple systems trying to interface with each other. Granted, the price is very different between the cost of those two solutions unless you add in the cost of hiring developers to maintain and constantly monitor your code. For me, I'm taking the integrated system any day of the week.
Monday, September 21, 2009
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.
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.
Friday, September 11, 2009
EAM Migration to 12.1
Found out yesterday that there are some specific pre-migration setup steps that need to be completed in order for EAM assets to migrate correctly. Apprently EAM gets integrated with Oracle Installed Base in release 12 and for that integration to work you have to have your Install Base parameters set up appropriately. It would have been nice of Oracle to include this in their upgrade documentation (Oracle Applications Upgrade Guide Release 11i to 12.1.1 Part No, E14010-01) but as Sept 11, 2009 this step is not included.
From what I understand a script runs during patch 6678700 called eamsnupd.sql which inserts the eam asset number into the csi_item_instance but if you do not have the Install Base parameters setup then when the sql tries to fetch an internal_party_id it fails to get any records from the csi_install_parameters.
Its interesting that they included this setup information in the EAM Release Notes for 12.0.6 but not for 12.1.1. So far I've only been able to find two metalink documents that explain this install base setup(437577.1 and 748070.1 this second doc being the release notes for 12.0.6).
So, just want to make you aware, if you are upgrading from 11i to 12.1 and you have EAM installed but aren't currently using Install Base then you need to setup the Install Base parameters before you migrate so that EAM asset numbers can be inserted into the item instance table.
Here is what the Oracle Release Notes say you need to do to setup Installed Base parameters:
Updated Sept 14th: Found another link on metalink, Doc Id 885895.1. This one seems to be the most detailed of the three docs.
From what I understand a script runs during patch 6678700 called eamsnupd.sql which inserts the eam asset number into the csi_item_instance but if you do not have the Install Base parameters setup then when the sql tries to fetch an internal_party_id it fails to get any records from the csi_install_parameters.
Its interesting that they included this setup information in the EAM Release Notes for 12.0.6 but not for 12.1.1. So far I've only been able to find two metalink documents that explain this install base setup(437577.1 and 748070.1 this second doc being the release notes for 12.0.6).
So, just want to make you aware, if you are upgrading from 11i to 12.1 and you have EAM installed but aren't currently using Install Base then you need to setup the Install Base parameters before you migrate so that EAM asset numbers can be inserted into the item instance table.
Here is what the Oracle Release Notes say you need to do to setup Installed Base parameters:
Beginning with Release 12.0, Oracle Enterprise Asset Management is integrated with Oracle Installed Base. Therefore, the Installed Base parameters must be set up to ensure that assets are created correctly in eAM.
We added a new section to the Setting Up chapter in the Oracle Enterprise Asset Management User's Guide relating to the installation parameters for Installed Base. These parameters must be set up in order to create asset correctly. This issue is related to Note 437577.1.
Setting Up Installed Base Parameters
You must perform the following steps in Oracle Installed Base:
Navigate to the Install Base Administrator responsibility.
Under the Setups menu, click the Install Parameters link.
Set up the Install Parameters for Installed Base. Additional Information: See Oracle Installed Base Implementation Guide for assistance on how to set up the Installed Base parameters. See "Set Up Installation Parameters", Setup Steps within Oracle Installed Base, Oracle Installed Base Implementation Guide.
Make sure that the Freeze checkbox has been selected. If it is unchecked, then select the checkbox.
Save your work.' (Oracle Metalink Doc Id 748070.1)
Updated Sept 14th: Found another link on metalink, Doc Id 885895.1. This one seems to be the most detailed of the three docs.
Tuesday, September 1, 2009
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.
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.
Tuesday, July 14, 2009
Oracle Pedigree and Serialization Manager
Today I sat in on a demo of the pedigree and serialization manager which is an Oracle product in development. Regulations being developed in Europe, Florida and California are the impetus behind this product. Pedigree and serialization manager is designed to reduce counterfeiting, primarily in the pharmaceutical industry, by having the manufacturer serialize each sellable unit and then tracking that unit through the supply chain via electronic pedigree until it is sold to an end consumer. From a consumer safety point of view I’m okay with validating that the prescription I’m filling is actually made by Pfizer or Merck instead of El Casa de Merck but from an operations and supply chain point of view I have two major questions: 1) How do you implement such an extensive tracking system without dramatically increasing the cost to the consumer and 2) What agency, company, or government is going to regulate and store all of this data?
Now let me get back to Oracle’s product. During the demo the presenter said that once a serial number is placed on a sellable unit, every transaction that happens against that unit will be stored electronically in the form of a pedigree. That pedigree will be passed from manufacturer, to wholesaler, to distributor, to pharmacy so that when a consumer purchases a product they can validate the origins of their medication. It’s a great idea, one which the state of
One thought would be to have all companies use the same application so that data passed would be compatible for each specific system. It seems like Oracle is trying to go down this road by basing this product on their Fusion tech stack which is supposed to easily integrate with E-business Suite, JD Edwards, PeopleSoft, and even SAP. However it still seems like passing this much information for each sellable unit is going drastically affect database performance.
Oracles Pedigree and Serialization Manager has capabilities to comply with either of the regulations stated above, however, until these regulations are strictly enforced I don’t see too many companies looking into implementing this product. Currently these regulations are being focused toward the pharmaceutical industry but sometime around 2000 the FDA began a ‘track and trace’ which is defined below. Based on that statement it seems like everyone within the food and drug industry ought to start preparing to implement some sort of pedigree/serialization. It will be interesting to see; how companies handle this regulation, how much it will increase costs, and how much of those cost increases will trickle down to the consumer.
‘The ability to trace products both forwards and backwards is critical for protecting consumers. FDA has formed an internal multi-Center group to meet with external entities (such as industry, consumers, and foreign governments) to better understand the universe of track and trace systems that are currently in use or are being developed. FDA is currently reaching out to various organizations to gain a better understanding of best practices for traceability and the use of electronic track and trace technologies to more rapidly and precisely track the origin and destination of contaminated foods, feed, and ingredients. FDA will use the information to develop the key attributes for a successful track and trace system. In addition, FDA plans to issue a Request for Applications to provide funding to six states to establish Rapid Response Teams to investigate multi-state outbreaks of foodborne illness.’
David Acheson, M.D., F.R.C.P.
Associate Commissioner for Foods
Food and Drug Administration
June 12, 2008
Subscribe to:
Posts (Atom)