Showing posts with label R12. Show all posts
Showing posts with label R12. Show all posts

Wednesday, February 15, 2023

SQL Query to get Payment Process Request (PPR) Templates Used to Create a Payment Process Request (PPR) in oracle EBS R12

Query to get all AP Payments related to a PPR:-

SELECT c.*
FROM   ap_checks_all c
WHERE  c.payment_id IN (SELECT ip.payment_id
                        FROM   iby_payments_all ip
                        WHERE  payment_service_request_id IN
                               (SELECT
                               payment_service_request_id
                                                              FROM
                               iby_pay_service_requests
                                                              WHERE
                               calling_app_id = 200
                               AND
                                       call_app_pay_service_req_code =
                                       '&checkrun_name')

                              ); 




SQL Query to get Payment Process Request (PPR) Templates Used to Create a Payment Process Request (PPR) in oracle EBS R12 :-


SELECT AISCA.checkrun_name                        PPR_Name,

       apt.template_id,
       apt.template_name,
       ipmv.payment_method_name                   pmt_method_name,
       cba.bank_account_name                      bank_acct_name,
       ipp.payment_profile_name                   pmt_profile_name,
       cpd.payment_document_name                  pmt_doc_name,
       apt.pay_group_option                       pay_grp_optn,
       (SELECT Rtrim(Xmlagg(XMLELEMENT(e, apg.vendor_pay_group||
                     ',')) .extract('//text()'),
                       ',')
        FROM   ap_pay_group apg
        WHERE  apg.template_id = apt.template_id) enabled_pay_groups,
       apt.ou_group_option                        ou_grp_optn,
       (SELECT Rtrim(Xmlagg(XMLELEMENT(e, hou.short_code||
                     ',')) .extract('//text()'),
               ',')
        FROM   ap_ou_group,
               hr_operating_units hou
        WHERE  org_id = hou.organization_id
               AND template_id = apt.template_id) enabled_ous,
       apt.currency_group_option                  curr_grp_optn,
       (SELECT Rtrim(Xmlagg(XMLELEMENT(e, acg.currency_code||
                     ',')) .extract('//text()'), ',')
        FROM   ap_currency_group acg
        WHERE  acg.template_id = apt.template_id) enabled_currencies,
       apt.description                            ppp_description,
       apt.inactive_date,
       apt.addl_pay_thru_days,
       apt.addl_pay_from_days,
       apt.low_payment_priority,
       apt.hi_payment_priority,
       apt.vendor_id,
       apt.pay_only_when_due_flag,
       apt.vendor_type_lookup_code                vdr_type_lcode,
       apt.bank_account_id,
       apt.payment_profile_id,
       apt.zero_inv_allowed_flag,
       apt.payment_method_code,
       apt.inv_exchange_rate_type,
       apt.payment_date_option,
       apt.addl_payment_days,
       apt.payment_exchange_rate_type,
       apt.zero_amounts_allowed,
       apt.payables_review_settings,
       apt.calc_awt_int_flag,
       apt.payments_review_settings,
       apt.document_rejection_level_code          doc_reject_lvl,
       apt.create_instrs_flag,
       apt.payment_rejection_level_code           pmt_reject_lvl,
       apt.payment_document_id,
       plc.displayed_field                        supplier_type,
       pv.vendor_name                             payee,
       alc1.displayed_field                       template_type_name,
       gdct.user_conversion_type                  user_rate_type,
       fu.user_name
FROM   ap_payment_templates apt,
       po_lookup_codes plc,
       iby_payment_methods_vl ipmv,
       iby_payment_profiles ipp,
       ce_bank_accounts cba,
       ap_lookup_codes alc1,
       gl_daily_conversion_types gdct,
       po_vendors pv,
       fnd_user fu,
       ce_payment_documents cpd,
       ap_inv_selection_criteria_all AISCA
WHERE  1 = 1
       AND fu.user_id = apt.last_updated_by
       AND AISCA.checkrun_name = '&checkrun_name'
       AND AISCA.template_id = apt.template_id
       AND plc.lookup_code(+) = apt.vendor_type_lookup_code
       AND plc.lookup_type(+) = 'VENDOR TYPE'
       AND cba.bank_account_id(+) = apt.bank_account_id
       AND ipmv.payment_method_code(+) = apt.payment_method_code
       AND alc1.lookup_type(+) = 'PAYMENT_TEMPLATE_TYPE'
       AND alc1.lookup_code(+) = apt.template_type
       AND gdct.conversion_type(+) = apt.payment_exchange_rate_type
       AND ipp.payment_profile_id(+) = apt.payment_profile_id
       AND pv.party_id(+) = apt.party_id
       AND apt.payment_document_id = cpd.payment_document_id(+)
ORDER  BY apt.template_name,
          ipmv.payment_method_name; 

Monday, November 15, 2021

Can I assign an Operating Unit to Multiple Legal Entities?

 The short answer is sort of. Which is not much help to anyone, hopefully you will have a few moments to read on and I can explain myself. This post assumes that you understand the relationship between Legal Entities and Ledgers which I discussed in an earlier post.

In R12, a new Legal Entity Configurator was introduced in financials and Legal Entities defined here are assigned to Ledgers and/or Balancing Segments (Company Codes). However, it is not possible to assign a Financials Legal Entity to an Operating Unit, you can only define a Default Legal Context (DLC) to an Operating Unit. This assignment can cause confusion as it is only possible to assign one DLC, but I can use more than one LE in that Operating Unit. The key word in DLC is default.

Legal Entity Configurator can be accessed via 'Legal Entity Manager' responsibility.

When I am in Payables or Receivables the LE is stamped on the transactions and used to identify the Legal Owner for Legal reporting as well as Tax calculation. The invoice exists within an OU and that OU has a ledger which will account the transactions, if that has more than one LE associated with it then a hierarchy of LE derivation is used to default an LE, the last resort being the DLC.

For example, in AR the Legal Entity derivation hierarchy for transactions is

1.       Transaction Type

2.       Batch Source

Assigning a LE to a transaction type or batch source is optional and only the LE’s mapped to the Ledger associated with the OU are available to assign.

So, in R12 we have much better support for many LE accounted in a single OU as we clearly mark the LE on the transactions.

How do I define my Legal Entities?

In the real world a Legal Entity (LE) can enter into contracts, own cash (bank accounts), employ people, pay taxes, be sued and similar. In Oracle Financials Release 12, a whole new product; Legal Entity Configurator, was created to manage them. We allow you to define your real-world Legal Entities and then map them to the E-Business Suite objects and structures. Transactions are stamped with an owning (first party) Legal Entity and that will be used to drive tax, accounting, intercompany and Legal Reporting.

So, let’s look at the relationships LE have to other E-Business suite objects.

1- Accounting Structures

In the General Ledger Set Up a Legal Entity can be mapped to

·         A Single Ledger

·         One or more Balancing Segment Values (aka Company Code) within a ledger.

2 – Operating Unit

There is no explicit mapping of Legal Entity to an OU, the relationship is derived from the ledger assigned to the OU and the Legal Entity mappings to ledgers as detailed above.

So how might you set up your LE in relation to your other set up in financials? There are two implementation models

1: Many

·         LE are mapped to the Balancing Segment Value (BSV, aka Company code) within a Ledger, so multiple LE are accounted for in a ledger.

·         An OU will have one Ledger assigned so transactions for many LE are processed and accounted in a single OU

1:1:1

·         A single LE is mapped to a Ledger

·         An OU will have one Ledger assigned

·         Therefore, an OU only has one LE (that means it is easy to derive the LE given the OU)

 

So what model should you use?

That depends where the LE are registered.

The 1:M model is recommended and preferred in the US, the 1:1:1 model is recommended for most non-US regions.

SQL query to Extract Contact Points from Bill-To Site, Using AR Transaction in Oracle Fusion Cloud (AR)

  Introduction In Oracle Fusion AR, reporting requirements often go beyond basic transaction data. Business users frequently need the comp...