CONFIGURE TO ORDER (CTO):
It is a method of manufacturing which allows you, or your customer, to choose a base product at the very moment of ordering and then configure all the variable parameters (features) associated with that product from defined/available options. Based on these selections, configurable items on each quote or order typically generates the unique product configuration and manufacturing routing and/or bill of materials based on various features and options. Vendor/order receiving company subsequently builds that configuration dynamically upon receipt of the order. The ability of the vendor to make and deliver products customized to specific customer needs offers a powerful competitive edge over competitors.

CTO is an environment in which the product or service is assembled or kitted on receipt of the sales order. Oracle EBS supports the Configure to Order environment with a range of features in order entry, demand forecasting, master scheduling, production, shipping, and financial accounting. Configure to Order includes Pick-to-Order (PTO) and Assemble-to-Order (ATO) items, models, and hybrids. It supports building configurations using other configurations as sub-assemblies (multi-level configure-to-order), internal and external sourcing of ATO models at any level in the BOM and supports multi-level PTO/ATO hybrids.
PICK TO ORDER (PTO):
It is a configure-to-order environment where the options and included items in a PTO model (finished good) appear on pick slips after you receive the sales order from customer. Pickers gather the options (based on selection rules), the predefined shippable products parts/components or service from their predefined locations using pick slip and then ship the order. It is assumed that options and components quantity are readily available. It is an alternative to manufacturing the parent item on a work order and then shipping it. There is no additional value added after getting the customer order

Example: Computer System (CPU, Monitor and Printer) A pick to order model can have PTO option class, PTO items, ATO model, ATO Option class and ATO option items. There can not be any PTO model, PTO option class or PTO item under an ATO model. You want to manufacture a promotional laptop computer, you need laptop computer, dikettes, accessories and battery pack. Here, you define PL computer as PTO model, laptop computer as ATO model, battery pack, diskette and accessories as purchase items

ASSEMBLE-TO-ORDER (ATO):

ATO simplifies the process of manufacturing finished goods. These goods are standard products and are often configured by customers from Bills of material, where you can define available options for unique product configurations. Based on forecasting, subassemblies are manufactured prior to receiving the customer order and when the order is received, the stocked subassemblies and components are assembled to make the finished products. It is an environment where you open a final assembly order to assemble items that customers orders. It is manufacturing method/strategy which allows a product to be made or service to be available to meet the needs of a specific customer order (i.e. If i am a customer i can build my own configuration from the available options). While producing finished goods on a large scale, this requires sophisticated planning processes which master schedules ATO models and options and then create work orders to build the unique configuration in WIP module while maintaining control of inventory, planning, cost accounting and Bills of Material. Planning process also anticipates changing demand for external or internal components or accessories and at the same time focuses on product customizations for individual customers

WIP, Order Management and Shipping modules support building and shipping of ATO configurations. A discrete job is created from a configuration. An assemble to order item/assembly then can be linked to a sales order. Assemble-to-order is also an item attribute in Inventory module that you can apply to standard, model, and option class items. In Bills of Material module, a model bill can be either assemble-to-order or pick-to-order and an option class bill can be either assemble-to-order or pick-to-order

Example: Automobiles, computer manufacturing…

MAKE TO STOCK (MTS):

In MTS, stock is created by companies for items without receiving an order from customer. Examples are manufacturing of refrigerators, washing nachines and Television sets. They are manufactured in a shop floor based on master schedule and stocked in finished goods subinventory until they are shipped to a cutomer

Example: You can Purchase certian goods from available vendors and manufacture some of the goods on your shop floor. and finally build a product and store and ship to your customer.

MAKE-TO-ORDER (MTO):
MTO are manufactured after receiving customer order, which means customer is willing to accept longer delivery period. The examples are commercial dish washers and refrigerators for hotels. These items are produced in a shop floor or in job shop depending up on the range of product families produced by the factory. In order to reduce lead time the factory often uses ready components to manufacture a product.

ENGINEER-TO-ORDER (ETO):

ETO item is built on the customer product specifications such as large commercial aircrafts. Such product can not be produces according to existing specifications of the company because some engineering skill is required to incorporate customer specifications in to the design of the final product. Companies using this manufacturing strategy, always quote longer lead time .The engineering and manufacturing costs involved are also high and are tracked for each order separately.

Normally while converting legacy systems to oracle, or implementing a new brand oracle ERP to a company. There are lot of steps and set ups involved for each and every module.

Let us consider for an example we are configuring the PURCHASING system, there are some specific setups which need to be be in place to have the PURCHASING module to work as expected.

Attached is the document which let you know the set up check list for the PURCHASING.

When a company is planning to adopt R12 from previous versions, the first question arises is whether to Upgrade or Re-implement?

First let us see what is the difference between an upgrade and re-implement.

An R12 upgrade involves running the scripts on a database to transform it into R12 structure. During the upgrade all the data will be moved to the respective  tables in R12.

A re-implementation involves creating a completely new oracle applications installation, doing all the set-ups from scratch and moving the data using data conversions to the new R12 database.

Let us see the advantages and disadvantages of an upgrade and re-implement

Upgrade:

The major advantages of an upgrade process are:

1. The upgrade process has become easy as the technology, tools and the upgrade scripts are significantly improved
2. There will be no effort of data conversions and testing, as the data will be moved during the upgrade process
3. Not many customizations are needed
4. No changes in the functional setups
5. Upgrade is often cheaper as it involves significantly less work for setting up the applications

But an upgrade process requires very significant effort technically and is more challenging. In comparison with re-implementation process an upgrade is risky in technical perspective.

Re-implement:

The main advantage with Re-implementation process is that the technical risk is low when compared with an upgrade.

Disadvantages:

1. Re-implementation process is very extensive as the data conversions and testing is involved.
2. Lot of effort is needed for application configuration.

Organizations generally go for following considerations before going for the re-implementation.

1. There are major changes in the Organization structure or business processes, and the existing application configuration doesn’t fit for the business
2. There are lot of customizations that can be avoided with the new features and functionality
3. The original implementation has disturbed and unusable.
4. There is lot of bad data exists.

Period-End process is performed at the end of each period(depends on the organization). It is very important in any organization because if the period is not closed, the accounting for that period can not be closed, which will affect the financial results reporting of the respective period.
One can not close any module without following the order.

The suggested module wise sequence to be followed for Period-End process is as follows.

1. Projects
2. Payables
3. Purchasing
4. Assets 
5. Receivables
6. Inventory
7. General Ledger

In Oracle Quality module, the Quality Element ‘Revision’ on Enter Quality Results window has no list of values after R12 upgrade, where it was available in 11i. The users who want to capture the ‘Revision’ for an item on quality plans have no option to select the list of values for Revision. 
According to Oracle, this is expected functionality in R12. The Item revision collection element would be enabled and editable only for a Revision controlled Item. 
The behavior in 11.5.10 was a bug because of which even though the revision field was grayed out, the user could still enter Revision values by invoking the LOV. This was fixed in R12.
The following are the three possible options available to resolve the issue:

Srl# Option Remarks
1 Activate “Revision Control Code” for the items in question:
All items for which Revision needs to be captured in the Quality Collection Plan’s results, using an LOV, we need to active the Revision Control code for the items in inventory.
The drawback of this option is that all material transactions would mandate the entry of Revision of the item, which makes it very cumbersome for the Inventory and other modules’ users.
Hence, may not be a viable option
2 Go with the new functionality suggested by Oracle This also may not be a good option if users need to capture the Revision of items on QC plans
3 Creation of a new Quality Collection Element that has the capability of accepting Revision of items;
In this option, the “Revision Control” code for items need not be activated.
This workaround would enable the users to capture Revision of items during the entry of Quality Results.
This option is explained in detail in the subsequent section.
  

Solution for Option 3: Create new collection Element

  1. Create a new collection element with SQL Validation statement to populate the LOV. The following screen shot show the details of the new custom collection element to be created
     Navigation:  Quality Setup Collection Elements

The “select” statement to fetch the item’s revisions within the LOV is as under: 
  
2.   Identify all the QA Plans that use the standard / seeded QA element “Revision” for all the inventory organizations 
3.   Add the new custom QA element to all the QA Plans (stored in the table QA_PLAN_CHARS) identified in step 2. This could be programmatically done using an open API

4.  Using standard APIs, copy the existing data present in the “Revision” column of QA_RESULTS table into the column of newly added “custom revision” of the same table. Once the change is activated, the data captured under the new “custom revision” column would be stored in one of the custom (user-defined) columns titled CHARACTER1 through CHARACTER100. 

 
5.   Finally, once the copying of the Revision data is completed into the QA_RESULTS table (via Oracle APIs), nullify the data in “Revision” column
 
6.   Modification of Reports: All reports (Oracle Reports / SQL / Discoverer based) that were referring to “Revision” column should now be referring to the custom / user-defined columns defined for the new “custom revision” QA collection element.