credit checking

27/08/12 Document

1/39https://support.oracle.com/epmos/faces/ui/km/DocContentDisplay.jspx?_adf.ctrl-state=dc6xraayb_72

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 laterJD Edwards EnterpriseOne CRM Sales Order Entry - Version XE and laterJD Edwards EnterpriseOne Sales Order Entry - Version XE and laterJD Edwards EnterpriseOne Sales Order Processing - Version XE and laterInformation 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 > Note625508.1

Credit Checking is an EnterpriseOne tool that is used to reduce exposure against customer's accounts receivable. It provides information about a customer’s accountstatus. The system compares the customer's total accounts receivable and open orders to the customer's current credit limit, assigned in the Customer Master, andputs the order on hold based on credit hold set up.

Details

Table of Contents

OverviewUnderstanding the Customer Credit Check InquiryHow to Setup and Test a Credit Limit HoldOrder Requested Date and Aging HoldsBranch Commitment Days and Credit CheckingReleasing Orders from Credit HoldUsing Credit Checking with Multi-CurrencyUsing Credit Checking with a Credit Insurance PolicyUsing Parent-Child Credit CheckingUsing Credit Checking with Line of Business CustomersWorkflow for Approval of Credit Limit ChangesTroubleshooting 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 customer’s accountstatus. The system compares the customer’s total accounts receivable and open orders to the customer’s current credit limit, assigned in the customer master, andputs 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 exceedstheir credit limit, their sales orders go on hold.

2. Aging – Criteria can be setup that causes a customer’s orders to go on hold based on how old the receivables are and what percentage of receivables areallowed 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 anaging 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. Thesystem 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 customerservice 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 todisplay credit checkinginformation 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 datathat is informational only.

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 itemdisplayed on the credit check inquiry is retrieved from.

Field Name TableFieldAlias

Explanation/Example

ParentNumber

F0150AddressOrganizationStructureMaster

PA8Parent number is populated when using Credit checking level P(parent-child) otherwise it is blank.

AddressNumber

F03012CustomerMaster byLine ofBusiness

AN8

Sold to customer address being evaluated.

As of Date

If this fieldis left blank,the systemassignstoday’s date

ASDEThis date is used in determining the number of days past due forany AR invoice (F03B11 record).

Future

F03B11CustomerLedger andF0010 ARConstants

AG

If an invoice past due days falls before the beginning value foraging days in the AR constants (P0000/F0010), the invoice amount(AAP) will be counted in the future aging category.

For example if the current aging period in AR constants is definedto start at -30 days and the customer has payment terms of net60 days, the invoice will be -60 days past due on the day it iscreated and it will fall into the future aging category.

Calculated by AccumulateARBalance business function(B4200510).

CurrentF03B11CustomerLedger

AG1

If an invoice past due days falls between the first and secondaging days values defined in the AR constants (P0000/F0010), theinvoice amount (AAP) will be counted in the current agingcategory.

For example if the first two aging days defined in the AR constantsare -30 and 0, and the invoice is between -30 and 0 days past duethe invoice will be counted in the current aging category.


1-30


AG2

If the second and third aging days defined in the AR constants are0 and 30, and the invoice is between 1 and 30 days past due itwill fall into the 1-30 aging period.


31-60


AG3

f the third and forth aging days defined in the AR constants are 30and 60, and the invoice is between 31 and 60 days past due it willfall into the 31-60 aging period.


F03B11 If the fourth and fifth aging days defined in the AR constants are

27/08/12 Document


61-90CustomerLedger andF0010 ARConstants

AG460 and 90, and the invoice is between 61 and 90 days past due itwill fall into the 61-90 aging period.


91-120


AG5

If the fifth and sixth aging days defined in the AR constants are 90and 120, and the invoice is between 91 and 120 days past due itwill fall into the 91-120 aging period.


121-150


AG6

f the sixth and seventh aging days defined in the AR constants are120 and 150, and the invoice is between 121 and 150 days pastdue it will fall into the 121-150 aging period.


151-199


AG7

If the seventh and eighth aging days defined in the AR constantsare 150 and 999, and the invoice is between 151 and 999 dayspast due it will fall into the 151-999 aging period.


AmountDue

Calculated ADTotal amount due after summing the values from AG through AG7plus future for the particular company inquired.

OpenOrders


APRC

A running total of the open order value for this customer. Thisfield is updated on the customer sold to address record in thecustomer master at the time the sales order is created orupdated.

Currently, the credit checking program does not include taxamounts in the order amount field. Enhancement Bug 10860799:TAX AND CREDIT CHECKING has been raised for this issue but itwas returned as redesign not planned. The tax information is notstored in any tables. Taxes in the system are calculated on the flyin real time. During the invoicing process, taxes will be applied tothe order and printed on the invoice.

TotalExposure

Calculated AMTU Sum of amount due plus open orders.

Credit Limit


Or

F03B29CreditInsurance

ACL

RetrieveCustomerMasterAmounts business function (B0100081)will retrieve the credit limit value setup in F03012.ACL unlessthere is a records setup in the F03B29 credit insurance table.

If the customer F03B29 record has a policy type (IPT) of 2 and aninsured amount (INA) greater than 0, theRetrieveCustomerMasterAmounts business function (B0100081)will retrieve the insured amount value setup in F03B29.INA.

Over CreditLimit

Calculated AOCL Total Exposure - Credit Limit.

ABC CodeSales


ABC1A grade between A and F that indicates the level of sales activityfor a customer. Informational only. Does not affect credit checkinglogic.

ABC CodeInvestment


ABC2A grade from A to D that indicates the level of investment activityfor a customer. Informational only. Does not affect credit checkinglogic.

ABC CodeAverageDays


ABC3A grade from A to F that indicates the average number of days acustomer takes to pay a bill. Informational only. Does not affectcredit checking logic.

AverageDays Late


AVD

The average number or days that it takes a customer to pay aninvoice.

The system calculates the average days late, which is non-weighted, by determining the number of days that each invoicewas past due, and then dividing that number by the total numberof invoices. The system calculates the average days late when theStatistics History Update (R03B16) program is run.

Informational only. Does not affect credit checking logic.

Date ofFirst

F03012CustomerMaster by DFIJ

The GL date of the first invoice generated for this customer.

27/08/12 Document


Invoice Line ofBusiness


Last InvoiceDate


DLIJThe GL date of the last invoice generated for the customer.


Date LastPaid


DLPThe date of the last payment received for this customer.


InvoicedThis Year


ASTY

The amount invoiced for the year. The system uses the grossamount of the invoice record (F03B11) regardless of whethertaxes are included. The system updates this field when StatisticsHistory Update (R03B16) program is run.


InvoicedPrior Year


SPYE

The Invoiced Prior Year (SPYE) field is updated by running theupdate YTD and PYE Amounts (R03B161) program. WhenR03B161 is run, the value from the ASTY field is moved to theSPYE field and the ASTY field is cleared. In addition to theCustomer Master tables, both of these fields are also stored in theA/R Statistical Summary Table (F03B16S).


LastAppliedAmount


ALP

The amount of the last payment applied to invoices based on theGL date of the cash receipt detail record (F03B14). The systemdisplays this information from either the AR statistical summarytable (F03B16S) or the AR statistical history table (F03B16),depending on the form. The system displays information fromF03B16S on the account statistical summary form and informationfrom F03B16 on the periodic statistics form.


Number ofOpen Drafts


NOD

he number of draft records (R1) in the Customer Ledger table(F03B11) that have a pay status not equal to P.


This is displayed only when P42050 Process Tab Option #1 is setto 2 to display draft information. Informational only. Does not affect credit checking logic.

OutstandingDraftAmount


ODAM

The total value of the open draft amounts. Outstanding drafts areconsidered all drafts in Italy and only drafts not yet due in France.


This is displayed only when P42050 Process Tab Option #1 is setto 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.

27/08/12 Document


The customer’s 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. Itcan 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 runagainst 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.

27/08/12 Document


The credit check levels are defined as follows:

P - Credit check based on the credit limit on the sold to customer’s parent customer record in the customer master (F03012).C - Credit check against the credit limit on sold to customer’s record in the customer master (F03012).S – Same as credit check level C.L - Credit check against the sold to customer’s 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

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 setupfor credit limit checking. If using P42101, make sure the P4210 version called in the P42101 processing options has the order holds processing option setup forcustomer 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 theircredit limit before the order was entered even an order for $0.01 will go on hold.

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 versionwith data selection on the customer address book number (AN8).

R42542 credit hold batch PDF will show the C1 hold was applied to several orders.

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 theprocessing 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 puton 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 isthe 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.

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 asof aging date equal to the requested date and not today’s date. This will cause the order to go on C2 hold. The assumption is made that if an order is placed with arequested 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/Rperiod 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 wayto 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 today’s 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.

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 today’s date and a requesteddate of 8/13/2010, which is more than 30 days in the future.

The order goes on C2 hold even though based on today’s date the customer’s 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.

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 agingbucket.

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 thatthe aging is done based on the aging of accounts receivable on the order requested date and not based on today’s 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 R42542batch credit hold may not place the orders on C2 hold if the requested date is in the past, before today’s date. When checking why an order does or does not go onaging 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 ifcustomers 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 ordersrelease 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. Makesure 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. Whenprompted, enter the password. The password screen will appear multiple times for each different branch plant where orders will be released because each branchplant can have a different person responsible for releasing held orders.

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 repostshould 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 modifyany 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 thanthe 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 holdto 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 holdcode and branch plant of orders being released.

The PDF R42550 shows the order was evaluated and displays the message "Order Released".

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 releasethe 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 beautomatically released without requiring a visual verification by the credit manager. The P43070 can be used by the credit manager for exceptional situations where anorder 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 reviewof 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 CreditCheck. 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 immediatelyafter 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 creditlimit, 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 holdcode 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 canbe 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 simplefor a programmer to create a customized purge program using object management work bench (OMW) table conversion design aid. By following the steps in the tableconversion 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 toavoid purging the wrong records unintentionally. Custom purge UBEs are not supported by EnterpriseOne Global Software Support, so this should be taken intoconsideration 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 agreedpercentage 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 CreditInsurance (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 fieldin 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.

FieldName

TableFieldAlias

Explanation/Example

InsuranceCompany


ANSIA number that identifies an entry in the Address Book system. Usethis number to identify insurance companies.

PolicyNumber


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

Policy TypeF03B29CreditInsurance

IPT

1 - General Policy. Use this policy for all customers.

2 - Single Policy. Use this policy for a single customer so the systemwill use the credit insurance insured amount (F03B29.INA) instead ofthe credit limit on the customer master (F03012.ACL) for the creditlimit to be used in credit checking.

3 - Single Policy No Credit Check. Use this policy so the system will

27/08/12 Document


check the standard credit limit (F03012.ACL) instead of the insuredcredit limit (F03B29.INA).

CustomerNumber


AN8The address number of a customer for whom the Insurance isapplicable [applicable for Policy type 2 and 3].

EffectiveDate


DEF Date the insurance policy becomes effective.

EndingDate


END Date the insurance policy expires.

InsuredAmount


INAThe maximum amount covered by an insured Company if thecustomer fails to pay.

CurrencyCode


CRCD The currency in which the amount is insured.

InsurancePremium


IPAThe fee paid to an insurance company to Purchase a credit insurancepolicy.

PercentageCovered


COVP

The percentage of the customer's open, unpaid balance that isinsured by the policy. For example, if “50” is entered, the insurancepolicy pays 50% of the customer's total open amount. The valueentered 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).

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 inthe 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.

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.

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.

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 customer’s currency. Populating the customer master currency code field will cause the currency code value to automaticallydefault 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 defaultdomestic currency will be used for credit checking.

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

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 thedomestic 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 thecustomer 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).

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.

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 withno 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 childcustomer 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 F03B11for 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 (addressnumber 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.

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.

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 populatedwith the credit limit value of $2,000 from the parent address (52250).

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 noton 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 parentaddress.

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 rowexit

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.

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 invoiceof and child 52272 has no open AR invoices.

On customer service inquiry, select order for 72272 and take row exit to credit check.

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 ARamount 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.

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 thecreation 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 thecustomer/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 LOBrecord. 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 totalexposure 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.

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).

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, populatecredit 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.

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 creditlimit.

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 LOBis 2,500.00, but orders total $2,400.00.

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 companyDefault 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 (customerlevel) 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 company00000 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 willinclude 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 - CREDITCHECKING 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 thecompany. 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 ofthis 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

27/08/12 Document


the L Credit Check Level.

Enhancement Bug 13887437 - ENH CREDIT CHECKING WITH LOB AND DIFFERENT CREDIT CHECK LEVELS was entered requesting for the L Credit Check Level recordsnot 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 setupand troubleshooting information.

Back to Top

Troubleshooting Credit Checking

If orders don’t 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 limitvalue 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 thepast 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 periodamounts are populated. To correct the problem try resetting the requested date to today’s 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 shouldn�t 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 overtheir 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 recordmay 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 policytype (IPT) of 2 and an insured amount (INA) greater than 0, the RetrieveCustomerMasterAmounts business function (B0100081) will retrieve the credit limitvalue 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 shouldn’t. On the credit check inquiry Screen does it show anamount 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 isexceeded. 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 asof 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, acredit 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 inthe 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 checkthe 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 managerthe 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?

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 isexceeded 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 becompared 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 onhold 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 tobe 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 notinclude 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 databasetable. 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 bepossible 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 achange 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 processingoption 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 theF03012Z1 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 theMBF 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, forsome 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 notover 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 userfinds an order on C1 hold and takes the row exit, the Credit Check Inquiry (P42050) displays for the correct customer, but if the user closesP42050, returns to the Work with Release Held Orders screen, selects a different order with a different customer, and takes the Credit row exitagain, 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 VersionZJDE0001. 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 beused 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 whenProcess 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 areincluded 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 intothe 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 byR48199 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. TheP42050 (Form W42050B) will display all aging amounts from F03B11, regardless of the source of the invoice.

27/08/12 Document


Back to Top

Question 11: When a new invoice record (F03B11) is added to a parent customer, the amount due field in the Credit Check Inquiry (P42050) isincreased by double the amount of the invoice just created. This only occurs when the Customer for the invoice happens to be a Parent customerand 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 beingdoubled 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 hadthe 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 fora 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 theTotal 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 PDFoutput 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 suppressedfrom 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 "Bug13706303: 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 CustomerCredit 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 CustomerCredit 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 userto 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 wasopened 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 willbe 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 invoicingbut 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 previouslysent.

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 SUCCESSFULLYNOTE:1342177.2 - Information Center: JD Edwards EnterpriseOne Sales ProductNOTE:1346684.2 - Information Center: Using JD Edwards EnterpriseOne Sales ProductNOTE:637171.1 - E1: 03B: How To Credit Limit with Threshold Distribution ListBUG:10860799 - TAX AND CREDIT CHECKING - SAR: 7318345BUG:11055570 - R42542 AND STATUS UPDATE - SAR: 8975893BUG:13452678 - P42050 - REQUEST OPTION TO DISPLAY VALUE IN A/B AMOUNT CODE CURRENCYBUG:13507254 - R42550 CUSTOMER EXPOSURE NOT CALCULATEDNOTE: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

27/08/12 Document


credit checking

Documents