accrual account definition-

If the destination type is Expense then the Accrual account is populated from

the Purchasing Options Expense AP accrual account.

Navigation: Purchasing Resp > Setup > Organizations > Organizations > Purchasing

Options

If the destination type is Inventory the accrual account is populated from

the receiving Organization’s Organization Parameters region.

Navigation: Setup > Organizations > Query the Inventory Org > Organization

Classifications > Organization Parameters > Other accounts > Inventory

AP accrual account

Disabling correction button in Oracle Payable invoices

open Oracle Invoice Form,

go to Help> Personalization.

Seq: 10

=========

Description: e.g Hide Correction

Level: Form

Condition:

=========

Trigger Event : WHEN-NEW-FORM-INSTANCE

Trigger Object :

Condition : Null

Processing Mode :Both

Context (Tab)

=======

Level :Responsibility

Value :<Enter the Responsibility> or <Enter User>

Or

Leave it at Site

Actions (Tab)

=======

Seq : 10

Type :Property

Language : All

Enabled : Checked

Object Type : Item

Target Object: INV_SUM_CONTROL.CORRECTIONS

Property Name :DISPLAYED

Value:FALSE

Save and Apply

Exit the Form and Open it again,

Corrections button shouldn't be displayed, and form data entry shouldn't encounter any issue

Duplicate Invoice Number With Different Supplier Site allowed (Doc ID 1674300.1)

APPLIES TO:

Oracle Payables - Version 12.0.1 and later
Information in this document applies to any platform.

SYMPTOMS

 The Invoice Workbench is allowing users to enter duplicate invoice numbers as long as the supplier site is different.

CAUSE

As per Doc ID 1282143.1 there was an Enhancement created where you can create invoices using the same invoice number from the same supplier with different supplier sites.  This functionality was provided by Patch 9105666:R12.AP.A/B.

SOLUTION

If you would prefer this was not allowed, a workaround can be setup using the following personalizations, which still allow the duplicate invoice number to be created, but present a warning message letting the user know they created the duplicate invoice number.
Both personalizations below, need to be used for the warning message to appear and they are meant to work when profile option AP: Use Invoice Batch Controls is switched to NO.

PERSONALIZATION 1
--------------------------

Function Name: AP_APXINWKB (system created)
Form Name: APXINWKB (system created)
Debug Mode: Off (system created)

Sequence: 10
Description: XX_DUP_INVOICE_NUM_1
Level: Function
Enabled: Checked

Condition:
Trigger Event: PRE-INSERT          **(If pre-insert is not in your LOV, you can just type it in)
Trigger Object: << leave blank, will be grayed out >>
Condition:

   0 <(select count(*) from ap_invoices_all ai
   where invoice_num =:INV_SUM_FOLDER.INVOICE_NUM
   and vendor_id =:INV_SUM_FOLDER.VENDOR_ID
   and org_id    = :INV_SUM_FOLDER.org_id
   and ((:inv_sum_folder.invoice_id IS NULL) OR :inv_sum_folder.invoice_id <> ai.invoice_id))

Processing Mode: Both

Context: <I would recommend setting this to whatever responsibility you enter invoices>

Actions:
Sequence: 10
Type: Message
Description: <null>
Language: All
Enabled: Checked

Message Type: Warn
Message Text: You have entered duplicate Invoice Number for same Supplier. Please Use Different Invoice Number.


PERSONALIZATION 2
--------------------------

Function Name: AP_APXINWKB (system created)
Form Name: APXINWKB (system created)
Debug Mode: Off (system created)

Sequence: 10
Description: XX_DUP_INVOICE_NUM_2
Level: Function
Enabled: Checked

Condition:
Trigger Event: PRE-UPDATE          **(If pre-insert is not in your LOV, you can just type it in)
Trigger Object: << leave blank, will be grayed out >>
Condition:

   0 <(select count(*) from ap_invoices_all ai
   where invoice_num =:INV_SUM_FOLDER.INVOICE_NUM
   and vendor_id =:INV_SUM_FOLDER.VENDOR_ID
   and org_id    = :INV_SUM_FOLDER.org_id
   and ((:inv_sum_folder.invoice_id IS NULL) OR :inv_sum_folder.invoice_id <> ai.invoice_id))

Processing Mode: Both

Context: <I would recommend setting this to whatever responsibility you enter invoices>

Actions:
Sequence: 10
Type: Message
Description: <null>
Language: All
Enabled: Checked

Message Type: Warn
Message Text: You have entered duplicate Invoice Number for same Supplier. Please Use Different Invoice Number.

Auto assignment of Locator and Subinventory to Item

goal: How to assign Sub Inventory and Stock locator Automatically when you 
receive the items?

fact: Oracle Inventory 11.5 and later


Note : 
1. Navigation : Inventory -> Items -> Organisation Items -> Query for 
the Item-> Inventory Tab
2. Navigation : Inventory  -> Set Up -> Transactions -> Item 
Transaction Defaults

Ensure the Set Up as below
1.Set the locator control to the item level 
a).Set the flag "restrict sub-inventory" and "restrict locator" 
b).Set the locator control to "pre-specified" 

2.Define Locator name following the below Navigation
In  Item Transaction Defaults Window

a.Sub Inventories Tab 

 Enter Item ,  Value of Default for = Receiving , and  Sub Inventory value
b.Locators tab 
 Enter the Value of the Default Locator for  this Item and  ensure that the
 Value of Default for is Receiving.

Note :
Define at least one locator for an item in one inventory to use "Item 
Transaction Defaults"

YTD Depreciation Incorrect For Assets Added Via ADI and Mass Additions (Doc ID 189519.1)

APPLIES TO:

Oracle Assets - Version 11.5.10.0 to 11.5.10.0 [Release 11.5]
Information in this document applies to any platform.
This document is a replacement for 162929.1 which has been deleted.

SYMPTOMS

The year to date (YTD) depreciation for assets added with ADI is not as expected.  The assets were added via the mass additions interface table and were added with YTD depreciation and depreciation reserve.  

CAUSE

When performing a data conversion into Oracle Fixed Assets, two columns need to be populated in the FA_MASS_ADDITIONS interface table - the Amortize_NBV_Flag ('Y') and Amortization_Start_Date (date in the current FA period).

This is important for correct depreciation calculations when importing assets with accumulated depreciation.  The amortization start date should be a date in the currently open period in FA.  It is an as of or start from date.  The last or the first day in the open FA period could be used.

SOLUTION

Make sure that columns AMORTIZE_NBV_FLAG ('Y') and AMORTIZATION_START_DATE (date in current FA period) in the table FA_MASS_ADDITIONS are populated before posting.

what is table name for prepayment application

exec mo_global.set_policy_context('S',&org_id);

select * from AP_VIEW_PREPAYS_V where vendor_name='&vendor_name' and vendor_site_code='&vendor_site_code';

How Are Purchase Orders Closed Automatically? Closed Status Rolled Up? PO's Are Not Closing? (Doc ID 1265680.1)

APPLIES TO:

Oracle Purchasing - Version 11.5.10.2 to 12.2 [Release 11.5 to 12.2]
Information in this document applies to any platform.

GOAL

What are the key components for moving the approved purchase orders to a closed status?

SOLUTION

There are various factors which must be considered that relate to the systematic closing of the Purchase Order Shipments, Lines and Headers. 

Factor 1 - Matching

2 Way Matching - Approve/Invoice
3 Way Matching - Approve/Invoice/Receipt
4 Way Matching - Approve/Invoice/Inspect/Receipt

The level of matching (2, 3,or 4) defaults in the following order:
Level 1 - Item if not found then
Level 2 - Line Type - if not found then
Level 3 - Supplier - Receiving Tab Options Area - if not found then
Level 4 - Purchasing Options



________





If Receipt Required is Yes and Inspection Required is No
– this is 3 way matching – meaning Approve/Receive/Invoice

If Receipt Required is No and Inspection Required is No
– this is 2 way matching – meaning Approve/Invoice

If Receipt Required is Yes and Inspection Required is Yes
– this is 4 way matching – meaning Approve / Inspect / Receive / Invoice

Take notice that Receipt Close Tolerance is also on the Item as well as Invoice Close Tolerance.
This is also the primary default for these values as well.

________





In the supplier screen – the match approval level can also be set. This is the second defaulting level in the hierarchy.

________





In the Line Type – there are two columns – Receipt Required and Receipt Close.
Receipt Required as Yes – serves as a 3 way match – No – would serve as a 2 way match.
You can name the line type anything – in this example 2 way match was given to help clarify.
Also, you see the receipt close tolerance – in this case is set at 100%. This will be explained in the tolerances section.

________





In the Purchasing Options – there are settings for Match Approval Level – Receipt Close – and Invoice Close tolerance. This is the last location that is checked for values – when entering a Purchase Order.

________


Factor 2 - Receive and Invoice Close Tolerances

The Receive and Invoice Close tolerances are entered based on percentages. 

The defaulting order of these tolerances is as follows:
Receipt Close Tolerance – Defaulting Hierarchy

Level 1 – Item in the Item Master – if not found then
Level 2 – Line Type – if not found then
Level 3 – Purchasing Options

Invoice Close Tolerance - Defaulting Hierarchy

Level 1 - Item in the Item Master - if not found then
Level 2 - Purchasing Options

The screen prints in Factor 1 also show the locations for entering the tolerance percentages.

Here is a quick link to the Purchase Order Defaulting Rules - Note 1067175.1.

________

The receipt close tolerance determines how much quantity must be received before a Purchase Order Shipment will move to the status of Closed For Receiving.

The invoice close tolerance determines how much quantity must be billed prior to moving to a status of Closed for Invoicing.

Once a purchase order/blanket release shipment has met both tolerance conditions for closing – as related to invoicing and receipt – the shipment will automatically close. The Closure Status for the shipment will show – Closed with a reason of  Status Rolled Up.

After all shipments have closed for a particular line – the closure status of the Line will become Closed as well. Finally, when all lines have closed on the purchase order – the header level of the Purchase Order will become closed.

________

Here is an example of how the receipt close tolerance works.

Suppose that a purchase order line has a quantity of 100.
The receipt close tolerance is 10%. This is seen on the Purchase Order Shipment – More TAB
10% of 100 is 10. Deduct this from the shipment total as 100 – 10 = 90.

This means that in order for this Purchase Order Shipment to move to a status of Closed for Receiving, at least a quantity of 90 or greater - out of the total 100 would need to be received/delivered.





Now, for 2 way matching – the desire is to only have to approve and then create an invoice. For this to work – it is necessary to have the receipt close tolerance come in as 100%. By putting in 100% - the system is being told that no receipt would need to be done – as 100% of the quantity is all quantity ordered.

By using 100% receipt close tolerance with 2 way match – the system will move the purchase order shipment immediately to Closed for Receiving. See below:





Here is a purchase order – that is having 2 way match – with 100% receipt close tolerance.
Notice the status tab – below – the shipment is already Closed for Receiving. This now sets up the system so that when the invoicing is conducted – and reaches within the invoice close tolerance – the purchase order shipment will be closed. In this case – the invoice close tolerance is 0% which means that this purchase order shipment would require the full amount to be invoiced. If the full amount is not billed – the shipment will remain in the Closed for Receiving status – and not close (roll up) automatically.





________

Factor 3 - Receipt Close Point

The receipt close point is a key component when using 3 and 4 way matching.  This determines when the closure process should be engaged for the Receive/Inspection portion of the Purchase Order Receipt.

The receipt close point is set in the Purchasing Options.





When a Purchase Order Receipt is conducted - it consists of two transactions - Receive and Deliver.
The Receipt Close Point tells the system when to determine/consider the shipment for Closure.

Receive is completed - Receiving/Receipts
Deliver is completed - Receiving/Receiving Transactions

Receipt Routing is set in the Purchase Order Shipment - Receiving Controls. There are three different types of Receipt Routing:
 - Standard Receipt - The Receive and Deliver will be done separately
 - Direct Delivery - The Receive and Deliver transaction are done at the time of Receive
 - Inspection Required - The Receive - Inspect - and Deliver are done separately

Here is an example:
 - Purchase Order - Line 1 - quantity 100 - and shipment is having Receiving Routing - Standard Receipt
 - The Receive Close Tolerance is set to 0% - meaning that the quantity will need to be fully Receipted
 - The Purchasing Options -  Receive Close Point is set to Deliver

The user enters Receiving/Receipts - and conducts the first portion of the Receipt.
 - The user does not conduct the Delivery of the receipt
 - The shipment will still be open - it will not goto Closed For Receiving - as the receipt close point is Deliver and the Deliver transaction has not yet been accomplished.

Now, in the above scenario - had the Receipt Routing on the Purchase Order Shipment - Receiving Controls - been Direct Delivery - then at the time the user conducted the Receive portion of  the Receipt - the Deliver would also have been done - which satisfies the Receipt Close Point of Deliver. This would move the shipment to Closed For Receiving.

Note: If receipt close point is set to 'Accepted' try changing to 'Receive' or 'Deliver' for automatic close.

What are the definitions of the Closure statuses:

Closed for Invoicing and Closed for Receiving:
Purchasing automatically closes your purchase order for receipt when it is fully received. You can manually close partially received purchase orders if you no longer expect any
more receipts against them. Close for invoicing and close for receiving are managed using tolerances. You can specify that when you have received a certain percentage
of a shipment, Purchasing will close the receipt. This is a soft close, and you can reopen the receipt. Purchasing rolls up closing to the line and header level, and
"Closed" information does not show in the Open Purchase Orders Report. Also, if there is a remaining balance, closed quantities are no longer visible as supply
scheduled receipts to MRP/ATP

Closed:

As the receiving and invoice tolerances are met on each shipment, the shipments will close - and as all shipments reach a closed status - the line will then close.
As all lines eventually close on the purchase order - the header will then close as well.  It is possible to use the purchase order summary to again Open a Closed Purchase Order.

Finally Closed:
Finally Closed status leaves the purchase order in a state where no further actions are possible.  Any supply picture should be removed as well as reversal of any uncumbered funds.
Once a Purchase Order is Finally Closed - no further actions are possible. Finally Close actions are done via the Purchase Order Summary - and are also possible during the invoice
match which is taking place from Oracle Payables - known as a Final Match.

________

R12: CE: Unable to See the Legal Entity List of Values in the Bank Account Owner Field (Doc ID 415529.1)

APPLIES TO:

Oracle Cash Management - Version 12.0.0 and later
Information in this document applies to any platform.

SYMPTOMS

Unable to create a new bank account in release 12 in Cash Management.  The list of values (LoV) in the Bank Account Owner field does not display the Legal Entities that have been created.

CAUSE

This is not a bug, it is a setup issue. Cash Management responsibility must be assigned the Legal Entities to which you want to grant access to all bank accounts.

SOLUTION

Please do the following to assign Legal Entities to the Cash Management responsibility:

1. Log in as Sysadmin.
2. Go to the User Management Responsibility.
3. Path: Roles & Role Inheritance
4. In the Type field select Roles and Responsibilities
5. Wait until a new field appears, you will see the category field, please select Miscellaneous
6. In the Application select 'Cash Management' and click on GO button.
7. Search your Cash Management responsibility or role that you are using to create your bank account.
8. Click on the update icon.
9. A new window will be displayed, please click in the Security wizard button.
10. For CE UMX Security wizard click on the Run Wizard.
11. In this window you should add the legal entities that you want to grant the access to all the bank accounts within a legal entity and choose the privileges that you want to assign to this role on the bank accounts such as: USE, MAINTENANCE and BANK ACCOUNT TRANSFERS.
12. Save and apply the changes and then verify in Cash management responsibility if you now are able to see that legal entity in the bank account creation form.

Unexpected Error Occurred During Tax Calculation - Exception: 023 When Attempting to Save a Newly Created PO (Doc ID 1966482.1)

Unexpected Error Occurred During Tax Calculation - Exception: 023 When Attempting to Save a Newly Created PO (Doc ID 1966482.1)

To Bottom

---

APPLIES TO: Oracle Purchasing - Version 12.1.3 and later Information in this document applies to any platform. SYMPTOMS On R12  Instance when attempting to Save/Approve a newly created PO (Purchase Order)the following error occurs: ERROR ________ "Unexpected error occurred during Tax Calculation - Exception: 023" Debug log Message shows: x_acct_rate_type is null x_acct_rate_date is null x_acct_exchange_rate is null Steps To Reproduce:         Login to the E-Business Suite         Go to the Purchasing Responsibility         Create a new Purchase Order         Enter the details and  Save / Approve you see the above error CAUSE Incorrect setup. Creating a PO(Purchase order) in foreign currency i.e  'USD' without providing the Rate Type and Rate Details in the Currency Tab.  It is mandatory to define Rate Type and Rate Details in the Currency Tab when using foreign currency This is explained in the following bug       Bug 20405214 : PO APPROVAL ERROR:UNEXPECTED ERROR DURING TAX CALCULATION - EXCEPTION: 023 SOLUTION To implement the solution, please execute the following steps in test instance: 1. It is mandatory to define Rate Type and Rate details in the currency tab when using foreign currency 2. Fill the PO Header Information and PO Lines 3. Click on Currency Tab 4.Make sure Currency is Populated eg 'USD' 5.Make sure Rate Type is populated 6.Make sure Rate Date is populated 7.Make sure Rate column is populated 8.Save the Purchase Order and Approve it 9. If Successful Migrate the solution as appropriate to other environments.

How To Setup And Use AME For Purchase Requisition Approval

How To Setup And Use AME For Purchase Requisition Approvals [ID 434143.1]

Compiled by Ali Raza Kazmi (ACA)

Assign AME Roles and Responsibilities
AME responsibilities in 11i.AME.A are assigned directly to the users. However, In R12 or 11i.AME.B and higher, AME responsibilities are assigned indirectly to users through roles. The roles are assigned to the users by the SYSADMIN user using the User Management responsibility. Once the roles are assigned, the AME responsibilities are automatically available to the users without specifically assigning the AME responsibilities to the users. Here are steps to assign the roles:
1. Login as System Administrator user
2. Select the responsibility "User Management". (NOTE: User Management data is stored in the UMX schema)
3. Select "Users" menu option
4. Search for the user to whom you wish to grant AME roles
5. In the results table, click on update icon
6. In the update user page, user details can be seen along with a list of roles available to user. Click on "Assign Roles"
7. Search for Approval% and Select roles from the resulting LOV. Choose the roles that are applicable (proper authority) for the user, and click the Select button.
8. Specify justification and relevant dates for the newly assigned roles, and click Apply to assign the roles to the user.
Reference Note 413300.1 Oracle Approvals Management Not Enabled? What Does It Take To Enable It?
Grant Transaction Type Access to Users
AME restricts access to transaction types using Data Security. Grant users access to the transaction types using the Grants page. Set up user access as follows: 1. Navigate to the Personal Home Page. 2. Select Functional Administrator Responsibility 3. From the Grants page, press on the Create Grant button 4. Create a grant with the following information:
Name 
Grantee Type = Specific User
Grantee = 
Object = AME Transaction Types
5. Click Next and select the Object Data Context
Data Context Type = All Rows
6. Click Next to define the object parameters and Select Set
Set = AME Calling Applications
7. Click Next. Review the changes and then Finish the process.
Review and Modify AME Setup
AME is designed to provide approval logic for many transaction types. Transaction types used for Purchase Requisitions include the following: Purchase Requisition Approval, Internal Requisition Approval, and Requester Change Order Approval. This whitepaper focuses on Purchase Requisition Approval, however, many of the concepts are applicable to the other two requisition transaction types as well. Likewise, some examples and comments in this paper are written in iProcurement context, but the same AME concepts apply to core apps requisitions also.
1. Navigate to the Approvals Management Business Analyst, Standard responsibility
2. Choose the Business Analyst Dashboard menu from the responsibility
3. Use the Transaction Type LOV to search and select the transaction type = Purchase Requisition Approval
4. Use the links on the right in the Approval Process Setup region to set the components (Attributes, Conditions, Action Types, Approver Groups) and rules, or to use the test workbench in AME.
1. Action Types
1. An action type is a collection of actions having similar functionality. Every action belongs to an action type. Action types are enabled or disabled for a particular transaction type. AME may give an error when attempting to enable an action type for a transaction if the transaction is not designed to allow that action type. Reference Note 293315.1 11.5.10 FAQ for Approvals Management (AME) Integration For iProcurement and Purchasing - for a list of action types allowed for requisition transactions in AME. In addition, Note 404152.1 Release Content Documents for E-Business Suite R12 - provides a link to the Procurement Family RCD which clarifies (Section 3.4.2.14) that requisition approval with Oracle Approvals Management (AME) in R12 allows use of Position Hierarchy based Approvals, Parallel Approvals, and Support for FYI Notifications.
2. To disable or enable action types for the transaction, select the Action Types link
3. The Action Types page shows the action types that are currently enabled for the transaction type (Purchase Requisition Approval). Use the Previous and Next links to scroll through the list of enabled action types. Select the Use Existing Action Type button to see other pre-defined action types available in AME. Some of these may or may not be applicable to the currently select transaction type; AME will give an error if the user tries to add a non-relevant action type for the selected transaction type.
4. Navigate to HR responsibility -> Work Structures -> Job -> Description - to assign a Level (Approval Authority) to a Job. Query up the Job and enter the appropriate Job Level in the Approval Authority field.
5. In AME, select any or all of the following Action Types for JOB BASED approvals if applicable for your business requirements:
1. absolute job level / chains of authority based on absolute job level
2. final approver only / chains of authority containing only the final job-level approver
3. manager then final approver / chain of authority includes requestor's manager and then the final approver
4. relative job level / chains of authority based on relative job level
5. supervisory level / chains of authority based on number of supervisory levels
6. In AME, select any or all of the following Action types for APPROVER GROUP approvals if applicable for your business requirements:
1. post-chain-of-authority approvals / group approvals after the chain of authority
2. pre-chain-of-authority approvals / group approvals before the chain of authority
3. approval-group chain of authority / chain of authority includes an approval group
7. In AME, select any of all of the following Action types for POSITION BASED approvals (Only in R12 and higher) if applicable for your business requirements
1. hr position / chains of authority based on a particular HR position
2. hr position level / chains of authority based on HR positions
2. Attributes
1. Attributes are the base element for an AME Rule. Attribute values are retrieved from the Oracle EBusiness Suite Applications database or derived from values in the database. AME is seeded with attributes relevant to the transaction type, and the user can create new attributes in AME for use in AME rules.
2. Select the Attributes link to view or add attributes for the selected transaction type
3. Use the Previous and Next links to scroll through the existing attributes. Some of the attributes relevant to Purchase Requisition Approval include ITEM_CATEGORY, ITEM_NUMBER, and REQUISITION_TOTAL as well as other attributes. When AME approvals is enabled for purchase requisitions, these values are retrieved for the relevant requisition while navigating through iProcurement checkout or core apps requisition create, and AME uses this information to determine the appropriate AME rule(s) to use.
4. In addition to the seeded attributes, a customized attribute can be created. DAVE_CATEGORY_SEGMENT is an example of this. This attribute uses a query to capture SEGMENT1 of the Item Category flexfield. The Item Category flexfield may be setup to use one or more segments; this customized AME attribute captures only SEGMENT1 of the flexfield. This allows the users to setup conditions and rules that are dependent on a certain value in SEGMENT1 of the ITEM Category used on the requisition. NOTE: The new attribute DAVE_CATEGORY_SEGMENT1 uses the same sql query as the seeded ITEM_CATEGORY AME attribute, except it selects mck.segment1 rather than mck.concatenated_segments.
3. Conditions
1. Conditions identify values and value ranges for some or all of the attributes available. AME rules refer to these conditions to determine if a particular rule is applicable for the specific document (requisition) being approved. For example, an AME rule can be setup to require certain approvers if $0 USD <= requisition total < $1000 USD. Since REQUISITION_TOTAL is a seeded attribute, the user can define a condition $0 USD <= requisition total < $1000 USD, and then use this condition in a rule to require certain approvers for the requisition. The rule cannot refer to this condition until it is defined in AME Conditions for the Purchase Requisition Approval transaction type.
2. Select the Conditions link from the AME Business Analyst Dashboard after specifying the Purchase Requisition Approval transaction type. Selecting the Conditions link will display the existing conditions defined for the transaction type, and also allow the user to create new conditions for the transaction.
3. Click the Create button to create a new condition
4. To define the new condition, specify whether the condition is ordinary, or an exception condition (which can only be used in an exception rule – see the online Help for details). Use the Attribute LOV to choose the attribute on which the condition is based. The condition will specify a value or range of values for the attribute, so the attribute must be selected before the value(s) can be defined.
5. Define the allowed value or value range for the selected attribute. Click Apply to complete the condition definition.
4. Approver Groups
1. Approver Groups are optional. Setup Approver Groups if additional approvers are required for particular conditions, or to specify a dynamic sql query for additional approvers. The rules defined for the transaction can be based on Approver Groups, Jobs defined in HR setup, or Positions defined in HR setup (only in R12); the rules may also use a combination of Job, Position, and Approver Group basis. (See the Rules details later in this paper for more information about the rules)
2. Select the Approver Groups link from the AME Business Analyst Dashboard.
3. View and edit existing approver groups, or Click the Create button to create a new approver group.
4. When creating the approval group specify all the mandatory values.
1. Give a name and description to the approval group.
2. Specify an order number (order number of this approver group relative to other approver groups).
3. Choose a voting regime – only Serial is supported for Purchase Requisition Approval in 11.5.10 and 11.5.9. R12 does allow other voting regimes that use parallel routing.
4. Choose Static if approvers will be selected when defining the approval group, or choose Dynamic if a sql query is used to dynamically find the approvers for this approver group when the requisition approval transaction is being processed.
5. Click the Add Another Row button to add approvers to the approval group now.
6. Click Apply to save the approver group
5. The approval group members can be added as additional approvers to the normal chain of command approvers generated by AME.
5. Rules
1. Define rules to specify approvers that should be included in the approval list under specific conditions for the requisition approval transaction.
2. Select the Rules link from the AME Dashboard after selecting the transaction type – Purchase Requisition Approval
3. Review the list of existing rules already defined for the transaction
4. Select the Create button to create a new rule for the transaction. (Optionally, if there already exists a similar rule choose the Duplicate icon or the Use Existing Rule button).
5. Step 1 of 4: Specify a name for the new rule and choose the rule type and effective dates. Rule types are explained in the AME online help pages along with examples. The most common types are List Creation, Pre List Approver Group and Post List Approver Group. (NOTE: Some rule types may not be available if the corresponding action types have not been assigned to the transaction – Purchase Requisition Approval. Use the Action Types feature to add or remove action types for the transaction)
6. Step 2 of 4: Specify one or more conditions that activate the rule. The Conditions are defined in the AME Setup, and they may be seeded conditions or user defined conditions.
7. Step 3 of 4: Choose the Action Type and then choose a specific action. The list of actions available is dependent on the Action Type selected. The actions are related to Jobs, Positions (in R12), or Approver Groups. (Action Types are discussed previously in this whitepaper)
8. Step 4 of 4: Review the rule details and click Finish to complete the rule setup, or click Back to make changes.
6. Test Workbench
1. Use the Test Workbench to determine which AME Rule(s) apply to a specific requisition, or to determine which AME Rule(s) apply for an adhoc combination of values specified at the time of the test. Select the Test Workbench link from the AME Dashboard
1. Specific Requisition test
1. Click the Run Real Transaction Test button.
2. Specify the value of REQUISITION_HEADER_ID from PO_REQUISITION_HEADERS_ALL as the Transaction Id value. Click Go to see the AME rules that apply to the requisition.
3. Adjust the rules setup to cause rules to be called differently based on the business requirements.
2. Adhoc test
1. Click the Create button on the Test Workbench page
2. Specify Name and Description for the test, and specify values for pertinent attributes (e.g. Requisition Total = $100 USD)
3. Click the Run Test Case button to see the applicable AME rules, and the resulting AME approval list that will be built based on the conditions specified for the attributes.
Enable AME for Requisition Approval
1. Navigate to Purchasing responsibility
2. Setup / Purchasing / Document Types
3. Select Purchase Requisition (or Internal Requisition) as the document type
4. Specify Approval Transaction Type = PURCHASE_REQ (or INTERNAL_REQ) to enableAME approvals for Purchase Requisitions (or Internal Requsitions) in the current operating unit
Test the Functionality
1. Create a requisition in Core Apps Purchasing or iProcurement and verify that the Approval List is built per the AME rules based on the conditions present on the requisition attributes.
View the AME Setup
1. Click the Setup Report link in the Quick Links section of the Dashboard
2. Select the appropriate transaction type (Example: Purchase Requisition Approval) and click Go.
3. Click the Printable Page button to view the complete setup for the selected transaction type (Attributes, Conditions, Rules, Approval Groups, and etc.)
4. Compare the AME setup to the requisition attributes and approval list generated for a specific requisition, or compare the AME setup to the business requirements. NOTE: This document is not considered formal documentation of the product, but is a useful tool for applying the functionality described.
MSWord Format - AME for Purchase Requisition Approval - Whitepaper 
NOTE1: These same instructions are provided in MSWord document format with screenshots in the file attached to this note. Please see the attached MSWord document for more details.
NOTE2: This document is not consider formal documentation of the product, but is a useful tool for applying the functionality described.
Summary
This paper describes the setup steps for accessing AME, designating AME as the approval choice for requisitions, and using the AME approval routing for requisitions. Use this document as a guide for initial AME setup, or for validating and adjusting a current AME setup to meet changing needs. This information is also helpful for troubleshooting approval routing issues when using AME approvals. For additional troubleshooting ideas reviewNote:428552.1.
Please provide feedback with your comments or recommendations for improving this document.
References
NOTE:293315.1 - 11.5.10 FAQ for Approvals Management (AME) Integration For iProcurement and PurchasingNOTE:404152.1 - E-Business Suite Release 12: Release Content DocumentsNOTE:413300.1 - Oracle Approvals Management Not Enabled? What Does It Take To Enable It?NOTE:428552.1 - How To Diagnose Issues With Approvals Management Engine (AME) In Procurement

impact of Accrual accounts on receipt for Expense and Inventory Items

When both inventory and expense items are accrued on receipt, the following problems may be encountered:

A) Receiving inspection balances will include both inventory assets and expenses, so at the end of the month, they will need to be manually reclassified.

B) The number of entries needed to research and reconcile the perpetual A/P Accrual Account(s) becomes significantly increased. Since the expense receipts could double the number of accrual accounting entries to process, the Accrual Reconciliation Report could take twice as long to run. The amount of time required by your staff to research any discrepancies would also increase.

Why are expense items typically accrued at period-end, and why are inventory items always accrued on receipt?

One should accrue on receipt if perpetual inventory is adopted to facilitate reconciliation between inventory valuation reports and accounting entries. Expense items typically are not accounted for on a daily basis, and most companies find it easier to account for and reconcile these expenses at month-end rather than at the time each individual expense is incurred.

What is the difference between 'Accrue On Receipt' and 'Accrue at Period End'?

Accrue On Receipt means that when a receipt is saved, accrual transactions are immediately recorded and sent to the general ledger interface. This is also known as "online" accruals. Accrue at Period End means that when a receipt is saved, the accrual transactions are not immediately recorded and sent to the general ledger; instead, the accounting entries are generated and sent at the end of the month by running the Receipt Accruals - Period-End Process.

All items with a destination type of either Inventory and Outside Processing are accrued on receipt. For items with a destination type of Expense, you have the option of accruing on receipt or at period end.

difference between expense and inventory item in Oracle Inventory

Difference between expense item and inventory item in Oracle.

Expense Item:

• Captive consumption of the organization 
• it will not be transferred (Stockable & Transactable ) to the inventory and
• hence will not hit the inventory valuation account.

Inventory Item:

• it will hit the inventory as well as inventory valuation account and
• it will be used in production of finished goods. 

Difference between expense item and inventory item

Those Item that needs to maintain stock and tracking are inventory Items. Creating unique Item coding for each SKU's

Non-Stock able Items that is direct IN & OUT, are expense items. For such items no need to create Item code for all. Only few codes can be created and in PR & PO description can be change

For example

Inventory items: Machine parts, Raw Materials, Any Trading Items etc

Expenses Items: Assets, services, Projects, consumables (Office Stationery) etc.

You cannot define an item as expense and inventoried at the same time. But you can define the item as inventory item.

And when you want to use it as expense, move it to an expense subinventory.

We need to uncheck the attribute "Asset Subinventory" in the specified subinventory.

You should uncheck the asset flag for that subinventory. Make sure that the subinventory accounts are setup correctly.

The terminology of items is rather confusing from an Purchasing/Inventory point of view:

For easy understanding these will be referred below points.

These Expense Items have attributes checked

a - Purchasable

b - Purchased

These Inventory Expense Items have the following attributes checked

a - inventory item = YES

b - stockable

c - transactable

d - Inventory Asset Value = NO

e - Costing Enabled = No

These Inventory Asset Items have the following attributes checked

a - inventory item = YES

b - stockable.

c - transactable

d - Inventory Asset Value = YES

e - Costing Enabled = YES

As you know "procure to pay" Business Flow start Purchasing requisition till paying to vendors and most important, in all the case the purchase is made for basic element called Items.

As you know there are three types of items:

• Inventory Expense Item
• Inventory Asset Item
• Expense item

Period End Process In General Ledger R12

Period End Process In General Ledger R12:

In Oracle General Ledger, an accounting period is closed after all the accounting transactions have been completed for the period. A closed period can be re-opened (provided it has not been permanently closed), if it is necessary to enter or modify accounting transactions for that period.

For most modules you can view and select one of the following:

* Never Opened - The period has never been used.
* Future Enter able - The period is open to accept transactions from other modules. Usually used where modules are maintained in different periods, and transactions are likely to be posted across modules.
* Open - Period is available for data entry
* Closed - Period is closed for processing, but can re re-opened if required.
* Permanently Closed - No further processing is possible.

Managers have the discretion to immediately close a period to prevent unauthorised processing, but be able to re-open periods for post processing adjustments. The periods can then be permanently closed as required, independent of the period/year end process.
Suggestion: Periods are usually only ‘finally closed’ when all adjustments and reporting requirements for the prior financial year are finalised.

Combined Basis Accounting:
If you have installed combined basis accounting, then the steps detailed below will need to be completed for both your accrual and cash Ledgers. This will mean that you will need to select the responsibility relevant to both Ledgers when completing these tasks. Depending on the Ledger set/Data Access Set attached to a responsibility, these tasks could be performed from a single responsibility. Procedures

The following steps are taken in performing period-end processing for Oracle General
Ledger.
1. Ensure the Next Accounting Period Status is set to Future Entry
Set the status of the next accounting period to ‘Future Entry’ if it is not already, except at year-end.
At year-end, it is recommended that you complete all period end processing, prior to opening the first period of the new financial year.

2. Complete Oracle Sub-ledger Interfaces to Oracle General Ledger
Journals are created to load accounting information into Oracle General Ledger. Journals are comprised of batch level, journal entry level, and journal entry line level, information. Ensure that the accounting information from the sub-ledgers (Oracle Payable, Purchasing, Inventory, Order Management, Receivables, Cash Management, Assets, Treasury and Projects) have been transferred to Oracle General Ledger. Run Create Accounting program or the appropriate program (based on previous runs of Create Accounting) to transfer data from sub ledgers, into Oracle General Ledger. The Create Accounting process of SLA submits Journal Import Process (based on appropriate parameters as discussed in previous sections). This process populates the GL_JE_BATCHES, GL_JE_HEADERS, and GL_JE_LINES tables, and is run automatically.

Attention: The journal posting process, run in Oracle General Ledger, updates the GL_BALANCES table.
Journal Import:
* If not automatically completed, review the Journal Import Execution Report to identify which journal entry batches were not successfully imported.
* Delete any error journal entry batches. Determine the source(s) for these error batches, and retrieve the run ID from the Journal Import Execution Report.
* Make the necessary corrections - in the GL_INTERFACE table, via the Correct Journal Import Data window.
* Re-import these corrected journal entry batches from the GL_INTERFACE table. Simply re-enter the source from which journal entry batches are to be imported.
Note: If journal import fails when importing from the sub ledger modules, data will be rolled back to SLA tables, so that there would not be any data left in the GL_INTERFACE table, when the profile option ‘SLA:Disable Journal Import’ is set to ‘No’.
Attention: Leave sufficient time to re-import any journal entries not successfully imported from the feeder systems. Then update and post them.
 
3. Upload Journals from Web Applications Desktop Integrator (Web ADI) to Oracle General Ledger (Optional)
Journal information can also be imported from spreadsheets into Oracle General Ledger using Web ADI.
 
4. Complete Non-Oracle Sub-ledger Interfaces to Oracle General Ledger
(Optional: only required if you want to post from non-Oracle systems)
Following the same procedures as for Step 2:
* Ensure that the accounting information from any site specific, non-Oracle subledgers has been transferred to Oracle General Ledger.
* Run the Journal Import process for these sources and ensure the resulting Journal Entries are posted either automatically by AutoPost or manually.

Note: If you are loading accounting journals for 3rd party systems directly to Oracle General Ledger, use the GL_Interface. If you are using Oracle Financials Accounting Hub to generate accounting for your 3rd party systems, the accounting journal details will automatically by stored in the XLA tables, prior to being transferred (in summary or detail) and imported into Oracle General Ledger.
 
5. Generate Reversal Journals (Optional)
Select all the Journals to be reversed. Submit the process to generate the Reversal Journals. This process can be run across ledgers.
 
6. Generate Recurring Journals (Optional)
Select all the Recurring Journals that require generation for the current period. Submit the process to generate the Recurring Journals. This process can be submitted for foreign currency and for multiple ledgers, provided the access is available.
 
7. Generate Mass Allocation Journals (Optional)
Select the Mass Allocation Journals that require generation for the current period. Ensure that all entries to the source accounting flexfields used in the Mass Allocation Journal definitions are finalised for the current period, prior to generating the journal. Post step-down allocations in the correct order (i.e. perform the calculation and post, for each successive level of allocation entry). This process can be run across ledgers
and across currencies.
 
8. Review and Verify Journal Details of Unposted Journal Entries
Review any remaining unposted journal entries for the current period. Update journal entries as appropriate.
Attention: Journal entries can be reviewed on-line, or via reports. Reviewing journal entries prior to posting minimises the number of corrections and changes after posting. Following review of journal entry batches, perform any journal entry updates, including any adjusting entries, before posting.

Standard Journal reports available included:
a) Journal Batch Summary Report
b) Journals - General Report
c) Journals - Entry Report
d) Journals - Line Report
e) Tax Journals Report
f) General Ledger - Entered Currency
g) Journals by Document Number Report (when document sequencing is used)
 
9. Post All Journal Batches
Post all journal entries for the current period, including reversal, recurring and allocation journals.
Review the results of the post:

* The Posting Execution Report facilitates review of the results of journal entry posting. Oracle General Ledger generates this report every time posting of journal entry batches occurs. This report indicates any errors in journal entries or journal entry lines were discovered during the posting process.
* Run the Journals - General Report with a Posting Status of Error Journals to review error journal entry batches and their journal entries. Update unpostable journal entries. Locate the problems with unpostable journal entry batches using the following information:

a) Control Total
When using a control total, ensure that the debits and credits equal the control total.
b) Period Status
Post Actual batches to open periods.
Post Budget batches to any period in an open budget year.
Post Encumbrance batches to any period up to the last period in the latest open encumbrance year.
c) Batch Status
Oracle General Ledger describes the problems with unpostable batches.
Common reasons for unpostable batches are:
* Control total violations
* Posting to unopened periods
* Unbalanced journal entries
Attention: All errors in the journal entry batches must be fixed, and the corrected journal entries re-submitted for posting. Post updated journal entries.
 
9a. Run the Period Close Exceptions Report
This is a new step in Release 12. The General Ledger accounting can run the Period Close Exceptions report to double check that there are no outstanding transactions in the subledgers and GL, and ensure a follow-up with relevant colleagues if any exceptions are identified.

10. Run GL Trial Balances and Preliminary Financial Statement Generator Reports (FSGs)
To maintain a consistent audit trail, it is advisable to create a standard period-end accounting report set that can be run at each period end. Custom accounting reports can be created by using the ‘Financial Statement
Generator (FSG)’.
Suggestion: To prevent confusing different versions of accounting reports for a specific accounting period, discard any obsolete versions of your report for that accounting period. Request financial reports such as:

a) Balance Sheets e.g. Detail Trial Balance Report
b) Income Statements
c) Gross Margin Analysis

11. Revalue Balances (Optional)
Revalue account balances to update functional currency equivalents.
 
12. Translate Balances (Optional)
Define any new currencies to which accounting balances are to be translated. Maintain period-end exchange rates for all foreign currencies to which you want to translate. Maintain average exchange rates for all foreign currencies to which you want to translate. Maintain historical rates or amounts for any owner’s equity accounts to be translated. Translate account balances to any defined currency.
 
13. Consolidate Ledgers (Optional)
Attention: You can consolidate using Global Consolidation System, Financial Consolidation Hub or the Hyperion Consolidation functionality. Whichever you choose you can run your extract programs to extract the data from General Ledger to the consolidation systems.
* Consolidate within ledgers
a) Enter consolidating journal entries
The following two methods can be used to create eliminating entries for multiple companies using a single Ledger:
Automatic Eliminating Entries - define mapping rules to eliminated intercompany receivables, payables, investments in subsidiaries, intercompany sales etc. Recurring Journals- use formulas
b) Post consolidating journal entries.
c) Define a reporting hierarchy that consolidates all the companies.
d) Define financial statements with the reporting hierarchy.
Suggestion: To automatically generate the amounts and accounts for consolidating and eliminating journal entries, use recurring journal entry formulas.
Suggestion: To produce financial reports that reconcile your consolidating companies with the consolidated totals, enter the consolidating entries to a separate company, and build reports with a separate column for ‘consolidating entries’.
 
* Example of consolidation across ledgers when sharing same COA and Calendar
(Using Ledger Set and access granted via ‘Data Access Set’):
a) Define consolidated FSG
b) Perform revaluation and translations across ledgers
c) Enter consolidated and eliminating entries
d) Report on FSG by selecting the ledger set option while running
 
* Example of consolidation across ledgers using the Global Consolidation System
(GCS):
a) Define consolidations.
b) Perform revaluation and translation of foreign subsidiaries as required.
c) Run consolidations.
d) Enter consolidated and eliminating entries.
e) Report on this consolidated ledger using FSG’s.
f) Analyse results using drill-down capability from Parent ledger to Subsidiary
ledger/s.
Attention: All errors in the journal entry batches must be fixed, and the corrected journal entries re-submitted for posting.

13a. Reconcile Inter company (optional)
Advanced Global Inter company System in Release 12 provides more advanced features such as automatic generation of intercompany invoices in AP and AR, improved online reconciliation reporting, and is also fully integrated with SLA. A new, online reconciliation report provides drill-down to underlying sources and source journals for easy identification of reconciliation differences.
 
14. Review and Correct Balances (Perform Reconciliations)
Oracle General Ledger should be reconciled with all other modules. Adjust journals to correct any errors in the journals. Create and post adjusting journals to correct errors in account balances.
* Review Detail Account Balances On-line
* Review Account Balances via Reports
Request accounting reports such as general ledgers, general journals, trial balances, and accounts analysis reports to facilitate reconciliation of Oracle General Ledger with the other Financial and manufacturing modules.
a) General Ledger Reports
General Ledger Reports facilitate tracing back each transaction to the original source. These reports list beginning and ending account balances and all journal entry lines affecting each account balance. The report provides detailed information on each journal entry line including source, category and date.
b) Accounts Analysis Reports
These reports list the accumulated balances of a range of Accounting Flexfields and all journal entries that affect that range. Detailed information is provided for each journal entry line, which includes the source, batch name, and description.
c) Trial Balance Reports
Use trial balance reports to review account balances and activity in summary or detail.
d) Journal Reports
These reports print journal entry batches and include journal entry subtotals, and descriptions and reference information for each journal entry line. You can report on foreign currency, posted, unposted or error journal entries and report on a specific batch or on journal entries from a specific source.
 
* Journal Reconciliation:
General Ledger Entry Reconciliation lets you reconcile transactions in GL accounts that should balance to zero. With General Ledger Entry Reconciliation, you can selectively cross-reference transactions in GL with each other by entering reconciliation reference information at the journal line level. When the balance for
group of transactions is zero you can mark the transaction as reconciled.
 
* Clear Suspense Accounts
Examine the General Ledger and account analysis reports to identify the source of entries to the suspense accounts. Determine the adjusting entries required to net these accounts to zero.
Attention: If suspense accounting is not allowed, Oracle General Ledger will not post out-of-balance batches.
 
* Reconcile Subsidiary Ledgers
Identify differences between subsidiary ledgers and the General Ledger. Determine which differences are errors requiring adjustment to the General Ledger.
* Check other key system accounts have not been transacted by ad-hoc journals, for
example, Creditors Control, Debtors Control, Intercompany accounts, etc.
 
15. Enter Adjustments and / or Accruals and Post
To correct errors in account balances made by posting incorrect journals, create and post adjusting and reversing journals.
Attention: The details of posted journals cannot be changed, except to mark or unmark for reversal. An incorrectly entered posted journal must be reversed to back-out the accounting of the original posted journal.
Other journal entry adjustments, for example, write-offs (refer Accrual Write-Off Report), and manual accruals can be entered into Oracle General Ledger at this point also.
 
16. Perform Final Adjustments
Enter and Post any final adjustments as required by the organisation.
 
17. Close the Current Oracle General Ledger Period
Close the current GL accounting period in the Open and Close Periods window. The period can be ‘soft closed’, if later adjustments to the balances for that period may be applicable, or ‘permanently closed’, which means that the period cannot be re-opened in the future.
This step will need to be repeated for each ledger unless a data access set is setup to give access to multiple ledgers. This is controlled by GL: Data Access Set profile option. With a data access set across ledgers programs can be run for multiple ledgers from a single responsibility.

18. Open the Next Oracle General Ledger Period
Open the next General Ledger accounting period in the Open and Close Periods window. This operation can be performed across ledgers provided ‘Data Access Set’ grants access.
Choose status ‘Open’ to open a new accounting period, or to re-open a previously soft closed period to enable adjustments to be made. Generate and post reversal journals that were entered in the prior period. For example any Oracle Purchasing receipted accruals and manual accruals. This step will need to be repeated for each ledger unless a data access set is setup to give access to multiple ledgers. Any Journals entered into this period while it had a status of Future Enterable, can now be posted as the period now has a status of Open. This is controlled by GL: Data Access Set profile option. With a data access set across ledgers programs can be run for multiple ledgers from a single responsibility.
 
19. Run Financial Reports for the Closed Period
Run a final Trial Balance Report.
Run final Financial Statement Generator Reports (FSG) or Report Sets as required by the organization including Income Statements and Balance Sheets. FSGs can also be published via the Application Desktop Integrator (ADI).
 
20. Run Reports for Tax Reporting Purposes (Optional)
A variety of standard reports can be used to provide tax information, which is required to be reported to the relevant Tax Authority, including withholding tax. The Financial Tax Register can be used to view the output from the Tax Reporting Ledger using Reports Exchange and Application Desktop Integrator (ADI). Using
these products you can change the layout of the report, publish the report in different formats, and export the data to a tab delimited or HTML file. The Tax Reporting Ledger consists of accounting information created in Oracle Receivables, Oracle Payables, and Oracle General Ledger. The Financial Tax Register uses this data to generate Tax Register reports using the Rxi reporting tool.
The following tax registers are available:
a) Deferred Output Tax Register
b) Recoverable and Non-Recoverable Tax Registers
c) Single Cross Product Tax Register
d) Standard Input and Output Tax Registers

21. Perform Encumbrance Year End Procedures (Optional)
Oracle Financials provides a number of facilities for the processing of outstanding encumbrances as part of year-end processing. The default processing for Oracle Financials at year end is to extinguish any outstanding encumbrances/ unused funds when you close the last period of the Financial Year within the General Ledger application.
The carry forward process enables managers to perform any of the following:
* Carry forward encumbrances for existing transactions (purchases/requisitions).
* Carry forward encumbrances, and the encumbered budget.
* Carry forward the funds available as at the end of the year. Other facilities available:
* Use mass allocations to bring forward part of the funds available.
* Carry forward budgets into the current appropriation budget, or to a separate budget to identify between current year and carry forward amounts if required. Mass budget processing also allows you to combine these budgets. To perform Encumbrance year-end procedures, including Carry Forward, you must complete each of the following steps:
a) Open the next encumbrance year
Use the Open and Close Periods window to open the next encumbrance year.
b) Open the next budget year
Use the Define Budget window to define a budget for the next budget period.
Attention: Ensure that the budget that you use is inclusive of the periods for the next budget year that you require
Attention: Ensure that the calendar periods for the next budget year have
been created prior to running this step. Verify that the next year budget figures have been entered. If you define a new budget for the purposes of the next year budgetary control, you may also need to update the
following:
Define Budget Organizations, where you have attached the funding budget to defined
account ranges within this form.
Define Summary Accounts, where summary templates are used as the basis for the budgetary control procedures.
c) Run Year End Carry Forward
This process enables you to determine the criteria that you want to use for carrying forward your encumbrances
The year-end carry forward is normally completed in two steps:
1) Perform the Year End Carry Forward in Preview mode
2) Perform the Year End Carry Forward without selecting the Preview option
Within the Year End Carry Forward form, you can select a wide range of criteria for carrying forward balances:
* Carry Forward Rule - This rule enables you to select Encumbrances Only,
Encumbrances and the Encumbered Budget, or Funds Available as the basis for the
Carry forward
* Encumbrance Type - Select ‘All’ for all encumbrances, or select the encumbrance
type that you require i.e. Commitment, Obligation etc.
* From/To Budget and Budget Organisation- Select the budgets where they are
different
* Accounting Flexfield Ranges - Select the range of relevant accounting flexfields to
be carried forward.

for further details: contact: razashahaca@gmail.com