This chapter describes setting up and administering credit policies, as well as reviewing the performance of the policies.
This chapter covers the following topics:
The flexible setup procedures that follow reflect Oracle Credit Management's ability to meet the demands of your enterprise's particular credit policies.
During setup, you define your credit policies that determine the data used for analysis, the credit scores that are calculated, and the credit recommendations that are made.
First, design the credit review tools that Oracle Credit Management uses to assess creditworthiness:
Then, define credit recommendations and approval policies.
Finally, use the tools on the Performance tab to ensure that your credit policies are adequately assessing the creditworthiness of your customers and prospects. See: Reviewing Credit Management Performance.
Related Topics
Chapter 2, Implementing Oracle Credit Management
A credit data point is a single piece of credit information, such as the number of late payments or DSO days (days sales outstanding), which Oracle Credit Management uses during credit analysis.
Credit Management pulls various credit data points from a multitude of sources to assess the creditworthiness of your customers and prospects. Sources include:
Seeded data points
Credit Management provides almost 200 data points that you can include in credit reviews. These data points are pulled from other applications in the E-Business Suite, such as Oracle Receivables and Oracle Order Management. See the Oracle Credit Management Data Points appendix in the Oracle Credit Management User Guide.
Dun & Bradstreet data points
You can purchase credit information from Dun & Bradstreet and include D&B data points in credit reviews. See: Maintaining Customer Data and Adding Dun & Bradstreet Data Points to a Checklist.
User-defined data points
Internal
You can define additional data points and associate a PL/SQL package and function to derive a value for that data point.
External
You can include data points from other sources from outside the E-Business Suite, such as credit bureaus that are not currently integrated with Credit Management.
Important: During a credit review, Credit Management will not automatically populate values for external data points upon case folder creation. Because these data points are missing when the case folder is created, the Credit Management workflow will fail and a credit analyst must manually enter the missing data point values.
When setting up your credit review tools (credit checklist and scoring model), you indicate which data points to include for credit analysis. Later, during a credit review, Oracle Credit Management pulls the data points specified on the credit checklist and analyzes the collected information based on the scoring model parameters.
Credit Management provides you with an inventory of almost 200 seeded data points on which to base credit reviews and decisions. Data points from other E-Business Suite applications, such as Oracle Order Management and Oracle Lease Management, are also provided for your use.
But what if the seeded inventory of data points does not cover your business requirements? You can extend the menu of available data points within Credit Management by defining your own data points to be selected during checklist and scoring model definition. To do this, use the Additional Data Points page off the Policy Management tab.
Tip: Remember to enable newly-created data points. Data points that are not enabled are not available during checklist and scoring model definition.
Note: On the Additional Data Points page, you can view and update only the user-defined data points, not the seeded data points.
When defining new data points, you can:
Add existing or user-defined PL/SQL packages and functions to automatically derive a value upon case folder creation. This ensures that the entire credit review process remains automated.
Caution: Carefully consider your business process before leaving the Package and Function fields empty. If you choose not to have Credit Management automatically derive a data point's value, then the value will be missing upon case folder creation. In this case, the workflow will fail and a credit analyst must manually add the data point value.
If a data point has an associated function, then the data point value is not updatable in the case folder.
For PL/SQL guidelines, see: Guidelines for Deriving Data Point Values.
Important: Please consider the following points while adding PL/SQL functions.
Do not include PL/SQL package or function names in an ADP unless the package function exists in the database and is valid and operational. If an invalid package name is included, it will not create the case folders.
If you define a PL/SQL function for an ADP, make sure that the function will complete normally and successfully for all customers or scenarios. Make sure that you handle all ORA-1403 or ORA-1422 (no data found/too many rows) issues which return null or zero values inside your package.
All ADPs are executed for all customers on all case folders. While you may not use the ADP in all cases, it should calculate or handle exceptions for cases where it cannot compute a value.
Define hierarchical relationships between data points by selecting a parent data point.
Hierarchical relationships can involve one parent and many children, or multiple levels of children.
For example, during a credit review of a customer who is applying for a new lease agreement for a tractor, you will probably want to include in the credit analysis the tractor's rental fee. In this case, the asset is the parent data point, and its child data point is the rental fee. If the rental fee is different depending on the lease term (0-12 months vs. 13-48 months), then the lease term becomes a child of the rental fee data point.
Note: During checklist definition, child data points are not available for selection. If a parent data point is required, then its child data points are also required.
Specify a data point category. A data point category acts as a filter to classify your user-defined data points. For example, you might want to organize data points by external source, such as by credit bureau name.
To implement categories, you must first define them using the OCM_USER_DATA_POINT_CATEGORIES lookup. See: Defining Lookups.
Indicate if a data point is scorable.
If a data point is scorable, then you can define ranges and scores for that data point during scoring model definition.
Tip: If a data point is associated with a PL/SQL function that returns multiple values, then this data point is not scorable.
When defining an additional data point, is there any impact if I do not assign a PL/SQL function?
If no package is associated then the value will be defaulted to NULL, and your credit analysts must manually enter values in the case folder. This means that upon case folder creation, the workflow will fail and the credit review will be routed to the Credit Scheduler for assignment to a credit analyst.
What happens if an assigned PL/SQL function fails during case folder creation?
The workflow process will fail and the case folder will be routed to the Credit Scheduler for assignment to a credit analyst.
How can a credit review include data points in a foreign currency?
Set the AR: Default Credit Management Currency profile option to identify the currency in which you want to conduct your credit reviews. Credit Management checks this profile option, then converts foreign currency data points into the stated currency. See: Profile Options and Profile Option Categories Overview.
You must also define multi-currency credit exposure usage rules. See: Defining Credit Usage Rules Sets.
Related Topics
Overview of Oracle Credit Management Setup
In Oracle Credit Management, you document your enterprise's credit policies via user-defined credit checklists. Using various checklists, you manage the credit analysis process by defining the required and optional data points that are included in the credit review.
Defining a checklist is a multi-step process, during which you can select checklist criteria in the form of data points from a multitude of sources. Credit Management uses these checklists in two places:
Credit application - The checklist determines which fields are required on the application.
Credit analysis - The checklist identifies what data should be automatically collected and displayed in the case folder.
When defining a checklist, you select a credit review type and credit classification combination. During a credit review, Credit Management uses the intersection of the credit review type and the applicant's credit classification to select the appropriate checklist to use for the credit analysis. The higher the customer credit classification risk, the more stringent the credit policy (scoring model).
For example, your enterprise defines these credit review types:
Credit checking
Credit review
Periodic credit review
Credit application
Lease application
Additionally, your enterprise defines these credit classifications:
High Risk
Moderate Risk
Low Risk
For each combination of credit review type and credit classification, define a checklist based on your credit policies. For example, during a lease application credit review for a High Risk customer, the assigned checklist might require additional collateral and bank reference data points on which to base a credit decision.
Note: For any combination of credit review type and credit classification, only one checklist is active at a time.
This table lists the pages from which you select data points that you want to include in the checklist.
Checklist Definition Page | Data Point Description | Data Point Source |
---|---|---|
Select Credit Data Points | Indicates which credit-related data from Receivables and user-entered business information to include in the credit analysis | Receivables and user-entered |
Select References Data Points | Indicates the number of bank references and trade references to enter in the credit analysis, as well as guarantors, venture capital, and collateral | User-entered |
Select Payments Data Points | Indicates which historical order and receivables data to include in the credit analysis | Order Management and Receivables |
Select Aging Data Points | Indicates which aging data to include in the credit analysis | Receivables |
Select Dun & Bradstreet Data Points | Indicates which data points from the specific Dun & Bradstreet Global Access Data Products report to include in the credit analysis | Dun & Bradstreet |
Define Additional Items | Indicates if the credit analysis requires additional information from an outside source | User-entered |
Prerequisites
You must first define your enterprise's credit classifications as well as credit review types. See: Defining Lookups.
On the Define Checklist page, enter a name and description for this checklist.
Select the credit classification that you want to associate with this checklist.
Select the credit review type that you want to associate with this credit classification and checklist.
In the Notes field, optionally enter comments about this checklist.
The Start Date field defaults to the current date, but you can change it to a future date.
If your credit policies change, then you can end date a checklist for a combination and create a new checklist.
After you designate an end date for a checklist, you cannot change or remove it.
Note: If you enter a future end date, then you can associate a second checklist with this same combination of credit classification and credit review type, provided that the second checklist's start date is after this checklist's end date.
Optionally assign a scoring model to this checklist.
Whenever Credit Management uses this checklist for a credit analysis, the scoring model that you assign here will be the default.
Note: During a credit analysis, you can generate various what-if scenarios by changing the scoring model that is attached to the checklist. See: Calculating a Credit Score.
Important: Before assigning a scoring model, ensure that the scoring model's selected data points are also included by this checklist.
Use the Credit Policy Statement field to optionally enter a description of the credit policy that this checklist enforces.
The following group of pages display various data points that you can select for inclusion in this checklist.
Select the data points that you want this checklist to include.
If you do not select either check box, then the checklist will not include the data point at all.
Data points that are user-entered or from an external source can be designated as required or optional. See: Defining Additional Data Points.
For additional information about selecting data points from Dun & Bradstreet, see Adding Dun & Bradstreet Credit Data to a Checklist.
On each page, you can view the checklist criteria that you have saved up to that point.
Click Submit to freeze the checklist.
Once you have submitted the checklist, you cannot modify it. If modifications are necessary, then you must end date the checklist and create a new checklist.
Related Topics
Overview of Oracle Credit Management Setup
When you first set up a checklist, the Select Dun & Bradstreet Data Points page provides you with an overview of Global Access Data Products that you can purchase. From this page, select the data product whose data points you want to include on your checklist. You can select more than one data product, but you would typically include only one product on a checklist.
Later, during a credit analysis, the case folder displays the D&B data points that you included on the associated checklist.
When you include a Global Access Data Product on a checklist, all data points for that report are displayed.
During a credit analysis, Credit Management checks to see whether the data exists in your database and is current:
If the data is not available and you selected the All Data Required check box, then you must purchase the data. Credit Management will not complete the credit analysis and make a recommendation until the data is imported from Dun & Bradstreet.
If the data is not available and you selected the All Data Optional check box, then you will receive a notification that the data does not exist. However, Credit Management will still complete the credit analysis and make a recommendation.
Related Topics
Third Party Data Integration Overview, Oracle Trading Community Architecture User Guide
Overview of Oracle Credit Management Setup
A scoring model is one of the primary credit review tools that Oracle Credit Management uses to assess the creditworthiness of your customers and prospects. See: Overview of Oracle Credit Management.
Scoring models include the data points and scoring method that are appropriate for a particular credit review. When defining scoring models, for each data point, (1) indicate a score for each range of values and (2) optionally assign a relative weighting factor.
During a credit analysis, Credit Management uses the scores that you assigned to each data point range of values to calculate a score. The lower the credit score, the greater the credit risk.
Note: Credit scores are calculated as whole integers, with decimal values .5 or greater rounded up. For example, 70.5 becomes 71, and 70.4 becomes 70.
The power of the scoring model lies in its ability to facilitate the automated credit review process, because you can attach recommendations to each score range. Once a score has been calculated, Credit Management can automatically determine the appropriate credit recommendations without user intervention. See: Assigning Automation Rules.
Credit Management provides you with the ability to define multiple scoring models. Define a different scoring model for each type of credit review that you need. This lets you apply standard and consistent scoring guidelines across your customers and prospects.
You can assign a default scoring model to a credit checklist. See: Defining Checklists.
Later, during credit analysis, you can generate various "what-if" scenarios during a credit review by selecting different scoring models from the case folder. See: Calculating a Credit Score.
Tip: You can ignore Credit Management's scoring model altogether and use an external scoring engine to derive a credit score. See: External Scoring.
You can assign different scoring attributes to each data point in your scoring model.
For each data point that the scoring model includes, you must assign a range of values and a corresponding score for each range. The ranges of values for a data point typically represent levels of credit risk.
Numeric ranges can be positive or negative, and you can use decimal points. Scores must be numeric values, either positive or negative.
For example, this table illustrates sample ranges and scores for the Percentage of Invoices Paid Late data point:
Credit Risk | Range Value | Score |
---|---|---|
Low | 0 to 20 | 15 |
Moderate | 21 to 50 | 10 |
High | 51 to 100 | 0 |
This table illustrates sample ranges and scores for the DSO data point:
Credit Risk | Range Value | Score |
---|---|---|
Low | -999 to 9 | 8 |
Moderate | 10 to 24 | 5 |
High | 25 to 34 | 2 |
Highest | 35 to 999 | 1 |
Assign a weighting factor to each data point to indicate the relative importance of each data point in the scoring model.
For example, will you use this scoring model to determine a credit limit increase for an existing customer who has years of credit history with your enterprise? In that case, you might assign a higher weighting factor to the Percentages Of Invoices Paid Late data point, and a lower weighting factor to the Credit Agency Score data point.
Or, assign no weights at all to produce a raw score. If no weights are assigned, then the calculated score could fall outside the 0 to 100 range.
Tip: You can view the minimum and maximum potential raw scores on the Review page during scoring model definition. This is helpful to know when defining automation rules. See: Assigning Automation Rules.
Continuing the previous example, this table illustrates the possible weighting factors for the Percentage of Invoices Paid Late and DSO data points:
Data Point | Weight |
---|---|
Percentage of Invoices Paid Late | 65 |
DSO | 35 |
Note: If you assign weights, then the sum of all data point weighting factors must equal 100.
This example illustrates how the credit score is calculated, based on the scoring model defined in the previous examples. This table shows the values for each data point.
Data Point | Value |
---|---|
Percentage of Invoices Paid Late | 75 |
DSO | 15 |
For each data point, the score for the value's range is divided by the largest possible score for the data point.
Percentage of Invoices Paid Late: 0 / 15 = 0
DSO: 5 / 8 = .625
The result from step 1 is multiplied by the weight.
Percentage of Invoices Paid Late: 0 * .65 = 0
DSO: .625 * .35 = .13671875
The results of step 1 and 2 are added for each data point.
0 + .13671875 = .13671875
The result of step 3 is multiplied by 100.
.13671875 * 100 = 13.671875
The credit score is 14.
On the Define Scoring Model page, enter the name and description of this scoring model.
In the Currency field, from the list of values, select the currency for this scoring model.
The selected currency indicates the currency in which the data point range is expressed. Credit Management uses the Exchange Rate Type system option during currency conversion.
Use the Notes field to optionally enter comments about this scoring model.
The Start Date defaults to the current date, but you can change it to a future date.
If your credit requirements change and you want to define a new scoring model that is more in line with your revised credit policies, inactivate the outdated scoring model by entering an end date. The only valid end date is the current date.
Tip: Inactive scoring models do not display on the scoring models search page, unless you select the Show Inactive Scoring Model check box as a search parameter.
When you create a new case folder or attach a scoring model to a credit checklist, you can select only a scoring model that has no end date, or an end date that is greater than the case folder or checklist creation date.
Note: Once you enter an end date and save your work, you can no longer change or remove the date. This ensures that your credit policies are strictly enforced, and also that comparisons across scoring models remain meaningful.
Use the Convert null values to zero values check box to indicate how Credit Management should treat data points with null values.
Tip: Carefully consider your business requirements before leaving this box blank. If you do not select this box, then a scoring model will not calculate a score if a data point contains a null value. In this case, the workflow will stop and the credit review will be routed to the Credit Scheduler for credit analyst assignment.
On the Select Data Points page, select the data points that you want to include in the scoring model.
For each data point that is included in this scoring model, assign a range of values and a corresponding score for each range.
The ranges that you enter should include all possible values. You can enter up to 15 characters for each value in the range.
Note: If you enter alphanumeric values for a data point, then both range values must be the same. This table illustrates an example:
Range | Low | High | Score |
---|---|---|---|
Range 1 | A2B | A2B | 10 |
Range 2 | B3B | B3B | 5 |
When you have completed assigning ranges and scores to the data points in this scoring model, optionally assign a weight to each data point. The weight that you assign indicates the relative importance of the data point in the scoring model.
Review the scoring model.
Tip: If you have not assigned weights, then the scoring model will calculate a raw score. Note the minimum and maximum potential raw scores on this page, because you will need to know this range if you define automation rules. See: Assigning Automation Rules.
You can still update a scoring model after you save it. After you submit a scoring model, however, you can no longer update it.
What is the difference between a null data point value and a zero data point value?
A null data point value indicates no activity, while a zero data point value indicates that activity has occurred in the past, but there is no value for the particular data point. For example, let's consider the Count of Invoices Paid Late data point. In this case, a null value might indicate that no payments have been made, while a zero value indicates that all invoices were paid on time.
Related Topics
Overview of Oracle Credit Management Setup
You can bypass Oracle Credit Management's scoring functionality and score a case folder's data points using a third party scoring engine. This process involves:
Exporting case folder contents outside Credit Management, and scoring the contents using your own scoring engine
Importing the resulting credit score, and storing it in the case folder
To determine whether a case folder's data should be externally scored, Credit Management reviews the scoring model that is associated with the checklist in the case folder. External scoring is initiated if the scoring model includes the seeded External Score data point.
See: Defining Scoring Models.
If the scoring model includes the External Score data point, then the Credit Management workflow bypasses the assigned scoring model and instead automatically submits the Extract XML Case Folder concurrent program. This program extracts the case folder data points in an XML file, which you can retrieve for processing in your external system by subscribing to the business event, oracle.apps.ar.cmgt.CaseFolder.extract.
Upon extraction of the case folder data points, the Credit Management workflow locks the case folder to prevent manual updates and sets the case folder status to In Process.
Additionally, the workflow sends a notification to the credit analyst assigned to the case folder, or to the Credit Scheduler if a credit analyst has not yet been assigned. The notification indicates that the case folder was submitted for external scoring.
After your external system completes the scoring process, you must then import the final score back into Credit Management for storage in the case folder. To import the score, use the Get Score API.
Note: For API usage information, see the Credit Management API User Notes appendix in the Oracle Credit Management User Guide.
Upon import, Credit Management records the score as the value for the External Score data point, and also includes the score in an XML file attached to the case folder for audit purposes.
To unlock the case folder and resume workflow processing, you must ensure that the Submit Case Folder API runs after the Get Score API.
The Submit Case Folder API unlocks the case folder and removes the In Process status. The case folder is now ready for credit recommendations:
If automation rules are associated with the scoring model, then credit recommendations are automatically assigned according to the automation rules and the externally derived credit score. The case folder is then submitted for approval.
If no automation rules exist, then a credit analyst must manually assign a credit recommendation and submit the case folder for approval.
Once approvals are processed, the case folder is closed.
Note: In addition to importing an externally derived credit score, you can also import credit recommendations, as well as additional data points. See: Importing Credit Recommendations and Other Data.
When using an external scoring engine, you are not limited to importing only the final credit score. You can also optionally import additional data points that you want to capture in the case folder, as well as credit recommendations.
Important: Before you can import credit recommendations, the recommendations must already be defined in Credit Management. See: Defining Lookups.
To import additional data points and credit recommendations, ensure that the Include Data Points API and Get Recommendations API are run after the Get Score API. As always, the Submit Case Folder API must run at the end of the process to unlock the case folder for processing.
Upon import, Credit Management refreshes the case folder with the additional data points and credit recommendations.
Note: Credit recommendations that are imported take precedence over any automation rules that might already exist on the scoring model.
Additional data points and credit recommendations are stored in the same XML file (attached to the case folder) where the credit score resides.
Related Topics
Appendix F: Credit Management API User Notes
Overview of Oracle Credit Management Setup
For any scoring model, you can define a set of automation rules to guide the implementation of credit recommendations without user intervention. Automation rules let a credit review proceed uninterrupted through the workflow, during which a credit recommendation is automatically implemented based on the score that the scoring model calculates.
To accomplish this automatic implementation of credit recommendations, you associate credit score ranges with recommendations when defining automation rules. For example, if the credit score is below 50, you might want to automatically reject a credit request.
Such automation is preferable when the credit risk, as defined by your enterprise's credit policies, is minimal and the credit score can drive the credit decision. This lets your credit personnel focus their efforts on higher risk credit reviews.
When you define automation rules, you can also indicate approval options for each decision. Credit Management lets you decide if you want to skip the required approval on a credit decision. See: Setting Up Credit Decision Approval Policies.
You can define a set of automation rules for any of your scoring models, provided that:
A checklist and scoring model are defined and assigned to a credit review type and credit classification combination
Automation rules do not yet exist for the combination
Prerequisites
Create a scoring model. See: Defining Scoring Models.
On the Automation Rules page, search for a submitted scoring model to view its existing automation rules, or search for a saved scoring model to view and update automation rules.
Select a scoring model and click the View Details to navigate to the Automation Rule Details page.
The Automation Rule Details page displays all credit decisions that are defined for the selected scoring model.
Otherwise, to define new rules, click Create Automation Rule.
The Create Automation Rules page displays the scoring models that are eligible for automation.
Select a scoring model and click the Add Rules icon to define a set of automation rules.
Enter the effective dates for this automation rule.
The Start Date defaults to the current date, but you can change it to a future date.
In the End Date field, optionally enter the end date for this set of automation rules. Enter an end date if your credit requirements change and you want to define a new set of automation rules that are more in line with your revised credit policies.
If the End Date field is populated, then this set of automation rules is inactive. Any credit analysis using these rules will require user intervention.
Use the Low Score and High Score fields to define the score range for this automation rule.
Note: Credit scores are calculated as whole values, so enter only integers.
Select the Skip Approval check box if you want to automatically implement credit recommendations without the defined approval hierarchy.
Click the Add Recommendations icon to assign automation rules (automatic credit decisions) to this score range.
Use the Overall Credit Limit or Transaction Credit Limit fields to define the credit limit for this score range. Or, use the Change Overall Credit Limit by Percentage or Change Overall Transaction Credit Limit fields to indicate a percentage increase limit.
You can assign additional values for a recommendation. For example, for a recommendation of increase credit limit to CAD $800,000, value 1 is currency = CAD and value 2 is 800,000.
Do not enter a value in any field if you do not want Credit Management to automatically implement credit increases.
From the list of values, select a credit classification that you want to automatically assign to the applicant if they receive a credit score in this range.
Select the recommendation or recommendations that you want to automatically implement for an applicant who scores in this range.
You can add another row to enter another score range and associated automation rules.
If the scoring model uses weighting factors for each score range, then the credit score is always a complete range from 0 to 100. If not, then the scoring model will produce a raw score that can be outside the 0 to 100 range.
Warning: When defining automation rules, be sure to enter ranges for the entire potential range of credit scores. Later, during a credit review, if a score falls outside the automation rule score ranges, then the workflow will fail and the credit review will be assigned to an analyst for a manually selected recommendation.
Alternatively, you might want the workflow to fail for a particular score range. For example, if a credit score is below 20, then you might want to assign a credit analyst to this credit review for manual processing. In that case, you can skip of range of scores when defining automation rules.
Click Submit to freeze this set of automation rules for the selected scoring model.
After you submit, you can no longer update these automation rules.
Related Topics
Overview of Oracle Credit Management Setup
Oracle Approvals Management Implementation Guide
Credit recommendations are made at the end of a credit review in one of either two ways:
A credit analyst enters one or more recommendations in the case folder, on the Recommendations page.
See: Making a Recommendation.
The automation rules associated with the case folder's assigned scoring model use the calculated credit score to select one or more recommendations.
Oracle Credit Management provides you with a seeded inventory of credit recommendations, but you can define your own.
Credit Management distinguishes between trade credit and term credit.
Seeded trade credit recommendations include:
Change Periodic Review Cycle
Assign Credit Classification
Assign Overall Credit Limit
Place Customer on Credit Hold
No Change
Change Overall Credit Limit by Percentage
Change Transaction Credit Limit by Percentage
Remove Customer from Credit Hold
Remove Order from Hold
Send Credit Reference
Assign Transaction Credit Limit
Seeded term credit recommendations include:
Approve
Authorize Appeal
Extend
Increase
Reject
Terminate
You define recommendations using user-extensible lookup codes. Define your recommendations for both trade and term credit using these lookup codes:
AR_CMGT_RECOMMENDATIONS (credit recommendations for trade credit)
AR_CMGT_TERM_RECOMMENDATIONS (credit recommendations for term credit)
See: Defining Lookups.
Note: User-defined recommendations are available for business event subscription.
If you are using Oracle Lease Management or Oracle Loans and want to define application-specific recommendations, see: Defining Recommendations for Integrated Applications.
You can add a condition as an attribute of a user-defined recommendation. A condition will launch a new page where the user can document a large set of data points.
To add a condition to a recommendation, you must build a custom page first where condition fulfillment details can be recorded. You then add the new page's OA function to the recommendation's lookup type, in the Tag field.
Tip: Use the ability to add an OA function to recommendations to further extend the implementation of credit policies that require more complex information than a set of single data points.
See: Approving a Credit Review with Conditions.
How many values can I associate with a recommendation?
When you define automation rules for a scoring model, you assign one or more recommendations to a credit score range. See: Assigning Automation Rules.
Recommendations can have up to two associated values. For example, for a recommendation of increase credit limit to CAD $800,000, value 1 is currency = CAD and value 2 is 800,000.
Related Topics
Overview of Oracle Credit Management Setup
In Oracle Credit Management, credit recommendations are made in two ways:
Automatic:
Oracle Workflow can create a credit application and case folder, calculate a score using the assigned scoring model, and use the scoring model's automation rules to arrive at a final credit recommendation, all without user intervention.
Manual:
A credit analyst can make a credit recommendation at the conclusion of a manual credit analysis.
But how are those credit recommendations actually approved and implemented?
During setup, you decide which recommendations require approval. For example, certain risky credit recommendations might require approval by a defined list of approvers.
On the other hand, you might want less risky credit recommendations to be immediately implemented without approval.
This decision about whether to approve credit recommendations is another dimension of credit policy management:
For credit recommendations that do not require approval, you implement this type of policy using the Skip Approval check box during scoring model definition. See: Bypassing the Approval Hierarchy.
For credit recommendations that require approval, Credit Management works with Oracle Approvals Management (AME) to manage the list of required approvers.
When a credit review is submitted for approval, Credit Management passes the credit analyst ID to Approvals Management.
Note: If no credit analyst is assigned to a credit review, then the credit review must be routed to the Credit Scheduler first, before Credit Management can initiate the approval process with Approvals Management.
Approvals Management uses the HR hierarchy to determine the appropriate approver for that particular credit review, and returns the approver ID to Credit Management. Credit Management uses Workflow to send a notification to the identified approver. Upon approval, Credit Management passes the approver's ID back to Approvals Management.
If an additional approver is required, then Approvals Management returns the next approver's ID. The cycle repeats until Approvals Management returns a null value; this tells Credit Management that the approval sequence has concluded. At this point, Credit Management implements the recommendation, assigns a status of Approved to the recommendation, and closes the case folder with a status of Closed.
See: Oracle Approvals Management Implementation Guide.
Depending on the associated risk, a credit recommendation typically requires approval from one or more persons in your enterprise. As described above, Approvals Management derives the list of approvers based on approval rules set up in that application.
If the associated risk is minimal, however, then you might decide an approval flow via Approvals Management is unnecessary.
To accomplish this, select the Skip Approval check box on the Create Automation Rule Details page for each recommendation that does not require approval. If a recommendation has Skip Approval enabled and the recommendation is selected according to the calculated credit score, then Credit Management automatically implements the recommendation without calling Approvals Management for a list of approvers.
This Skip Approval option lets you automatically implement credit recommendations without the defined approval hierarchy in all but the riskiest of cases.
Tip: Typically, all scoring models will have automation rules. For a set of automation rules, you might enable the Skip Approval option on:
the lowest credit score range, to automatically implement the rejection recommendation due to high risk
the highest credit score range, to automatically implement the approval recommendation due to low risk
You might require approval, however, for the mid-range credit score.
Consider Company ABC:
Credit classification is Medium Risk
Existing credit limit is $100,000
Pending orders and outstanding invoices equal $95,000
Also consider the following credit policy that your enterprise defines for Company ABC, should ABC surpass its existing credit limit:
During a credit review, if the customer scores 71 or higher, then the credit limit is automatically increased to $200,000.
Implementation: For this credit score range, the Skip Approval check box is selected.
If the customer scores 50 or higher, but below 71, then the credit limit is increased to $150,000, but approval by the sales department is required.
Implementation: For this credit score range, the Skip Approval check box is not selected.
If the customer scores less than 50, then the workflow fails and the credit review is automatically passed to a credit analyst for manual processing.
Implementation: This credit score range does not exist on the scoring model's automation rules.
What actually happens?
When ABC places an order in the amount of $10,000, the order is automatically placed on hold and a request for a credit review is automatically generated.
The scoring model calculates a credit score using the included data points, with a higher credit score indicating less of a credit risk. Below are examples of outcomes based on the calculated credit score:
A credit score is calculated between 71 and 100:
A recommendation to change the credit limit to $200,000 is added to the case folder, and is assigned a status of Approved.
Credit Management initiates the process to change the credit limit.
The case folder is assigned a status of Closed.
A credit score is calculated between 51 and 70:
A recommendation to change the credit limit to $150,000 is added to the case folder.
Credit Management works with Approvals Management to notify the appropriate people in the sales department for approval.
Once approval has been granted, the recommendation is assigned a status of Approved, Credit Management initiates the process to change the credit limit, and the case folder is assigned a status of Closed.
A credit score is calculated between 0 and 50:
The automatic process stops and a notification is sent to the assigned credit analyst or credit manager for further action.
Approvals Management is set up with Credit Management to use the HR hierarchy to determine the approval chain.
However, you can leverage Approvals Management to accomplish other, more complex approval list functions. For example, you can set up a list of approvers based on:
Credit request amount
Job role or level, as defined in Oracle HRMS
You also have the flexibility to define a list of either parallel or sequential approvers.
For example, for orders placed on hold, perhaps your enterprise defined the following credit policy:
For orders $500 or less, the approval list should be Jane, a credit analyst, and Bob, her credit manager.
For orders over $500, the approval list should be Bob, the credit manager, and Mary, the vice-president of Finance.
You can define the above approval lists in Approvals Management.
In Credit Management, you might also define the following exception to the above Approvals Management rules:
If the customer credit classification is Low Risk, the credit review type is a periodic credit review, the credit score is above 80, and the order on hold is less than $500, then no approval is required to implement a credit recommendation. In other words, the Skip Approval check box would be enabled for this particular combination.
Related Topics
Overview of Oracle Credit Management Setup
Credit Management provides you with comparison tools that help you to determine if your credit policies have adequately assessed the creditworthiness of your customers.
On the Performance tab, you can access simple views into the workload and effectiveness of the checklists and scoring models that you have set up and used in credit reviews.
The Credit Workload Quick Check displays a summary of:
Number of Credit Reviews in Process
Number of Automatic Reviews Processed
Number of Customers on Credit Hold
The Quick Check provides you with a view into the amount of work that is outstanding. A high number of in-process reviews can indicate that a delay exists in meeting credit review completion goals.
The Top Ten Customer Credit Exposure report provides you with an overview of the top ten customers with the greatest receivables balance.
By drilling down into the Aging details, you can see whether there is cause for concern.
Use this comparison to view pertinent trend data from one credit review to the next for an account. Comparison data from each case folder includes the receivables balance, weighted average days paid, and days sales outstanding.
This is particularly useful for accounts who have a long-term relationship with you and are assigned a periodic review cycle.
To perform this comparison, the account must have more than one case folder for a credit review type, and the case folders must have a status of Closed. The credit reviews must also use the same credit currency.
Use this comparison to determine whether your credit policies have adequately assessed the creditworthiness of your customers.
This page displays the checklists that were used in completed credit reviews during the past year, broken down by month.
In addition, this page compares the checklist and credit score objectives with related recommendations, and identifies where the credit limit recommendations were above and below acceptable thresholds.
An average risk factor for each checklist is displayed, and is a ratio of the credit limits implemented vs. the calculated credit exposure for the customer.
The risk factor ranges from positive to negative:
A positive number indicates that the credit limits might be set too conservatively
A negative number indicates an aggressive credit policy
The absence of a risk factor indicates that a risk factor could not be calculated due to missing data.
Use this comparison to determine whether your scoring model ranges are correctly scored to ensure accurate recommendations.
The risk factors for each scoring model, calculated similarly to the checklist risk factors, provide intelligence about your enterprise's credit reviews that included a scoring model with credit limit recommendations.
Use this outbound credit reference page to respond to trade requests from other companies.
Search for a customer, then create a printable credit reference that contains payment history and high credit.
Related Topics