Few Important AP Tables

Few Important AP Tables

AP_SUPPLIERS:

• This table replaces the old PO_VENDORS table.
• It stores information about your supplier level attributes.
• Each row includes the purchasing, receiving, invoice, tax, classification, and general information.
• Oracle Purchasing uses this information to determine active suppliers.
• The supplier name, legal identifiers of the supplier will be stored in TCA and a reference to the party created in TCA will be stored in AP_SUPPLIERS.PARTY_ID, to link the party record in TCA.

AP_SUPPLIER_SITES_ALL:

• This table replaces the old PO_VENDOR_SITES_ALL table.
• It stores information about your supplier site level attributes.
• There is a row for unique combination of supplier address, operating unit and the business relationship that you have with the supplier.
• The supplier address information is not maintained in this table and is maintained in TCA. The reference to the internal identifier of address in TCA will be stored in AP_SUPPLIER_SITES_ALL.LOCATION_ID, to link the address record in TCA.
• Each row includes the supplier reference, purchasing, invoice, and general information.

AP_INVOICES_ALL:

• It contains records for invoices you enter.
• There is one row for each invoice you enter.
• An invoice can have one or more invoice distribution lines and can have one or more scheduled payments.  

AP_INVOICE_LINES_ALL:

• It contains records for invoice lines entered manually, generated automatically or imported from the Open Interface.
• An invoice can have one or more invoice lines.
• An invoice line represents goods (direct or indirect materials), service(s), and/or associated tax/freight/miscellaneous charges invoiced from a supplier.
• An invoice line should contain all the attributes that are present on the physical or electronic invoice presented by the supplier.

AP_INVOICE_DISTRIBUTIONS_ALL:

• It holds the distribution information that is manually entered or system-generated.
• There is one row for each invoice distribution and a distribution must be associated with an invoice.
• An invoice can have multiple distributions.

AP_INVOICE_PAYMENTS_ALL:

• It contains records of invoice payments that you made to suppliers.
• There is one row for each payment you make for each invoice and there is one payment and one invoice for each payment in this table.
• Oracle Payables application updates this table when you confirm an automatic payment batch, enter a manual payment, or process a Quick payment.
• When you void a payment, your Oracle Payables inserts an additional payment line that is the negative of the original payment line.

AP_PAYMENT_SCHEDULES_ALL:

• This table stores information about scheduled payment information on invoices.

AP_PAYMENT_HISTORY_ALL:

• It stores the clearing/unclearing history for payments.
• It also stores the maturity history for future dated payments.
• The table contains a row for each future dated payment, once the future dated payment matures, i.e. becomes negotiable.
• Any time a payment is cleared or uncleared, a row is inserted into this table for the payment.

AP_BATCHES_ALL:

• It contains summary information about invoices you enter in batches if you enable the Batch Control Payables option.
• There is one row for each batch of invoices you enter.
•  If you enable Batch Control, each invoice must correspond to a record in this table.
•  Your Oracle Payables application uses this information to group together invoices that one person entered in a batch.

AP_CHECKS_ALL:

• It stores information about payments issued to suppliers or refunds received from suppliers. 
• There is one row for each payment you issue to a supplier or refund received from a supplier. 
• Oracle Payables application uses this information to record payments you make to suppliers or refunds you receive from suppliers. 
• Oracle Payables application stores the supplier name and bank account name for auditing purposes, in case either one is changed after you create the payment. Oracle Payables application also stores address information for all payments.

AP_HOLDS_ALL:

• It contains information about holds that you or your Oracle Payables application place on an invoice. 
• For non-matching holds, there is one row for each hold placed on an invoice. For matching holds, there is one row for each hold placed on an invoice-shipment match. 
• An invoice may have one or more corresponding rows in this table. 
• Your Oracle Payables application does not pay invoices that have one or more unreleased holds recorded in this table.

AP_BANK_ACCOUNTS_ALL:

• It contains information about your bank accounts.
• There is one row for each bank account you define and each bank account must be affiliated with one bank branch.

AP_BANK_ACCOUNT_USES_ALL:

• It stores information for the internal and external bank accounts you define in Oracle Payables and Oracle Receivables applications.

AP_CARDS_ALL:

• It stores information about the corporate credit cards issued to your employees by your corporate credit card providers.

AP_TRIAL_BALANCE:

• It contains denormalized information about invoices and payments posted to the accrual set of books.

FILED UNDER APPS TABLES, PAYABLES TAGGED WITH ACCOUNT PAYABLES, AP, APPS TABLES, ORACLE APPS, ORACLE E-BUSINESS SUITE

AR Tables:A Diagrammatic Relation

AUGUST 3, 2010 LEAVE A COMMENT

 

 

 

 

 

 

3 Votes

AR Tables:A Diagrammatic Relation

A Diagrammatic Relation between AR Tables

HZ(TCA) tables in Oracle Receivables

HZ(TCA) tables in Oracle Receivables

This article describes few important HZ tables in AR and their relationships with each other.

HZ_PARTIES:

The HZ_PARTIES table stores basic information about parties that can be shared with any relationship that the party might establish with another party. The primary key for this table is PARTY_ID.

Few Important Columns are

• PARTY_ID: Party identifier
• PARTY_NUMBER: Unique identification number for this party
• PARTY_NAME: Name of the party
• PARTY_TYPE: The party type can only be Person, Organization, Group or Relationship.

HZ_PARTY_SITES:

The HZ_PARTY_SITES table links a party (HZ_PARTIES) and a location (HZ_LOCATIONS) and stores location-specific party information. One party can optionally have one or more party sites. One location can optionally be used by one or more parties. The primary key for this table is PARTY_SITE_ID.

Few Important Columns are

• PARTY_SITE_ID: Party site identifier.
• PARTY_ID: Identifier for the party. Foreign key to the HZ_PARTIES table.
• LOCATION_ID: Identifier for the party site. Foreign key to the HZ_LOCATIONS table.
• PARTY_SITE_NUMBER: Party site number.
• PARTY_SITE_NAME: User-defined name for the site.
• ADDRESSEE: Addressee information.

HZ_LOCATIONS:

The HZ_LOCATIONS table stores information about a delivery or postal address such as building number, street address, postal code, and directions to a location. This table provides physical location information about parties (organizations and people) and customer accounts. The primary key for this table is LOCATION_ID.

Few Important Columns are

• LOCATION_ID: Unique identifier for this location
• COUNTRY: Country code from the TERRITORY_CODE column in the FND_TERRITORY table
• ADDRESS1: First line for address
• ADDRESS2: Second line for address
• ADDRESS3: Third line for address
• ADDRESS4: Fourth line for address
• CITY: City
• POSTAL_CODE: Postal Code
• STATE: State
• ADDRESS_KEY: Derived key that facilitates fuzzy searches

HZ_CUST_ACCOUNTS:

The HZ_CUST_ACCOUNTS table stores information about customer accounts , or business relationships that the deploying company establishes with a party of type Organization or Person. This table focuses on business relationships and how transactions are conducted in the relationship. Since a party can have multiple customer accounts, this table might contain several records for a single party. For example, an individual person can establish a personal account, family account, and a professional account for a consulting practice. The primary key for this table is CUST_ACCOUNT_ID.

Few Important Columns are

• CUST_ACCOUNT_ID: Customer account identifier
• PARTY_ID: A foreign key to the HZ_PARTY table.
• ACCOUNT_NUMBER: Account Number
• CUSTOMER_TYPE: Receivables lookup code for the CUSTOMER_TYPE attribute. I for internal customers, R for revenue generating external customers.
• CUSTOMER_CLASS_CODE: Customer class identifier

HZ_CUST_ACCT_SITES_ALL:

The HZ_CUST_ACCT_SITES_ALL table stores all customer account sites across all operating units. Customer account sites are addresses, for customer accounts, where the deploying company does business with its customers. One customer account can have multiple customer account sites, and customer account sites for one customer account can belong to multiple operating units. The primary key for this table is CUST_ACCT_SITE_ID.

Few Important Columns are

• CUST_ACCT_SITE_ID: Customer site identifier
• CUST_ACCOUNT_ID: Identifier for a customer account. Foreign key to the HZ_CUST_ACCOUNTS table
• PARTY_SITE_ID: Identifier for a party site. Foreign key to the HZ_PARTY_SITES table
• BILL_TO_FLAG: Indicates if this is a Bill-To site.
• SHIP_TO_FLAG: Indicates if this is a Ship-To site.
• MARKET_FLAG: Indicates if this is a Marketing site.

HZ_CUST_SITE_USES_ALL:

The HZ_CUST_SITE_USES_ALL table stores business purposes assigned to customer account sites, for example Bill-To, Ship-To, and Statements. Each customer account site can have one or more purposes. This table is a child of the HZ_CUST_ACCT_SITES_ALL table, with the foreign
key CUST_ACCT_SITE_ID. The HZ_CUST_SITE_USES_ALL table also stores operating unit identifier, though the HZ_CUST_ACCT_SITES_ALL table itself stores the operating unit for customer account sites. The primary key for this table is SITE_USE_ID.

Few Important Columns are

• SITE_USE_ID: Site use identifier
• CUST_ACCT_SITE_ID: Identifier for the customer account site. Foreign key to the HZ_CUST_ACCT_SITES_ALL table
• SITE_USE_CODE: Business purpose assigned to customer site account, such as Bill-To, Market, and Statements.
• PRIMARY_FLAG: Indicates if this site is the primary site for this customer account. Y for the primary customer account site. N for other customer account sites.

HZ_CUSTOMER_PROFILES:

The HZ_CUSTOMER_PROFILES table stores information about the credit characteristics of a single customer account or a customer account site or a party. A profile class defined in the
HZ_CUSTOMER_PROFILE_CLASSES table can be used to provide default values for the attributes in this table. The primary key for this table is CUST_ACCOUNT_PROFILE_ID.

Few Important Columns are

• CUST_ACCOUNT_PROFILE_ID: Unique identifier of this customer profile
• CUST_ACCOUNT_ID: Identifier for the Customer Account. Foreign key to the HZ_CUST_ACCOUNTS table.
• STATUS: Indicates whether the profile is active or inactive

HZ_CUST_PROFILE_CLASSES:

The HZ_CUST_PROFILE_CLASSES table stores information about the credit characteristics that are common across a group of customer accounts. The characteristics specified in this table can be used as default characteristics for similar customer accounts. The primary key for this table is PROFILE_CLASS_ID.

HZ_PARTY_RELATIONSHIPS:

The HZ_PARTY_RELATIONSHIPS table stores information about relationships between parties.

Relationship between the tables

API’s to Create User,Reset Password and Add Responsibility

API’s to Create User,Reset Password and Add Responsibility

I have created few queries using Oracle provided package:’FND_USER_PKG’. These queries might be very useful when you donot have the Oracle Apps front end access or you like to get in done through backend.

Using the below query, you can create a User in Oracle application.Just pass username, password and email id as parameters and it will create a user.

declare
v_user_name varchar2(30):=upper('&Enter_User_Name');
v_password varchar2(30):='&Enter_Password';
v_session_id integer := userenv('sessionid');
v_email varchar2(30):=upper('&Enter_Email_Id');
begin
  fnd_user_pkg.createuser (
  x_user_name => v_user_name,
  x_owner => null,
  x_unencrypted_password => v_password,
  x_session_number => v_session_id,
  x_start_date => sysdate,
  x_end_date => null,
  x_email_address => v_email
  );
  commit;
  DBMS_OUTPUT.put_line ('User:'||v_user_name||'Created Successfully');
EXCEPTION
when others then
  DBMS_OUTPUT.put_line ('Unable to create User due to'||SQLCODE||' '||SUBSTR(SQLERRM, 1, 100));
  ROLLBACK;
end;

May a times we forgot the apps password. Then you can use the below query to resent the password just in few seconds.

declare
v_user_name varchar2(30):=upper('&Enter_User_Name');
v_new_password varchar2(30):='&Enter_New_Password';
v_status boolean;
begin
 v_status:= fnd_user_pkg.ChangePassword (
    username => v_user_name,
    newpassword => v_new_password
  );
  if v_status =true then
  dbms_output.put_line ('The password reset successfully for the User:'||v_user_name);
  commit;
  else
  DBMS_OUTPUT.put_line ('Unable to reset password due to'||SQLCODE||' '||SUBSTR(SQLERRM, 1, 100));
  rollback;
  END if;
end;

Use the below query to add a responsibility to a user. The advantage here is that you donot require system administrator responsibility access to add a responsibility.

declare
v_user_name varchar2(30):=upper('&Enter_User_Name');
v_resp varchar2(30):='&Enter_Responsibility';
v_resp_key varchar2(30);
v_app_short_name varchar2(50);
begin
  select
    r.responsibility_key ,
    a.application_short_name
  into v_resp_key,v_app_short_name
  from fnd_responsibility_vl r,
    fnd_application_vl a
  where
    r.application_id =a.application_id
    and upper(r.responsibility_name) = upper(v_resp);

  fnd_user_pkg.AddResp (
  username => v_user_name,
  resp_app => v_app_short_name,
  resp_key => v_resp_key,
  security_group => 'STANDARD',
  description => null,
  start_date => sysdate,
  end_date => null
  );
  commit;
  DBMS_OUTPUT.put_line ('Responsibility:'||v_resp||' '||'is added to the User:'||v_user_name);
EXCEPTION
when others then
  DBMS_OUTPUT.put_line ('Unable to add the responsibility due to'||SQLCODE||' '||SUBSTR(SQLERRM, 1, 100));
  rollback;
end;

How to create concurrent programs from database

Here are couple of APIs useful for creating any concurrent programs from the backend database.

1)    Registering the Executable from back-end:

Usually we create executable in the front-end, but this can be done from the database tier i.e. back-end too. Below is the PL/SQL code to create an executable from back-end.

1 2 3 4 5 6 7 8 9 10 11 12 13 14

BEGIN   FND_PROGRAM.executable(executable => 'XXFIN TEST EXECUTABLE' , -- Executable Name   application=>'XXFIN' , -- Application Short Name   short_name=>'XXFINTSTEXE' , -- Executable Short Name   description=>'Test Executable created from Backend' ,     -- Description,DEFAULT NULL   execution_method=>'PL/SQL Stored Procedure',              -- Execution Method   execution_file_name=>'XXFIN_TEST_PROC' ,                  -- Execution File Name,DEFAULT NULL   subroutine_name=>NULL ,                                   -- Subroutine Name,DEFAULT NULL   icon_name=>NULL ,                                         -- Icon Name,DEFAULT NULL   language_code=>'US' ,                                     -- Language Code,DEFAULT 'US'   execution_file_path=>NULL                                 -- Execution File Path, DEFAULT NULL   );   COMMIT; END;

View from Frontend:

Notes:

1] The above API inserts the new records in FND_EXECUTABLES and FND_EXECUTABLES_TL table.

2] You can use the below query to get all the Execution Methods available:

SELECT MEANING “Execution Method”

FROM fnd_lookup_values

WHERE lookup_type = ‘CP_EXECUTION_METHOD_CODE’

AND enabled_flag  = ‘Y’;

2)    Registering the Concurrent program from back-end:     

Usually we create Concurrent program in the front-end, but this can be done from the database tier too. Below is the program to create a Concurrent program from back-end.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

BEGIN   FND_PROGRAM.register(program =>'Test CP from DB', -- CP Name   application =>'XXFIN' , -- Application Short Name   enabled =>'Y',                                    -- Flag to Enable/Disable a CP   short_name =>'XXFINTSTCPDB', -- CP Short Name   description =>'Test CP created from Backend' ,    -- Description,DEFAULT NULL   executable_short_name =>'XXFINTSTEXE', -- Executable Short Name   executable_application =>'XXFIN' , -- Executable Application Short Name   execution_options => NULL,                        -- Execution Options,DEFAULT NULL,   priority => NULL,                                 -- Priority,DEFAULT NULL,   save_output =>'Y',                                -- Save Output,DEFAULT 'Y',   PRINT =>'Y' ,                                     -- Print,DEFAULT 'Y',   cols => NULL, -- DEFAULT NULL,   rows => NULL, -- DEFAULT NULL,   style => NULL,                                    -- DEFAULT NULL,   style_required =>'N' ,                            -- DEFAULT 'N',   printer => NULL,                                  -- DEFAULT NULL,   request_type => NULL,                             -- DEFAULT NULL,   request_type_application => NULL,                 -- DEFAULT NULL,   use_in_srs =>'N' ,                                -- DEFAULT 'N',   allow_disabled_values =>'N' ,                     -- DEFAULT 'N',   run_alone =>'N' ,                                 -- DEFAULT 'N',   output_type =>'TEXT',                             -- DEFAULT 'TEXT'   enable_trace =>'N' ,                              -- DEFAULT 'N',   restart =>'Y' ,                                   -- DEFAULT 'Y',   nls_compliant =>'Y' ,                             -- DEFAULT 'Y',   icon_name => NULL,                                -- DEFAULT NULL,   language_code => 'US',                            -- DEFAULT 'US',   mls_function_short_name => NULL,                  -- DEFAULT NULL,   mls_function_application => NULL,                 -- DEFAULT NULL,   incrementor => NULL, -- DEFAULT NULL,   refresh_portlet => NULL                           -- DEFAULT NULL,   );   COMMIT; END;

View from Frontend:

Notes:

1] The various output types are ‘PS’, ‘PDF’, ‘HTML’, ‘TEXT’, ‘PCL’, ‘XML’.

2] The above API inserts the new records in fnd_concurrent_programs and FND_CONCURRENT_PROGRAMS_TL

3)    Attaching the concurrent program to the request group

Usually we Attach Concurrent program to the request group in the front-end, but this can be done from database tier too. Below is the program to Attach Concurrent program to the request group from back-end.

1 2 3 4 5 6 7

BEGIN   FND_PROGRAM.add_to_group('XXFINTSTCPDB', -- Concurrent Program Short Name   'XXFIN' , -- Application Short Name   'All Reports',                           -- Report Group Name   'SQLAP'); -- Report Group Application   COMMIT; END;

Apart from these APIs, the above package also contains to create/delete parameters, delete executable, and delete concurrent programs and all.