This appendix describes public Oracle Credit Management APIs.
This appendix covers the following topics:
This document outlines the specifications and the methodology for using the Credit Management public APIs.
The Credit Management public APIs includes five APIs:
All APIs are PL/SQL APIs that create or update objects in the Credit Management system based on the specified parameters. The APIs do not cause performance degradation to the main flow calling the API.
Products in the Oracle e-Business Suite use Oracle Credit Management as part of their respective business flows to perform credit analyses on parties, accounts, or account sites. For example, Oracle Order Management and Oracle Lease Management are two such products.
In addition to entering the credit request (more formally known as the credit application) from within Credit Management, e-Business Suite products might want to trigger the creation of a credit request from their existing flows.
Specific requirements from each product also exist for handling the results (which are the recommendations) of a credit analysis performed in Credit Management.
Some of these products might also want to perform custom processing if the automation process of a credit request fails.
See: Credit Request Business Events.
Initialization of ARP_STANDARD and ARP_GLOBAL
Custom code that uses AR, OCM, or HZ APIs will set the ORG_ID via dbms_application_info.set_client_info() and then call the APIs. The APIs in turn might access either ARP_STANDARD and ARP_GLOBAL, which initialize the global variables that are used across Credit Management when the package is first called. Most of these global variable values are organization dependent, and the first such call sets the global variables based on the current ORG_ID.
If additional custom code then changes the ORG_ID via another call to dbms_application_info.set_client_info(), then the ORG context changes, but the ARP_STANDARD and ARP_GLOBAL context does not.
In such cases, you should explicitly re-initialize the global variables by a call to these two public procedures:
ARP_GLOBAL.INIT_GLOBAL: For setting public variables in ARP_GLOBAL.
ARP_STANDARD.INIT_STANDARD: For setting public variables in ARP_STANDARD.
The major features of these public APIs are:
Easy to administer and maintain the consumer product's processes.
Credit Management has published business events.
External systems can subscribe to the business events in Credit Management.
Related Topics
Credit Request Business Events
The ar_cmgt_credit_request_api.create_credit_request routine is used to create a credit request for initiating a credit review for a party, account, or account site.
This API routine has 4 output and 35 input parameters. The API returns the credit_request_id of the credit request created in Credit Management as one of the default output parameters. The following is the breakdown of the parameters:
Standard API parameters: 4
Credit Request parameters: 35
Standard API parameters: 3
Credit Request parameters: 1
The following table lists standard API parameters that are common to all Credit Request API routines.
| Parameter | Type | Data-type | Required | Default Value | Description |
|---|---|---|---|---|---|
| p_api_version | IN | NUMBER | Yes | Used to compare version numbers of incoming calls to its current version number. An unexpected error is raised if version incompatibility exists. In the current version of the API, you should pass a value of 1.0 for this parameter. | |
| p_init_msg_list | IN | VARCHAR2 | FND_API.G_FALSE | Allows API callers to request that the API executes initialization of the message list on their behalf. | |
| p_commit | IN | VARCHAR2 | FND_API.G_FALSE | Used by API callers to ask the API to commit on their behalf. | |
| p_validation_level | IN | VARCHAR2 | FND_API.G_VALID_LEVEL_FULL | Currently, not for use. | |
| x_return_status | OUT | VARCHAR2 | Represents the API overall return status. The expected values are: --FND_API.G_RET_STS_SUCCESS --FND_API.G_RET_STS_ERROR --FND_API.G_RET_STS_UNEXP_ERROR | ||
| x_msg_count | OUT | NUMBER | Number of messages in the API message list. | ||
| x_msg_data | OUT | VARCHAR2 | Message in encoded format if x_msg_count=1. |
The following table lists the parameters that are relevant to the Create Credit Request API.
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| p_application_number | IN | VARCHAR2(30) | Application number on the credit request. This could be internally generated by a sequence based on the setting in the Credit Management system option. | |
| p_application_date | IN | DATE | Date on the credit request. | |
| p_requestor_type | IN | VARCHAR2(30) | Requestor type. Valid values are EMPLOYEE or FND_USER. | |
| p_requestor_id | IN | NUMBER | HR PERSON_ID or FND_USER_ID, depending on requestor type. | |
| p_review_type | IN | VARCHAR2(30) | 'Review type' of the credit request. 'Review types' are created as AR lookups during Credit Management setup. | |
| p_credit_classification | IN | VARCHAR2(30) | 'Credit classification' of the party/account/site that are created as AR lookups during Credit Management setup. | |
| p_requested_amount | IN | NUMBER | Requested credit limit amount. | |
| p_requested_currency | IN | VARCHAR2(30) | Currency of the requested credit limit. | |
| p_trx_amount | IN | NUMBER | Transaction amount. | |
| p_trx_currency | IN | VARCHAR2(30) | Transaction currency. | |
| credit_type | IN | VARCHAR2(30) | Type of credit request. Possible values are 'Term' and 'Trade'. | |
| p_term_length | IN | NUMBER | Term length specified as number of months. Relevant for the credit_type 'Term'. | |
| p_credit_check_rule_id | IN | NUMBER | Identifier of the credit check rule defined in Order Management (OM-specific attribute). | |
| p_credit_request_status | IN | VARCHAR2(30) | Credit request status. Possible values are SAVE and SUBMIT. | |
| p_party_id | IN | Party identifier. | ||
| p_cust_account_id | IN | NUMBER | Customer account identifier. | |
| p_cust_acct_site_id | IN | NUMBER | Customer account site identifier. | |
| p_contact_party_id | IN | NUMBER | Party identifier for the credit contact. | |
| p_site_use_id | IN | NUMBER | Site use identifier. | |
| p_notes | IN | VARCHAR2(2000) | Notes. | |
| p_source_org_id | IN | NUMBER | ||
| p_source_user_id | IN | NUMBER | ||
| p_source_resp_id | IN | NUMBER | ||
| p_source_resp_appln_id | IN | NUMBER | ||
| p_source_security_group_id | IN | NUMBER | ||
| p_source_name | IN | VARCHAR2(30) | Source name on the credit request, which is used to identify the source product that initiated the credit request. | |
| p_source_column1 | IN | VARCHAR2(150) | Unique identifier of the entity for which the credit request was created. | |
| p_source_column2 | IN | VARCHAR2(150) | Unique identifier of the entity for which the credit request was created. | |
| p_source_column3 | IN | VARCHAR2(150) | Unique identifier of the entity for which the credit request was created. | |
| p_credit_request_id | OUT | NUMBER | Credit request identifier. | |
| p_review_cycle | IN | VARCHAR2(30) | ||
| p_case_folder_number | IN | VARCHAR2(30) | Case folder number, which is used by the case folder generated by this credit request. | |
| p_score_model_id | IN | NUMBER | ||
| p_parent_credit_request_id | IN | NUMBER | Parent credit request ID | |
| p_credit_request_type | IN | VARCHAR2 | Credit request type. Derived from AR lookups OCM_CREDIT_REQUEST_TYPE. | |
| p_reco | IN | VARCHAR2 | Recommendation name. Users can pass their own recommendations. The recommendation must be a lookup. |
The ocm_credit_request_update_pub routine is used to update an existing credit request for a party, account, or account site.
To view the standard API parameters that are common to all Credit Request API routines, see: Standard API Parameters.
The Update Credit Request API includes the p_credit_request_rec parameter of PL/SQL record type, which shares parameters with the Create Credit Request API. See the table that describes the shared parameters.
The following table describes the parameters of p_credit_request_rec that are unique to the Update Credit Request API.
| Parameter | Data-type |
|---|---|
| check_list_id | NUMBER |
| credit_analyst_id | NUMBER |
| case_folder_id | NUMBER |
| stock_exchange | VARCHAR2(50) |
| current_stock_price | NUMBER |
| stock_currency | VARCHAR2(30) |
| market_capitalization | NUMBER |
| market_cap_monetary_unit | VARCHAR2(15) |
| pending_litigations | NUMBER |
| bond_rating | VARCHAR2(30) |
| legal_entity_name | VARCHAR2(240) |
| entity_type | VARCHAR2(30) |
| recommendation_name | VARCHAR2(30) |
| attachment_flag | VARCHAR2 |
| status | VARCHAR2 |
| request_id | NUMBER |
The ocm_credit_req_withdraw_pub routine is used to withdraw an existing credit request for a party, account, or account site.
To view the standard API parameters that are common to all Credit Request API routines, see: Standard API Parameters.
The following table describes the parameters that are unique to the Withdraw Credit Request API.
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| p_credit_request_id | IN | NUMBER | Credit request ID | |
| p_withdrawl_reason_code | IN | VARCHAR2 | Withdrawal reason code. Derived from AR_CMGT_APP_WITHDRAW_REASONS lookup type. |
The ocm_guarantor_pub routine is used to automatically submit a credit application for a guarantor that is included on a credit application or in a case folder.
To view the standard API parameters that are common to all Credit Request API routines, see: Standard API Parameters.
The following table describes the parameters that are unique to the Guarantor API.
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| x_guarantor_credit_request_id | OUT | VARCHAR2 | Guarantor credit request ID | |
| x_guarantor_application_number | IN OUT | VARCHAR2 | Guarantor application number | |
| p_party_id | IN | NUMBER | Party identifier | |
| p_contact_party_id | IN | NUMBER | Contact party identifier | |
| p_parent_credit_request_id | IN | NUMBER | Parent credit request identifier | |
| p_currency | IN | VARCHAR2 | Currency | |
| p_guaranted_amount | IN | NUMBER | Guarantee amount | |
| p_funding_available_from | IN | DATE | Funding available from date | |
| p_funding_available_to | IN | DATE | Funding available to date | |
| p_case_folder_id | IN | NUMBER | Case folder identifier | |
| p_notes | IN | VARCHAR2 | Notes | |
| p_credit_classification | IN | VARCHAR2 | Credit classification of party, from AR lookups. Defaulted as “GUARANTOR”. | |
| p_review_type | IN | VARCHAR2 | Review type of party, from AR lookups. Defaulted as “GUARANTOR”. | |
| p_requestor_id | IN | NUMBER | Requestor identifier | |
| p_source_org_id | IN | NUMBER | Source product organization identifier | |
| p_source_user_id | IN | NUMBER | Source product user ID | |
| p_source_resp_id | IN | NUMBER | Source product responsibility ID | |
| p_source_appln_id | IN | NUMBER | Source product application ID | |
| p_source_security_group_id | IN | NUMBER | Source product security group ID | |
| p_source_name | IN | VARCHAR2 | Source product name, derived from AR lookup OCM_REQUEST_SOURCE | |
| p_source_column1 | IN | VARCHAR2 | Source product column 1, must be passed as source product identifier | |
| p_source_column2 | IN | VARCHAR2 | Source product column 2, must be passed as source product document number | |
| p_source_column3 | IN | VARCHAR2 | Source product column 3 | |
| p_credit_request_status | IN | VARCHAR2 | Request status | |
| p_review_cycle | IN | VARCHAR2 | Review cycle | |
| p_case_folder_number | IN | VARCHAR2 | Case folder number | |
| p_score_model_id | IN | NUMBER | Scoring model ID | |
| p_asset_class_code | IN | VARCHAR2 | Asset class code | |
| p_asset_type_code | IN | VARCHAR2 | Asset type code | |
| p_description | IN | VARCHAR2 | Description | |
| p_quantity | IN | NUMBER | Quantity | |
| p_uom_code | IN | VARCHAR2 | Unit of measurement | |
| p_reference_type | IN | VARCHAR2 | Reference type | |
| p_appraiser | IN | VARCHAR2 | Appraiser name | |
| p_appraiser_phone | IN | VARCHAR2 | Appraiser phone | |
| p_valuation | IN | NUMBER | Valuation | |
| p_valuation_method_code | IN | VARCHAR2 | Valuation method code | |
| p_valuation_date | IN | DATE | Valuation date | |
| p_acquisition_date | IN | DATE | Acquisition date | |
| p_asset_identifier | IN | VARCHAR2 | Asset identifier |
The ocm_get_extrl_decsn_pub routine is used to bypass Credit Management's scoring functionality and extract case folder contents for scoring by an external scoring engine.
This API consists of four procedures:
Get Score
Include Data Points
Get Recommendations
Submit Case Folder
The following table lists standard API parameters that are common to all four Get External Decision procedures:
| Parameter | Type | Data-type | Required | Default Value | Description |
|---|---|---|---|---|---|
| p_api_version | IN | NUMBER | Yes | Used to compare version numbers of incoming calls to its current version number. An unexpected error is raised if version incompatibility exists. In the current version of the API, you should pass a value of 1.0 for this parameter. | |
| p_init_msg_list | IN | VARCHAR2 | FND_API.G_TRUE | Allows API callers to request that the API executes initialization of the message list on their behalf. | |
| p_commit | IN | VARCHAR2 | Used by API callers to ask the API to commit on their behalf. | ||
| p_validation_level | IN | VARCHAR2 | Currently, not for use. | ||
| x_return_status | OUT | VARCHAR2 | Represents the API overall return status. The expected values are: --FND_API.G_RET_STS_SUCCESS --FND_API.G_RET_STS_ERROR --FND_API.G_RET_STS_UNEXP_ERROR | ||
| x_msg_count | OUT | NUMBER | Number of messages in the API message list. | ||
| x_msg_data | OUT | VARCHAR2 | Message in encoded format if x_msg_count=1. |
The following table lists the parameters for the Get Score API:
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| p_case_folder_id | IN | NUMBER | Case folder identifier | |
| p_score_model_id | IN | NUMBER | Scoring model identifier | |
| p_score | IN | NUMBER | Score |
The following table lists the parameters for the Include Data Points API:
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| p_case_folder_id | IN | NUMBER | Case folder identifier | |
| p_data_point_id | IN | data_point_id_varray | Array of data points to be included in case folders |
The following table lists the parameters for the Get Recommendations API:
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| p_case_folder_id | IN | NUMBER | Case folder identifier | |
| p_recommendations_type | IN | VARCHAR2 | Name of recommendation (defined as lookup type) | |
| p_recommendations_tbl | IN | credit_recommendation_tbl | List of recommendations to be included. |
The following table lists the parameters for the Submit Case Folder API:
| Parameter | Type | Data-type | Required | Description |
|---|---|---|---|---|
| p_case_folder_id | IN | NUMBER | Case folder identifier |
The Credit Management APIs return three types of information to its calling programs:
Overall status
Messages describing the operations performed or errors encountered by the APIs
Some output values that the API caller might want to use (this is different for different API routines and is described in API Usage)
The return status (x_return_status) of the API informs the caller about the result of the operation (or operations) performed by the API. The different possible values for an API return status are:
Success (FND_API.G_RET_STS_SUCCESS)
Error (FND_API.G_RET_STS_ERROR)
Unexpected error (FND_API.G_RET_STS_UNEXP_ERROR)
The following section describes the different values of return status and their meanings.
Success
A success return status means that the API was able to perform all the operations requested by its caller. A success return status may be accompanied by messages in the API message list which will be informative.
Error
An error return status means that the API failed to perform some or all of the operations requested by its caller. An error return status is usually accompanied by messages describing the error (or errors) and how to fix it.
In most cases, you should be able to take corrective action to fix regular, expected errors such as missing attributes or invalid date ranges.
Unexpected error
An unexpected error status means that the API has encountered an error condition it did not expect or could not handle. In this case, the API is unable to continue with its regular processing. Examples of such errors are unrecoverable data consistency errors, memory errors, and programming errors (such as attempting a division by zero).
In most cases, only system administrators or application developers can fix these unexpected errors.
The APIs put result messages into a message list. Programs calling the APIs can then get the messages from the list and process them by issuing them, loading them into a database table, or writing them to a log file.
Messages are stored in an encoded format to let the API callers find message names using the standard functions provided by the message dictionary. It also allows the storing of these messages in database tables and reporting off these tables in different languages.
The API message list must be initialized every time a program calls an API. API callers can either call the message list utility function FND_MSG_PUB.Initialize or request that the API do the initialization on their behalf by setting the p_init_msg_list parameter to TRUE.
The program calling the API can retrieve messages from the message stack using the existing FND API functions FND_MSG_PUB.Count_Msg and FND_MSG_PUB.Get.
Message Level Threshold
The message level threshold is stored in a profile option named FND_API_MSG_LEVEL_THRESHOLD. This profile option can be updated at all levels (site, application, or user). The API checks against this threshold before writing a message to the API message list.