Flexfield Qualifiers and Segment Qualifiers

Qualifiers are of two types. Flexfield Qualifiers and Segment Qualifiers

Flexfield Qualifiers: Flexifield Qualfiers are used to assign a property to the segment colums which are used to determine the behaviour of CHART OF ACCOUNTS(COA).

Segment Qualifiers: Segment Qualifiers are based on flexfield qualifiers. It is used to assign a property to the value of a segment.

A flexfield qualifier identifies a particular segment of a key flexfield. Usually an application needs some method of identifying a particular segment for some application purpose such as security or computations. However, since a key flexfield can be customized so that segments appear in any order with any prompts, the application needs a mechanism other than the segment name or segment order to use for segment identification. Flexfield qualifiers serve this purpose. You can think of a flexfield qualifier as an "identification tag" for a segment.

For example, your Oracle General Ledger product needs to be able to identify which segment in the Accounting Flexfield contains balancing information and which segment contains natural account information. Since you can customize the Accounting Flexfield so that segments appear in any order with any prompts, Oracle General Ledger needs the flexfield qualifier to determine which segment you are using for natural account information. When you define your Accounting Flexfield, you must specify which flexfield qualifiers apply to which segments. Other applications, such as Oracle Human Resources, also use flexfield qualifiers. Oracle Human Resources uses flexfield qualifiers to control who has access to confidential information in flexfield segments.

A segment qualifier identifies a particular type of value in a single segment of a key flexfield. In the Oracle Applications, only the Accounting Flexfield uses segment qualifiers. You can think of a segment qualifier as an "identification tag" for a value. In the Accounting Flexfield, segment qualifiers can identify the account type for a natural account segment value, and determine whether detail posting or budgeting are allowed for a particular value. It is easy to confuse the two types of qualifiers. You should think of a flexfield qualifier as something the whole flexfield uses to tag its pieces, and you can think of a segment qualifier as something the segment uses to tag its values.

Employee as a supplier in Oracle Payables R12

Not able to create employee as supplier.

Reason: In Create Supplier page, there is only one option"Supplier Type = Standard Supplier".

To Enable this,
Go to System Administrator responsibility,  Navigate to Application->Menu
Query Menu name "POS_HT_SP_FULL_ACCESS_MENU"

You can see the function "Create/Update employee supplier details" is not granted to this menu(Grant Check box is unchecked).

Check this option and save the form.                                                             

Go back to the Create Supplier page, Now you can see Supplier Type field populated by  two values

1) Standard Supplier
2) Supplier to used to process expense payments to internal employee

R12 Supplier Bank Accounts-More Technical by LT Solutions

The data model for storing Banks and Bank Account information has changed for this release of the Oracle Applications Suite. Banks and their Branches are now each stored as Parties (in HZ_PARTIES) in their own right. They are linked together through Relationships (in HZ_RELATIONSHIP). There is a separate link for both Bank to Branch and also from Branch to Bank. The Bank Accounts themselves are now stored in the new Oracle Payments Application. All tables are prefixed with the Application Short Name, IBY. The bank accounts themselves are stored in the IBY_EXT_BANK_ACCOUNTS table. The bank_id and branch_id fields link the Bank Account to the relevant Bank and Branch Parties in the HZ_PARTIES table.

Now, linking the Bank Account to the relevant Supplier is a bit more involved. The table IBY_ACCOUNT_OWNERS can be used to identify the Supplier Party (using the ext_bank_account_id to link the 2 IBY tables) that the Bank Account belongs to. Identifying the Supplier Site that the Bank Account is actually attached to is a little bit trickier!  This is done through linking together the following tables IBY_EXTERNAL_PAYEES_ALL and IBY_PMT_INSTR_USES_ALL. A record is created in the Payment Instrument Uses table IBY_PMT_INSTR_USES_ALL for each assignment of a Bank Account. This record is linked to the bank account by matching the ext_bank_account_id to the instrument_id. Now, each Instrument Record links to an External Payee Record held in IBY_EXTERNAL_PAYEES_ALL using the ext_pmt_party_id. It is the External Payee Record that links us to a Supplier Party ID (payee_party_id), Supplier Party Site ID (party_site_id) and Supplier Site ID (supplier_site_id). There is a record stored in the IBY_EXTERNAL_PAYEES_ALL table for every Supplier Site defined and for the supplier itself (Bank Accounts can be defined at supplier level too). The IBY_PMT_INSTR_USES_ALL is a pointer to the specific Site/Supplier that the Bank Account has been assigned to.

As an added complexity in R12, links to Suppliers are now created in the TCA. Suppliers have a Party Record and Supplier Sites have Party Site Records. As part of this functionality shift, Suppliers and
their Sites have now moved to AP_SUPPLIERS and AP_SUPPLIER_SITES_ALL (although the unique keys are still called VENDOR_ID and VENDOR_SITE_ID respectively!!). The old PO tables
used in 11i and before are now created as views which link the Supplier Records to their related TCA records (i.e. PO_VENDORS links AP_SUPPLIERS with HZ_PARTIES and PO_VENDOR_SITES_ALL links AP_SUPPLIER_SITES_ALL with HZ_PARTY_SITES).

The following query gives you the links required for matching a Bank Account to its Supplier Site Record (This will have to be updated if the Bank Accounts is assigned directly to the Supplier rather
than the supplier site):

SELECT party_supp.party_name supplier_name
,      aps.segment1          supplier_number
,      ass.vendor_site_code  supplier_site
,      ieb.bank_account_num
,      ieb.bank_account_name
,      party_bank.party_name bank_name
,      branch_prof.bank_or_branch_number bank_number
,      party_branch.party_name branch_name
,      branch_prof.bank_or_branch_number branch_number
FROM   hz_parties party_supp
,      ap_suppliers aps
,      hz_party_sites site_supp
,      ap_supplier_sites_all ass
,      iby_external_payees_all iep
,      iby_pmt_instr_uses_all ipi
,      iby_ext_bank_accounts ieb
,      hz_parties party_bank
,      hz_parties party_branch
,      hz_organization_profiles bank_prof
,      hz_organization_profiles branch_prof
WHERE  party_supp.party_id = aps.party_id
AND    party_supp.party_id = site_supp.party_id
AND    site_supp.party_site_id = ass.party_site_id
AND    ass.vendor_id = aps.vendor_id
AND    iep.payee_party_id = party_supp.party_id
AND    iep.party_site_id = site_supp.party_site_id
AND    iep.supplier_site_id = ass.vendor_site_id
AND    iep.ext_payee_id = ipi.ext_pmt_party_id
AND    ipi.instrument_id = ieb.ext_bank_account_id
AND    ieb.bank_id = party_bank.party_id
AND    ieb.bank_id = party_branch.party_id
AND    party_branch.party_id = branch_prof.party_id
AND    party_bank.party_id = bank_prof.party_id
ORDER BY party_supp.party_name 
,        ass.vendor_site_code

Invoice Match to PO and Invoice Match to Receipt by Srinivasa Rao

Oracle Payables shares purchase order information from your purchasing system to enable online matching with invoices. Invoiced or billed items are matched to the original purchase orders to ensure that you pay only for the goods or services you ordered and/or received. If you are billed for an item over the amount and quantity tolerances you define in the Invoice Tolerance window, during Approval, Oracle Payables applies a hold to the invoice, which prevents payment.

Oracle Payables supports three levels of matching which verify that purchase order and invoice information match within defined tolerances.

>>Match Approval Level: 2-Way , 3-Way, 4-Way.

In 2-way: what ever you have ordered for the PO you will make the payment for the suppliers in 2- way i.e we will compare two documents PO and Invoice. 2-way matching verifies that Purchase order and invoice information match within your tolerances:
Quantity billed <= Quantity Ordered
Invoice price <= Purchase order price
Eg:Suppose we Had given PO for 100 items ,for that we will receive invoice for 100 items. so that we will make payment for that 100 items.

In 3-Way you will compare 3 documents i.e PO+reciept+Invoice. 3-way matching verifies that the receipt and invoice information match with the quantity tolerances defined:
Quantity billed <= Quantity received.
Eg:Suppose we have ordered 100 items in PO. But we had received only 75 items ,But we had received invoice for 100 items. so, we will make payment for only 75 items.

In 4-Way you will compare 4 documents i.e PO+Receipt+Invoice+Inspection. 4-way matching verifies that acceptance documents and invoice information match within the quantity tolerances defined:
Quantity billed <= Quantity accepted.
Eg:Suppose we have 100 items in PO. Suppers send us 75 items We will do inspection on those items what ever we have received, If 15items got damaged. finally, we are going to make payment to the 60 items only.

When you match to a purchase order, Payables automatically checks that the total of PO_DISTRIBUTIONS.QUANTITY_ORDERED = AP_INVOICE_DISTRIBUTIONS.QUANTITY_INVOICED (2-way matching). Payables only checks QUANTITY_RECEIVED (3-way matching) if the RECEIPT_REQUIRED_FLAG is set to Y and only checks QUANTITY_ACCEPTED (4-way matching) if the INSPECTION_REQUIRED_FLAG is set to Y.

>>Invoice Match Option:
The Invoice Match Option determines whether or not you intend to match invoices for this supplier against purchase orders or receipts.

Invoice Match option to PO Match:
•Payables must match the invoice to the purchase order.
•If the Invoice is matched to a PO rather than to the Receipt when the AP team do a match they have the full PO available to match rather than just the specific lines on the PO that were received.
•There is a possibility someone in payables matching to the wrong distribution if they use Match to PO.
•The accrual is valued at the PO exchange rate date.

Invoice Match option to Receipt Match:
•Payables must match the invoice to the receipt.
•Receipt Match Option is recommended if you want accounting to use exchange rate information based on the receipt date or if you want to update exchange rate information on the receipt.
•If you use the match to receipt option AP team can't match until the goods are received. If the receiving doesn't happen there is no way to associate the invoice with the PO.
•Invoice processing will be on hold till a receipt is entered into the system.
•Receipt Match option determines the cost with more accuracy i.e. Match to Material item receipt and link other invoice charges to receipt and You can now also associate freight, tax, and miscellaneous charges from invoices to the related receipt.
•Run the Matching Detail Report from Other -> Request -> Run. This report will show you detail of how an invoice, purchase order, or receipt was matched. This report is especially helpful when an invoice is on hold and you are trying determine why the hold was placed.

The Invoice Match Option defaults from the Supplier Sites window. You can change the Invoice Match Option on the shipment until you receive against the shipment.
 
Financial Options - Invoice Match Option:
For purchase order shipments, indicate whether you want to match invoices to purchase orders or to purchase order receipts. If the supplier was created automatically during Expense Report Import, the default value is Purchase Order, and you can change it to Receipts as appropriate.

The decision to set the Invoice match option to Receipt or Purchase Order depends on Business Needs.
•If you are using Multi Currency Functionality for Purchase Order and if like to have the rate based on Receipt date you need to go with Receipt Match at the invoice match option.
•The main advantage is the Exchange Rate factor i.e. Receipt/Current Date instead of Purchaser Order date.
•Receipt Match gives much closer control of the matching process,Particularly where you have multiple receipts of large purchase order.

If a Business is using Invoice Match option Purhcase Order and like to change from Purchase Order to Receipt Match, then what would be the impact?

•All Supplier sites need to be updated with Invoice Match option to Receipt.
•Purchase orders which are already approved with Invoice Match Option of Purchase order should continue with the same existing process.
•All existing Open PO, which need a change from Purchase Order to Receipt, should be corrected by changing the invoice match option in the purchase order shipment to Receipt. Payables team should match invoices to Receipt for all Purchase Orders created after the cut-off date.
•Training to AP/PO users.r the receipt to use the current exchange rate and not the PO exchange rate, the Invoice Match Option at the system level and on the suppliers should be Receipt, not Purchase Order.

Source:http://oracleappsyashrajvarsity.blogspot.com/search/label/4way

Automatic Offsets and Invoice Processing

Overview
If you enable Automatic Offsets, Payables automatically allocates an invoice's liability amount across multiple balancing segments according to the balancing segments on the invoice distributions. This ensures that invoices always balance by balancing segment.

Payables creates the liability distributions when you submit Approval for an invoice. You cannot overwrite the accounts, since Payables does not display online the offsetting account for each invoice distribution. However, you can review the liability distributions on the Expense Distribution Detail Report. If you do not enable Automatic Offsets, Payables records the invoice liability using the liability account on the invoice, which defaults from the supplier site. When you distribute invoice distributions across multiple balancing segments, the invoice will not balance by balancing segment. However, General Ledger can automatically create intercompany balancing entries when you post the invoice if you have enabled the Balance Intercompany Journals option for your set of books.

How Payables Builds the Offsetting Liability Accounts
When you use Automatic Offsets and submit Approval for an invoice, Payables automatically builds the offsetting liability account for each invoice distribution on the basis of the default liability account for the invoice. The liability account for an invoice defaults from the supplier site; however, you can override it during invoice entry.

When you enable Automatic Offsets, Payables gives you a choice of two different methods for building your offsetting accounts on the basis of this default, Account or Balancing.

If you select Balancing as your Automatic Offset Method, payables takes the default liability account for the invoice, substitutes the balancing segment from the invoice distribution and uses that as the distribution's offsetting liability account.

If you select Account as your Automatic Offset Method, payables takes the account used for the invoice distribution and substitutes the account segment from the default liability account for the invoice, preserving all other segment values.

Suggestion: Use this option if you want to carry all the detail from your invoice distributions on your offsetting accounts. For example, if you are a manufacturing company and you use a product segment to record sales information, you may want to capture product segment values in your expense account, your liability account and your cash account.

Example: You selected Automatic Offsets as None, and your Accounting Flexfield structure is Balancing Segment-Cost Center-Account. Your default liability account for supplier site ABC is 101-000-2300. You enter an invoice for supplier site ABC and distribute it as follows:
DR 101-100-4500 $60
DR 200-201-4610 $40

Payables records the following liability account offsets automatically when you approve the invoice:
CR 101-000-2300 $60
CR 101-000-2300 $40

Example: You enable Automatic Offsets using the Balancing method, and your Accounting Flexfield structure is Balancing Segment-Cost Center-Account. Your default liability account for supplier site ABC is 101-000-2300. You enter an invoice for supplier site ABC and distribute it as follows:
DR 101-100-4500 $60
DR 200-201-4610 $40

Payables records the following liability account offsets automatically when you approve the invoice:
CR 101-000-2300 $60
CR 200-000-2300 $40

Example: You enable Automatic Offsets using the Account method, and your Accounting Flexfield structure is Balancing Segment-Cost Center-Account. Your default liability account for supplier site ABC is 101-000-2300. You enter an invoice for supplier site ABC and distribute it as follows:
DR 101-100-4500 $60
DR 200-201-4610 $40

Payables records the following liability account offsets automatically when you approve the invoice:
CR 101-100-2300 $60
CR 200-201-2300 $40

Intercompany Accounting When You Use Oracle General Ledger

When you use Oracle General Ledger, you can perform accounting for multiple companies within one set of books. When you post journal entries, if a journal entry is out of balance for a balancing segment/company, Oracle General Ledger automatically posts any difference against the intercompany account you defined for the combination of source and category. The following example explains the process further:

Example
An organization owns three companies: A, B, and C. Company A receives a $150 invoice for supplies which all three companies use. Company A enters the invoice in Payables and splits the expense three ways, creating three distributions, one for each company.

At this point, the journal entries for this transaction are out of balance, because company A has a liability of $150, and an expense of $50. Companies B and C are also out of balance, with expenses of $50 and no liability. The T-accounts below illustrate this situation:

During the posting process, General Ledger identifies unbalanced entries such as the one shown above and automatically creates additional intercompany balancing entries. Then it posts both the invoice and balancing entries.
The T-accounts below illustrate the intercompany balancing entries which General Ledger creates to resolve the imbalance presented in the preceding example: