Monday, November 30, 2009

What is Tolerance in Payables and How to define Tolerances?

In Payables, You can set tolerance for Purchase Order Matching and Tax Override.

Purchase Order Matching/Invoice Tolerances
Use the Invoice Tolerances window to define the matching tolerances you want to allow for variances between invoice, purchase order, and receipt information. You can define both percentage-based and amount-based tolerances.

If you enter a zero for a percentage tolerance and enable the check box for that tolerance, Payables will not allow any variance at all. If you want a low tolerance, you can enter a very small percentage. If you enter no value, then Payables will allow infinite variance. If you enter an amount-based tolerance, enter all amounts in your ledger currency. If an invoice exceeds these tolerances, Invoice Validation will apply a hold to it.

Navigation Path: Payables->Setup->Invoice->Tolerances


Tax Tolerances
Tax tolerances are used to determine whether E-Business Tax places a tax hold on an invoice due to the
override of calculated tax lines.

A tax tolerance is the acceptable variance between the calculated tax amount on an invoice and the override tax amount entered by the user. If the variance between these two amounts exceeds the tolerances you specify, then E-Business Tax places the invoice on hold. To define tax tolerances, you must first set the Allow Override for Calculated Tax Lines option.

Navigation Path: Payables->Setup->Options->Payables Options->Invoice->Tax Tolerances

What is Distribution Set and How to define Distribution Sets?

Specify a distribution set for the invoice. A distribution set is a template for invoice distributions. When you specify a distribution set for an invoice, Payables automatically creates invoice distributions based on the distribution set.

There are two types distribution sets
Full Distribution Set
Skeleton Distribution Set

Creating Full and Skeleton Distribution Sets
Navigation Path: Payables->Setup->Invoice->Distribution Sets

What is Payment Terms and How to define Payment Terms?

Payables uses payment terms to automatically calculate due dates, discount dates, and discount amounts for each invoice you enter. Payment terms will default from the supplier site. If you need to change the payment terms and the terms you want to use are not on the list of values, you can define additional terms in the Payment Terms window.

Defining Payment Terms
Example: Payement Term - 10/30 Net 45
Your supplier has just notified you that they are going to offer 10% discount if you pay their invoices in 30 days. The entire invoice amount will be due in 45 days. In this case, you will set up payment terms as follows.

Navigation Path: Payables->Setup->Invoice->Payment Terms

Types of Value Sets

You can define several types of value sets depending on how you need your values to be checked. All value sets perform minimal checking; some value sets also check against the actual values, if you have provided any.

Navigation Path: System Administrator->Application->Validation->Set/Values

None - A value set of the type None has no list of approved values associated with it. A None value set performs only minimal checking of, for example, data type and length. Examples of such values include credit card numbers, street addresses, and phone numbers.

Independent - Use the validation type Independent when you know the allowable values ahead of time. Independent type value sets perform basic checking but also check a value entered against the list of approved values you define.

Dependent
- A Dependent value set is also associated with a list of approved values. In this case however, the values on the list can be grouped into subsets of values. Each subset of values is then associated with a value from an Independent value set. Once a value from the Independent value set has been specified, the list of values for the Dependent value set displays only the values that are approved for the value selected from the Independent value set.

In below picture, once a value from the Category value set has been specified, only the appropriate values from the Item value set are displayed.

Table - Table value sets obtain their lists of approved values from existing application tables. When defining your table value set, you specify a SQL query to retrieve all the approved values from the table.

Special - This specialized value set provides another flexfield as a value set for a single segment. Special value sets can accept an entire key flexfield as a segment value in a descriptive flexfield or report parameter.
Pair - This specialized value set provides a range flexfield as a value set for a pair of segments.

Translatable Independent - Translatable Independent value sets are similar to Independent value sets except that translated values can be displayed to the user. Translatable Independent value sets enable you to use hidden values and displayed (translated) values in your value sets. In this way your users can see a value in their preferred languages, yet the values will be validated against a hidden value that is not translated. A Translatable Independent value set can have only Translatable Dependent value sets dependent on it.
See Example: Appliances and Furniture can be displayed in two languages (Gerate and Mobel) or (Appareils and Meubles).

Translatable Dependent -Translatable Dependent value sets are similar to Dependent value sets except that translated values can be displayed to the user. Translatable Dependent value sets enable you to use hidden values and displayed (translated) values in your value sets. In this way your users can see a value in their preferred languages, yet the values will be validated against a hidden value that is not translated. Translatable Dependent value sets must be dependent on a Translatable Independent value set.
See Example: Appliances and Furniture can be displayed in two languages (Gerate and Mobel) or (Appareils and Meubles).  Microwave can be displayed in Mikrowellenherd or Four a micro-ondes.

MOAC in Concurrent Programs/Reporting

A new field "Operating Unit Mode" is added in the Define Concurrent Programs in the OA Framework pages. The user can query the program or report based on an operating unit by updating the "Operating Unit Mode" field with one of the following values:
  • Single
  • Multiple
  • Empty
    The default value is Empty.

    The multiple organizations context is automatically initialized by the concurrent program if the "Operating Unit Mode" is set to either Single or Multiple. The user can also select a value from the Operating Unit field's LOV in Request form when the mode is Single. The value of the "Operating Unit Mode" must be Single for a majority of the existing operating unit context sensitive reports. Example: Invoice Register report.

    In case of Multiple,  Operating Unit field in Request page will be disabled, it indicates that CP will run for all user accessible OUs. You can also define Operating Unit field as a input parameter for CP. In this case you can run CP for selected OU or for all. Example: Invoice Validation report.

    **You should not change "Operating Unit Mode" of  any reports which are owned by Oracle. Use this option for user defined reports only.

    Navigation Path: System Administrator->Concurrent->Programs Here select Request tab. There u can see "Operating Unit Mode".


    Query to check this option from back-end:

    SELECT concurrent_program_name, multi_org_category
    FROM fnd_concurrent_programs
    WHERE concurrent_program_name = '--CP short name';  Ex: 'APXINRIR'

    S-Single
    M-Multiple
    null-Empty

    Thursday, November 26, 2009

    Defaulting Operating Unit in MOAC

    1.If the profile option 'MO: Security Profile' is set and gives access to multiple Operating Units, then the profile value of 'MO: Default Operating Unit' will be defaulted, if this value is validated against the list of Operating Units in 'MO: Security Profile'. i.e. If the Operating Unit is included in the security profile then it is returned as the default value. Otherwise there is no Operating Unit default. Also, if the Profile Option 'MO: Default Operating Unit' is not set, then there is no default Operating Unit.

    2.If the profile option 'MO: Security Profile' is set and gives access to one Operating Unit, then default Operating Unit will return this value even if 'MO: Default Operating Unit' is set to a different value.

    3.If the profile option 'MO: Security Profile' is not set, then 'MO: Operating Unit' value will be used as the default Operating Unit even if 'MO: Default Operating Unit' profile is set to a different value.

    MOAC functions

    MO_GLOBAL Package
    MOAC functionality is provided through the MO_GLOBAL package (AFMOGBLB.pls).  Following are some of the more important functions and procedures in the package.

    Init() This is generally called by forms and reports to setup the list of orgs that can be accessed.  It calls the set_org_access procedure, which in turn calls populate_orgs.  This inserts the orgs a user is allowed to access in a global temporary table -- MO_GLOB_ORG_ACCESS_TMP.  The table is populated based on the MO: Security Profile and MO: Operating Unit profile option values.

    Org_security() This returns a sql predicate (where clause) that controls which records can be accessed. 
    Example:
    EXISTS (SELECT 1
                        FROM mo_glob_org_access_tmp oa
                        WHERE oa.organization_id = org_id)
    This is used in dbms_rls.add_policy to add the vpd security to synonyms.

    Check_access() Checks to see if an org can be accessed by a user.  If  access mode is M (Multiple), see if the org_id is in mo_glob_org_access_tmp.


    To Set Policy Context at VPD
    Single-org:
    Execute mo_global.set_policy_context('S',&org_id);

    Multi-org:
    Begin
    FND_GLOBAL.apps_initialize(
       l_user_id,    -- User id
       l_resp_id,    -- Responsibility Id
       200);           -- Application Id
    MO_GLOBAL.init('SQLAP');
    End;

    R12 Multi-Org Access Control (MOAC)

    'Multi-Org Access Control' popularly known as 'MOAC' in short form is a enhanced feature in Release 12. MOAC will enable users to access secured data in one or more Operating Units from a single responsibility.

    End-Users can access/transact data within several operating units based on Security Profile attached to a responsibility. i.e. End-Users can access/transact data on multiple Operating units by accessing one operating unit at a time without changing a responsibility. This Provides flexibility for end-users to work conveniently with multiple Operating Units in shared service Environments with single responsibility.

    Profile Options which take major Role in MOAC
    MO: Security Profile
    MO: Default Operating Unit(Optional)
    MO: Operating Unit(Mandatory for only Single Org or if MO: Security Profile is not defined) 


    MOAC Configuration
    1. Define Operating Units
    Navigation Path:

    2.Define Security Profile
    Navigation Path: HRMS Management responsibility->Security
    Security Profile: Allows you to assign multiple operating units for the same business group.
    Global Security Profile: Allows you to assign multiple operating units across business groups.

    Choose a Security Profile menu item.

    1.Enter a unique name for the security profile.
    2.There are 4 security types:
    • View all organizations – generally the application will not let you save a new security profile with this setting because it automatically seeds one and there is no point to create another.
    • Secure organizations by organization hierarchy and/or organization list – This lets you define a hierarchy to be accessed and to exclude operating units from that hierarchy or include them from outside the hierarchy.  You can also just list operating units without designating a hierarchy.
    • Secure organizations by single operating unit – In this case the operating unit will be determined using the operating unit specified in the MO:Operating Unit profile option.
    • Secure organizations by operating unit and inventory organizations – Here the operating unit will also be determined using the operating unit specified in the MO:Operating Unit profile option.
    To restrict access by discrete list of organizations, select 'Secure organizations by organization hierarchy and/or organization list for the Security Type'.
    3.Check the Exclude Business Group check box to remove the business group in the list of organizations.
    4.Use the Classification field to limit the LOV in the Organization Name field. For example, if you select the Classification to Operating Unit, only Operating Units would display for the LOV in the 'Organization Name' field.
    5.In the organization name field, select the Operating Unit for which you want access. Repeat this step until you have included all organizations that you need access.

         Seeded Security Profiles
    1. One for each business group that allows access to each org in the business group.  This has the same name as the business group. Since this allows access within a business group, it is in the security profile form.
    2. One that allows access to all orgs.  This is named like Global Vision. Since it allows access across business groups, it is in the global security profile form.
    So if you want to allow access to all organizations or all organizations in one business group, you can use one of the seeded security profiles.

    3.Run concurrent program "Security List Maintenance Program" from the standard request submission form. The "Security List Maintenance Program" could be preferably run for one named security profile to prevent disturbing other security profile setup.

    4.Assign MO: Security Profile
    Navigate to System Administrator Responsibility->System Profile OptionsAssign the security profile to MO: Security Profile profile option for your responsibility or user.

    5.Assign MO: Default Operating Unit(Optional)
    Navigate to System Administrator Responsibility->System Profile Options
    Assign the default Operating unit to MO: Default Operating Unit profile option for your responsibility or user.

    6.Assign MO: Operating Unit(Mandatory for only Single Org or if MO: Security Profile is not defined)
    Navigate to System Administrator Responsibility->System Profile OptionsAssign the Operating unit to MO: Operating Unit profile option for your responsibility or user.


    If both 'MO: Security Profile' and 'MO: Operating Unit' are defined at a responsibility level then 'MO: Operating Unit' will be ignored and 'MO: Security Profile' will be effective.

    Now you can see multiple operating units in below MOAC enabled form

    Wednesday, November 25, 2009

    R12 Payment Process Request(PPR) in Payment Manager

    In 11i, we used Payment Batches to pay multiple invoices same time. In R12, PPR is the replacement for 11i Payment Batches. Release 12 payment setup enables a Payment Administrator to select multiple invoices for payment by selection criteria and he can pause the invoice selection and payment build process . During the invoice selection review, payment manager can review the selected invoices, the invoices that met the criteria but were either not validated or were not approved and hence did not get included in the payment process request. He can adjust the invoice selection by adding or removing the invoices and can also review the cash requirements. While reviewing the payments, payment manager can dismiss individual documents or payments if necessary, and restart the payment build process.


    Frequently Used Terms..
    Oracle Payments
    Oracle Payments is an e-Business Suite module Payables will leverage to group invoices into payments, create instructions, and print or communicate with the bank. Payment Manager(OA page) is the function you can access it from Payables respondibilty.
    Navigation Path: Payables->Payments:Entry->Payment Manager

    Pay Run
    A business action to select multiple invoices on a regular basis to be processed for payment. This may also be referred to as creating and processing payment batches and, in this release, managing a payment process request through completion

    Payment Process Request
    The payment process request is the selection of invoices into a group for payment processing.

    Payment Instruction
    Information compiled from one or more payment process requests that is formatted and either transmitted to a financial institution for payment or used in-house to print check documents..

    Template
    Templates provide a way to store section criteria, payment attributes, and processing rules that can be reused for single pay runs or scheduled pay runs.


    Payment Manger Page
    There are five tabs under payment manger.


    1.Home
    The Home tab on Payment Manager Dashboard presents the useful information for a Payment Manager to:
    #Monitor the progress of the recent pay run processes
    #Highlight any payment processes that require attention and automatically prompt to take appropriate actions.
    #Shortcuts and Tabs for initiating, reviewing and adjusting proposed funds disbursements

    2.Templates
    Using Payment Manager dashboard, a Payment Manager can perform all the tasks associated with pay run process. In the Template tab he can click the “Create” button to create new templates. He can also query a
    template and then use it to submit or schedule the payment process requests and run cash requirements before a pay run.

    3.Payment Process Requests(PPR)
    Payment Process Requests tab can be used to submit a single payment process request or schedule the repeating payment process requests. The pending action on the payment process request can be performed
    using “Start Action” icon and the payment request can be cancelled using “Cancel” icon. Clicking on the Payment Process request name, payment manager can drill down to the details.

    #Process Automation tab in PPR
    The pay run process itself provides for processing steps that you can pause for review based on your needs. In Process Automation tab, the payment manager can specify up front whether the pay run process should
    pause for review  or if the payment process will be fully automated.  Of course, if issues arise during processing that require user input, the process will pause regardless of these options.

    ##Processing options in Process Automation tab

    ###Maximize Credits: If Maximize Credits checkbox is enabled then during invoice selection, if there is any credit for a payee, after interest and payment withholding calculations the system will group all scheduled payments for the payee site  together to be paid on one payment, and if the sum is negative, the system will reduce the credit amount so the sum is zero.
    ###Stop Process for Review After Scheduled Payment Selection
    ###Calculate Payment Withholding and Interest During Scheduled Payment Selection
    ###Stop Process for Review After Creation of Proposed Payments
    ###Create Payment Instructions option
    If the user wants immediate payment instructions creation, the user can set this option to start the payment instruction program immediately when the payment process request has a Completed status. This option has
    an additional function: It ensures that payments from this payment process request will not be combined with payments from other payment process requests when the system builds the payment instructions. 
    Or,
    the user can set the option to wait until the Payment Instruction Program is submitted, typically, in this case an enterprise would schedule the Payment Instruction Program to run periodically.  An enterprise would choose this option to take all built payments from multiple payment process requests and build fewer payment instructions.

    4.Payment Instructions
    Payment Manager can use the Payment Instructions tab to review the status of the payment instructions and if required, can perform any subsequent actions. He can also drill down into the details of the payment instruction and can void all the payments in the instruction.

    5.Payments
    Payment Manager can use the Payments tab to review the status of the payments created by his payment process requests. He can also can drill down into the details of the payments to stop or void the payments.


    Steps in Pay Run Process
    Managing a Pay Run involves 3 main processes:
    1)Selection of the invoices for payment
    2)Grouping the invoices into payments
    3)Building the payment instruction files to either print checks or send instructions to the bank.

    Follow red mark numbers in the picture to get the sequence of process steps in Pay Run Process

    Pay Run Process
    1. Invoice Selection
    After user submits PPR, the Payment Process request completes with the status “Invoices Pending Review” if it has been configured to pause after the invoice selection. Clicking on “Start Action” icon navigates the user to the  “Selected Scheduled Payments” page.

    On the “Selected Scheduled Payments” page, Payment Manager can review the total count of selected scheduled payments. Amount remaining , discounts, payment amount, and interest due can also be reviewed for each currency in the payment process request.

    The page also lists all the invoices along with their details. Payment Manager can add or remove the scheduled payments or modify the Discounts and payment amounts.

    Clicking on the “View Unselected” takes the Payment Manager to a “Unselected Scheduled Payments” page that gives the following information:
    Counts for invoices that were never validated and that failed validations
    Counts for invoices that require approval and where approval is rejected
    Counts of invoices on Scheduled Payment Hold and Supplier Site hold
    Counts where Payee total is zero or less and where Discount rate is too low
    Count of Unselected Payment Schedules, Total Amount, and Discount per currency
    List of Invoices  with invoice information and reason for not getting selected

    Payment Manager can add more Scheduled Payments by clicking on the “Add Scheduled Payments”, and choosing the search criteria for the documents payables from the list of values.

    Once the Payment Manager is done reviewing the payment process request, he can click on the “Submit” button to initiate the Payment creation process. This action also generates the Scheduled Payment Selection
    Report again.

    The Payment Process will complete with the status “Information Required – Pending Action” if certain information required for the payment creation was missing on scheduled payments. Clicking on “Start Action” icon navigates the user to the  “Complete Document Assignments” page.

    2.Grouping into Payments
    The Payment Process request completes with the status “Pending Proposed Payment Review” if it has been configured to pause after the creation of proposed payments. The payment process request also displays the count for documents that were rejected during payment creation. Clicking on “Start Action” icon navigates the user to the “Review Proposed Payments” page.

    In the Review Proposed Payments page, payment manager can review the payment information for the selected scheduled payments.

    After reviewing, payment manager can then specify the action “Run Payment Process” to submit the Payment build process. After this action, the payment process request has the status of “Assembled Payments”.

    Payment Manager can drill down to view payment details by clicking on the Payment Process request link. He can view the number of payments, documents, and Total Payment Amount per currency. Individual payments are also listed along with more information. By selecting the radio button of a payment, payment manager can view the scheduled payments that got included in that payment.

    Clicking on “Rejected and Removed Items”, Payment manager can navigate to see the details for scheduled payments that got rejected/removed.

    Rejected and Removed Items page lists the rejected document payables, and clicking on the reference number link you can view the details of the document and the reason it got rejected.

    3.Building Payment Instructions
    For creating Printed payment instructions, Payment Manager can specify the criteria for selecting payments and printing information. The criteria can include the Payment Process profile, Currency, Internal Bank Account, Payment Document, Payment Process Request, etc.

    Tuesday, November 24, 2009

    Oracle Procure to Pay Process

    I. P2P Process and Imp Stages
    II. More Detail About Each Step in the P2P Process
    III. Basic Steps to Create P2P Process

    I. P2P Process and Imp Stages



    1.Demand
    The procurement process generates and manages requests for the purchase of goods.  The demand for purchase items may be a one-time event or may recur in either predictable or random time intervals.

    2.Source
    The procurement sourcing process covers the business activities related to the search, qualification, and selection of suitable suppliers for requested goods and services.

    3.Order
    The procurement ordering process includes purchase order placement by the buying organization and purchase order execution by the supplying organization.

    4.Receive

    The receipt process acknowledges that a purchase order has been duly executed.  For orders of physical goods, it will typically include the receipt, inspection and delivery of the goods to inventory or to another designated location.  For orders of services, it will typically consist of a notification from the requester or the approving person that the service has been performed as agreed.

    5.Pay
    The payment process consists of those activities involved in the payment for ordered goods and services.


    II. More Detail About Each Step in the P2P Process
    1.Requisitions(Demand)
    Requisitions represent demand for goods or services. With online requisitions, you can centralize your purchasing department, source your requisition with the best suppliers, and ensure that you obtain the appropriate management approval before creating purchase orders from requisitions.

    Requisitions for goods and services:
    Are generated by applications like Inventory, Work in Process (WIP), Advanced Supply Chain Planning (ASCP) and Order Management
    May be entered manually through Oracle Purchasing windows
    May be entered using Oracle iProcurement
    May be imported from external systems

    With Oracle Purchasing, you can:
    Create, edit, and review requisition information on-line.
    Review the current status and action history of your requisitions. You should always know who approves requisitions and whether they are in the approval, purchasing, receiving, or delivery stage.
    Source goods from your own inventory with internal requisitions.

    2.RFQs and Quotations(Source)
    Oracle Purchasing provides you with request for quotation (RFQ), and quotation features to handle your sourcing needs.  You can create an RFQ from requisitions, match supplier quotations to your RFQ, and automatically copy quotation information to purchase orders.

    Quotations can be:
    Entered manually
    Copied from an RFQ
    Imported using the Purchasing Documents Open Interface
    Imported using the e-Commerce Gateway

    With Oracle Purchasing, you can:
    Identify requisitions that require supplier quotations and automatically create an RFQ.
    Create an RFQ with or without approved requisitions so that you can plan ahead for your future procurement requirements.
    Record supplier quotations from a catalog, telephone conversation, or response from your request for quotation.  You can also receive quotations electronically.
    Review, analyze, and approve supplier quotations that you want available to reference on purchase orders and requisitions.  You should be able to evaluate your suppliers based on quotation information.
    Receive automatic notification when a quotation or request for quotation approaches expiration.
    Review quotation information online when creating purchase orders or requisitions and copy specific quotation information to a purchase order or requisition.

    3.Suppliers
    You must define a supplier before performing most activities within Oracle Purchasing and Payables.
    You optionally enter a recommended supplier on a requisition.
    You need a supplier to issue a request for quotation.
    You use that same supplier when you enter a quotation.
    You need supplier information for purchase orders.
    You receive goods or services from suppliers.
    You return goods to suppliers.
    You must pay the supplier for the goods or services purchased.

    Set up suppliers to record information about individuals and companies you purchase goods and services from.  You can also enter employees you reimburse for expense reports.  You can designate supplier sites as pay sites, purchasing sites, RFQ only sites, or procurement card sites.  For example, for a single supplier, you can buy from several different sites and send payments to several different sites.  Most supplier information automatically defaults to all supplier sites to facilitate supplier site entry. However, you can override these defaults and have unique information for each site.

    4.Purchase Orders(Order)
    Oracle Purchasing supports four types of purchase orders:  standard, blanket, contract and planned.  There are several methods that can be used to create purchase orders.  You can manually create purchase orders or search approved requisitions and add them to purchase orders.  Standard purchase orders can be imported through the Purchasing Documents Open Interface in a status of Incomplete or Approved.  You can automate purchase document creation using the PO Create Documents workflow to automatically create a blanket purchase agreement release or a standard purchase order upon approval of a requisition.

    Once purchase orders are created, they may be submitted for approval.  The approval process checks to see if the submitter has sufficient authority to approve the purchase order.  Once the document is approved, it may be sent to your supplier using a variety of methods including: printed document, EDI, fax, e-mail, Oracle iSupplier Portal and XML.  Once the purchase order or release is sent to your supplier, they are authorized to ship goods at the times and to the locations that have been agreed upon.

    Purchase documents may be created:
    By buyers using the AutoCreate window
    By importing them using the Purchasing Documents Open Interface
    Automatically, by the Create Releases program (blanket releases)
    Automatically, by Workflow (blanket releases or standard purchase orders)

    With Oracle Purchasing, you can:
    Review all of your purchases with your suppliers to negotiate better discounts.
    Create purchase orders simply by entering a supplier and item details.
    Create standard purchase orders and blanket releases from both on-line and paper requisitions.
    Create accurate and detailed accounting information so that you charge purchases to the appropriate departments.
    Review the status and history of your purchase orders at any time for all the information you need.
    Record supplier acceptances of your purchase orders.  You always know whether your suppliers have received and accepted your purchase order terms and conditions.
    Copy existing purchase orders.
    Manage global supplier agreements (blankets and contracts) from a centralized business unit.
    Manage approved contractual terminology from a library of terms using Oracle Procurement Contracts.

    5.Receiving(Receive)
    Using Oracle Purchasing, you can process receipts from suppliers, receipts from other warehouses or inventory organizations, in-transit shipments and receipts due to customer returns.  You can search for expected receipts based on a purchase order or a customer return recorded in Oracle Order Management and then process them to their final destination whether it is inventory, expense or shop floor. Oracle Purchasing lets you control the items you order through receiving, inspection, transfer, and internal delivery.  You can use these features to indicate the quantity, quality, and internal delivery of the items you receive.

    With Oracle Purchasing, you can:
    Use routing controls at the organization, supplier, item, or order level to enforce material movement through receiving.  For example, you can require inspection for some items and dock-to-stock receipt for others.
    Define receiving tolerances at the organization, supplier, item, and order level, with the lowest level overriding previous levels.  You can define tolerances for receipt quantity, on-time delivery, and receiving location.
    Use blind receiving to improve accuracy in the receiving process.  With this option, the quantity due for each shipment does not show and quantity control tolerances are ignored. Use Express and Cascade receiving to process certain types of receipts more quickly.

    With Oracle iProcurement, you can:
    Receive orders from your desktop, bypassing the need for receiving department interaction.

    6.Invoicing(Pay)
    Once you’ve received goods or service from your supplier, you’ll also receive an invoice.  Using Oracle Payables you can record invoices in a number of different ways.

    With Oracle Payables you can:
    Enter invoices manually, either individually or in batches.
    Use the Invoice Gateway for rapid, high-volume entry of standard invoices and credit memos that are not complex and do not require extensive online validation.
    Automate invoice creation for periodic invoices using the Recurring Invoice functionality.
    Use Oracle iExpenses to enter employee expense reports using a web browser.
    Record credit card/procurement card invoices from transactions the credit card issuer sends to you in a flat file.
    Record Oracle Project related expense reports.
    Import EDI invoices processed with the Oracle e-Commerce Gateway.
    Import lease invoices transferred from Oracle Property Manager.
    Match invoices to purchase orders to ensure you only pay what you’re supposed to be paying for.

    7.Payment

    Once invoices have been validated, they can be selected for payment. Oracle Payables provides the information that you need to make effective payment decisions, stay in control of payments to suppliers and employees, and keep your accounting records up-to-date so that you always know your cash position. Oracle Payables handles every form of payment, including checks, manual payments, wire transfers, EDI payments, bank drafts, and electronic funds transfers. Oracle Payables is integrated with Oracle Cash Management to support automatic or manual reconciliation of your payments with bank statements sent by the bank. 

    With Oracle Payables, you can:
    Ensure duplicate invoice payments never occur.
    Pay only invoices that are due, and automatically take the maximum discount available.
    Select invoices for payment using a wide variety of criteria.
    Record stop payments
    Record void payments
    Review information on line on the status of every payment
    Process positive pay.

    III. Basic Steps to Create P2P Process
    1.Enter supplier information

    2.Enter Purchase Requisitions
    Create Purchase requisition (PR) for the Purchased items
    Navigation Path: Purchasing Responsibility->Requisitions->Requisitions

    Enter item details one by one. Open Distributions form and provide charge account. Go back to the main form and give it for approval.

    To check it is approved or not:
    Go to the Requisition Summary from and provide Requisition number.
    Navigation Path : Purchasing Responsibility->Requisitions->Requisition Summary

    3.Create Purchase Orders
    Create Purchase Order from the Purchase Requisition created above. We have auto-create Purchase order option to create Purchase Order (PO) from Purchase Requisition (PR). Using Auto-create also there are two Options to create Purchase order.
    Manual or Automatic

    Manual way:
    Navigation Path : Purchasing Responsibility->Auto-create Form

    Click on the form and enter Purchase Requisition (PR) number and click on Find Button. This Opens auto-create Documents form. Choose the checkbox against the each of the item and click on manual button. This opens the form New Document Form. Provide  Supplier name  and click create Button. It creates a Document Builder in Autocreate Documents Form. Choose Item one by one and click on Add to document Button. This will add each Item to Document Builder Tab. After adding all the Items click on Create button in the Bottom. This crates PO and shows message with PO Number.

    Open PO. This will be in Incomplete status. Click Shipments button and open the form. Here you can set Receipt Routing. Go to More tab in the same form. Here you can set Match Approval level. In same form click on Receiving Controls button and open the form. Here you can set receipt Routing(Direct Delivery/Inspection Required/Standard receipt).
    • Standard Routing: This process will receive the Inventory in main inventory org and you need to do a manual transfer to sub-inventory if we choose this option.
    • Direct Delivery: This process delivers the goods directly in sub-inventories.
    • Inspection required: This process requires inspection of goods before receiving the goods in the inventory org.
    After you did all above changes, click on Approve button to approve the PO. If PO is approved then we can receive inventory against this PO.

    Automatic way:
    Navigation Path: Purchasing Responsibility->Auto-create Form

    Click on the form and enter Purchase Requisition (PR) number and click on Find Button. This Opens auto-create Documents form. Choose the checkbox against the each of the item and click on Automatic button.
    It opens the New Documents form. Click on Create Button. It creates a new PO with status of Incomplete. Perform required modification to the Match Approval Level and Receipt Routing. Approve PO.

    You can also create PO without matching Purchase Requisition (PR).

    4.Create  Receipts(When you receive inventory against PO)
    Navigation Path: Purchasing responsibility->Receiving->Receipts

    Click on the Receipts Form and enter the PO Number and click on find button. Receipt Header Form Opens(Keep New receipt redio button checked). Click on Receipts form. Select all Items on the Left-hand side check Box and Save the record. Click on the Header Button to note down the Receipt Number.

    5.Auto-Create Supplier Invoice
    We have to run Pay on Receipt Program to create self Billing Invoices for Receipts we created.

    Navigation Path: Purchasing Responsibility->Requests

    Run CP for Pay on Receipts Autoinvoice Program. Provide Receipt number in parameters windo of CP. Check the output and note down Invoice Number that has beed created.

    6.Create PO Match Invoice
    Navigation Path: Payables responsibility->Invoices->Invoices

    Provide invoice header level information in invoice workbench. Click on Match button. Provide PO Number and click find. Here select match check box for shipments you want to match to Invoice. Click Match button. This creates distributions for selected shipments. Open Actions form and validate and approve the invoice.

    7.Invoice Accounting
    From Invoice workbench, open Actions form and select Create Accounting. This creates accounting entries for invoice. Click on Tools Menu and view Accounting to view the accounting entries Created.

    8.Payment
    Click on Actions Button from the Invoice Screen to make Payment for the Invoice. In Invoice Actions Button enable Pay in full check Box and click Ok. Payments Window opens up. Choose the Type as Quick and choose the Bank account and Document Type and save the Record. Payment Document Generated for this record.

    9.Payment Accounting
    We need to Account for the Check Payment what have been made.

    Navigation Path: Accounts Payables->Payments->Entry->Payments

    Click on the Payment form and Query for the Document Number. Click on Actions Button and Enable the Create Accounting Check Box and Click Ok button. Click on Tools Menu to view the Accounting Entries created for the Payment

    Purchase Order Types

    Purchasing provides the following purchase order types: Standard Purchase Order, Planned Purchase Order, Blanket Purchase Agreement, and Contract Purchase Agreement.

    Standard Purchase Orders
    You generally create standard purchase orders for one-time purchase of various items. You create standard purchase orders when you know the details of the goods or services you require, estimated costs, quantities, delivery schedules, and accounting distributions.

    Blanket Purchase Agreements
    You create blanket purchase agreements when you know the detail of the goods or services you plan to buy from a specific supplier in a period, but you do not yet know the detail of your delivery schedules. You can use blanket purchase agreements to specify negotiated prices for your items before actually purchasing them. Blanket purchase agreements can be created for a single organization or to be shared by different business units of your organization (global agreements).

    Contract Purchase Agreements
    You create contract purchase agreements with your suppliers to agree on specific terms and conditions without indicating the goods and services that you will be purchasing. You can later issue standard purchase orders referencing your contracts.

    Planned Purchase Orders
    A planned purchase order is a long-term agreement committing to buy items or services from a single source. You must specify tentative delivery schedules and all details for goods or services that you want to buy, including charge account, quantities, and estimated cost.

    Monday, November 23, 2009

    Accounting and Reconciliation Reports in AP

    • Accounts Payable Trial Balance Report
    • Accounts Payable Negative Supplier Balance Report
    • Period Close Exceptions Report
    • Posted Invoice Register
    • Posted Payment Register
    • Unaccounted Transactions Report

    Accounts Payable Trial Balance Report
    Use the Accounts Payable Trial Balance Report to verify that total accounts payable liabilities in Payables equal those in the general ledger. To reconcile these balances you can compare the cumulative total liability provided by this report with the total liability provided by your general ledger. The Accounts Payable Trial Balance report is a Payables-specific version of the Open Account Balances Listing report. By running this report from Payables, you can run this report for a specific operating unit.

    Accounts Payable Negative Supplier Balance Report
    The Accounts Payable Negative Supplier Balance report allows you to run a Payables-specific version of the Open Account Balances Listing report. By running this report from Payables, you can view the negative supplier balances for a specific operating unit.

    Period Close Exceptions Report
    Submit this report to review a complete list of exceptions that are preventing you from closing a Payables accounting period. This report lists, for each organization within the ledger, the following exceptions:
    • Outstanding Payment Batches
    • Accounting Entries not Transferred to General Ledger
    • Bills Payable Requiring Maturity Event and Accounting
    • Unaccounted Invoices
    • Unaccounted Payments

    Posted Invoice Register
    Use the Posted Invoice Register to review accounting lines for invoices that have been transferred to your general ledger. Because it presents amounts that have been charged to liability accounts, this report is valid only for an accrual ledger.

    The Posted Invoice Register is primarily a reconciliation tool. Use this report along with the Posted Payment Register and the Accounts Payable Trial Balance Report to reconcile balances between Payables and your general ledger. To make their output easier to read, each of these reports can be generated for a single liability account. For example, if you are using Automatic Offsets and the liability for your invoices is allocated across multiple balancing segments, then you can use the Liability Account parameter to limit your reports to a single balancing organization.

    You can generate the report in summary or in detail. When generated in detail, the report displays invoices charged to liability accounts and the accounting information that has been transferred to the general ledger. Also included is the supplier and amount information for each invoice listed. Payables displays the total invoice amount in the invoice currency, and the transferred distribution amount in both the invoice currency and accounted currency for easier reconciliation with your general ledger.

    Posted Payment Register
    Use the Posted Payment Register to review accounting lines for payments that have been transferred to general ledger. Because it presents amounts that have been charged to liability accounts, this report is valid only for an accrual ledger. You can submit the Posted Payment Register for one payment journal entry batch or all payment journal entry batches.

    The Posted Payment Register is primarily a reconciliation tool. Use this report along with the Posted Invoice Register and the Accounts Payable Trial Balance Report to reconcile balances between Payables and your general ledger. To make the output easier to read, each of these reports can be generated for a single liability account. For example, if you are using Automatic Offsets and the liability for your invoices is allocated across multiple balancing segments, then you can use the Liability Account parameter to limit your reports to a single balancing organization.

    You can generate the report in summary or in detail. When generated in detail, the report displays payments that relieve liability accounts and that have had their accounting information transferred to the general ledger. Also included is the supplier and amount information for each payment listed. Payables displays the payment amount in the entered currency and the liability amount relieved in the accounted currency. In detail mode, the report also displays the payment document and disbursement type for each batch of payments. It provides a report total and subtotals for each payment document and bank account.

    Unaccounted Transactions Report
    Use this report to identify and review all unaccounted invoice and payment transactions and see the reason that Payables cannot account for a transaction. Payables sorts the report by transaction type (invoice or payment), exception, supplier, transaction currency, and transaction number. Run this report after you create accounting entries. The report will then show only transactions that had problems that prevented accounting. You can then correct the problems and resubmit the accounting process. Note that this report does not include invoices that have no distributions.

    R12 Trial Balance report in AP and Reconciling AP to GL

    Trial Balance report in AP
    In R12, there are 4 Concurrent Programs related to the trial balance.

    1.Report Name = "Accounts Payable Trial Balance (Old) "  Short Name = APXTRBAL
     This is the R11i Accounts Payable Trial Balance, it should be disabled in R12.

    2.Report Name = "Accounts Payable Trial Balance"  Short Name = APTBRPT
    This is the R12 Accounts Payable Trial Balance, this is the correct report name to run if Trial Balance Remodel Phase 4 or higher has been applied.  This report is a modified version of the Open Account Balance Listing report.

    3.Report Name = "Open Account Balance Listing"  Short Name = XLATBRPT
    This is a Subledger Accounting report.  This report should NOT be used for Payables.  Instead, use the applicable Payables modified version of the report.

    4.Report Name = "Open Account AP Balance Listing"  Short Name = XLAAPRPT
    This is the subledger Open Account Balance Listing report modified for Payables and should be used with Trial Balance Remodel Phases 1 - 3.

    Note: Currently, the Trial Balance documentation and notes refer to the Accounts Payable Trial Balance and Open Account AP Balance Listing report interchangeably.  The name change was due to a change in Phase 1 - 3, going forward all Payables Trial Balance patches should retain the name "Accounts Payable Trial Balance".  Please make sure you run the correct report based on your Trial Balance remodel phase and do NOT run the Open Account Balance Listing report for Payables.

    Reconciling AP to GL
    1.Run Accounts Payables Trial Balance report for current period with following details:
    • Start Date = Begin Date for first period you started using Oracle (This parameter is hidden as of Trial Balance Remodel phase 4, with default date 01-Jan-1950)
    • As of Date = End Date for Period to be reconciled
    • Show Transaction Detail = Yes
    • Include Write Offs = No
    • Include SLA Manuals/Other Sources = Yes (This parameter is only applicable for the "Group by Account, Summary" template.
         Select report template
    • Accounts Payables Trial Balance - Group by Account, Detail
    • Accounts Payables Trial Balance - Group by Account, Summary

    2.Run Invoice and Payment posting reports.
    Payables Posted Invoice Register
    Payables Posted Payment Register

    3.The correct method for reconciling AP to GL is as follows:

    Last Months Accounts Payable Trial Balance 
       + This months Payables Posted Invoice Register
            - This months Payables Posted Payment Register
                         = This months Accounts Payable Trial Balance


    Note: The Accounts Payable Trial Balance report output shows a GL total. That GL total includes manual and non Liability class entries from the Payables subledger, and non-Payables source entries in GL. Use the given method to reconcile, and the Trial Balance amount remaining total should equal the GL total excluding the manual and non Liability class entries from the Payables subledger, and non-Payables source entries in GL.

    Source=>
    Refer Note 553484.1 on R12 Steps In Reconciling AP to GL Balance
    Refer Note 823043.1 on R12 Steps In Reconciling GL Balance And AP And PO

    Saturday, November 21, 2009

    R12 Subledger Accounting (SLA)

    What is Subledger Accounting?
    #Subledger Accounting is a Service, not an Application.
    #There are no SLA responsibilities and there is no direct login to SLA.
    #SLA forms and programs are embedded within standard Oracle Application responsibilities(e.g. Payables Manager).

    o Simply, It is a rule-based accounting engine, toolset & repository supporting Oracle E-Business Suite modules.
    o Allows multiple accounting representations for a single business event, resolving conflicts between corporate and local fiscal accounting requirements.
    o Retains the most granular level of detail in the subledger accounting model, with different summarization options in the General Ledger, allowing full auditability and reconciliation.
    o Introduces a common data model and UI across subledgers, replaces various disparate 11i setups, providing single source of truth for financial and management analysis.


    Screen shots of sample Invoice Distribution and It's Accounting Journal Entries




    Simple Illustration on Journal Line Creation in SLA
    Please go thorough the AMB components explained below to understand more about this picture.



    What is Accounting Methods Builder(AMB) in SLA?
    A set of screens which provides flexibility to create your own subledger accounting set up or use seeded subledger accounting setup.

    You can use the AMB to define the way in which subledger transactions are accounted. This enables you to create and modify subledger journal line setups and application accounting definitions. These definitions define the journal entries that enable an organization to meet specific fiscal, regulatory, and analytical requirements. These definitions are grouped into subledger accounting methods and assigned collectively to the ledger.

    Following picture shows hierarchy of the components in the AMB.

    o Each ledger is assigned with SLAM.
    o Subledger accounting method(SLAM) which tells what type of accounting method you are using(Ex: Cash or Accrual) in your ledger.
    o Under SLAM, you will find set of Application Accounting Definitions(AAD) for different subledgers(Ex: Payables, Receivables) 
    o Under AAD, you will find set of journal line definitions(JLD) for each Event Class(Ex: Invoices, Prepayments, Payments) and Event Type(Ex: Invoice Validated, Prepay Application, Payment Created) combination. 
    o Each journal line definitions(JLD) holds group of JLT's(Ex: Name it Liability, Item Expense, Gain, Loss, etc), ADR(rules), JED(description) for each Event Class and Event Type combination.
        o Journal Line Types(JLT) contains..
    1. Accounting Attributes(Ex: Accounting Date, Entered Amount, Accounted Amount, Party Id, etc )
    2. Basic Info which determines journal line properties( Ex: Side(Cr or Dr), Balance Type(Actual or Encum), TransferToGL(Summary or Detail), etc)
    3. Conditions(This condition need to be satisfied to use this JLT)
        o Account Derivation Rules(ADR) (Ex: Accounting segment values. It is nothing but GL account)
       
    o Journal Entry Descriptions(JED): Which give more information about transaction (Ex: Invoice/Check details)



    Navigation Paths to SLA Forms




    Explain AMB Components?
    Event Model(Definition of the subledger transaction types and lifecycle)

    Event Entities
    Group event classes into technical transaction models called event entities. For example, group the event classes Invoices and Prepayments into the event entity Invoices because both classes of transaction are stored in the Payables invoice transaction table (AP_INVOICES_ALL). Event entities enable you to treat events for a single transaction model in the same way. The event entity often logically corresponds to a single document used as a basis for several related transactions.




    Event Class
    Group accounting event types into user-orientated transaction categories called event classes. For example, group the event types Invoice Approved, Invoice Adjusted, and Invoice Canceled into the event class Invoices. Then assign AMB components, such as journal line types, by event class within the application accounting definition. This assignment simplifies setup when the accounting requirements for all event types in a class are the same. Also, sources assigned to an event class are available for the accounting of all event types in that event class.


    Example
    Payables: Invoice, Debit Memo, Prepayment, Payments, Refunds
    Receivables: Invoice, Deposit, Receipt, Bill Receivable


    Event Type
    Each accounting event should be represented by an accounting event type. These types are registered in the AMB. When subledger journal entries need to be created, the event type determines which application accounting definitions should be used to process the accounting event. Application accounting definitions created in the AMB determine the lines, descriptions, accounts, and other elements of subledger journal entries.


    Example
    AP Invoice Events: Validated, Adjusted, Cancelled
    AR Receipt Events: Created, Applied, Unapplied, Updated, Reversed



    Subledger Accounting Method(SLAM)
    The subledger accounting method(SLAM) is a collection of accounting definitions for all the applications that you will be generating accounting for. Each primary and subledger level or adjustment secondary ledger is associated with a SLAM, which determines the accounting rules and standards that will be applied when generating entries for that ledger.

    Example:
    Standard Accrual, Standard Cash, etc

    Application Accounting Definition(AAD)
    Use Application Accounting Definitions(AADs) to assign journal line definitions and header descriptions to event classes and event types. AADs must be included in a subledger accounting method and assigned to a ledger. You can group accounting definitions from multiple products, such as Oracle Payables, receivables Assets into a single accounting method.


    Journal Line Definition(JLD)
    Journal line type, description, account derivations rules grouped together as a journal line definition to create the rule for particular event type.


    Journal Line Type(JLT)
    -Identify the natural side:  Debit, Credit, Gain/Loss
    -Determine the accounting class
    -Set under which conditions the rule will create a line
    -Define the values needed for entry line generation, such as amount, currency, conversion rate information
    -Control behavior for certain features i.e. multi period accounting, business flows, line merging and summarization



    Account Derivation Rules(ADR)
    Account derivation rules are used to determine the account combinations for subledger journal entries. You can define various rules in te AMB to determine how a journal entry account is derived. You can derive accounts segment by segment or as a complete account combination. This picture shows an Account Derivation Rule with conditional logic. If the condition holds for priority 1, then this source (Invoice Liability Account) is used. If not, SLA uses the source for priority 2(If it is available).



    Journal Entry Description
    This is useful in finding the actual transaction object details(Ex: Invoice/Payment details from journal line) 


    Transaction Object
    Example for transaction objects:
    ap_invoice_extract_details_v.xdf
    ap_invoice_extract_header_v.xdf
    ap_payment_extract_details_v.xdf
    ap_payment_extract_header_v.xdf
    ap_prepayapp_extract_details_v.xdf
    ap_system_parameters_extract_v.xdf

    Transaction Object is nothing but a view which fetches all transaction information required to create journal line for particular event class. AP_INVOICE_EXTRACT_HEADER_V, AP_INVOICE_EXTRACT_DETAILS_V are transaction objects for event class Invoices. So, accounting for all invoice type events get transaction information from these transaction objects.


    Sources
    Each column in the transaction object is defined as Source in the AMB. AMB uses these sources to get transaction information from Transaction Objects.


    Accounting Attributes
    Sources are mapped with Accounting Attributes. Accounting Attributes are bridge between JLT and Sources. 


    Example
    GL Date, Entered Currency Code, Entered Amount, Accounted Amount, Conversion Rate Date, Conversion Rate Type, Conversion Rate, Distribution Type, Party Type, Party Identifier, Party Site Identifier



    What are the important tables in SLA Accounting?
    The XLA_EVENTS table stores records for accounting events generated by subledger applications. Each product team populates this table by calling Subledger Accounting API and the respective product team will decide when this table is to be populated during the transaction life cycle.

    The XLA_AE_HEADERS table stores subledger journal entries. There is a one-to-many relationship between accounting events and journal entry headers.

    The XLA_DISTRIBUTION_LINKS table stores detailed distributions for journal entries. This table stores the data at most granular level and represents data contained in respective subledger product’s distribution tables. The detailed distributions stored in this table are merged into accounting lines and stored in XLA_AE_LINES table. Subledger Accounting uses this table for processing reversals and business flows.

    The XLA_AE_LINES table stores the subledger journal entry lines. There is a one-to-many relationship between subledger journal entry headers and subledger journal entry lines. This table will store at least one row for debit and one row for credit for each accounting entry created. If multiple debit or credit journal entry lines exists for any specific event type and if the journal line type allows merge matching lines then these lines will be merged into single line. The unmerged granular level of detail for each accounting line will be available in XLA_DISTRIBUTION_LINKS table.


    What are the Accounting Methods seeded in SLA?
    Standard Accrual
    Standard Cash
    Encumbrance Accrual and Encumbrance Cash
    United States Federal
    China Standard Accrual


    What are the reports available in SLA?
    Journal Entries Report
    Account Analysis Report
    Third Party Balances Report
    Period Close Exceptions Report
    Open Account Balances Listing

    Wednesday, November 18, 2009

    Types of Invoices in Payables


    What are all different Journal Entry Types available in GL?

    Within Oracle General Ledger, you can work with the following types of journal entries:
    Manual Journal Entries: The basic journal entry type is used for most accounting transactions. Examples include adjustments and reclassifications.
    Reversing Journal Entries: Reversing journal entries are created by reversing an existing journal entry. You can reverse any journal entry and post it to the current or any future open accounting period.
    Recurring Journal Entries: Recurring journal entries are defined once, then are repeated for each subsequent accounting period you generate. You can use recurring journal entries to define automatic consolidating and eliminating entries. Examples include intercompany debt, bad debt expense, and periodic accruals.
    MassAllocations: MassAllocations are journal entries that utilize a single journal entry formula to allocate balances across a group of cost centers, departments, divisions or other segments. Examples include rent expense allocated by headcount or administrative costs allocated by machine labor hours.

    Using Secondary Ledgers for Consolidated Reporting

    Use secondary ledgers for consolidated reporting to prevent the need to perform balance transfer consolidations, and to obtain a cross-company view of your enterprise. For example, assume the two accounting setups described in the following picture defined for the company's legal entities. The France legal entity uses a primary ledger for corporate accounting purposes and a secondary ledger for statutory reporting purposes. Both ledgers use different charts of accounts and accounting calendars. The US subsidiary uses its own chart of accounts and currency to account for its transactions in its main record-keeping ledger, the primary ledger.



    For ease of consolidation, the US subsidiary can assign a secondary ledger to its primary ledger. The secondary ledger should use the same chart of accounts, accounting calendar, and currency as the parent entity, France. Then, by using a ledger set to group the secondary ledger of the US subsidiary with the primary ledger of the parent entity, consolidated results can be obtained by simply running an FSG report using the ledger set. This prevents the need to perform balance transfer consolidations every period.

    Primary Ledger Vs Secondary Ledger Vs Reporting Currency

    Primary Ledger Vs Secondary Ledger
    Use secondary ledgers for supplementary purposes, such as consolidation, statutory reporting, or adjustments for one or more legal entities within the same accounting setup. For example, use a primary ledger for corporate accounting purposes that use the corporate chart of accounts and subledger accounting method, and use a secondary ledger for statutory reporting purposes that use the statutory chart of accounts and subledger accounting method. This allows you to maintain both a corporate and statutory representation of the same legal entity's transactions in parallel.

    Reporting Currency Vs Secondary Ledger
    Reporting Currencies are not the same as secondary ledgers. Looking at the 4 C's that define a ledger, we have a chart of accounts, calendar, accounting method, and currency. If you only need multiple currencies to support your reporting requirements, use reporting currencies. If you need to account for your data using different calendars, charts of accounts, accounting methods in addition to currency, use a secondary ledger.

    What is Reporting Currency and It's Coversion Levels

    Reporting Currencies are integrated with ledgers. You specify the reporting currency as a part of the ledger with which you are working. Using Reporting Currency, you can maintain additional currency representations of your primary ledger at three different levels:
    - Balance level
    - Journal level
    - Subledger level

    Balance level maintains translated balances. Every time you run translation in General Ledger, balances are stored in a balance level reporting currency.

    Journal level, is a currency representation of only your GL journals and balances. Every time you post a journal in GL, the journal will be converted to one or more journal level reporting currencies.

    Subledger level is a complete currency representation of your subledger transactions, GL journals entries and balances.

    What is ASM(Accounting Setup Manager)?

    It is central place for defining and maintaing accounting setup for following:
    1.Legal Entities
    2.Operating Units
    3.Ledgers(Primary and Secondary)
    4.Reporting Currencies
    5.Subledger Accounting
    6.Intercompany and Intracompany balancing
    7.Sequencing

    Secondary Ledger and it's Conversion Levels

    Additional ledgers to the primary ledger called Secondary Ledgers. They can optionally be assigned to an accounting setup to maintain multiple accounting representations for the same legal entity.

    Each secondary ledger can be maintained at one of the following data conversion levels:
    Subledger level secondary ledger maintains subledger journals, general ledger journal entries, and balances in the additional accounting representation. This data conversion level uses both Subledger Accounting and the General Ledger Posting program to create the necessary journals in both the primary and secondary ledgers simultaneously. Subledger Accounting creates the journal entries from subledger transactions if the subledger integrates with Subledger Accounting. General Ledger Posting creates the journal entries for all other transactions that do no integrate with Subledger Accounting, including manual journal entries.

    Journal level secondary ledger maintains primary ledger journal entries and balances in an additional accounting representation. This type of secondary ledger is maintained using the General Ledger Posting program. Every time a journal is posted in the primary ledger, the same journal can be automatically replicated and maintained in the secondary ledger for those journal sources and categories that are set up for this behavior.

    Balance level secondary ledger maintains primary ledger account balances in another accounting representation. This type of secondary ledger requires Oracle General Ledger Consolidation to transfer primary ledger balances to this secondary ledger.

    Adjustments only secondary ledger level is an incomplete accounting representation that holds only adjustments. The adjustments can be manual adjustments or automated adjustments from Subledger Accounting. This type of ledger must share the same chart of accounts, accounting calendar/period type combination, and currency as the associated primary ledger. To obtain a complete secondary accounting representation that includes both the transactional data and the adjustments, use ledger sets to combine the adjustments-only secondary ledger with the primary ledger when running reports.

    Foreign Currency Concepts: Conversion, Revaluation, Translation

    What is Conversion?
    Conversion refers to foreign currency transactions that are immediately converted at the time of entry to the ledger currency of the ledger in which the transaction takes place.

    Whtat is Revaluation?
    Revaluation adjusts liability or asset accounts that may be materially understated or overstated at the end of a period due to a fluctuation in the exchange rate between the time the transaction was entered and the end of the period.

    What is Translation?
    Translation refers to the act of restating an entire ledger or balances for a company from the ledger currency to a foreign currency.
    Related Posts Plugin for WordPress, Blogger...