, , , , ,

“Error: The action can not be performed because the selected records are not eligible.”.

“Error: The action can not be performed because the selected records are not eligible.”.

Solution

There are several ways to resolve this, depending on how you want the order to progress:
A. If you want to ship the delivery lines , do the following:
1. Query the Order in Shipping Transaction form
2. Navigate to Delivery tab. From the Actions button, choose Reopen Delivery>Go. Re-query order to confirm Delivery status is now “Open”.
3. From the Actions button again, choose Unassign Trip>Go
4. Re-query order to confirm the Trip has been removed, then from the Actions button again, choose Confirm Order>Go
5. Enter required information (such as Ship Method, quantity, Inventory Control)
6. Confirm the Order as usual.

B. If you want to cancel the order or order line, the delivery must be closed to do this, so do the following:
1. Query the Order in Shipping Transaction form
2. Navigate to Delivery tab. From the Actions button, choose Reopen Delivery>Go. Re-query order to confirm Delivery status is now “Open”.
3. From the Actions button again, choose Unassign Trip>Go
4. Once the Trip is removed, navigate to Delivery Line tab and remove the Shipped Quantity.
5. Once the Shipped Quantity field is null, go back to Delivery tab>then Actions button, choose Confirm Order>Go
6. Choose the Backorder All.
7. Once the delivery is closed and delivery lines are in backordered status, then navigate to Sales Order and cancel as needed.

C. To close a stop manually please follow steps below: To implement the solution, please execute the following steps:: You will need to manually close the stops

1. On the test instance, please click on the Path by Stop tab and manually close all of
the sequences:
Query order on Shipping Transaction form > Path by Stop tab > Actions > Update
Stop Status >Close
Also be sure to check the ‘Defer Interface’ checkbox on the form.

2. Then submit the Interface Trip Stop – SRS program

3. The line should now progress to ‘Interfaced’.

/by
, , , ,

Oracle Purchasing Document Style and PO Output Communication

Defining Document Styles
Use the Document Styles window to create and update purchase order styles.
Purchase order document styles allow organizations to control the look and feel of the application to match the usage of the purchasing document.
Through reusable document styles, organizations can turn on or off various Oracle Purchasing features, thereby simplifying the user interface.
In addition, document styles provide the ability to define purchasing document names that align more closely with the naming conventions of your organization’s business.
When a purchasing document is created using a document style, disabled features are hidden.
For example, you can create a document style for a specific commodity, such as temporary labor.
This document style optimizes field labels and presentation for that commodity, thereby simplifying purchase order entry.
Prerequisites
Document styles only apply to authoring documents in the Buyer Work Center.
Document styles are not organization specific.
To define document styles:
1. Navigate to the Document Styles window.
2. If you are defining a new document style click Create. To enter changes to an existing style use the Search region to enter the Name, Description, or the Status. Once you have completed one or all of these fields click Go. Enter your changes by clicking the Update icon for your document style.

Note: Once a style has been saved, you can only update the style to be less restrictive.

3. Enter the Name and Description of the document style. The style name must be unique.
4. Select the Status as Active for a new style or Inactive for a style you no longer want used.
5. You must enter a unique Display Name for the Standard Purchase Order. This is the name that appears in the Buyer Work Center.
6. If you are defining a style that applies to contract purchase agreements or blanket purchase agreements, check their boxes and enter a unique Display Name.
7. If Services Procurement is implemented, check the Purchase Bases that apply to this document style. See: Defining Purchase Basis, .
8. Select whether specific or all Line Types are enabled for this document style. See: Line Types in Purchasing Documents, .
9. If you are defining a style that includes blanket purchase agreements, enable price breaks using the Price Breaks checkbox.
10. If Services Procurement is implemented and you have enabled a Temp Labor basis, use the checkbox to enable Price Differentials.
11. If Services Procurement is implemented, enable the Complex Payments attributes that apply:
• Check Advances if advance payments are to be allowed.
• Check Retainage if withholding of a portion of the payment until all work under a contract is accepted is to be allowed.
• Check Progress Payments to enable partial payments during performance of the contract. If Progress Payments is enabled, at least one pay item must be selected.
• Milestone – Enable for payments based on progress events. Enabled by default for Goods line type.
• Rate – Enable when payment amount is pro-rated based on the percentage of work completed.
• Lump Sum – Enable when payment amount is a fixed amount based on the percentage of work completed.
• Enable Treat Progress Payments as Contract Financing if it applies to this style’s progress payments.

12. Click Apply.
Purchase Order Communication Setup Steps
This section discusses the setup steps which define your supplier’s preferred communication method. Oracle Purchasing supports the following methods of communicating purchase orders:

• Print
• Facsimile (fax)
• Electronic mail (e-mail)
• Extensible Markup Language (XML)
• Electronic Data Interchange (EDI)

Important: It is important to note that enabling PDF output (described below) activates the Communicate selection in the Tools menu of the Purchase Order Summary window.
/by
, , , ,

Setup – Approval Hierarchies in Oracle Purchasing Position & Supervisor

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 job assigned 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, selects 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

/by
, , , , , , ,

Order to Cash – Technical Flow in R12

This article lists the Order to Cash Flow in R12, with technical flow of data as taught in our FocusThread trainings.

1. Order Entry

This is first stage, When the order is entered in the system, it creates a record in order headers and Order Lines table.

Enter header details: Once you enter details on the order header and save it or move it to lines, record goes to one table oe_order_headers_all flow_status_code = ENTERED, booked_flag = N), Primary key=HEADER_ID

No record exist in any other table for this order till now.

Enter Line details for this order: Enter different item numbers, quantity and other details in line tab. When the record gets saved, it goes to one table. Order header details will be linked with line details by order HEADER_ID. oe_order_lines_all (flow_status_code = ENTERED, booked_flag = N, open_flag = Y) Primary key= LINE_ID

2.Order Booking
This is next stage, when Order is booked then the Flow status changed from Entered to Booked. At this stage, these below table get affected.

oe_order_headers_alL (flow_status_code as BOOKED, booked_flag updated to Y)
oe_order_lines_all (flow_status_code as AWAITING_SHIPPING, booked_flag updated Y)
wsh_delivery_details (DELIVERY_DETAIL_ID is assigned here, released_status ‘R’ ready to release, LINE_ID comes as SOURCE_LINE_ID)
wsh_delivery_assignments (DELIVERY_ASSIGNMENT_ID is assigned for DELIVERY_DETAIL_ID present in wsh_delivery_details, DELIVERY_ID remains blank till this stage)

*In shipping transaction form order status remains “Ready to Release”.

At the same time, Demand interface program runs in background And insert into inventory tables mtl_demand, here LINE_ID come as a reference in DEMAND_SOURCE_LINE

3. Reservation
This step is required for doing reservations SCHEDULE ORDER PROGRAM runs in the background and quantities are reserved. Once this program get successfully get completed, the mtl_demand and mtl_reservations table get updated. LINE_ID gets updated in DEMAND_SOURCE_LINE_ID in both the tables.

4. Pick Release
Pick Release is the process of putting reservation on on-hand quantity available in the inventory and pick them for particular sales order.

Pick release can be done from ‘Release Sales Order’ form or ‘Pick release SRS’ program can be scheduled in background. In both of these cases all lines of the order gets pick released depending on the Picking rule used. If specific line/s needs to be pick release it can be done from ‘Shipping Transaction form. For this case Pick Release is done from ‘Release Sales Order’ form with Pick Confirm=NO.
Once pick release is done these are the tables get affected:

If step 3 is not done then MTL_RESERVATIONS gets updated now.
wsh_new_deliveries (one record gets inserted with SOURCE_HEADER_ID= order header ID, status_code=OP =>open)
wsh_delivery_assignments (DELIVERY_ID gets assigned which comes from wsh_new_deliveries)
wsh_delivery_details (released_status ‘S’ ‘submitted for release’)
MTL_TXN_REQUEST_HEADERS
MTL_TXN_REQUEST_LINES (LINE_ID goes as TXN_SOURCE_LINE_ID)
(move order tables. Here request is generated to move item from Source (RM or FG) sub-inventory to staging sub-inventory)
Mtl_material_transactions_temp (link to above tables through move_order_header_id/line_id, this table holds the record temporally)
MTL_SERIAL_NUMBERS_TEMP (if item is serial controlled at receipt then record goes in this table)
MTL_SERIAL_NUMBERS (enter value in GROUP_MARK_ID )

*In shipping transaction form order status remains “Released to Warehouse” and all the material still remains in source sub-inventory. We need to do Move Order Transaction for this order. Till this no material transaction has been posted to MTL_MATERIAL_TRANSACTIONS

5.Pick Confirm/ Move Order Transaction

Items are transferred from source sub-inventory to staging Sub-inventory. Here material transaction occurs.

Order line status becomes ‘Picked’ on Sales Order and ‘Staged/Pick Confirmed’ on Shipping Transaction Form.

MTL_MATERIAL_TRANSACTIONS_TEMP (Record gets deleted from here and gets posted to MTL_MATERIAL_TRANSACTIONS)
oe_order_lines_all (flow_status_code ‘PICKED’ )
MTL_MATERIAL_TRANSACTIONS (LINE_ID goes as TRX_SOURCE_LINE_ID)
mtl_transaction_accounts
wsh_delivery_details (released_status becomes ‘Y’ => ‘Released’ )
wsh_delivery_assignments
MTL_ONHAND_QUANTITIES
MTL_SERIAL_NUMBERS_TEMP (record gets inserted after putting details for the item which are serial controlled at ‘Sales order issue’)
MTL_SERIAL_NUMBERS (record gets inserted after putting details for the item which are serial controlled at ‘Sales order issue’)

* This step can be eliminated if we set Pick Confirm=YES at the time of Pick Release

6.Ship Confirm
Here ship confirm interface program runs in background. Data removed from wsh_new_deliveries.

The items on the delivery gets shipped to customer at this stage.

oe_order_lines_all (flow_status_code ‘shipped’)
wsh_delivery_details (released_status ‘C’ ‘Shipped’, SERIAL_NUMBER if quantity is ONE)
WSH_SERIAL_NUMBERS (records gets inserted with the DELIVERY_DETAIL_ID reference, only in case of shipped quantity is two or more)
mtl_transaction_interface
mtl_material_TRANSACTIONS (linked through Transaction source header id)
mtl_transaction_accounts
Data deleted from mtl_demand, MTL_reservations
Item deducted from MTL_ONHAND_QUANTITIES
MTL_SERIAL_NUMBERS_TEMP (records gets deleted from this table)
MTL_SERIAL_NUMBERS (Serial number stauts gets updated CURRENT_STATUS=4 , ‘Issued out of store’)

7.Enter Invoice
After shipping the order the order lines gets eligible to get transfered to RA_INTERFACE_LINES_ALL. Workflow background engine picks those records and post it to RA_INTERFACE_LINES_ALL. This is also called Receivables interface, that mean information moved to accounting area for invoicing details. Invoicing workflow activity transfers shipped item information to Oracle Receivables. At the same time records also goes in the table RA_INTERFACE_SALESCREDITS_ALL which hold details of sales credit for the particular order.

ra_interface_lines_all (interface table into which the data is transferred from order management) Then Autoinvoice program imports data from this table which get affected into this stage are receivables base table. At the same time records goes in

ra_customer_trx_all (cust_trx_id is primary key to link it to trx_lines table and trx_number is the invoice number)
ra_customer_trx_lines_all (line_attribute_1 and line_attribute_6 are linked to order number and line_id of the orders)

8.Complete Line
In this stage order line level table get updated with Flow status and open flag.
oe_order_lines_all (flow_status_code ‘shipped’, open_flag “N”)

9.Close Order
This is last step of Order Processing. In this stage only oe_order_lines_all table get updated. These are the table get affected in this step.

oe_order_lines_all (flow_status_code ‘closed’, open_flag “N”)

oe_order_HEADERS_all
In this stage order line level table get updated with Flow status and open flag.
oe_order_lines_all (flow_status_code ‘shipped’, open_flag “N”)

9.Close Order
This is last step of Order Processing. In this stage only oe_order_lines_all table get updated. These are the table get affected in this step.

oe_order_lines_all (flow_status_code ‘closed’, open_flag “N”)

oe_order_HEADERS_all

/by
, , , , , , , , , ,

Important Profiles During Implementation

 Important Profiles
1. Receiving transaction Processor concurrent not visible
TP: INV Transaction processing mode                 —         On-line

RCV: Processing Mode                                   —         On-Line  set to User & Resp.

2. Auto creates tools copy document next document form not pop-up.

PO: Display the Autocreated Document               —         No to Yes

PO: Display the Autocreated Quotation                —         No to Yes

PO: Allow Buyer Override in Autocreate Find        —         Yes or No

PO: Allow Category Override in Autocreate Find   —         Yes or No

PO: Allow Referencing CPA Under Amendment    —         Yes or No

PO: Allow Requisition Approval Forward Action     —         Yes or No

HR: Supervisor Hierarchy Usage —Use Assignment-based  Supervisor Hierarchies
                                                     Use Person-based Supervisor Hierarchies

HR: Display Position Hierarchy                           —         Yes or No

PO: Allow Requisition Approval Forward Action     —         Yes or No       

3. Requisition Import required Internal & Purchase Requisition

PO: Legal Requisition Type                                             —         Both

PO: Restrict Requisition line modify to quantity split         —         No

RCV: Allow routing override                                             —         Yes

OM: Display New Order after Copy                                  —         Yes

OM: Item Change Honors Frozen Price                            —         Yes

OM: Return Item Mismatch Action                                   —         Allow

4. Sales Order Number not automatic sequencing

Sequential Numbering                                                    —         Always Used

AR:Maximum lines per AutoInvoice                                  —        20

AR: AutoInvoice Gather Statistics                                    —         No

AR: Use Invoice Accounting For Credit Memos                 —         Yes

eBTax: Allow Override of Customer Exemptions                —         Yes

WIP:Job Name Updatable                                               —         Yes to No

Drop ship

OM: Population Of Buyer Code For Dropship Lines           —         Order Creator     (not mandatory)

Requisition import & Create release both should run at a time

PO: Release During ReqImport                                        —         Yes

Localization Profiles

Responsibility    —          Purchasing

JG: Application                          —         Purchasing

JG: Product                               —         Asia/Pacific Localizations

JG: Territory                              —         India

JG: Company Operating Unit       —         Operating Unit Name

Responsibility    —          Inventory

JG: Application                          —         Inventory

JG: Product                               —         Asia/Pacific Localizations

JG: Territory                              —         India

JG: Company Operating Unit       —         Operating Unit Name

Responsibility    —          Order Management

JG: Application                          —         Order Management

JG: Product                               —         Asia/Pacific Localizations

JG: Territory                              —         India

JG: Company Operating Unit       —         Operating Unit Name

Any changes from SO Header level it won’t affect to line level need to set the profile – R12 Futures:-

OM: Sales Order Form:
Cascade Header Changes to Line               —    Automatic

QP: Item Validation Organization               —    IMO

OM: Item Validation Organization             —    IMO setting up both should Same
                                     (then only Item should be listing in price list and modifier)

FND: Record History Enabled

FND: Diagnostics                     —    Yes (Customer web page view record history

Personalize Self-Service Defn–>

                                            No to Yes (Customer web page view record history)

HZ: Enable Duplicate Prevention at Party Creation —   Disabled

                                                                               Organization only

                                                                               Organization and Person

                                                                                Person only

HZ: Enable DQM Party Search                          —    Yes

ASO : Price List Override                                   —    Yes

PO: Allow Buyer Override in Autocreate Find       —     Yes

Transaction type added Customer PO mandatory —    Check box enabled
                                                                              Organization Type
In a Human Resources responsibility, the navigation is Other Definitions > Application Utilities Lookup.

    Works
    Non-Works
    Dump
    Branch
    Warehouse
    Goodown

1. Define FOB: AR à Purchasing lookup à Query FOB      —         Add the Value
                                                                             
2. Define Freight carrier: Order Management à Setup à Shipping à Freight Carrier, Cost Type à Freight Carrier      —         Add the value

3. Define Freight Terms: Order Management à Setup à Quick Codes à Order Management à Query Freight Terms   —   Add the Value

AR: AutoInvoice Gather Statistics               —         No to Yes

( AutoInvoice Master Program concurrent error)

AR:Maximum lines per AutoInvoice worker    —         10000 (null to 10000)

Credit Memo Profile

AR: Use Invoice Accounting For Credit Memos         —        Null to Yes

AR: Transaction Batch Source                                 —         Null to
                                                                                    
INV: Advanced Pricing for Inter-Org Transfers        —         Null to Yes

INV: Advanced Pricing for Inter-Org Transfers        —         No

Price list security:-
Price list and Modifier need to set to Operating Unit level or Global
QP: Security Control                                                —         OFF / ON

QP: Security Default Maintain Privilege                    —  Global
                                                                                      None
                                                                                      Operating Unit
                                                                                      Responsibility
                                                                                      UserQP: Security Default ViewOnly Privilege                   —   Global
                                                                                      None
                                                                                      Operating Unit
                                                                                      Responsibility
                                                                                      User

CST: Transfer Pricing Option                                     —         No

 Internal Sales Order Price Defaulted from Inventory Item cost à Sales Order à Line items à pricing tab à Calculate Price flag set Freeze price to Calculate price.

OM: E-Mail Required on new Customers  — No to Yes (When create new customer or add Contact)

Parallel Pick Future R12
Set the profile site level to
1. WSH: Number of Pick Release Child Processes’  –  50

Consigned Inventory functionality set this Profiles
INV: Allow Expense to Asset Transfer = Yes.

Check following 2 condition for your environment.
1) OE: Autobackorder is only effective if the profile, OE: Reservation = Yes
2) only affects items in a kit, model, or ship set during Pick Release.

/by