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'.
Friday, January 29, 2010
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.
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.
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.
Subscribe to:
Posts (Atom)