Credit Checking

27/08/12
Document
E1: 42: Credit Checking (P4210/P42101/R42542/P43070/R42550) [ID 625508.1]

Modified: 13-Aug-2012 Type: BULLETIN Status: PUBLISHED Priority: 3
Applies to:
JD Edwards EnterpriseOne Sales Order Management - Version XE and later JD Edwards EnterpriseOne CRM Sales Order Entry - Version XE and later JD Edwards EnterpriseOne Sales Order Entry - Version XE and later JD Edwards EnterpriseOne Sales Order Processing - Version XE and later Information in this document applies to any platform.
Purpose
This document is part of an Information Center - to see other documents related to Sales, please use the links provided below: Information Center: Overview of JD Edwards EnterpriseOne Sales Product > Information Center: Using JD Edwards EnterpriseOne Sales Product > Note 625508.1 Credit Checking is an EnterpriseOne tool that is used to reduce exposure against customer's accounts receivable. It provides information about a customers account status. The system compares the customer's total accounts receivable and open orders to the customer's current credit limit, assigned in the Customer Master, and puts the order on hold based on credit hold set up.
Details
Table of Contents
Overview Understanding the Customer Credit Check Inquiry How to Setup and Test a Credit Limit Hold Order Requested Date and Aging Holds Branch Commitment Days and Credit Checking Releasing Orders from Credit Hold Using Credit Checking with Multi-Currency Using Credit Checking with a Credit Insurance Policy Using Parent-Child Credit Checking Using Credit Checking with Line of Business Customers Workflow for Approval of Credit Limit Changes Troubleshooting Credit Checking Frequently Asked Questions
Overview
Credit checking is an EnterpriseOne tool that is used to reduce exposure against customer's accounts receivable. It provides information about a customers account status. The system compares the customers total accounts receivable and open orders to the customers current credit limit, assigned in the customer master, and puts the order on hold based on credit hold set up. There are two types of credit checking: 1. Credit Limit This is an amount set up in the customer master to compare against the order and any outstanding AR balances. When the customer exceeds their credit limit, their sales orders go on hold. 2. Aging Criteria can be setup that causes a customers orders to go on hold based on how old the receivables are and what percentage of receivables are allowed to be that old. When users follow the setup for an aging check in the order hold constants, indicated later in this document, the system will perform a credit limit check as well as an aging check. There is no way to perform only an aging check. Users can perform only a credit limit check or perform a credit limit check with an aging check. The system will not distinguish if aging criteria or the credit limit caused the order to go on credit hold. Back to Top
Understanding the Customer Credit Check Inquiry (P42050)

The credit checking inquiry (P42050) is a way to view the customer's credit exposure. This can be accessed from menu G42112, credit check row exit from customer service inquiry (P4210) or the credit check form exit from sales order header revisions (P4210). Credit limits are associated with a company and that company's currency code, therefore P42050 displays the amounts in the company currency. Note: Enhancement Bug 13452678 - P42050 - REQUEST OPTION TO DISPLAY VALUE IN A/B AMOUNT CODE CURRENCY - requests to have an option in P42050 to display credit checking information based on either the company currency code (the way the software currently functions) or another currency code such as the AB amount code. The screen is split into two sections. The left hand side of the screen is utilized in credit checking to put an order on hold. The right hand side contains historical data that is informational only.
https://support.oracle.com/epmos/faces/ui/km/DocContentDisplay.jspx?_adf.ctrl-state=dc6xraayb_72
1/39
27/08/12
Document
It is important to note all data in this inquiry is retrieved from non-sales tables. Below is a table showing the database table and field name where each data item displayed on the credit check inquiry is retrieved from. Field Name Table F0150 Address Organization Structure Master F03012 Customer Master by Line of Business If this field is left blank, the system assigns todays date Field Explanation/Example Alias Parent number is populated when using Credit checking level P (parent-child) otherwise it is blank. Sold to customer address being evaluated. AN8
Parent Number
PA8
Address Number
As of Date
ASDE
This date is used in determining the number of days past due for any AR invoice (F03B11 record). If an invoice past due days falls before the beginning value for aging days in the AR constants (P0000/F0010), the invoice amount (AAP) will be counted in the future aging category.
Future
F03B11 Customer Ledger and F0010 AR Constants
AG
For example if the current aging period in AR constants is defined to start at -30 days and the customer has payment terms of net 60 days, the invoice will be -60 days past due on the day it is created and it will fall into the future aging category. Calculated by AccumulateARBalance business function (B4200510). If an invoice past due days falls between the first and second aging days values defined in the AR constants (P0000/F0010), the invoice amount (AAP) will be counted in the current aging category.
Current
F03B11 Customer Ledger
AG1
For example if the first two aging days defined in the AR constants are -30 and 0, and the invoice is between -30 and 0 days past due the invoice will be counted in the current aging category. Calculated by AccumulateARBalance business function (B4200510).
1-30
F03B11 Customer Ledger and F0010 AR Constants F03B11 Customer Ledger and F0010 AR Constants F03B11
AG2
If the second and third aging days defined in the AR constants are 0 and 30, and the invoice is between 1 and 30 days past due it will fall into the 1-30 aging period. Calculated by AccumulateARBalance business function (B4200510). f the third and forth aging days defined in the AR constants are 30 and 60, and the invoice is between 31 and 60 days past due it will fall into the 31-60 aging period. Calculated by AccumulateARBalance business function (B4200510). If the fourth and fifth aging days defined in the AR constants are
31-60
AG3
2/39
27/08/12
61-90 Customer Ledger and F0010 AR Constants AG4
Document
60 and 90, and the invoice is between 61 and 90 days past due it will fall into the 61-90 aging period. Calculated by AccumulateARBalance business function (B4200510). If the fifth and sixth aging days defined in the AR constants are 90 and 120, and the invoice is between 91 and 120 days past due it will fall into the 91-120 aging period. Calculated by AccumulateARBalance business function (B4200510). f the sixth and seventh aging days defined in the AR constants are 120 and 150, and the invoice is between 121 and 150 days past due it will fall into the 121-150 aging period. Calculated by AccumulateARBalance business function (B4200510). If the seventh and eighth aging days defined in the AR constants are 150 and 999, and the invoice is between 151 and 999 days past due it will fall into the 151-999 aging period. Calculated by AccumulateARBalance business function (B4200510). AD Total amount due after summing the values from AG through AG7 plus future for the particular company inquired. A running total of the open order value for this customer. This field is updated on the customer sold to address record in the customer master at the time the sales order is created or updated. APRC Currently, the credit checking program does not include tax amounts in the order amount field. Enhancement Bug 10860799: TAX AND CREDIT CHECKING has been raised for this issue but it was returned as redesign not planned. The tax information is not stored in any tables. Taxes in the system are calculated on the fly in real time. During the invoicing process, taxes will be applied to the order and printed on the invoice.
91-120
F03B11 Customer Ledger and F0010 AR Constants F03B11 Customer Ledger and F0010 AR Constants
AG5
121-150
AG6
151-199
F03B11 Customer Ledger and F0010 AR Constants Calculated
AG7
Amount Due
Open Orders
F03012 Customer Master by Line of Business
Total Exposure
Calculated F03012 Customer Master by Line of Business
AMTU Sum of amount due plus open orders.
RetrieveCustomerMasterAmounts business function (B0100081) will retrieve the credit limit value setup in F03012.ACL unless there is a records setup in the F03B29 credit insurance table. ACL If the customer F03B29 record has a policy type (IPT) of 2 and an insured amount (INA) greater than 0, the RetrieveCustomerMasterAmounts business function (B0100081) will retrieve the insured amount value setup in F03B29.INA.
Credit Limit Or F03B29 Credit Insurance Over Credit Calculated Limit ABC Code Sales F03012 Customer Master by Line of Business
AOCL Total Exposure - Credit Limit. A grade between A and F that indicates the level of sales activity ABC1 for a customer. Informational only. Does not affect credit checking logic.
F03012 Customer ABC Code Master by Investment Line of Business ABC Code Average Days F03012 Customer Master by Line of Business
A grade from A to D that indicates the level of investment activity ABC2 for a customer. Informational only. Does not affect credit checking logic.
A grade from A to F that indicates the average number of days a ABC3 customer takes to pay a bill. Informational only. Does not affect credit checking logic. The average number or days that it takes a customer to pay an invoice.
Average Days Late
The system calculates the average days late, which is nonweighted, by determining the number of days that each invoice AVD was past due, and then dividing that number by the total number of invoices. The system calculates the average days late when the Statistics History Update (R03B16) program is run. Informational only. Does not affect credit checking logic.
Date of First
F03012 Customer Master by
The GL date of the first invoice generated for this customer. DFIJ
3/39
27/08/12
Invoice Line of Business
Document
Informational only. Does not affect credit checking logic.
F03012 Customer Last Invoice Master by Date Line of Business Date Last Paid F03012 Customer Master by Line of Business F03012 Customer Master by Line of Business
The GL date of the last invoice generated for the customer. DLIJ Informational only. Does not affect credit checking logic.
The date of the last payment received for this customer. DLP Informational only. Does not affect credit checking logic. The amount invoiced for the year. The system uses the gross amount of the invoice record (F03B11) regardless of whether taxes are included. The system updates this field when Statistics ASTY History Update (R03B16) program is run. Informational only. Does not affect credit checking logic. The Invoiced Prior Year (SPYE) field is updated by running the update YTD and PYE Amounts (R03B161) program. When R03B161 is run, the value from the ASTY field is moved to the SPYE field and the ASTY field is cleared. In addition to the SPYE Customer Master tables, both of these fields are also stored in the A/R Statistical Summary Table (F03B16S). Informational only. Does not affect credit checking logic. The amount of the last payment applied to invoices based on the GL date of the cash receipt detail record (F03B14). The system displays this information from either the AR statistical summary table (F03B16S) or the AR statistical history table (F03B16), depending on the form. The system displays information from F03B16S on the account statistical summary form and information from F03B16 on the periodic statistics form. Informational only. Does not affect credit checking logic. he number of draft records (R1) in the Customer Ledger table (F03B11) that have a pay status not equal to P.
Invoiced This Year
Invoiced Prior Year
Last Applied Amount
ALP
F03012 Customer Number of Master by Open Drafts Line of Business
NOD
Calculated by AccumulateARBalance business function (B4200510). This is displayed only when P42050 Process Tab Option #1 is set to 2 to display draft information. Informational only. Does not affect credit checking logic. The total value of the open draft amounts. Outstanding drafts are considered all drafts in Italy and only drafts not yet due in France.
F03012 Outstanding Customer Draft Master by Amount Line of Business
ODAM
Calculated by AccumulateARBalance business function (B4200510). This is displayed only when P42050 Process Tab Option #1 is set to 2 to display draft information. Informational only. Does not affect credit checking logic.
Example of How to Verify the Aged Accounts Receivable Amounts

Customer 59334 has $9,338.50 in the 151-999 days past due (AG7) period.
4/39
27/08/12
Document
The customers invoice (F03B11) records are extracted into a spreadsheet. The invoice due date is compared to the as of aging date to determine the days past due. It can be verified that all the invoices fall between 151 and 999 days past due and the sum of the open amounts (AAP) of those invoices is equal to $9,338.50.
Back to Top
How to Setup and Test a Credit Limit Hold

Credit checking can be performed interactively during sales order entry (P4210 and P42101) for new sales orders. Batch credit hold processing (R42542) can be run against existing open orders to check if customers are over their credit limit and place those orders on credit hold.
Credit Checking Levels

Credit checking levels are defined in the field ARTO in the customer billing page 1 of the customer master based upon values in UDC H42|AR.
5/39
27/08/12
Document
The credit check levels are defined as follows: P - Credit check based on the credit limit on the sold to customers parent customer record in the customer master (F03012). C - Credit check against the credit limit on sold to customers record in the customer master (F03012). S Same as credit check level C. L - Credit check against the sold to customers company (line of business) record in the customer master (F03012). The examples for credit limit checking and aging limit checking presented below will use customer level credit checking (C and S). The setup and behavior of parent (P) level and line of business (L) level credit checking will be explored later in this paper.
To Setup the Customer Master for Credit Checking

Verify the credit checking level (ARTO) is C or S in the customer master (P03013) billing page 1.
Setup the credit limit in the customer master credit tab.
To Setup the Hold Code for Credit Limit Checking

https://support.oracle.com/epmos/faces/ui/km/DocContentDisplay.jspx?_adf.ctrl-state=dc6xraayb_72 6/39
27/08/12
Document
From menu G4241 access order hold information (P42090). Add a credit hold code from UDC 42|HC for a specific branch plant. Person responsible should be the person responsible for releasing or approving the credit holds. The limit type and code type fields apply to margin hold codes and do not affect credit checking. Limit type is A (amount). Code type is O (order basis). Password can be specific for the responsible person.
To Setup Credit Limit Checking with Sales Order Entry (P4210 and P42101)
To setup credit limit checking during sales order entry, simply populate P4210 order holds tab processing option #1 (customer credit check) with the hold code setup for credit limit checking. If using P42101, make sure the P4210 version called in the P42101 processing options has the order holds processing option setup for customer credit check.
Test by creating a new sales order for any amount using the P4210 version setup with credit checking. If the credit check inquiry shows the customer was over their credit limit before the order was entered even an order for $0.01 will go on hold.
7/39
27/08/12
Document
Using Credit Limit Batch Processing (R42542)

Suppose several existing sales orders are not on hold, but the customer is over the credit limit.
Credit Limit Batch Processing (R42542) should have defaults tab processing option #7 (hold orders code) set to the hold code used for credit checking. Run the version with data selection on the customer address book number (AN8). R42542 credit hold batch PDF will show the C1 hold was applied to several orders.
8/39
27/08/12
Document
Refreshing customer service inquiry shows that now, all existing orders for the customer are now on credit hold.
R42542 is designed to put the orders on hold if the customer is over their credit limit and only in this situation the UBE will advance the statuses based on the processing options #4 and #5. The UBE R42542 will not update the statuses if the order does not go on hold. Enhancement Bug 11055570 "R42542 and Status Update" was entered requesting R42542 to update the statuses of all the processed orders, regardless if they are put on hold or not; this being the only way to know if an order that is not on hold, has been checked by R42542 or not. Back to Top
How to Setup and Test an Aging Hold

Determine Period for Aging Criteria
In the credit check inquiry determine which aging period will be used to set aging criteria. Use field help to display the alias of the aging period. For example, AG4 is the aging period for the 61-90 days field in the credit check inquiry. In this case most of the AR is greater than 60 days past due.
9/39
27/08/12
Document
Order Requested Date and Aging Holds

When performing aging credit checking with Sales Order Entry (P4210 or P42101) or using the Batch Credit Hold (R42542) program the system is coded to set the as of aging date equal to the requested date and not todays date. This will cause the order to go on C2 hold. The assumption is made that if an order is placed with a requested date in the future, any existing accounts receivable will still be outstanding on that future date and on that future date it will no longer be in the current A/R period but will be in a past due period. The customer may very well pay off the outstanding AR invoice before the order requested date is shipped, but there is no way to know that at the time the order is entered. For example, a customer (5924) has one outstanding invoice for $10,000 created on 7/5/2010.
The credit check inquiry shows that 100% of the accounts receivable amount due is in the current period based upon todays date of 7/5/2010.
The C2 order hold is setup so that if 10% of accounts receivable falls in period 2 or later, the new order should go on hold.
10/39
27/08/12
Document
With the C2 hold setup in the Sales Order Entry (P4210) processing options, a new order is created for any amount with an order date of todays date and a requested date of 8/13/2010, which is more than 30 days in the future.
The order goes on C2 hold even though based on todays date the customers A/R balance is in the current period.
Credit check inquiry with as of aging date of 7/5/2010 shows all the A/R amounts in the current period.
11/39
27/08/12
Document
However if changing the as of aging date to be the same as the requested date and take the form exit to retrieve A/R, the amount is moved into the 31-60 days aging bucket.
If orders will typically have requested dates in the future take this into consideration when setting up the age from bucket in the order hold constants. Remember that the aging is done based on the aging of accounts receivable on the order requested date and not based on todays date. In some businesses where items have long lead times the orders are created a long before they are due and kept open for a long time. In such scenarios the R42542 batch credit hold may not place the orders on C2 hold if the requested date is in the past, before todays date. When checking why an order does or does not go on aging hold, be sure to populate the as of aging date and retrieve A/R in the credit check inquiry to see what aging period the A/R amounts fall into. Back to Top
Branch Commitment Days and Credit Checking

If the branch plant constants are set with a value in the commitment days field and the requested date on the order is further in the future than the commitment days, the order will not go on credit limit hold or aging hold. Back to Top
Releasing Orders From Credit Hold

Orders on credit hold can be released interactively using the release held orders (P43070) program. The batch credit orders release (R42550) can be used to check if customers have gone back under their credit limit by paying some of their past due bills. If the customer has gone back under the credit limit, the batch credit orders release will release them from credit hold.
Using Release Held Orders Program (P43070)

This is an interactive program to release held orders. It is not just for credit and aging holds. It is used to release purchase orders and sales orders on any hold. Make sure the version for releasing credit holds has display tab processing option #1 = 1 to display sales orders.
Find the order(s) to be released in the work with held orders screen. Select the orders to release, and click the select button or take the row exit to release. When prompted, enter the password. The password screen will appear multiple times for each different branch plant where orders will be released because each branch plant can have a different person responsible for releasing held orders.
12/39
27/08/12
Document
Notice that amount fields in some records of the P43070 inquiry are blank. The data displayed by P43070 is order header (F4201) data and the amount field in P43070 (ACHG) is mapped from the sales order header open order total (F4201.OTOT) field. If the order amount is blank it may be the OTOT is corrupted and R42995 repost should be run to recalculate it.
Note: When the approver clicks "Find" in P43070, all displayed F4211 records will get a record reservation in P00095. No sales order entry user will be able to modify any of the orders listed selected in the P43070 screen till the approver closes the P43070 application.
Using Batch Credit Orders Release (R42550)

The purpose of the R42550 UBE is to automatically release credit limit holds when the customer is no longer past the credit limit. For example, the customer sends in several payments which pay off old invoices (F03B11 records) that were past due. This causes the total exposure to be less than the credit limit, and orders to get released by R42550. Another example is the credit manager reevaluates the customer and increases the credit limit on the customer master. This causes several orders that were on hold to get released by R42550. For batch credit orders release to work, the user id of the person submitting the job must have the same address book number as the person responsible for the hold code and branch plant of orders being released. The PDF R42550 shows the order was evaluated and displays the message "Order Released".
13/39
27/08/12
Document
The program releases sales orders based on the pick date as well as the customer credit limit using the earliest pick date on the order detail line.
Differences Between R42550 and P43070 for Releasing Credit Holds

The R42550 is different than the P43070 since it performs credit checking to decide if it is OK to release the credit hold. The P43070 will let the credit manager release the credit hold regardless of whether the customer has gone under the credit limit. The R42550 compliments the capability of P43070 so that some orders can be automatically released without requiring a visual verification by the credit manager. The P43070 can be used by the credit manager for exceptional situations where an order will be released even though the customer is over their credit limit. By having a batch process available, the credit manager does not have to do a manual review of every individual order on hold.
R42550 does not perform Aging Checking

R42550 batch credit release does not do an aging credit check, only a credit limit check when releasing orders from credit hold. Refer to BUG 8951490 No Aging Credit Check. If an order is on hold because it exceeds the aging criteria, but is not exceeding its credit limit, the R42550 will release the order from credit hold. To avoid releasing orders that should not be released because they exceed the aging criteria, schedule R42550 Credit Hold Release to run first, followed immediately after with R42542 Batch Credit Hold. By following R42550 with the R42542 the system would put the order back on hold if the aging criteria is exceeded.
R42550 will Release Customer Billing Instructions Credit Holds

If a Credit Hold is placed on an order by populating the hold code field in the order header from the customer billing instructions and the customer is not over the credit limit, the R42550 will release the hold code populated in the R42550 processing options is the same as the hold code on the order header. When populating a hold code from the customer billing instructions it is best to use a different hold code than what is released by R42550.
Held Orders Table (F4209)

The F4209 held orders table gets a new record populated every time an order goes on hold. When the release held orders (P43070) program or batch credit release (R42550) is run and the hold is released, the record is never purged from the F4209. If many orders are routinely going on credit hold for review, the F4209 table can be built up very fast, which can affect performance and result in wasted storage space. There is no standard purge program provided in EnterpriseOne to delete old records in the F4209 table that were released from hold. However it is relatively simple for a programmer to create a customized purge program using object management work bench (OMW) table conversion design aid. By following the steps in the table conversion director, a programmer can develop a purge program without having to write any code. It should be noted that custom purge UBEs should be created by an IT support professional or programmer to make sure appropriate safeguards are designed in to avoid purging the wrong records unintentionally. Custom purge UBEs are not supported by EnterpriseOne Global Software Support, so this should be taken into consideration before deciding to deploy a custom purge UBE to the production environment. Back to Top
Using Credit Checking with a Credit Insurance Policy

Business credit insurance is an insurance policy that businesses purchase to insure payment of credit extended by the business. Credit insurance policies pay an agreed percentage or amount of accounts receivable that remain unpaid as a result of default, insolvency or bankruptcy of a customer. EnterpriseOne provides a program to define credit insurance policies (P03B2901) as to their type, amount and percentage coverage which are stored in Credit Insurance (F03B29) table. The value in the credit insurance insured amount (INA) field (also known as "insured credit limit") may be used in lieu of the credit limit field in the customer master for credit checking and placing an order on credit hold. Below is a table defining the database table and field names on the Credit Insurance Policies (P03B2901) program and valid input values for the program. Field Name Insurance Company Policy Number Table F03B29 Credit Insurance F03B29 Credit Insurance Field Explanation/Example Alias ANSI A number that identifies an entry in the Address Book system. Use this number to identify insurance companies.
INSP A 25 digit alpha-numeric field with special characters allowed.
1 - General Policy. Use this policy for all customers. 2 - Single Policy. Use this policy for a single customer so the system will use the credit insurance insured amount (F03B29.INA) instead of the credit limit on the customer master (F03012.ACL) for the credit limit to be used in credit checking. 3 - Single Policy No Credit Check. Use this policy so the system will
F03B29 Policy Type Credit Insurance
IPT
14/39
27/08/12
Document
check the standard credit limit (F03012.ACL) instead of the insured credit limit (F03B29.INA).
Customer Number Effective Date Ending Date Insured Amount Currency Code Insurance Premium
F03B29 Credit Insurance F03B29 Credit Insurance F03B29 Credit Insurance F03B29 Credit Insurance
AN8
The address number of a customer for whom the Insurance is applicable [applicable for Policy type 2 and 3]. Date the insurance policy becomes effective.
DEF
END Date the insurance policy expires. The maximum amount covered by an insured Company if the customer fails to pay.
INA
F03B29 Credit CRCD The currency in which the amount is insured. Insurance F03B29 Credit Insurance IPA The fee paid to an insurance company to Purchase a credit insurance policy.
The percentage of the customer's open, unpaid balance that is F03B29 Percentage insured by the policy. For example, if 50 is entered, the insurance Credit COVP Covered policy pays 50% of the customer's total open amount. The value Insurance entered in this field is for information only.
Example of Credit Checking with Credit Insurance

Customer 5228 has a credit limit set of 10.00 in the customer master credit tab.
Customer has a currency of USD in the invoices tab.
Customer contains a record in P03B2901 showing they are covered by a 10,000.00 USD credit insurance policy (Type 2).
15/39
27/08/12
Document
Credit check inquiry for customer 5228 shows the value of $10,000 USD populated in the credit limit, not $10.00 USD.
Create a sales order for 100.00 USD for customer 5228. This is greater than the credit limit on the customer master (10.00 USD), but less than the insured amount in the credit insurance table (10,000.00 USD). The order does not go on C1 hold.
Credit check inquiry shows customer is 9,900.00 USD under the credit limit defined by the credit insurance insured amount.
16/39
27/08/12
Document
Change the policy from type 2 to type 3.
Now credit check inquiry shows the credit limit is 10.00 USD from the customer master, not 10,000 USD from the credit insurance insured amount.
17/39
27/08/12
Document
Create another order for 100.00 USD. The order goes on C1 hold based upon the credit limit on the customer master.
Credit check inquiry now shows the customer is 190.00 USD over the credit limit.
18/39
27/08/12
Document
Back to Top
Using Credit Checking with Multi-Currency

When using multi-currency the customer master will display two additional fields. The currency code field identifies the customers currency. Populating the customer master currency code field will cause the currency code value to automatically default into the sales order. The A/B amount codes field controls what currency will be used to display the credit limit and financial data in the credit check inquiry. Most of the time the default domestic currency will be used for credit checking.
In this example the credit limit is set to 25,000 CAD.
19/39
27/08/12
Document
Using the credit check inquiry (P42050) directly

If check credit inquiry (P42050) is used from the menu or the fastpath, it will always display in domestic currency of company 00000. In this example, notice the domestic currency of company 00000 is (USD) and the amounts are displayed in domestic (USD) currency. Note the credit limit is converted from (25,000 CAD in the customer master) to (16,666.67 USD in the check credit inquiry).
From the credit check inquiry screen change the company to 00077 and Take the Row Exit to Retrieve AR.
The system will then return the values in the currency of the Canadian company (CAD).
20/39
27/08/12
Document
Using the Customer Credit Check Row Exit from Customer Service
Find a sales order that was created in a company with a different currency than company 0000. Take the row exit for credit check.
Notice that the currency displayed in the credit check screen is for the base company of the order rather than company 00000.
21/39
27/08/12
Document
Back to Top
Using Parent-Child Credit Checking

Setup a credit limit on the parent customer address number company 00000 record. Multiple child customer addresses can be setup under the parent customer with no credit limit populated. When reviewing the credit check inquiry (P42050), both parent and sold to (child) addresses will be populated. The credit limit will be retrieved from the parent customer master company 00000 records (F03012). The open order amount will come from the sum of the child customer master records APRC (F03012) for that parent. The amount due and aging period amounts will come from the sum of the unpaid invoice records in F03B11 for that parent.
Child Customer(s) Setup

In menu G4221, customer billing instructions add 52251 as a customer. On billing page 1, set the billing address type = X, related address number = 2 (address number 2) and credit check level = P (parent of sold to).
Return to customer master and take the form exit to A/B revision. Populate the parent address (52250) in 2nd address number field. Click OK to save.
22/39
27/08/12
Document
Return to the customer master screen, select the invoices tab, and populate the parent number field with the parent address (52250)
Verify there is no credit limit set on the child customer master on the credit tab.
23/39
27/08/12
Document
Go into the P42050 credit check inquiry for child customer 52251. Notice the credit limit is populated with the credit limit value of $2,000 from the parent address (52250).
Go through the same procedure to create address 52252 as a child customer. Credit check inquiry for child customer 52252 will also show the credit limit is populated with the credit limit value of $2,000 from the parent address (52250).
24/39
27/08/12
Document
In sales order entry, with C1 hold activated, create an order for $1,200 for child customer 52251 and 52252 and reinquire. The order for child customer 52251 is not on hold, but the order for child customer 52251 is on C1 hold because it puts the parent customer (52250) over its credit limit of $2,000.
The credit check inquiry for shows child customer 52251 shows is over their credit limit by $400 because it uses the sum of the orders for all children under the parent address.
25/39
27/08/12
Document
The credit check inquiry shows child customer 52252 is over credit limit by $400 because it uses the sum of the orders for all children under the parent address.
Back to Top
Retrieving AR Amount in Parent-Child Credit Checking

Notice when performing the credit check inquiry on one child sold-to address that the open order amount displayed is for the sum of all open orders under the parent, but the AR amount due field gets populated with the amount of the child address only. To display all rolled up AR amounts due on the parent use the retrieve AR row exit
Example: retrieving AR amounts due

Parent customer is 52270 and two child customers are 52271 and 52272. Two open orders exist for child customers 52271 and 52272 and two closed orders exist for parent 52270 and child 52271.
26/39
27/08/12
Document
Go into Customer Ledger Inquiry (P03B2002) enter the parent 52270 and click find. See that 52270 (parent) has an AR invoice of and 52271 (child) has an AR invoice of and child 52272 has no open AR invoices.
On customer service inquiry, select order for 72272 and take row exit to credit check.
27/39
27/08/12
Document
The credit check inquiry displays open order amount of 1,200 which includes the open orders for both child customers, but the AR amount due is blank, which is the AR amount for 52272 but does not include the AR amounts for 52270 and 52271. In order to roll up all the AR amounts under the parent, take the retrieve AR form exit.
After retrieving AR, the amount due field shows a value of $700.00 which includes the AR invoice for the parent 52270 of $200, and the AR invoice for child 52271 of $500.00.
28/39
27/08/12
Document
Back to Top
Using Credit Checking with Line of Business Customers

Line of Business is Activated in P0000 Accounts Receivable Constants Form W000C (Enhanced AR Constants). The decision to use Line of Business is made prior to the creation of any transaction data in EnterpriseOne. Setup one customer address and it will be created with company 00000. Then add additional customer master line of business records for other company numbers.
Each customer master company record can have its own credit limit, currency, credit manager, collection manager and other unique values. Line of business customers can be used with any of the credit checking levels (P, C, S or L). Using credit check level L will cause the credit limit on the customer/company record, known as the line of business to be evaluated.
Line of Business (LOB) Customer with Credit Check Level L

Enter a sales order for a company with the LOB record setup. The credit check inquiry will add the order total to the open order amount (APRC) in the customer LOB record. This total will then be compared against the credit limit on the LOB record that matches the order company. The order goes on credit hold if it causes the total exposure to exceed the credit limit on the customer LOB record. Only one address book number needs to be created for the new line of business customer.
Add a record to customer master (P03013) for company 00077 (Canadian company) and populate the currency code as CAD.
29/39
27/08/12
Document
On the credit tab, populate credit limit of 2,000 CAD, use credit manager 2.
On the billing information page set the credit checking level to L (line of business).
30/39
27/08/12
Document
Follow the same steps to create a customer master (P03013) for company 00001 (US company) and populate the currency code as USD. On the credit tab, populate credit limit of 2,500 USD, use credit manager 1.
Notice in customer master inquiry (P03013) there is three LOB records, company 00077, company 00001, and company 00000.
In customer credit check inquiry (P42050) only two of the LOB records have credit limits populated, company 00077 and company 00001.
31/39
27/08/12
Document
Create two sales orders for company 00077 Branch 77 for 1,200 CAD, The second order goes on hold, because it puts the customer LOB over the 2,000 CAD LOB credit limit.
The credit check inquiry shows customer is 400 CAD over the limit for customer in the Canadian LOB (company 00077).
Create two sales orders for company 00001 branch 20 for 1,200.00 USD, The neither order goes on hold, because the customer credit limit in the company 00001 LOB is 2,500.00, but orders total $2,400.00.
32/39
27/08/12
Document
The credit check inquiry shows customer is 100.00 USD under the limit for the customer in the company 00001 LOB.
Line of Business and Credit Check Levels

Line of business is an accounts receivable feature allowing a customer to have different accounts receivable values for different Companies, such as: Default payment terms can be different by company Default payment instruments can be different by company. Default sales rep commission codes can be different by company Just because the customer master has LOB records, the credit check level does not have to be set to L. The credit check level can be P (parent level) or C (customer level) or S (sold to address). S and C have the same functionality. If customer master LOB records are setup with P or C or S credit check levels, the sales order total exposure will be compared with the credit limit from the company 00000 record, not the LOB record. Note: Using companies with line of business activated, when setting up customer master records with different Credit Check Levels (C and L), the system will include the open order amount of the L credit check level records in the calculation of the APRC (Open Order Amount) field. (Please see Bug 13825329 - CREDIT CHECKING WITH LOB AND DIFFERENT CREDIT CHECK LEVELS for more details on the setup.)
For example: Customer A contains records in three companies (00000, 00001, 00200). For company 00000 and 00001, the Credit Check Level is set to C (Customer Sold To) and for company 00200, the Credit Check Level is set to L (Line of Business). For company 00001, the APRC amounts of all three customer master rows (00000, 00001, 00200) will be summed up and displayed as the Open Order Amount for the company. As company 00200 also comes under the same customer, its open order amount will also be taken into consideration (irrespective of the credit check level of this particular company) while calculating the total Open Order Amount for the customer in 00001. For company 00200, only the APRC amounts of 00200 customer master records will be summed up and displayed as the Open Order Amount for the company, due to
33/39
27/08/12
the L Credit Check Level.
Document
Enhancement Bug 13887437 - ENH CREDIT CHECKING WITH LOB AND DIFFERENT CREDIT CHECK LEVELS was entered requesting for the L Credit Check Level records not to be included in the calculation of the Open Order Amount APRC field of C customers. Back to Top
Workflow for Approval of Credit Limit Changes

If not able to change the credit limit, check to see if workflow is on for CREDLMT. Please refer to Doc ID 637171.1 Credit Limit with Threshold Distribution List for setup and troubleshooting information. Back to Top
Troubleshooting Credit Checking

If orders dont go on hold, check the following:
1. Order payment instrument is "prepaid" (special handling code has 11, 12 or 13 in UDC 00|PY). Prepaid orders will not go on credit hold. 2. Payment terms preference is activated, selecting a "prepaid" payment instrument. 3. Order is "future committed". Check commitment days in branch plant constants and requested date on order. Future committed orders will not go on credit hold. 4. Credit hold exempt flag (EXHD) is checked in customer billing instructions. 5. Make sure the branch plant has the hold code setup in order hold constants (P42090). It the hold code is not setup for the branch plant, the order will not go on credit hold. 6. Check the credit insurance policy (P03B2901) program to see if a type 2 insurance policy setup for the customer. If the customer F03B29 record has a policy type (IPT) of 2 and an insured amount (INA) greater than 0, the RetrieveCustomerMasterAmounts business function (B0100081) will retrieve the credit limit value setup in F03B29.INA instead of the credit limit value setup in F03012.ACL. 7. When using batch credit checking (R42542) to apply aging holds, a requested date in the distant past can cause the aging hold to not be applied. Verify if the past requested date is the cause by populating the as of aging date in the credit check inquiry and using the retrieve A/R form exit to see how the aging period amounts are populated. To correct the problem try resetting the requested date to todays date or a date in the near future if the batch credit checking (R42542) does not apply the aging hold.
If orders go on hold that shouldnt go on hold.

1. Check customer billing instructions, billing page 2. Is the hold code populated there? This will cause orders to go on hold even when the customer is not over their credit limit. 2. Check customer billing instructions to see if credit check level (ARTO) is L (line of business) or P (parent). The line of business record or parent customer record may have a lower credit limit populated than the sold to address on the order. 3. Check the credit insurance policy (P03B2901) program to see if a type 2 insurance policy setup for the customer. If the customer F03B29 record has a policy type (IPT) of 2 and an insured amount (INA) greater than 0, the RetrieveCustomerMasterAmounts business function (B0100081) will retrieve the credit limit value setup in F03B29.INA instead of the credit limit value setup in F03012.ACL. 4. Always go to the credit check inquiry (P42050) first if a user claims an order is going on hold that shouldnt. On the credit check inquiry Screen does it show an amount in the over credit limit field? Use the values in the credit check inquiry to determine if the order should be on hold. 5. Remember if aging criteria is populated on the order hold constants, the order may be going on hold for aging reasons rather than because the credit limit is exceeded. The as of aging date for any order is the requested date. Verify if a future requested date is the cause of an order going on hold by populating the as of aging date in the credit check inquiry and using the retrieve A/R form exit to see how the aging period amounts are populated. 6. Be aware that a credit order where money is owed to the customer may go on credit hold. Unless the credit is for more than the over credit limit amount, a credit order will still go on hold if the hold code is populated in the P4210 order holds tab for the credit order version. Back to Top
Frequently Asked Questions

Question 1: Is possible for a customer to place an order if they have exceeded their credit limit/aging credit? Answer 1: Yes this can be accomplished with a C.O.D (cash on delivery) order. To create a cash based payment instrument, make sure that in the 00/PY UDC table (payment instrument), the first character in the special handling code must = "1". Then when the order is created, the cash payment instrument can be populated in the order header. Back to Top Question 2: Are backordered lines with no extended amount considered in placing an order on credit hold? Answer 2: The full amount of all order lines is considered for credit checking. The amount populated in the field OTOT in the order header (F4201) is used to check the credit for the specific order, not the sum of extended amount fields (AEXP) on the order detail lines (F4211). Back to Top Question 3: Should credit orders with negative amounts go on credit hold where money is owed to the customer? Answer 3: Yes. Unless the credit order is large enough to offset the amount over the credit limit, the credit order will go on hold. This will allow the credit manager the opportunity to review the customer's credit and past due accounts receivable before processing a financial credit. Back to Top Question 4: Will zero dollar orders go on hold?
34/39
27/08/12
Document
Answer 4: While performing interactive sales order entry (P4210) and entering Zero dollar orders the order will not go on credit limit hold, but if the aging criteria is exceeded at the time the order is entered, they will go on aging hold. Also, if the Batch Credit Hold Processor (R42542) is run over the same zero dollar sales order, the order will go on credit hold. Sales Order Entry (P4210) and the Batch Credit Hold processor (R42542) have different design features relative to zero dollar sales orders. The Sales Order Entry (P4210) application is designed not to do credit check when the order amount equals zero. This functionality was established many years ago. The Credit Hold Batch Processor (R42542) is designed with a narrower focus. It is not intended as an alternative to Sales Order Entry (P4210) and should not be compared with it. R42542 is for the specific purpose of applying a credit hold to existing open orders. If customers are over the credit limit, the orders will be placed on hold regardless of the order amount. Back to Top Question 5: Is it possible to eliminate sales quotes from being included in the Outstanding Orders and total exposure for credit checking? Answer 5: Yes, if in the processing options behind the version of Sales Order Entry used to create sales quotes set Processing Option # 2 on the commitment tab to be committed to Other Quantity 1. This effectively stops the order total from being considered as an open order on the check credit program, and therefore does not include the amounts on a quote order in the total exposure. When that quote order is then converted to a regular sales order, make sure that the quantities are committed correctly at that time. Back to Top Question 6: Is there a report available showing all the credit limit changes made for auditing purposes? Answer 6: There is no standard report to show credit limit changes. When a credit limit is changed, the old credit limit data is not written to an application database table. Therefore the data is not available even to write an audit report showing changes to credit limit history. Because the data does not get captured, it would not be possible to create a report like this in EnterpriseOne. Possible Workaround: Through JDE EnterpriseOne interop capabilities, all customer master table changes can be written to F03012Z1 table. This would write a record to the table any time a change is made to any field in the customer master; it is not restricted to just the credit limit field. On the version of the customer master, master business function, P0100042, we have a processing option for Outbound Transaction Type. Populate this processing option with JDECM. The next processing option on that tab allows user to write before and after images. With these options populated, records will be written in the F03012Z1 every time a record is changed in the F03012. A number of applications call the customer master MBF. Ensure each application that calls a version of the MBF indicates the correct version. Otherwise, change records will not be recorded. Once the data is captured in the F03012Z1 a custom report could be created to show the changes in the credit limit. One drawback to this approach is there may be performance issues since there are a number of programs that call this MBF and would be writing additional data. Back to Top Question 7: In customer master, credit tab, the credit message (CM) field is populated. When the P42050 customer credit check inquiry is run, for some customers the credit message is not displayed on the inquiry screen. On other customers the credit message is displayed. Answer 7: Caused by the fact the customer is not over the credit limit. Credit messages will not be displayed in the credit checking screen, when the customer is not over the credit limit. Back to Top Question 8: The Release Held Orders (P43070) program has a Credit row exit that takes the users to the Credit Check Inquiry (P42050). If the user finds an order on C1 hold and takes the row exit, the Credit Check Inquiry (P42050) displays for the correct customer, but if the user closes P42050, returns to the Work with Release Held Orders screen, selects a different order with a different customer, and takes the Credit row exit again, the previous customer credit check screen is displayed instead of the correct customer. Why does this occur? Answer 8: This is caused by an incorrect setup in P42050 Version ZJDE0001. The Release Held Orders (P43070) program is hard coded to call P42050 Version ZJDE0001. In P42050 Version ZJDE0001, Process Tab Option #1 was set to 1 (Activate Customer Self-Service functionality for use in Java/HTML). This setting is to be used only for Customer Self-Service Portal. To correct the setup, change Process Tab Option #1 from 1 to Blank. The Credit Check Inquiry will work correctly when Process Tab Option #1 = Blank. Back to Top Question 9: If an order has multiple lines and each line has a different scheduled pick date, how will the order get released? Answer 9: The R42550 batch credit release will use the order line with the earliest pick date to release the order and ignore the pick dates on the other lines. Back to Top Question 10: Do invoices generated from Contract/Service Billing affect the period buckets on the P42050 Credit Check screen? If they are included in the period buckets, at what point do they start to be included in those buckets, or what process has to run for them to be pulled into the P42050 inquiry? Answer 10: Contract/Service Billing does create invoices in A/R, but the total of those transactions would not be included in the APRC (Open Order Amount) value that value only includes open sales orders. Accounts receivable can get invoices from a number of 'sources' including sales transactions, contract billing, service billing, EDI, and batch invoice processing. So, in order for the contract/service billing invoices to be included in the buckets, the invoices have to be generated into A/R by R48199 Create A/R Entries. Then, these invoices will age like invoices created purely in A/R. The buckets would include the invoices once they hit the F03B11. The P42050 (Form W42050B) will display all aging amounts from F03B11, regardless of the source of the invoice.
35/39
27/08/12
Back to Top
Document
Question 11: When a new invoice record (F03B11) is added to a parent customer, the amount due field in the Credit Check Inquiry (P42050) is increased by double the amount of the invoice just created. This only occurs when the Customer for the invoice happens to be a Parent customer and when Parent Level Credit Checking is activated on the Parent Address. When adding an invoice for a child address, the amount is not doubled. It appears that the amount calculated by AccumulateARBalance business function (B4200510) used by the Credit Check Inquiry (P42050) is being doubled when the invoice is both the customer (AN8) and the parent (PA8) address. Is this a bug or a setup problem? Answer 11: The issue is caused by an incorrect setup in the address book (P01012). In the Address book for the parent address, the Related Address book tab had the Parent address set as itself, this caused the doubling of the invoice amounts. To resolve this, remove the address value from the Parent number field, in the Related Address tab of the address book record for the Parent. The Parent Number for a Parent Address Book record should remain blank and not be populated. Back to Top Question 12: When a Sales Order is released from Credit Hold, the R42550 does not calculate or display the Customer Exposure on the R42550, Release Credit Hold, PDF report. Why would the Customer Exposure be blank? And why doesn't the Customer Exposure on the R42550 equal the Total Exposure in the Customer Credit Check screen (Row exit in Customer Service Inquiry, P4210 > to Customer Credit Check)? Answer 12: This is a known issue reported in "Bug 13507254 - R42550 CUSTOMER EXPOSURE NOT CALCULATED". This is a problem that affects the report PDF output only when Print Tab option #1 (Print financial amounts on the report) is set to Blank. If the setting is 1, the Customer Exposure information will be suppressed from printing. This issue does not affect the ability of the program to perform credit checks and correctly release orders from credit hold. Because of several problems identified related to processing the printed output it was determined that the UBE will need to be redesigned. Enhancement bug "Bug 13706303: OPEN ISSUES IN UBE R42550 RELEASE ORDER HOLDS" outlines the redesign proposal. The suggestion in the Enhancement is to make Customer Exposure =[Open Order Amount + Amount Due of customer which is the same calculation in the Customer Credit Check Total Exposure. Back to Top Question 13: If a user of CRM Sales Order Entry (P42101) selects multiple order records from the the grid and takes the Row Exit to Customer Credit Check the Cancel (X) button on the Credit Check (P42050) form will not allow the user to return to the sales inquiry screen, forcing the user to logout to exit. Answer 13: When multiple records are fetched for the Credit Check Inquiry (P42050) then multiple Credit Check screens are opened and each screen that was opened must be canceled before the user will be returned to the inquiry screen. For example if you fetch 500 records and take the Row Exit to Credit Check, there will be 500 credit check forms opened and you will have to click cancel 500 times before you will be returned to the Sales Order Entry screen. This was reported in Bug 10958513 - CAN'T EXIT FROM CREDIT CHECK - SAR: 8470197 and closed as functioning as designed. Back to Top Question 14: A sales order that has already been invoiced and was not on hold goes on credit hold if a change is made to the price after invoicing but before sales update. Why doesn't credit checking skip already invoiced orders? Answer 14: Whenever a change is made to the price on an open sales order, credit checking will be processed regardless of whether a sales invoice was previously sent. This was reported in Bug 10954070 - CREDIT CHECK FOR INVOICED SALE - SAR: 8418612 determined to be functioning as designed. Back to Top
To discuss information further with Oracle experts and industry peers, we encourage you to review, join or start a discussion in the JDE1 Distribution Community. To look at upcoming or archived Advisor Webcasts please see Advisor Webcast Details (Doc ID 548764.1) if your topic is not currently scheduled please suggest it.
ODS-01-0094
References
BUG:13887437 - ENH CREDIT CHECKING WITH LOB AND DIFFERENT CREDIT CHECK LEVELS @ BUG:8951490 - CAN EDIT A MODEL NAME TO EXISTING NAME AND SAVE SUCCESSFULLY NOTE:1342177.2 - Information Center: JD Edwards EnterpriseOne Sales Product NOTE:1346684.2 - Information Center: Using JD Edwards EnterpriseOne Sales Product NOTE:637171.1 - E1: 03B: How To Credit Limit with Threshold Distribution List BUG:10860799 - TAX AND CREDIT CHECKING - SAR: 7318345 BUG:11055570 - R42542 AND STATUS UPDATE - SAR: 8975893 BUG:13452678 - P42050 - REQUEST OPTION TO DISPLAY VALUE IN A/B AMOUNT CODE CURRENCY BUG:13507254 - R42550 CUSTOMER EXPOSURE NOT CALCULATED NOTE:625508.1 - E1: 42: Credit Checking (P4210/P42101/R42542/P43070/R42550) BUG:13706303 - OPEN ISSUES IN UBE R42550 RELEASE ORDER HOLDS. BUG:13825329 - CREDIT CHECKING WITH LOB AND DIFFERENT CREDIT CHECK LEVELS
36/39
27/08/12
Document
37/39
27/08/12
Document
38/39
27/08/12
Document
39/39

Credit Checking

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Credit Checking

Diunggah oleh

Hak Cipta:

Format Tersedia

27/08/12

E1: 42: Credit Checking (P4210/P42101/R42542/P43070/R42550) [ID 625508.1]

Understanding the Customer Credit Check Inquiry (P42050)

F03B11 Customer Ledger and F0010 AR Constants

F03B11 Customer Ledger

F03B11 Customer Ledger and F0010 AR Constants Calculated

F03012 Customer Master by Line of Business

Calculated F03012 Customer Master by Line of Business

AMTU Sum of amount due plus open orders.

Average Days Late

F03012 Customer Master by Line of Business

F03012 Customer Master by

Invoiced This Year

Invoiced Prior Year

F03012 Customer Master by Line of Business

Last Applied Amount

F03012 Customer Master by Line of Business

F03012 Customer Number of Master by Open Drafts Line of Business

F03012 Outstanding Customer Draft Master by Amount Line of Business

Example of How to Verify the Aged Accounts Receivable Amounts

How to Setup and Test a Credit Limit Hold

Credit Checking Levels

To Setup the Customer Master for Credit Checking

Setup the credit limit in the customer master credit tab.

To Setup the Hold Code for Credit Limit Checking

Using Credit Limit Batch Processing (R42542)

How to Setup and Test an Aging Hold

Order Requested Date and Aging Holds

Branch Commitment Days and Credit Checking

Releasing Orders From Credit Hold

Using Release Held Orders Program (P43070)

Using Batch Credit Orders Release (R42550)

Differences Between R42550 and P43070 for Releasing Credit Holds

R42550 does not perform Aging Checking

R42550 will Release Customer Billing Instructions Credit Holds

Held Orders Table (F4209)

Using Credit Checking with a Credit Insurance Policy

INSP A 25 digit alpha-numeric field with special characters allowed.

F03B29 Policy Type Credit Insurance

Example of Credit Checking with Credit Insurance

Customer has a currency of USD in the invoices tab.

Change the policy from type 2 to type 3.

Using Credit Checking with Multi-Currency

In this example the credit limit is set to 25,000 CAD.

Using the credit check inquiry (P42050) directly

Using Parent-Child Credit Checking

Child Customer(s) Setup

Retrieving AR Amount in Parent-Child Credit Checking

Example: retrieving AR amounts due

Using Credit Checking with Line of Business Customers

Line of Business (LOB) Customer with Credit Check Level L

Line of Business and Credit Check Levels

Workflow for Approval of Credit Limit Changes

Troubleshooting Credit Checking

If orders go on hold that shouldnt go on hold.

Frequently Asked Questions

Anda mungkin juga menyukai