Internal requisitions provide the mechanism for requesting and transferring material from inventory to other inventory or expense locations. To use this functionality, you need to have Purchasing, Order Management, Shipping Execution, and Inventory installed. Internal Requisition (after suitable approval) will directly result in the generation of a sales order in the Order Management system through the Order Import process in Order Management
Setup Steps:
Step 1 - Creating the Item (Navigation: Items/Master Items)
a) On the Purchasing Tab - add a price if the item is to be used in iProcurement.
Uncheck the purchasing checkboxes, if the item is to ONLY be ordered from an internal source.
b) On the Order Management tab, and choose the attributes: Internal Ordered, Internal Orders Enabled & OE Transactable
c) Ensure that the item is assigned to both the Source and Destination Inventory Organizations
Step 2 - Create the Shipping Network (Navigation: Setup/Organizations/Shipping Networks)
a)Enter the Inventory Organization that will be the Source and the scope should be From or To Organizations
b)Choose the Transfer Type
Direct - means that when the Internal Sales Order is shipped the receipt process in the destination organization is done automatically
Intransit - means that when the Internal Sales Order is shipped - the destination inventory organization has to manually do the receiving process in Purchasing
c)Choose Internal Order Required checkbox
Step 3 - Create the Location (Navigation: Setup/Organization/Locations)
Enter a Location Name - for the Internal Location. This is the location that is used as the Destination Location & will eventually be tied to a customer
Step 4 - Conduct a Miscellaneous Receipt (Navigation: Transactions/Miscellaneous Transactions)
This step is being done to satisfy the Internal Sales Order which is created, as it ensures there will be ample quantity On Hand to perform the shipping portion of the Internal Sales Order process.
a)Choose the Inventory Organization that will be the Source Inventory Organization
b)Enter 'Miscellaneous Receipt' - Choose 'Transaction Lines'
c) Enter the Item created and then a sub-inventory, quantity, etc
Step 5 - Create the Internal Customer - Assign the Location
(Navigation: Customers/Standard)
a) Enter the Internal Customer Name - Choose the Find Button
b) If it is a new customer - choose New from the dialog box that appears
c) In this form - choose Open and enter the address details
d) Move to the lower half of the form - enter a usage - of 'Ship To'
e) Followed by choosing the Open button in the lower right hand corner of the form
In the new form which opened - enter the basic information for Payment Terms, Salesperson, etc.
Important: In the Internal Block - choose the Location which was created in Step 3
This association ties the customer to the location. Move to enter other pertinent information such as price list, etc, save - Close this SUB-FORM ONLY
It is also recommended to create a Bill To Usage record for the new customer.
Add a new record to the usage - and call this Bill To
Hit Open and enter any new information that pertains to the Bill To
Step 6 - Item Price (Navigation: Items/Master Items)
a) Query the item created in Step 1
b) Choose "Tools/Item Costs" from the top text menu. The screen to follow shows the item price that is used when creating the Internal Requisition. This is how purchasing derives the price when creating the Internal Requisition
Now you are ready to execute the flow which is explained in the next post titled "Setup steps required to use the Internal Requisition - Internal Sales Order Functionality - Part 2"
Thursday, November 29, 2007
Tuesday, November 27, 2007
Order Management - How To Setup Quote Entry?
Order Management uses the same form (OEXOEORD) to allow entry of 'Quotations' and 'Sales Orders', the fields available to quote (Quote Name, Quote Date) will be 'Enabled' under certain setup as mentioned below.
When the quote form is opened, (Navigation > OM Superuser > Negotiation > Quote),
the 'Transaction Phase' field decides if the form is used to enter quote or a sales order. It defaults values as 'Negotiation' for 'Quote Entry' or 'Fulfillment' for 'Sales Order Entry.
The profile OM: Default Sales Transaction Phase and the 'Default Transaction Phase' on the quote type setup decide the defaulting of the 'Transaction Phase'.
Follow the steps below to setup these values to have appropriate defaulting.
1.Remove the value (if any) from the profile "OM: Default Sales Transaction Phase" .
2. Assign a "Fulfillment" value in 'Default Transaction Phase' in 'Transaction Type Setup Form' for those Order Types for Sales Order.
3. Assign a "Negotiation" value in 'Default Transaction Phase' in 'Transaction Type Setup Form' for those Order Types for Quotes.
4. Submit Defaulting Generator against "Order Header" Entity (Do not specify attribute value).
Then the defaulting behavior will be :
(I) When entering sales order form first time, it will default to fulfillment
as transaction phase code.
(II) Then user choose a customer name/number , check if order type gets changed/ re-defaulted Transaction phase code will get re-defaulted according to defaulting rule.
Defaulting rule will find a value from the 'Default Transaction Phase' field in transaction type form for this order type.
When the quote form is opened, (Navigation > OM Superuser > Negotiation > Quote),
the 'Transaction Phase' field decides if the form is used to enter quote or a sales order. It defaults values as 'Negotiation' for 'Quote Entry' or 'Fulfillment' for 'Sales Order Entry.
The profile OM: Default Sales Transaction Phase and the 'Default Transaction Phase' on the quote type setup decide the defaulting of the 'Transaction Phase'.
Follow the steps below to setup these values to have appropriate defaulting.
1.Remove the value (if any) from the profile "OM: Default Sales Transaction Phase" .
2. Assign a "Fulfillment" value in 'Default Transaction Phase' in 'Transaction Type Setup Form' for those Order Types for Sales Order.
3. Assign a "Negotiation" value in 'Default Transaction Phase' in 'Transaction Type Setup Form' for those Order Types for Quotes.
4. Submit Defaulting Generator against "Order Header" Entity (Do not specify attribute value).
Then the defaulting behavior will be :
(I) When entering sales order form first time, it will default to fulfillment
as transaction phase code.
(II) Then user choose a customer name/number , check if order type gets changed/ re-defaulted Transaction phase code will get re-defaulted according to defaulting rule.
Defaulting rule will find a value from the 'Default Transaction Phase' field in transaction type form for this order type.
Wednesday, November 21, 2007
Understanding ERP - Right from the very basics
Would be a good idea to understand with a simple example..
Suppose you are running a small grocery shop. So the typical operation as a shop owner is you basically buy groceries from some big seller and stock it in your shop. Now people come to your shop for day-to-day needs and buy stuff from your shop at a slightly higher price than what you originally bought and stocked it in your shop.
Ocassionally you may not be carrying items or run out of stock that people ask for so you make a note of it and promise the person to come back tomorrow and they will get their item. So far so good, now lets name some entities before we proceed and things get complicated. The big seller from whom you buy stock is called as Vendor, the people who come to your shop to buy things are known as customers, the stock in your shop is known as inventory.
So far we have identified few entities that play an active role in your day-to-day operations. As time goes by, your business expands and now you take orders over the phone and provide service to deliver the items to your customers, so you hire people to help you out in maintaining the inventory, do the delivery part and all the necessary stuff to keep the business running smoothly. The people you hire are known as employees.
So in this small shop, you typically manage the bookkeeping activities by hand using a notepad or something similar. Now imagine the same setup on a larger scale where you have more than 10,000 customers, have more than 1000 vendors, have more than 1000employees and have a huge warehouse to maintain your inventory. Do you think you can manage all that information using pen and paper? Absolutely not possible! Agree?
To facilitate big businesses, companies like Oracle Corporation have created huge software known in the category of ERP (Enterprise Resource Planning) as Oracle Applications. Now coming to think of it, Oracle Applications is not one huge software, instead it is a collection of software known as modules that are integrated and talk to each other.
Now what is meant by integrated? First let us identify the modules by entities. For e.g Purchasing and Account Payables deal with the vendors since you typically purchase from vendors and eventually have to pay the dues. Oracle Purchasing handles all the requisitions and purchase orders to the vendors whereas Oracle Accounts Payables handles all the payments to the vendors.
Similarly Oracle Inventory deals with the items you maintain in stock, warehouse etc. Dealing with customers is handled collectively with the help of Oracle Receivables and Oracle Order Management. Order Management helps you collect all the information that your customer is ordering over the phone or webstore etc whereas Receivables help you collect the money for the orders that are delivered to the customers.
Now who maintains the paychecks, benefits of the 1000 employees? It is managed by Oracle Human Resources. So by now you might have got an idea - for each logical function there is a separate module that helps to execute and maintain that function.
So all the individual functions are being taken care but how do I know if I am making profit or loss? That’s where integration comes into play. There is another module known as Oracle General Ledger. This module receives information from all the different transaction modules and summarizes them in order to help you create profit and loss statements, reports for paying Taxes etc.
To simplify, when you pay your employees that payment is reported back to General Ledgers as cost i.e money going out, when you purchase inventory items the information is transferred to GL as money going out, and so is the case when you pay your vendors. Similarly when you receive items in your inventory it is transferred to GL as money (i.e. a form of money) coming in, when your customer sends payment it is transfered to GL as money coming in. So all the different transaction modules report to GL (General Ledger) as either “money going in” or “money going out”, the net result will tell you if you are making a profit or loss.
All the equipment, shops, warehouses, computers can be termed as Assets and they are managed by Oracle Fixed Assets. Initially Oracle Applications started as bunch of modules and as time passed by they added new modules for different and new functions growing to meet the needs of today's global business corporations
(Source: http://www.appsbi.com/2006/05/26/what-is-oracle-apps-erp)
Suppose you are running a small grocery shop. So the typical operation as a shop owner is you basically buy groceries from some big seller and stock it in your shop. Now people come to your shop for day-to-day needs and buy stuff from your shop at a slightly higher price than what you originally bought and stocked it in your shop.
Ocassionally you may not be carrying items or run out of stock that people ask for so you make a note of it and promise the person to come back tomorrow and they will get their item. So far so good, now lets name some entities before we proceed and things get complicated. The big seller from whom you buy stock is called as Vendor, the people who come to your shop to buy things are known as customers, the stock in your shop is known as inventory.
So far we have identified few entities that play an active role in your day-to-day operations. As time goes by, your business expands and now you take orders over the phone and provide service to deliver the items to your customers, so you hire people to help you out in maintaining the inventory, do the delivery part and all the necessary stuff to keep the business running smoothly. The people you hire are known as employees.
So in this small shop, you typically manage the bookkeeping activities by hand using a notepad or something similar. Now imagine the same setup on a larger scale where you have more than 10,000 customers, have more than 1000 vendors, have more than 1000employees and have a huge warehouse to maintain your inventory. Do you think you can manage all that information using pen and paper? Absolutely not possible! Agree?
To facilitate big businesses, companies like Oracle Corporation have created huge software known in the category of ERP (Enterprise Resource Planning) as Oracle Applications. Now coming to think of it, Oracle Applications is not one huge software, instead it is a collection of software known as modules that are integrated and talk to each other.
Now what is meant by integrated? First let us identify the modules by entities. For e.g Purchasing and Account Payables deal with the vendors since you typically purchase from vendors and eventually have to pay the dues. Oracle Purchasing handles all the requisitions and purchase orders to the vendors whereas Oracle Accounts Payables handles all the payments to the vendors.
Similarly Oracle Inventory deals with the items you maintain in stock, warehouse etc. Dealing with customers is handled collectively with the help of Oracle Receivables and Oracle Order Management. Order Management helps you collect all the information that your customer is ordering over the phone or webstore etc whereas Receivables help you collect the money for the orders that are delivered to the customers.
Now who maintains the paychecks, benefits of the 1000 employees? It is managed by Oracle Human Resources. So by now you might have got an idea - for each logical function there is a separate module that helps to execute and maintain that function.
So all the individual functions are being taken care but how do I know if I am making profit or loss? That’s where integration comes into play. There is another module known as Oracle General Ledger. This module receives information from all the different transaction modules and summarizes them in order to help you create profit and loss statements, reports for paying Taxes etc.
To simplify, when you pay your employees that payment is reported back to General Ledgers as cost i.e money going out, when you purchase inventory items the information is transferred to GL as money going out, and so is the case when you pay your vendors. Similarly when you receive items in your inventory it is transferred to GL as money (i.e. a form of money) coming in, when your customer sends payment it is transfered to GL as money coming in. So all the different transaction modules report to GL (General Ledger) as either “money going in” or “money going out”, the net result will tell you if you are making a profit or loss.
All the equipment, shops, warehouses, computers can be termed as Assets and they are managed by Oracle Fixed Assets. Initially Oracle Applications started as bunch of modules and as time passed by they added new modules for different and new functions growing to meet the needs of today's global business corporations
(Source: http://www.appsbi.com/2006/05/26/what-is-oracle-apps-erp)
Friday, November 9, 2007
ERP - Success and failures for ERP implementations
Introduction
Enterprise Resource Planning attempts to integrate all departments and functions across a company onto a single computer system that can serve all those different departments' particular needs.
Enterprise Resource Planning (ERP) predicts and balances, demand and supply. It is an
enterprise-wide set of forecasting, planning, and scheduling tools, which:
· links customers and suppliers into a complete supply chain,
· employs proven processes for decision-making, and
· co-ordinates sales, marketing, operations, logistics, purchasing, finance, product
development, and human resources
Benefits of ERP
ERP automates the tasks necessary to perform a business process—such as order fulfillment, which involves taking an order from a customer, shipping it and billing for it.
With ERP, when a customer service representative takes an order, he or she has all the necessary information—the customer's credit rating and order history, the company's inventory levels and the shipping dock's trucking schedule. Everyone else in the company can view the same information and has access to the single database that holds the order.
When one department finishes with the order, it is automatically routed via the ERP
system to the next department. To find out where the order is at any point, one need only log in to the system. The goals of ERP include high levels of customer service, productivity and cost reduction, and it provides the foundation for effective supply chain management and ecommerce.
It does it by developing plans and schedules so that the right resources -
manpower, materials, machinery, and money – are available in the right amount when
needed. ERP helps in co-ordinating the individual elements of the overall set of business processes. Many companies have experienced, as a direct result of ERP dramatic increases in responsiveness, productivity, on-time shipments and sales, along with substantial decreases in purchase costs, quality problems, and inventories.
ERP is the vehicle for getting valid plans and schedules, but not just of materials and production. It also means valid schedules of shipments to customers, of personnel and equipment requirements, of required product development resources, and of cash flow and profit.
Critical Success Factors:
The old saying 'the devil is in the details' is certainly a truism in ERP implementation. Building a solid implementation plan is critical for success. We need to plan our deployment in logical, manageable chunks to minimize risks and maximize acceptance of the new solution.
We might do so in a 'big bang' or use a ‘phased approach’. We need to decide which
business units will be implemented first and how will the application modules be
deployed. The IT infrastructure has to grow with our needs and we may need to integrate with legacy applications. We will need to keep the project focused on business results, and assess the results after the implementation.
An ERP system is not only the integration of various organisation processes. Any system has to possess few key characteristics to qualify for a true ERP solution. These features are:
1) Flexibility: An ERP system should be flexible to respond to the changing needs of an enterprise. The client server technology enables ERP to run across various data base back ends through Open Data Base Connectivity (ODBC).
2) Modular & Open: ERP system has to have an open system architecture. This means
that any module can be interfaced or detached whenever required without affecting
the other modules. It should support multiple hardware platforms for the companies
having heterogeneous collection of systems. It must support some third party add-ons
also.
3) Comprehensive: It should be able to support variety of organisational functions and must be suitable for a wide range of business organisations.
4) Beyond The Company: It should not be confined to the organisational boundaries,
rather support the on-line connectivity to the other business entities of the
organisation.
5) Best Business Practices: It must have a collection of the best business processes
applicable worldwide.
6) Simulation of Reality: Last but not the least, it must simulate the reality of business processes on the computers. In no way it should have the control beyond the business processes and it must be able to assign accountabilities to the users controlling the system.
Since, ERP gets the best out of the available resources, it is very important to reengineer the business processes before going for an ERP implementation.
Reasons for failures of ERP implementation
People don't like to change, and ERP asks them to change how they do their jobs. That is why the value of ERP is so hard to pin down. The software is less important than the changes companies make in the ways they do business.
If we use ERP to improve the ways people take orders, manufacture goods, ship them and bill for them, we will see value from the software; else the new software could slow us down by simply replacing the old software that everyone knew with new software that no one does. Common reasons for failure of ERP projects include:
1) Long period: ERP implementations usually run for a year or more. This long period
can be a pain for the company that is investing huge sums of money. But this should not be seen as a drawback as all the effort that is invested is for improving the business of the company itself.
2) Budget: A few oversights in the budgeting and planning stage can send ERP costs
spiraling out of control faster than oversights in planning almost any other information system undertaking.
3) Business Processes: The most common reason that companies walk away from
multimillion-dollar ERP projects is that they discover the software does not support one of their important business processes. At that point there are two things they can do:
i) They can change the business process to accommodate the software, which will mean
deep changes in long-established ways of doing business (that often provide competitive advantage) and shake up important people's roles and responsibilities.
Or
ii) They can modify the software to fit the process. This may slow down the project,
introduce dangerous bugs into the system and make upgrading the software to the ERP
vendor's next release excruciatingly difficult, because the customizations will need to be torn apart and rewritten to fit with the new version.
What are the hidden costs of ERP?
1. Training
Training expenses are high because workers almost invariably have to learn a new set of processes, not just a new software interface.
2. Integration and testing
Testing is done by running a real purchase order through the system, from order entry
through shipping and receipt of payment with the participation of the employees who will eventually do those jobs. Add-ons add to the integration costs of ERP
3. Customization:Tailor-Made Business Fit
The customizations can affect every module of the ERP system because they are all so
tightly linked together. It is like playing with fire.
4. Post-ERP depression
ERP systems often wreak cause havoc in the companies that install them. In a recent
Deloitte Consulting survey of 64 Fortune 500 companies, one in four admitted that they suffered a drop in performance when their ERP system went live. The true percentage is undoubtedly much higher. The most common reason for the performance problems is that everything looks and works differently from the way it did before.
5. Waiting for ROI (Return On Investments)
The company expects to gain value from the application as soon as it is installed but it does take some time for the fruits to ripen.
How to make a successful ERP implementation?
· Choosing the right software vendor: If two vendors offer a function required in a
specific industry segment, and one specializes in deploying it in that segment while
the other does not, the difference can be dramatic. Here the benefits that are offered need to be considered along with cost and risk.
· Analyzing the Risks: Even the most simple effort probably has only a 90 percent
chance of success - i.e., the project is on-time, within budget, and attains all the
planned benefits. As projects increase in scope, the odds of achieving success
diminish rapidly. Implementation projects require companies to strike a balance
between the desire to satisfy everyone's functionality needs, and the need to keep
things simple enough to ensure success. A methodology will help ward off risk, but a
contingency plan still is absolutely necessary.
· Determine Company Intentions and Commitment: Examine why you wish to
undertake such a major project.
1. Is it to improve your already efficient and streamlined procedures?
2. Is it to speed workflow bottlenecks?
3. Is everything in disarray or do you just need to remove one or two bad apples?
4. Are you trying to get everything fixed at once?
· Be True to the Budget: The project should have a contingency budget. Most projects
should have a contingency of 10 percent on time - if all tasks go well, it will finish 10 percent early. Maintain pressure to control costs on all project tasks.
· Selecting proper technology: The tradeoff between stable, proven technology and
newer, state-of-the-art systems is one of the most critical decision points for the
project. While stable technology - one that has been around for several years - runs
the risk of being obsolete in the near future, newer technology may involve near-term
instability, which can lead to its own problems.
The key to successful implementation of an enterprise software solution is to apply
people, process, and product initiatives within a structured methodology framework.
When these elements are brought together and skillfully managed, companies can fully
expect to realize shorter time to production, measurable business benefits, and a rapid return on their technology investment.
Enterprise Resource Planning attempts to integrate all departments and functions across a company onto a single computer system that can serve all those different departments' particular needs.
Enterprise Resource Planning (ERP) predicts and balances, demand and supply. It is an
enterprise-wide set of forecasting, planning, and scheduling tools, which:
· links customers and suppliers into a complete supply chain,
· employs proven processes for decision-making, and
· co-ordinates sales, marketing, operations, logistics, purchasing, finance, product
development, and human resources
Benefits of ERP
ERP automates the tasks necessary to perform a business process—such as order fulfillment, which involves taking an order from a customer, shipping it and billing for it.
With ERP, when a customer service representative takes an order, he or she has all the necessary information—the customer's credit rating and order history, the company's inventory levels and the shipping dock's trucking schedule. Everyone else in the company can view the same information and has access to the single database that holds the order.
When one department finishes with the order, it is automatically routed via the ERP
system to the next department. To find out where the order is at any point, one need only log in to the system. The goals of ERP include high levels of customer service, productivity and cost reduction, and it provides the foundation for effective supply chain management and ecommerce.
It does it by developing plans and schedules so that the right resources -
manpower, materials, machinery, and money – are available in the right amount when
needed. ERP helps in co-ordinating the individual elements of the overall set of business processes. Many companies have experienced, as a direct result of ERP dramatic increases in responsiveness, productivity, on-time shipments and sales, along with substantial decreases in purchase costs, quality problems, and inventories.
ERP is the vehicle for getting valid plans and schedules, but not just of materials and production. It also means valid schedules of shipments to customers, of personnel and equipment requirements, of required product development resources, and of cash flow and profit.
Critical Success Factors:
The old saying 'the devil is in the details' is certainly a truism in ERP implementation. Building a solid implementation plan is critical for success. We need to plan our deployment in logical, manageable chunks to minimize risks and maximize acceptance of the new solution.
We might do so in a 'big bang' or use a ‘phased approach’. We need to decide which
business units will be implemented first and how will the application modules be
deployed. The IT infrastructure has to grow with our needs and we may need to integrate with legacy applications. We will need to keep the project focused on business results, and assess the results after the implementation.
An ERP system is not only the integration of various organisation processes. Any system has to possess few key characteristics to qualify for a true ERP solution. These features are:
1) Flexibility: An ERP system should be flexible to respond to the changing needs of an enterprise. The client server technology enables ERP to run across various data base back ends through Open Data Base Connectivity (ODBC).
2) Modular & Open: ERP system has to have an open system architecture. This means
that any module can be interfaced or detached whenever required without affecting
the other modules. It should support multiple hardware platforms for the companies
having heterogeneous collection of systems. It must support some third party add-ons
also.
3) Comprehensive: It should be able to support variety of organisational functions and must be suitable for a wide range of business organisations.
4) Beyond The Company: It should not be confined to the organisational boundaries,
rather support the on-line connectivity to the other business entities of the
organisation.
5) Best Business Practices: It must have a collection of the best business processes
applicable worldwide.
6) Simulation of Reality: Last but not the least, it must simulate the reality of business processes on the computers. In no way it should have the control beyond the business processes and it must be able to assign accountabilities to the users controlling the system.
Since, ERP gets the best out of the available resources, it is very important to reengineer the business processes before going for an ERP implementation.
Reasons for failures of ERP implementation
People don't like to change, and ERP asks them to change how they do their jobs. That is why the value of ERP is so hard to pin down. The software is less important than the changes companies make in the ways they do business.
If we use ERP to improve the ways people take orders, manufacture goods, ship them and bill for them, we will see value from the software; else the new software could slow us down by simply replacing the old software that everyone knew with new software that no one does. Common reasons for failure of ERP projects include:
1) Long period: ERP implementations usually run for a year or more. This long period
can be a pain for the company that is investing huge sums of money. But this should not be seen as a drawback as all the effort that is invested is for improving the business of the company itself.
2) Budget: A few oversights in the budgeting and planning stage can send ERP costs
spiraling out of control faster than oversights in planning almost any other information system undertaking.
3) Business Processes: The most common reason that companies walk away from
multimillion-dollar ERP projects is that they discover the software does not support one of their important business processes. At that point there are two things they can do:
i) They can change the business process to accommodate the software, which will mean
deep changes in long-established ways of doing business (that often provide competitive advantage) and shake up important people's roles and responsibilities.
Or
ii) They can modify the software to fit the process. This may slow down the project,
introduce dangerous bugs into the system and make upgrading the software to the ERP
vendor's next release excruciatingly difficult, because the customizations will need to be torn apart and rewritten to fit with the new version.
What are the hidden costs of ERP?
1. Training
Training expenses are high because workers almost invariably have to learn a new set of processes, not just a new software interface.
2. Integration and testing
Testing is done by running a real purchase order through the system, from order entry
through shipping and receipt of payment with the participation of the employees who will eventually do those jobs. Add-ons add to the integration costs of ERP
3. Customization:Tailor-Made Business Fit
The customizations can affect every module of the ERP system because they are all so
tightly linked together. It is like playing with fire.
4. Post-ERP depression
ERP systems often wreak cause havoc in the companies that install them. In a recent
Deloitte Consulting survey of 64 Fortune 500 companies, one in four admitted that they suffered a drop in performance when their ERP system went live. The true percentage is undoubtedly much higher. The most common reason for the performance problems is that everything looks and works differently from the way it did before.
5. Waiting for ROI (Return On Investments)
The company expects to gain value from the application as soon as it is installed but it does take some time for the fruits to ripen.
How to make a successful ERP implementation?
· Choosing the right software vendor: If two vendors offer a function required in a
specific industry segment, and one specializes in deploying it in that segment while
the other does not, the difference can be dramatic. Here the benefits that are offered need to be considered along with cost and risk.
· Analyzing the Risks: Even the most simple effort probably has only a 90 percent
chance of success - i.e., the project is on-time, within budget, and attains all the
planned benefits. As projects increase in scope, the odds of achieving success
diminish rapidly. Implementation projects require companies to strike a balance
between the desire to satisfy everyone's functionality needs, and the need to keep
things simple enough to ensure success. A methodology will help ward off risk, but a
contingency plan still is absolutely necessary.
· Determine Company Intentions and Commitment: Examine why you wish to
undertake such a major project.
1. Is it to improve your already efficient and streamlined procedures?
2. Is it to speed workflow bottlenecks?
3. Is everything in disarray or do you just need to remove one or two bad apples?
4. Are you trying to get everything fixed at once?
· Be True to the Budget: The project should have a contingency budget. Most projects
should have a contingency of 10 percent on time - if all tasks go well, it will finish 10 percent early. Maintain pressure to control costs on all project tasks.
· Selecting proper technology: The tradeoff between stable, proven technology and
newer, state-of-the-art systems is one of the most critical decision points for the
project. While stable technology - one that has been around for several years - runs
the risk of being obsolete in the near future, newer technology may involve near-term
instability, which can lead to its own problems.
The key to successful implementation of an enterprise software solution is to apply
people, process, and product initiatives within a structured methodology framework.
When these elements are brought together and skillfully managed, companies can fully
expect to realize shorter time to production, measurable business benefits, and a rapid return on their technology investment.
Tuesday, November 6, 2007
Oracle Purchasing - Setup - Purchasing Options - Default Options
Use the Default Options region to define the defaults you can later use to speed up data entry and enforce system wide requirements in many Oracle Purchasing forms.
*These options must be defined separately for each Operating Unit.
*By assigning a value at the responsibility level when that responsibility has been tied to an operating unit,it is possible to have different values for different operating units.
Requisition Import Group-By:
Use the ReqImport process to import requisitions from other Oracle or non-Oracle systems. Sources for requisitions can include Work In Process, Master Scheduling/MRP, and Inventory, as well as custom systems. Requisition Import creates a requisition line and a requisition distribution for each row it finds in the interface table. It then groups these lines on requisitions according to parameters defined below.
All: group all requisition lines on one requisition
Buyer: group lines for each buyer name on a separate requisition.
Category: group lines for each purchasing category on a separate requisition.
Item: group lines for each item on a separate requisition
Location: group lines for each location on a separate requisition
Vendor: group lines for each vendor on a separate requisition.
Rate Type:
Select the currency Rate Type that defaults on requisitions, purchase
orders, RFQs, and quotations. Use conversion rate types to automatically
assign a rate when you convert foreign currency journal amounts to functional
currency equivalents. You enter daily conversion rates for specific
combinations of foreign currency, date, and conversion rate type. If the
Rate Type is User, you can override this default for each document line. If
either your functional currency (defined in your set of books) or your
transaction currency (the currency you enter in a purchasing document window)
is Euro (the European Monetary Unit currency), and the other is another
European currency, Purchasing defaults in the appropriate conversion Rate Type,
Rate, and Rate Date.
Spot: An exchange rate which you enter to perform conversion based on the
rate on a specific date. It applies to the immediate delivery of a currency.
Corporate: An exchange rate you define to standardize rates for your
company. This rate is generally a standard market rate determined by
senior financial management for use throughout the organization.
User: An exchange rate you specify when you enter a foreign currency
journal entry.
EMU Fixed: An exchange rate General Ledger provides automatically when
you enter journals (after the EMU effective starting date) using a foreign
currency that has a fixed relationship with the Euro.
Minimum Release Amount:
This is the minimum release amount which defaults on blanket, contract, and
planned purchase orders. This amount is in your functional currency.
Taxable:
Check the Taxable box to set the default taxable status to Yes.
This default is for new items and for purchase order shipments without an item number. You can override the taxable status for each item or shipment.
The taxable status is printed on purchase orders
Price Break Type:
The type selected here will default on blanket and planned purchase orders.
Cumulative: price breaks apply to the cumulative quantity on all released shipments for the item
Non-cumulative: price breaks apply to quantities on individual released shipments for the item.
Price Type:
The type selected here will default on purchase orders. Use the
Lookup Codes window to define price types.
These are:
Cost Plus Fee
Cost Plus Percentage
Fixed
Indexed
Variable
Quotation Warning Delay (Days):
This option sets the number of days of warning before a quotation expires. When the limit is reached, you receive the following message in the Alert Notifications window: "Quotations active or approaching expiration".
RFQ Required:
Clicking this box causes an RFQ to be required before an item can be autocreated onto a P.O.
Receipt Close % Tolerance:
Purchasing automatically closes a shipment for receiving if it is within the receiving close tolerance at the receiving close point. It can be overridden for specific items and orders. If you are not going to receive the goods then on the purchase order set the receipt close tolerance to 100%. When it is set to 100% then when the PO is approved the line will be closed for receiving. Then when you match the invoice to the PO the status will change to Closed.
Invoice Close % Tolerance:
Purchasing automatically closes a shipment for invoicing if it is within the vendor invoice close tolerance at time of invoice matching. It can be overridden for specific items and orders.
CAUTION: If you set this to 100%, the PO will automatically close for
invoicing upon approval.
Line Type:
This is the default Line Type for requisition, RFQ, quotation, and purchase order lines. When you create any of these documents, the line type is part of your item information. You can override the line type for each document line.
Invoice Matching:
Select one of the following default Invoice Match options:
Two-Way - Purchase Order and invoice quantities must match within
tolerance. Often used for services where no receiver is
generated.
Three-Way - Purchase Order, receipt and invoice quantities must match
within tolerance. Must enter receiver.
Four-Way - Purchase Order, receipt, inspection and invoice quantities
must match within tolerance. Must enter receiver and
inspection quantities
*These options must be defined separately for each Operating Unit.
*By assigning a value at the responsibility level when that responsibility has been tied to an operating unit,it is possible to have different values for different operating units.
Requisition Import Group-By:
Use the ReqImport process to import requisitions from other Oracle or non-Oracle systems. Sources for requisitions can include Work In Process, Master Scheduling/MRP, and Inventory, as well as custom systems. Requisition Import creates a requisition line and a requisition distribution for each row it finds in the interface table. It then groups these lines on requisitions according to parameters defined below.
All: group all requisition lines on one requisition
Buyer: group lines for each buyer name on a separate requisition.
Category: group lines for each purchasing category on a separate requisition.
Item: group lines for each item on a separate requisition
Location: group lines for each location on a separate requisition
Vendor: group lines for each vendor on a separate requisition.
Rate Type:
Select the currency Rate Type that defaults on requisitions, purchase
orders, RFQs, and quotations. Use conversion rate types to automatically
assign a rate when you convert foreign currency journal amounts to functional
currency equivalents. You enter daily conversion rates for specific
combinations of foreign currency, date, and conversion rate type. If the
Rate Type is User, you can override this default for each document line. If
either your functional currency (defined in your set of books) or your
transaction currency (the currency you enter in a purchasing document window)
is Euro (the European Monetary Unit currency), and the other is another
European currency, Purchasing defaults in the appropriate conversion Rate Type,
Rate, and Rate Date.
Spot: An exchange rate which you enter to perform conversion based on the
rate on a specific date. It applies to the immediate delivery of a currency.
Corporate: An exchange rate you define to standardize rates for your
company. This rate is generally a standard market rate determined by
senior financial management for use throughout the organization.
User: An exchange rate you specify when you enter a foreign currency
journal entry.
EMU Fixed: An exchange rate General Ledger provides automatically when
you enter journals (after the EMU effective starting date) using a foreign
currency that has a fixed relationship with the Euro.
Minimum Release Amount:
This is the minimum release amount which defaults on blanket, contract, and
planned purchase orders. This amount is in your functional currency.
Taxable:
Check the Taxable box to set the default taxable status to Yes.
This default is for new items and for purchase order shipments without an item number. You can override the taxable status for each item or shipment.
The taxable status is printed on purchase orders
Price Break Type:
The type selected here will default on blanket and planned purchase orders.
Cumulative: price breaks apply to the cumulative quantity on all released shipments for the item
Non-cumulative: price breaks apply to quantities on individual released shipments for the item.
Price Type:
The type selected here will default on purchase orders. Use the
Lookup Codes window to define price types.
These are:
Cost Plus Fee
Cost Plus Percentage
Fixed
Indexed
Variable
Quotation Warning Delay (Days):
This option sets the number of days of warning before a quotation expires. When the limit is reached, you receive the following message in the Alert Notifications window: "Quotations active or approaching expiration".
RFQ Required:
Clicking this box causes an RFQ to be required before an item can be autocreated onto a P.O.
Receipt Close % Tolerance:
Purchasing automatically closes a shipment for receiving if it is within the receiving close tolerance at the receiving close point. It can be overridden for specific items and orders. If you are not going to receive the goods then on the purchase order set the receipt close tolerance to 100%. When it is set to 100% then when the PO is approved the line will be closed for receiving. Then when you match the invoice to the PO the status will change to Closed.
Invoice Close % Tolerance:
Purchasing automatically closes a shipment for invoicing if it is within the vendor invoice close tolerance at time of invoice matching. It can be overridden for specific items and orders.
CAUTION: If you set this to 100%, the PO will automatically close for
invoicing upon approval.
Line Type:
This is the default Line Type for requisition, RFQ, quotation, and purchase order lines. When you create any of these documents, the line type is part of your item information. You can override the line type for each document line.
Invoice Matching:
Select one of the following default Invoice Match options:
Two-Way - Purchase Order and invoice quantities must match within
tolerance. Often used for services where no receiver is
generated.
Three-Way - Purchase Order, receipt and invoice quantities must match
within tolerance. Must enter receiver.
Four-Way - Purchase Order, receipt, inspection and invoice quantities
must match within tolerance. Must enter receiver and
inspection quantities
Oracle Purchasing - Setup - Purchasing Options - Overview
This set up must be entered for each Operating Unit if Multi-Org has been
implemented.
Purchasing > Setup > Organizations > Purchasing Options > Purchasing Options TAB
Use this form to define and review your Oracle Purchasing System Options, which are the default and control values for corresponding fields throughout Oracle Purchasing. You can often override these default values from the particular forms. You normally first use this form as part of your implementation of Oracle Purchasing. Setting up specific values in this form saves you time when you create your requisitions, purchase orders and agreements, receipts, quotations, and RFQs.
Oracle Purchasing lets you define specific categories of system options when you enter one of the following values in the Additional Purchasing Options field.
1) Default Options - Use the Default Options region to define the defaults you can later use to speed up data entry and enforce system wide requirements in many Oracle Purchasing forms. Oracle Purchasing displays the Default Options region when you initially enter the form.
2) Accrual Options - Use the Accrual Options region to define accrual options, such as whether you accrue expense items at period end or upon receipt.
3) Control Options - Use the Control Options region to define control options, such as the receipt close point and minimum release amount.
4) Internal Requisition Options - Use the Internal Requisition Options region to define internal requisition options, such as the order type and terms. You can navigate to this region only when Oracle Order Entry and Oracle Inventory are installed.
5) Numbering Options - Use the Numbering Options region to define the numbering method, numbering type, and next number for each of your documents.
6) Approval Options - Use the Approval Options region to define system wide approval controls, such as whether you want to enforce price tolerances and vendor holds.
7) Tax Defaults Options - Define the sources from which purchasing documents default tax information. Check one or more of the tax defaults sources from which your purchasing documents default tax codes. In the Hierarchy column, enter a ranking number (starting with 1) for each of the tax defaults sources you checked (even if you checked only one). For example, you may check Item, Supplier Site, and Supplier and rank them 3, 2, and 1 respectively. This means that when your purchasing documents default tax information, they look first for tax information from the supplier; if that tax information is not found, they look next for tax information from the supplier site; if that's not found, they look for tax information corresponding to the item.
Please read the next posts for details on each of the above SEVEN points
implemented.
Purchasing > Setup > Organizations > Purchasing Options > Purchasing Options TAB
Use this form to define and review your Oracle Purchasing System Options, which are the default and control values for corresponding fields throughout Oracle Purchasing. You can often override these default values from the particular forms. You normally first use this form as part of your implementation of Oracle Purchasing. Setting up specific values in this form saves you time when you create your requisitions, purchase orders and agreements, receipts, quotations, and RFQs.
Oracle Purchasing lets you define specific categories of system options when you enter one of the following values in the Additional Purchasing Options field.
1) Default Options - Use the Default Options region to define the defaults you can later use to speed up data entry and enforce system wide requirements in many Oracle Purchasing forms. Oracle Purchasing displays the Default Options region when you initially enter the form.
2) Accrual Options - Use the Accrual Options region to define accrual options, such as whether you accrue expense items at period end or upon receipt.
3) Control Options - Use the Control Options region to define control options, such as the receipt close point and minimum release amount.
4) Internal Requisition Options - Use the Internal Requisition Options region to define internal requisition options, such as the order type and terms. You can navigate to this region only when Oracle Order Entry and Oracle Inventory are installed.
5) Numbering Options - Use the Numbering Options region to define the numbering method, numbering type, and next number for each of your documents.
6) Approval Options - Use the Approval Options region to define system wide approval controls, such as whether you want to enforce price tolerances and vendor holds.
7) Tax Defaults Options - Define the sources from which purchasing documents default tax information. Check one or more of the tax defaults sources from which your purchasing documents default tax codes. In the Hierarchy column, enter a ranking number (starting with 1) for each of the tax defaults sources you checked (even if you checked only one). For example, you may check Item, Supplier Site, and Supplier and rank them 3, 2, and 1 respectively. This means that when your purchasing documents default tax information, they look first for tax information from the supplier; if that tax information is not found, they look next for tax information from the supplier site; if that's not found, they look for tax information corresponding to the item.
Please read the next posts for details on each of the above SEVEN points
Oracle Inventory - Organizations - Basics
Oracle Applications uses multiple types of organizations to build the business
execution structure. At the top of the structure is the accounting set of books
SOB), defined in the General Ledger. Next, different types of organizations are
used to further define the organization structure and relationships. All
organizations are defined and updated with the Define Organization form.
Set of Books: A General Ledger SOB, linked to the inventory organization,
controls the financial accounting of inventory transactions. A SOB is made up
of a chart of accounts, a financial calendar, and a currency. The general
ledger secures transactions (journal entries, balances) by SOB.
Legal Entity. A legal entity organization defines the tax and fiscal reporting
level. The legal entity represents the legal company.
Operating Unit: An operating unit organization defines the Purchasing, Order
Entry, Accounts Payable and Accounts Receivable level of operation. An operating
unit may span multiple manufacturing facilities, distribution points and sales
offices, or it may be limited to a single site.
Inventory Organization: Two flavors of inventory organizations are found in
Oracle Applications. They are defined the same, and both are assigned a set
of books, a legal entity organization, an operating unit organization, and a
location. An item master organization is used for item number maintenance and
validation. This master organization serves as a data repository storing items
and item attributes, master level categories and category sets, master level
cross references, and numerous data defaults. On-hand balances, inventory
movements, and other on-going inventory activities are not performed in an item
master organization. Generally, the master organization is used as the
validation organization for Purchasing and Order Entry. It is recommended
that a single item master organization be defined, even in multiple organization,
multiple sets of books environments.
In addition to the item master organization there are one or more non-master
inventory organizations. Like the item master inventory organization, the
non-master organizations are assigned a set of books, a legal entity organization
and an operating unit organization. The non-master inventory organization points
to a master organization and looks to the master organization for master level
item attributes, master level categories, and other master level controlled data.
Note that each organization has its own set of books/legal entity/operating unit
relationship, so inventory organizations with differing SOB’s or operating units
may share the same master organization.
These non-master inventory organizations are the execution level organizations.
They hold on-hand balances and transaction history. Here is where inventory
users execute their daily activities, such as receiving and issuing material,
performing cycle counts, and viewing material availability and transaction
history. A single organization therefore generally represents a single
manufacturing site or distribution center.
Locations: A location code is an address. Each inventory organization must
be assigned at least one location code.
Subinventories: A subinventory is used as a holding point for on-hand
inventory and generally represents a stockroom, stocking area or cage used
for storing material. Subinventories are defined within inventory
organizations. An inventory organization may have any number of
subinventories, and an asset account is assigned to each subinventory.
Since the subinventory entity is logical, as there is not an address or
physical location description associated with it, clients may define
subinventories for any physical or logical grouping of inventory
Stock Locators: Stock locators are an optional entity that may be used to
represent physical locations within a subinventory. You may choose to use
stock locators for selected subinventories or selected items within selected
subinventories. If locators are used, subinventory and locator track on-hand
balances. Therefore, if locators are defined to represent a shelf within a
stockroom, on-hand balances on the system would show the item and quantity
down to the physical location within the facility.
Oracle Inventory uses a key flexfield for stock locators. This presents a few
limitations for its use. Only one locator flexfield definition is allowed per
install. Therefore, if the stockroom (subinventory) wants to track material
by row, bin and shelf, it will likely define a three-segment flexfield with
segments for row, bin, and shelf. If locators are desired for another
subinventory, even in another organization, the structure will again be 3
segments for row, bin and shelf. In addition to this limitation, locators
must be unique within an organization; you cannot use the same locator in
different subinventories within an organization, but you can use the same
locator in subinventories in a different organization.
execution structure. At the top of the structure is the accounting set of books
SOB), defined in the General Ledger. Next, different types of organizations are
used to further define the organization structure and relationships. All
organizations are defined and updated with the Define Organization form.
Set of Books: A General Ledger SOB, linked to the inventory organization,
controls the financial accounting of inventory transactions. A SOB is made up
of a chart of accounts, a financial calendar, and a currency. The general
ledger secures transactions (journal entries, balances) by SOB.
Legal Entity. A legal entity organization defines the tax and fiscal reporting
level. The legal entity represents the legal company.
Operating Unit: An operating unit organization defines the Purchasing, Order
Entry, Accounts Payable and Accounts Receivable level of operation. An operating
unit may span multiple manufacturing facilities, distribution points and sales
offices, or it may be limited to a single site.
Inventory Organization: Two flavors of inventory organizations are found in
Oracle Applications. They are defined the same, and both are assigned a set
of books, a legal entity organization, an operating unit organization, and a
location. An item master organization is used for item number maintenance and
validation. This master organization serves as a data repository storing items
and item attributes, master level categories and category sets, master level
cross references, and numerous data defaults. On-hand balances, inventory
movements, and other on-going inventory activities are not performed in an item
master organization. Generally, the master organization is used as the
validation organization for Purchasing and Order Entry. It is recommended
that a single item master organization be defined, even in multiple organization,
multiple sets of books environments.
In addition to the item master organization there are one or more non-master
inventory organizations. Like the item master inventory organization, the
non-master organizations are assigned a set of books, a legal entity organization
and an operating unit organization. The non-master inventory organization points
to a master organization and looks to the master organization for master level
item attributes, master level categories, and other master level controlled data.
Note that each organization has its own set of books/legal entity/operating unit
relationship, so inventory organizations with differing SOB’s or operating units
may share the same master organization.
These non-master inventory organizations are the execution level organizations.
They hold on-hand balances and transaction history. Here is where inventory
users execute their daily activities, such as receiving and issuing material,
performing cycle counts, and viewing material availability and transaction
history. A single organization therefore generally represents a single
manufacturing site or distribution center.
Locations: A location code is an address. Each inventory organization must
be assigned at least one location code.
Subinventories: A subinventory is used as a holding point for on-hand
inventory and generally represents a stockroom, stocking area or cage used
for storing material. Subinventories are defined within inventory
organizations. An inventory organization may have any number of
subinventories, and an asset account is assigned to each subinventory.
Since the subinventory entity is logical, as there is not an address or
physical location description associated with it, clients may define
subinventories for any physical or logical grouping of inventory
Stock Locators: Stock locators are an optional entity that may be used to
represent physical locations within a subinventory. You may choose to use
stock locators for selected subinventories or selected items within selected
subinventories. If locators are used, subinventory and locator track on-hand
balances. Therefore, if locators are defined to represent a shelf within a
stockroom, on-hand balances on the system would show the item and quantity
down to the physical location within the facility.
Oracle Inventory uses a key flexfield for stock locators. This presents a few
limitations for its use. Only one locator flexfield definition is allowed per
install. Therefore, if the stockroom (subinventory) wants to track material
by row, bin and shelf, it will likely define a three-segment flexfield with
segments for row, bin, and shelf. If locators are desired for another
subinventory, even in another organization, the structure will again be 3
segments for row, bin and shelf. In addition to this limitation, locators
must be unique within an organization; you cannot use the same locator in
different subinventories within an organization, but you can use the same
locator in subinventories in a different organization.
Sunday, November 4, 2007
Inventory - Lot Control Setups
1. Set organization lot control parameter:
Navigate to Setup -> Organizations -> Parameters -> Select the Revision,
Lot, Serial alternative region.
1. Select an option for lot number uniqueness.
Across items: Enforce unique lot numbers for items across all
organizations.
None: Unique lot numbers are not required.
2. Select an option for lot number generation.
User-defined: Enter user-defined lot numbers when you receive
items.
At organization level: Define the starting prefix and lot number
information for items using the values
you enter in the Prefix, Zero Pad, Suffix
and Total Length fields. When you
receive items, this information is used
to automatically generate lot numbers for
your items.
At item level: Define the starting lot number prefix and the
starting lot number when you define the item.
This information is used to generate a lot number
for the item when it is received.
3. Indicate whether to add zeros to right-justify the numeric portion
of lot number (Zero Pad Suffix).
4. Optionally, select a alphanumeric lot number prefix to use for
system-generated lot numbers when generation is at the
organization level.
5. Optionally, define the maximum length for lot number.
________________________________________________________________
If you use Oracle Work in Process and you set the WIP parameter to
default the lot number based on inventory rules, then WIP
validates the length of the lot number against the length you
define in this field.
Navigation: WIP responsibility, setup--> parameters.
_____________________________________________________________
2. Set the item lot control attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Lot Control"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
3. Set the item starting lot number attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Starting Lot
Number"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
4. Set the item Starting Lot Prefix attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Starting Lot
Prefix"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
5. Set the item lot expiration attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Lot Expiration"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
6. Set the item shelf life days attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Shelf Life Days"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
7. Set up item lot control:
Navigate to Items -> Master Items -> Select the Inventory alternate
region.
1. Establish lot control for an item.
You can establish lot control for an item when define it.
No control: Do not establish lot control for the item.
Full control: Track inventory balances by lot number.
If you choose lot control you must assign lot numbers when you
receive the item into inventory. Thereafter, when you transact
this item, you must provide a lot number you specified when you
received the item.
You can update lot control options for an item if it has zero on-
hand quantity.
You can establish lot number control only for an item that has no
quantity on hand. IF Lot Control is controlled at Master Item
level, the check for on-hand quantity is against the sum of on-
hand quantities in all child organizations.
__________________________________________________________________
Note: For Oracle Order Entry, if profile option OE: Reservations
is Yes, you can specify a lot a t order entry or scheduling,
or let Pick Release use Inventory picking rules to determine
the lot when the order is picked. If the profile option is
No, you must enter a lot at ship confirmation.
Attention: Oracle Work in Process recognizes either lot control or
serial control for an item-but not both. You cannot
transact in item in Work in Process if it has both lot
and serial control defined.
--------------------------------------------------------------------
2. Establish starting lot prefix
Enter a starting prefix for all lot numbers you define for this
item. When Lot Number Generation is At item level in the
organization parameters, this prefix is used when you define a lot
number.
3. Establish starting lot number
Enter a starting numeric suffix for this item only. When Lot
number generation is At item level in the organization parameters,
this starting numeric suffix is used when you create a lot number.
Thereafter, this number is incremented for each succeeding lot.
4. Establish lot expiration (shelf life) control
Shelf life is the amount of time an item may be held in inventory
before it expires. When defining items under lot control, you can
choose your lot expiration.
No control: Shelf life control not established for this item.
Shelf life days: Specify a number of days for all lots of an
item, beginning on the day you create the lot by
receiving the item. You receive a warning
message that the lot expires after the specified
number of days.
User-defined: Specify an expiration date as you receive each lot.
You receive a warning but are not prevented from
using the lot after expiration.
5. Establish shelf life days
Enter the number of days each lot is active. At receipt, the
expiration date is determined by adding the shelf life days to the
system date (includes the day you define the lot). This is used
only when you choose Shelf life days for Lot Expiration Control.
Navigate to Setup -> Organizations -> Parameters -> Select the Revision,
Lot, Serial alternative region.
1. Select an option for lot number uniqueness.
Across items: Enforce unique lot numbers for items across all
organizations.
None: Unique lot numbers are not required.
2. Select an option for lot number generation.
User-defined: Enter user-defined lot numbers when you receive
items.
At organization level: Define the starting prefix and lot number
information for items using the values
you enter in the Prefix, Zero Pad, Suffix
and Total Length fields. When you
receive items, this information is used
to automatically generate lot numbers for
your items.
At item level: Define the starting lot number prefix and the
starting lot number when you define the item.
This information is used to generate a lot number
for the item when it is received.
3. Indicate whether to add zeros to right-justify the numeric portion
of lot number (Zero Pad Suffix).
4. Optionally, select a alphanumeric lot number prefix to use for
system-generated lot numbers when generation is at the
organization level.
5. Optionally, define the maximum length for lot number.
________________________________________________________________
If you use Oracle Work in Process and you set the WIP parameter to
default the lot number based on inventory rules, then WIP
validates the length of the lot number against the length you
define in this field.
Navigation: WIP responsibility, setup--> parameters.
_____________________________________________________________
2. Set the item lot control attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Lot Control"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
3. Set the item starting lot number attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Starting Lot
Number"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
4. Set the item Starting Lot Prefix attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Starting Lot
Prefix"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
5. Set the item lot expiration attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Lot Expiration"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
6. Set the item shelf life days attribute control level:
Navigate to Setup -> Items -> Attributes Controls
Scan the information displayed on the Group Name and Attribute Name to
find the Group Name = "Inventory" and Attribute Name = "Shelf Life Days"
Select a control level for the attribute.
Master Level: Define and maintain this attribute at the Master
level. For the same item, the values of this
attribute are identical across all organizations.
Org Level: Define and maintain this attribute at the Organization
level. For the same item, each organization may
define a different value for this attribute
7. Set up item lot control:
Navigate to Items -> Master Items -> Select the Inventory alternate
region.
1. Establish lot control for an item.
You can establish lot control for an item when define it.
No control: Do not establish lot control for the item.
Full control: Track inventory balances by lot number.
If you choose lot control you must assign lot numbers when you
receive the item into inventory. Thereafter, when you transact
this item, you must provide a lot number you specified when you
received the item.
You can update lot control options for an item if it has zero on-
hand quantity.
You can establish lot number control only for an item that has no
quantity on hand. IF Lot Control is controlled at Master Item
level, the check for on-hand quantity is against the sum of on-
hand quantities in all child organizations.
__________________________________________________________________
Note: For Oracle Order Entry, if profile option OE: Reservations
is Yes, you can specify a lot a t order entry or scheduling,
or let Pick Release use Inventory picking rules to determine
the lot when the order is picked. If the profile option is
No, you must enter a lot at ship confirmation.
Attention: Oracle Work in Process recognizes either lot control or
serial control for an item-but not both. You cannot
transact in item in Work in Process if it has both lot
and serial control defined.
--------------------------------------------------------------------
2. Establish starting lot prefix
Enter a starting prefix for all lot numbers you define for this
item. When Lot Number Generation is At item level in the
organization parameters, this prefix is used when you define a lot
number.
3. Establish starting lot number
Enter a starting numeric suffix for this item only. When Lot
number generation is At item level in the organization parameters,
this starting numeric suffix is used when you create a lot number.
Thereafter, this number is incremented for each succeeding lot.
4. Establish lot expiration (shelf life) control
Shelf life is the amount of time an item may be held in inventory
before it expires. When defining items under lot control, you can
choose your lot expiration.
No control: Shelf life control not established for this item.
Shelf life days: Specify a number of days for all lots of an
item, beginning on the day you create the lot by
receiving the item. You receive a warning
message that the lot expires after the specified
number of days.
User-defined: Specify an expiration date as you receive each lot.
You receive a warning but are not prevented from
using the lot after expiration.
5. Establish shelf life days
Enter the number of days each lot is active. At receipt, the
expiration date is determined by adding the shelf life days to the
system date (includes the day you define the lot). This is used
only when you choose Shelf life days for Lot Expiration Control.
Oracle Applications Release 12 - Inventory - What's new?
Oracle Inventory - Discrete & Process Manufacturing environments meet !
1. Improved Genealogy !
This genealogy links the final assembly to the various Lot and/or serialized components manufactured or procured from suppliers, so that rejects/product defects can be traced back to the root cause.
Increased product composition visibility, the lot and serial genealogy inquiries have been consolidated. Users now have a combined view of lot and serial genealogy in one inquiry.
In addition, for Oracle Discrete manufacturing users, operators performing the WIP issue transactions can tie their component lot and/ or serial numbers with a parent assembly. User can see the direct genealogy construct between the parent assembly lot and child component lots rather than using the WIP job as the connection between the products.
To ensure the integrity of the genealogy, only the lots that were issued to the work order can be returned from the work order into inventory when performing a component return for a lot controlled item.
2. Oracle Inventory's Dual Unit of Measure Control enables users to transact inventory in two unrelated units of measure where the conversion between the measures vary from lot to lot or from one transaction to the next.
If an item is dual unit of measure control enabled,during transactions, users will be prompted to enter the transaction quantity in both units and will be able to query on-hand balances, availability and reservations in both units for full supply chain visibility to all required handling units of measure.
Dual unit of measure control is available in Oracle Inventory, Purchasing & Receiving and Order Management and Shipping.
3. Tracking Assets
Users can now mandate entry of the location field while defining transaction types in Oracle Inventory. When users perform miscellaneous transactions for these transaction types, they are required to specify a field location from/to where the asset is being received or deployed.
4. For customers using Oracle's Configure to Order functionality on internal orders, intercompany invoicing can now determine the invoice price for an internal order based on the model and the options chosen. This eliminates the need to pre-define the configuration on a price list
5. In the Organization Parameters form, users can only select those accounts those are associated with the legal entity to which the inventory organization is assigned.
6. Material Workbench now lets a user see material across organizations categorized into three "buckets" -
• Inbound Intransit
• Receiving
• On-hand
User can drill down into each of the individual "buckets".
Availability information is calculated according to the material location of the relevant material for Inbound Intransit, Receiving, and Onhand material.
Users can save their queries and allow others to reuse common inquiries.
In a single form, users can view Purchase Orders, Advanced Shipment Notices and Internal Orders
7. Users can perform project issue and receipt transactions for any project defined in the set of operating units to which the user has access.
8. Functionality previously only available to Oracle Warehouse Management users that enable users to assign a material status to the material in an inventory lot, serial, subinventory or locator and to use that status to restrict transactions is now available to all Oracle Inventory users. Those material statuses will dictate which transactions can be performed on the lot, the serial or the material that is stored in the subinventory or locator. In addition, Oracle's planning applications and Inventory's availability calculations can now take the material status into consideration when determining availability. Users can determine whether or not product of a particular status can be reservable, included in ATP calculations or netted in production planning.
9.Sublot control allows users to track the parent lot from which multiple lots were created. The parent lot may refer to the production batch that spawned the lot but, if the output of that batch varied in term of grade or other QC attributes, multiple sublots might be received into inventory. Users can query lots in by their parent lot and view the parent lot in the lot genealogy form. Users can also now grade control their lot controlled items. The product can be queried by grade and the grade can be changed as required. Users can also track retest dates, expiration and retest actions among other lot attributes. In addition, a new concurrent request in Oracle Inventory can initiate a workflow if a lot or serial approaches any key milestone dates such as expiration, retest or best-by date.
10.Oracle Inventory picking rules engine has been enhanced to incorporate certain restrictions on allocation logic in addition to the sort criteria for acceptable material. These restrictions are available for both sales order and work order allocation processes.
For example, a customer may require premium grade material while another, more price sensitive client, may have no such restrictions. Some customers may mandate a certain number of usable days left on product that is to be shipped to them.
11.In order to better facilitate manual allocation processes, the transact move order form can now present all allocation options to a user and allows the user to choose the allocations that he or she wishes to commit. This ensures that the allocations honor the customer restrictions but still allows the warehouse operator the flexibility to choose the material that is most accessible for picking.
12.New material aging workflow. This workflow can be leveraged to create work orders, send notifications to planners, update material status or request a movement of expired product to a quarantine or inspection area. This functionality is offered in a new concurrent request in Oracle Inventory which can search for any date attribute of a lot or serial (including flexfields) and will initiate the workflow for the lot or serial if the date attribute is within a user specified range around the current date. For example, the request could initiate the workflow for all lots that will expire in the next 5 days.
13.Oracle Inventory has introduced the concept of lot indivisibility. This item attribute will indicate to the system that, during reservations and allocation, the system must allocate the entire lot quantity in a given location or none at all. In order to meet this requirement, over and under allocation, within tolerances, will be supported automatically at pick release for indivisible lots. Users may still choose to transact part of a lot quantity during user initiated transactions but Oracle Inventory will not suggest these splits during allocation and any reservation created will have to specify the lot to be reserved and will have to reserve the full lot
quantity.
14. Oracle Inventory's lot split, merge and translate transactions can now be performed on items that are both lot and serial controlled.
15. Inventory Organization parameters form has been added with attributes such as include labor reporting, locator aliasing, EPC compliance support for RFID tagging, chargeable subcontracting and best fit quantity allocation.
16.Oracle Inventory now supports reservations to expected supplies such as purchase orders, internal requisitions, advanced shipment notices, manufacturing jobs, and process manufacturing's batches. Users can create these reservations through Inventory forms and public APIs.
Users can now reserve a specific serial number and Oracle Inventory will ensure that the reserved serial is allocated at pick release.
17.Users can set a value for the Order Management system parameter “UOM Class for Charge Periodicity” to identify the available unit of measures to represent periodicity.
In order to enable Customer Service Representatives (CSRs) in service industries (Telco, Utilities etc) to better identify and group various charges (recurring, one-time, usage based) on customer orders/quotes, users can now identity the nature of each charge item (recurring vs. non-recurring) and the periodicity (weekly, monthly, quarterly etc) while setting them up in the Item Master.
19. Navigation
Different applications can invoke "transact move order" screen by passing the Inventory organization and Sales order information,and the system will directly show the results of the search criteria by completely bypassing the 'find' screen and taking the user to the 'detail' screen.
19. Not sure if this is already a feature in 11i or comes with Release 12, can someone help me finding out more on this ---> If such serialized equipment is shipped to a customer on a sales order, Oracle Inventory will ensure that serials shipped to a customer can only be returned into Inventory via an RMA receipt.
1. Improved Genealogy !
This genealogy links the final assembly to the various Lot and/or serialized components manufactured or procured from suppliers, so that rejects/product defects can be traced back to the root cause.
Increased product composition visibility, the lot and serial genealogy inquiries have been consolidated. Users now have a combined view of lot and serial genealogy in one inquiry.
In addition, for Oracle Discrete manufacturing users, operators performing the WIP issue transactions can tie their component lot and/ or serial numbers with a parent assembly. User can see the direct genealogy construct between the parent assembly lot and child component lots rather than using the WIP job as the connection between the products.
To ensure the integrity of the genealogy, only the lots that were issued to the work order can be returned from the work order into inventory when performing a component return for a lot controlled item.
2. Oracle Inventory's Dual Unit of Measure Control enables users to transact inventory in two unrelated units of measure where the conversion between the measures vary from lot to lot or from one transaction to the next.
If an item is dual unit of measure control enabled,during transactions, users will be prompted to enter the transaction quantity in both units and will be able to query on-hand balances, availability and reservations in both units for full supply chain visibility to all required handling units of measure.
Dual unit of measure control is available in Oracle Inventory, Purchasing & Receiving and Order Management and Shipping.
3. Tracking Assets
Users can now mandate entry of the location field while defining transaction types in Oracle Inventory. When users perform miscellaneous transactions for these transaction types, they are required to specify a field location from/to where the asset is being received or deployed.
4. For customers using Oracle's Configure to Order functionality on internal orders, intercompany invoicing can now determine the invoice price for an internal order based on the model and the options chosen. This eliminates the need to pre-define the configuration on a price list
5. In the Organization Parameters form, users can only select those accounts those are associated with the legal entity to which the inventory organization is assigned.
6. Material Workbench now lets a user see material across organizations categorized into three "buckets" -
• Inbound Intransit
• Receiving
• On-hand
User can drill down into each of the individual "buckets".
Availability information is calculated according to the material location of the relevant material for Inbound Intransit, Receiving, and Onhand material.
Users can save their queries and allow others to reuse common inquiries.
In a single form, users can view Purchase Orders, Advanced Shipment Notices and Internal Orders
7. Users can perform project issue and receipt transactions for any project defined in the set of operating units to which the user has access.
8. Functionality previously only available to Oracle Warehouse Management users that enable users to assign a material status to the material in an inventory lot, serial, subinventory or locator and to use that status to restrict transactions is now available to all Oracle Inventory users. Those material statuses will dictate which transactions can be performed on the lot, the serial or the material that is stored in the subinventory or locator. In addition, Oracle's planning applications and Inventory's availability calculations can now take the material status into consideration when determining availability. Users can determine whether or not product of a particular status can be reservable, included in ATP calculations or netted in production planning.
9.Sublot control allows users to track the parent lot from which multiple lots were created. The parent lot may refer to the production batch that spawned the lot but, if the output of that batch varied in term of grade or other QC attributes, multiple sublots might be received into inventory. Users can query lots in by their parent lot and view the parent lot in the lot genealogy form. Users can also now grade control their lot controlled items. The product can be queried by grade and the grade can be changed as required. Users can also track retest dates, expiration and retest actions among other lot attributes. In addition, a new concurrent request in Oracle Inventory can initiate a workflow if a lot or serial approaches any key milestone dates such as expiration, retest or best-by date.
10.Oracle Inventory picking rules engine has been enhanced to incorporate certain restrictions on allocation logic in addition to the sort criteria for acceptable material. These restrictions are available for both sales order and work order allocation processes.
For example, a customer may require premium grade material while another, more price sensitive client, may have no such restrictions. Some customers may mandate a certain number of usable days left on product that is to be shipped to them.
11.In order to better facilitate manual allocation processes, the transact move order form can now present all allocation options to a user and allows the user to choose the allocations that he or she wishes to commit. This ensures that the allocations honor the customer restrictions but still allows the warehouse operator the flexibility to choose the material that is most accessible for picking.
12.New material aging workflow. This workflow can be leveraged to create work orders, send notifications to planners, update material status or request a movement of expired product to a quarantine or inspection area. This functionality is offered in a new concurrent request in Oracle Inventory which can search for any date attribute of a lot or serial (including flexfields) and will initiate the workflow for the lot or serial if the date attribute is within a user specified range around the current date. For example, the request could initiate the workflow for all lots that will expire in the next 5 days.
13.Oracle Inventory has introduced the concept of lot indivisibility. This item attribute will indicate to the system that, during reservations and allocation, the system must allocate the entire lot quantity in a given location or none at all. In order to meet this requirement, over and under allocation, within tolerances, will be supported automatically at pick release for indivisible lots. Users may still choose to transact part of a lot quantity during user initiated transactions but Oracle Inventory will not suggest these splits during allocation and any reservation created will have to specify the lot to be reserved and will have to reserve the full lot
quantity.
14. Oracle Inventory's lot split, merge and translate transactions can now be performed on items that are both lot and serial controlled.
15. Inventory Organization parameters form has been added with attributes such as include labor reporting, locator aliasing, EPC compliance support for RFID tagging, chargeable subcontracting and best fit quantity allocation.
16.Oracle Inventory now supports reservations to expected supplies such as purchase orders, internal requisitions, advanced shipment notices, manufacturing jobs, and process manufacturing's batches. Users can create these reservations through Inventory forms and public APIs.
Users can now reserve a specific serial number and Oracle Inventory will ensure that the reserved serial is allocated at pick release.
17.Users can set a value for the Order Management system parameter “UOM Class for Charge Periodicity” to identify the available unit of measures to represent periodicity.
In order to enable Customer Service Representatives (CSRs) in service industries (Telco, Utilities etc) to better identify and group various charges (recurring, one-time, usage based) on customer orders/quotes, users can now identity the nature of each charge item (recurring vs. non-recurring) and the periodicity (weekly, monthly, quarterly etc) while setting them up in the Item Master.
19. Navigation
Different applications can invoke "transact move order" screen by passing the Inventory organization and Sales order information,and the system will directly show the results of the search criteria by completely bypassing the 'find' screen and taking the user to the 'detail' screen.
19. Not sure if this is already a feature in 11i or comes with Release 12, can someone help me finding out more on this ---> If such serialized equipment is shipped to a customer on a sales order, Oracle Inventory will ensure that serials shipped to a customer can only be returned into Inventory via an RMA receipt.
Setup - Approval Hierarchies in Oracle Purchasing
Purchasing setup of approval hierarchies
There are two most commonly known methods to route documents for approval.
1. Approval Hierarchies (uses position hierarchies)
2. Employee/Supervisor Relationships (use employee/supervisor relationship)
* Third method of Advanced Approval Support for Requisitions (Release 12 use integration with Oracle Approvals Management) . However in this article, focus here is set on above two most commonly used methods.
1. Position Hierarchies
Position Hierarchies are hierarchies that have a position relationship. Purchasing utilizes positions as a roadmap to determine how and where documents will be routed once the approval process has been initiated. It is first necessary to have created all positions that are going to be used in the system. Once all positions have been created, it is necessary to build the position hierarchy.Each position has approval limits, so when a purchase order exceeds the limits of the position, the purchase order is forwarded onto the next position in the Hierarchy.The hierarchy for positions is defined on the Position Hierarchy form. When this is complete or is changed, the Fill Employee Hierarchy concurrent program must be run for the new hierarchy to come into effect.You must set up Positions if you plan to use either security or approval hierarchies. If you are using Shared HR navigate, Purchasing: Setup: Personnel: Position Hierarchy. Otherwise, if you are using a full install of HR then navigate, Human Resources: Work Structures: Position: Hierarchy.
2. Employee/Supervisor Relationships
This type of hierarchy does not use the Approval Hierarchy form, but is defined by the employee/supervisor relationship. The supervisor of an employee is defined on the Assignment region of the Employee form. If the purchase order entered by the employee exceeds the approval limits, the purchase order is forwarded onto the employees' supervisor, as defined on the Employee form.
To implement this form of approval routing, you need only to define jobs. The job will then serve as the tie to the Approval group, and based on the approval limits from the Approval Group, the Document will either be Approved or Forwarded to the Employees’ Supervisor. If no Supervisor is able to be located and the jobassigned to the employee does not have Approval Authority, then the Approving employee must enter a Forward-to person, or the Document will be returned to an Incomplete status and a notification will be sent to the Approving employee, stating - 'No Approver Found - Please Select a Forward-To Employee'.
Selecting an approval routing method
There are two forms that determine the route that an approval will take:
1. Financial Options (Purchasing: Setup: Organizations: Financial Options)
2. Document Types (Purchasing: Setup: Document Types)
1. Financial Options
The Human Resources zone on the Financial Options form has an option called Use Approval Hierarchies. This option determines which type of hierarchy is used for the approval process. When checked, the Position Hierarchy is used and when unchecked the Employee/Supervisor relationship (i.e. Jobs) is used.
2. Document Types
There are three attributes on this form that determine the approval path of the document:
a) Forward Method
b) Default Hierarchy
c) Transaction Type (for Requisitions only)
* Each of these 3 options are described in some details below
a) Forward Method
This field has two options that apply regardless as to whether you use a Position Hierarchy or an Employee/Supervisor relationship.
- Direct: the document will pass to the next position or supervisor in the hierarchy who has enough authority to approve the document.
- Hierarchy: the document will pass to the next person in the hierarchy regardless to whether that position or supervisor has enough approval authority to approve.
b) Default Hierarchy
The Default Hierarchy option will only appear on the Document Type form if the option Use Approval Hierarchies is checked on the Human Resources zone on the Financial Options screen. The Default Hierarchy field has a LOV. This list is derived from the hierarchies created using the Position Hierarchy form.
The Default Hierarchy is the one that will be used by the approval process unless the person who submits the document for approval changes it in the Approval Modal form. But, the hierarchy can only be changed on the Approval Modal form if the attribute Can Change Approval Hierarchy is checked on the Document Type form - and this attribute is only enabled if the Use Approval Hierarchies is checked.
When choosing the action of 'Approve' for a document, if a Forward-To person is not defined and the person taking action does not have sufficient approval authority, the default hierarchy will first be searched for the employee attempting the approval. This default hierarchy is defined on the Document Types form:
Purchasing: Setup: Purchasing: Document Types
Thus, it is imperative that the low-end users (those with little approval authority) be present in this default hierarchy so the next Forward-To approver can be found. Alternatively, the checkbox Can Change Approval Hierarchies should be selected on the Document Types form. With this checkbox enabled, the user has the option to specify an alternate approval hierarchy, provided that the user belongs to one or more additional hierarchies (i.e. the Approval Hierarchy list of values in the Document Approval window will only contain the hierarchies that this user belongs to).
If the low-end user is not part of the default hierarchy specified in the Document Types form and chooses to approve the document, the end result will be a notification to the user stating 'No Approver Found'.
A similar scenario of 'No Approver Found' will result if the 'Owner Can Approve' checkbox (on the Document Types form) is disabled and the person attempting to approve the document is not in the Default Hierarchy. When the Approve button is clicked, this setting is validated and enforced; it is at this time that the requisition and purchase order approval workflows will look to the default approval hierarchy, searching for the current approver's position in the hierarchy in order for the next approver in line to be located.
c) Transaction Type
For requisitions only, select the Approval Transaction Type. If you have implemented Oracle Approvals Management, this selection associates the transaction type with the requisition document type. Leave the field blank to use the standard Oracle Purchasing approval logic
There are two most commonly known methods to route documents for approval.
1. Approval Hierarchies (uses position hierarchies)
2. Employee/Supervisor Relationships (use employee/supervisor relationship)
* Third method of Advanced Approval Support for Requisitions (Release 12 use integration with Oracle Approvals Management) . However in this article, focus here is set on above two most commonly used methods.
1. Position Hierarchies
Position Hierarchies are hierarchies that have a position relationship. Purchasing utilizes positions as a roadmap to determine how and where documents will be routed once the approval process has been initiated. It is first necessary to have created all positions that are going to be used in the system. Once all positions have been created, it is necessary to build the position hierarchy.Each position has approval limits, so when a purchase order exceeds the limits of the position, the purchase order is forwarded onto the next position in the Hierarchy.The hierarchy for positions is defined on the Position Hierarchy form. When this is complete or is changed, the Fill Employee Hierarchy concurrent program must be run for the new hierarchy to come into effect.You must set up Positions if you plan to use either security or approval hierarchies. If you are using Shared HR navigate, Purchasing: Setup: Personnel: Position Hierarchy. Otherwise, if you are using a full install of HR then navigate, Human Resources: Work Structures: Position: Hierarchy.
2. Employee/Supervisor Relationships
This type of hierarchy does not use the Approval Hierarchy form, but is defined by the employee/supervisor relationship. The supervisor of an employee is defined on the Assignment region of the Employee form. If the purchase order entered by the employee exceeds the approval limits, the purchase order is forwarded onto the employees' supervisor, as defined on the Employee form.
To implement this form of approval routing, you need only to define jobs. The job will then serve as the tie to the Approval group, and based on the approval limits from the Approval Group, the Document will either be Approved or Forwarded to the Employees’ Supervisor. If no Supervisor is able to be located and the jobassigned to the employee does not have Approval Authority, then the Approving employee must enter a Forward-to person, or the Document will be returned to an Incomplete status and a notification will be sent to the Approving employee, stating - 'No Approver Found - Please Select a Forward-To Employee'.
Selecting an approval routing method
There are two forms that determine the route that an approval will take:
1. Financial Options (Purchasing: Setup: Organizations: Financial Options)
2. Document Types (Purchasing: Setup: Document Types)
1. Financial Options
The Human Resources zone on the Financial Options form has an option called Use Approval Hierarchies. This option determines which type of hierarchy is used for the approval process. When checked, the Position Hierarchy is used and when unchecked the Employee/Supervisor relationship (i.e. Jobs) is used.
2. Document Types
There are three attributes on this form that determine the approval path of the document:
a) Forward Method
b) Default Hierarchy
c) Transaction Type (for Requisitions only)
* Each of these 3 options are described in some details below
a) Forward Method
This field has two options that apply regardless as to whether you use a Position Hierarchy or an Employee/Supervisor relationship.
- Direct: the document will pass to the next position or supervisor in the hierarchy who has enough authority to approve the document.
- Hierarchy: the document will pass to the next person in the hierarchy regardless to whether that position or supervisor has enough approval authority to approve.
b) Default Hierarchy
The Default Hierarchy option will only appear on the Document Type form if the option Use Approval Hierarchies is checked on the Human Resources zone on the Financial Options screen. The Default Hierarchy field has a LOV. This list is derived from the hierarchies created using the Position Hierarchy form.
The Default Hierarchy is the one that will be used by the approval process unless the person who submits the document for approval changes it in the Approval Modal form. But, the hierarchy can only be changed on the Approval Modal form if the attribute Can Change Approval Hierarchy is checked on the Document Type form - and this attribute is only enabled if the Use Approval Hierarchies is checked.
When choosing the action of 'Approve' for a document, if a Forward-To person is not defined and the person taking action does not have sufficient approval authority, the default hierarchy will first be searched for the employee attempting the approval. This default hierarchy is defined on the Document Types form:
Purchasing: Setup: Purchasing: Document Types
Thus, it is imperative that the low-end users (those with little approval authority) be present in this default hierarchy so the next Forward-To approver can be found. Alternatively, the checkbox Can Change Approval Hierarchies should be selected on the Document Types form. With this checkbox enabled, the user has the option to specify an alternate approval hierarchy, provided that the user belongs to one or more additional hierarchies (i.e. the Approval Hierarchy list of values in the Document Approval window will only contain the hierarchies that this user belongs to).
If the low-end user is not part of the default hierarchy specified in the Document Types form and chooses to approve the document, the end result will be a notification to the user stating 'No Approver Found'.
A similar scenario of 'No Approver Found' will result if the 'Owner Can Approve' checkbox (on the Document Types form) is disabled and the person attempting to approve the document is not in the Default Hierarchy. When the Approve button is clicked, this setting is validated and enforced; it is at this time that the requisition and purchase order approval workflows will look to the default approval hierarchy, searching for the current approver's position in the hierarchy in order for the next approver in line to be located.
c) Transaction Type
For requisitions only, select the Approval Transaction Type. If you have implemented Oracle Approvals Management, this selection associates the transaction type with the requisition document type. Leave the field blank to use the standard Oracle Purchasing approval logic
Subscribe to:
Posts (Atom)
