| Purpose |
| Questions and Answers |
| Accounts Receivable Next Number Questions |
| Question 1: Have there been any changes pertaining to generation of NN for RC Document type at the time of posting receipt batches? |
| Question 2: How do imbed digits work for the years 2000 to 2009? |
| Question 3: Why does the Invoice Journal Report (R03B305) show error "Error: Out of Balance" for an invoice and a credit memo? |
| Question 4: Is there a fix available on 9.0 release for Bug 11035643? |
| Question 5: Is it possible to set up next numbering so that the receipt number value will be automatically populated and incremented in both Standard Receipts Entry and Speed Receipts Entry? |
| Accounts Receivable User Defined Codes (UDC) Questions |
| Question 1: Where is UDC 03B/AR used? In World Software, UDC table 03/AR is used for write offs, charge backs and deductions. Which UDC table is used for this in EnterpriseOne? |
| Question 2: What is the special handling code in the UDC tables 03B/RC, 03B/CB, or 03B/CR used for? |
| Question 3: What is the purpose of Special Handling Code 99 in UDC 03B/CR? |
| Accounts Receivable Automatic Accounting Instructions (AAI) Questions |
| Question 2: Why is the system using the Customer Master/Address Book BU instead of Invoice Business Unit? |
| Question 3: The Post process is not creating a Sales Tax entry for the account associated with the RT AAI. |
| Question 4: The Posting Edit Code (PEC) for the G/L account associated with an AAI does not allow posting to this account, and sets an error accordingly. |
| Question 5: When entering a G-type receipt, the system triggers errors: fetch from table F0006 failed, Account Number xxxx is invalid, and AAI missing. |
| Question 8: Can the G/L accounts defined on the RY, RZ and R7 AAIs be set up as monetary accounts (i.e. an account where CRCD is not equal to blank)? |
Frequently Asked Questions about Accounts Receivable Setup - User Defined Code (UDC) tables, Next Numbers (NN). Automatic Accounting Instructions (AAI)
Answer 1: The Next Numbers for Cash Receipts generated at the time of posting has changed as of 9.1 under the Enhancement Request Bug 11035643. This enhancement has made the following changes for the receipt postings:
Answer 2: Next Numbers by Company allows the user to imbed the first digit or both digits of the fiscal year into the document number. A seven or an eight digit document number is created when the fiscal year is imbedded into the document number. If Next Numbers by Company is setup with the imbed digit value set to 2, fiscal year = 98, and next number = 33, the document number assigned is 98000037. If the imbed digit value is set to 1, fiscal year = 98, and next number = 47, the document number assigned is 90000047.
Year 2000 - 2009 Functionality:
Fiscal years between 2000 and 2009 contain leading zeros. The ability to imbed the first 2 digits of the fiscal year is not available. For the year 2000, the fiscal year cannot be imbedded into the document number. The data dictionary defines the document number as a numeric field. Numeric fields scrub leading zeros. For those customers who have been imbedding the fiscal year into their document numbers, this will be a change in how the document numbers are displayed. For the year 2000, the absence of the fiscal year will indicate that the documents are for fiscal year 2000. For the years 2001 - 2009, only the second digit will be imbedded (i.e. 1, 2, 3, etc.).
If you need to inquire or report on document numbers chronologically for the fiscal year, you will need to change the sequencing from document number to a date field (i.e. G/L date). This will enable you to provide a list of documents in document number order that are sequential by date.
Setup Alternatives for the Year 2000:
Both alternatives will still require the sequencing for reports and inquiries to be changed to a date field in
order to see document numbers in chronological order across multiple fiscal years.
Answer 3: If the amounts and GL dates are in balance, then a possible other reason is that both the credit memo and the invoice have the same Document Number (DOC) value.
Because their Document Type (DCT) values are different, the system allows the entry into the Customer Ledger (F03B11). But the GL Post (R09801) created one AE journal entry with two records on it, one for the credit memo and the second for the invoice.
This is causing the R03B305 to combine the two AE records for either the invoice or the credit memo, causing the other to show as out of balance.
Answer 4: This issue was fixed at a major release boundary, due to the invasiveness of the fix, and the implications of a change to intercompany postings.
EnterpriseOne believes this change would be disruptive to existing customers on an existing release such as 9.0. It is for this reason, the issue was fixed on 9.1, and was not backported to 9.0 or prior releases.
Answer 5: Next Number settings can be used to automatically increment and populate the receipt number in Standard Receipts Entry (P03B102). There is a processing option in P03B102 that controls whether this will be automatically done during receipt entry. Speed Receipts Entry (P03B0001) does not offer this functionality, so the receipt number would need to be entered manually. For more information about Next Number setup instructions and options for Accounts Receivable, please review E1: 03B: Overview and Set Up of Accounts Receivable Next Numbers and Next Numbers by Company and Fiscal Year (P0002) (Overview and Set Up of Accounts Receivable Next Numbers and Next Numbers by Company and Fiscal Year (P0002))
Answer 1: The UDC table used in EnterpriseOne for write-offs is 03B/RC, for chargebacks is 03B/CB and for deductions is 03B/CR. UDC 03B/AR is not being used anymore.
Answer 2: The special handling code will drive how a couple of fields will get calculated in the statistical history build. If the reason code has a blank value for the special handling code, this amount will accumulate in total amount for bad debt. If the reason code is populated with a '1', this amount will accumulate in the total amount for minor write-off. The statistical history build will create records in the F03B16 and F03B16S. In the F03B16 there are three fields that get populated: RVMWO (Amount Minor Write-off), RVBDBT (Amount Bad Debt), and RVTAWO (Total Amount Write-off). The TAWO is total of the MWO and BDBT.
None of the accounting entries will be any different based on the special handling code. It is just a way for the users to get some information about how much is due to bad debt v. write-offs for other reasons.
Answer 3:
The Special Handling Code value of '99' on Deduction Reason Code values (UDC 03B/CR), designates any deduction records created with that specific Deduction Reason Code value as intended to be sent to the Oracle Demantra system as part of the JD Edwards EnterpriseOne Integration with Oracle Demantra Deductions Settlement Management functionality. Because of this, deductions created with these deduction reason codes will be locked out of the "normal" working process for the deduction manager in P03B40. For more information on the Integration with Oracle Demantra Deductions Settlement Management functionality, please review Chapter 5 of the JD Edwards EnterpriseOne Applications Integration with Oracle Demantra Implementation Guide.
Additionally, if the special handling code of a reason code in UDC 03B/CR is set to 99, then you can’t define a negative deduction amount with that reason code when creating a receipt. In this case the system returns error 156U - Negative Deduction not allowed.
Answer 1: 1. Review of RT AAIs shows only the RT + GL offset AAIs are set up. Client does not have RT <blank> AAI setup for any company and/or company 00000. The post program validates the AAI setup at the beginning of the UBE processing, prior to reviewing the transactions, the associated tax rate areas, and the tax rate area setup. In the client's example, the transactions included tax rate area ABC. In the setup for tax rate area ABC, the GL offset of XYZ was indicated. The client had the RTXYZ AAI set up. The client did not have an AAI for RT <blank>. After setting up the RT <blank> AAI for company 00000, the IB batch posted successfully. The accounting entries were correctly created to the account indicated in the RTXYZ AAI.
Answer 2: While entering the receipt details and when the 'OK' button is clicked in the receipt entry form, the system validates the AAI setup for the specified account through the business function B0000055 (F0012 Get AAI Account Number). To this function the variable VA frm_CustomerBusinessUnit_MCU is passed which is fetched from the customer master.
The system has to evaluate the business unit from the customer master only. This is because if an invoice is created for a customer the client can override the business unit for that invoice. For example, if 2 invoices are created with 2 different business units. And if a receipt is created and the same receipt is matched against with the above created 2 invoices. In that case, it is not possible for the system to map different business unit from two different invoices with a single receipt.
Also, if an invoice is created with multiple pay items, and if each of the pay item is assigned with different business unit, in that case while matching any receipt with that invoice it is not possible for the system to map the business unit correctly.
Due to this scenario, the system is designed in such a way that it has to take the business unit from the customer master and not from the invoice.
Work around: Set up your AAI per company and populate BU, do not leave it blank.
Answer 3: When you enter a voucher or invoice with sales tax, the system calculates the tax amount but does not create a separate entry to the general ledger. The sales tax appears only in the voucher or invoice record. For vouchers, the tax is part of the expense, so you do not need to enter the tax in a specific account. For invoices, however, you might want to track the sales tax in a separate account because you must pay it. In this instance, you would need to subtract the sales tax amount from the revenue and enter it separately. Alternatively, you can use tax explanation code V for the system to record the tax in the account specified by PTxxxx (for payables) or RTxxxx (for receivables), where xxxx is the G/L offset that is entered on the tax rate area.
Answer 4: G/L accounts associated to AAIs are recommended to have a PEC of M for 'Machine generated'; this is to make sure these accounts cannot mistakenly be used for other types of transactions than those they were meant for. Alternatively leave the PEC blank to allow all postings.
Answer 5: Review of R8 AAI shows a blank business unit and object account xxxx.
When a G type receipt is entered, the R8 AAI is validated. If the R8 does not indicate a business unit, then the AAI validation for the business unit field must come from the customer (the Resp. BU on the A/B record for the customer) on the transaction.
Since the customer number is blank, the MCU (F0006) is invalid, the account number is invalid and the AAI is missing.
Answer 6: The R8 AAI is not designed to be set up with a GL offset.
Answer 7: This error with ID 1309 "AAI Account Set Up Error:
CAUSE . . AAI account is not set up correctly for company &2. The currency code associated with the AAI account is invalid.
=> If the account is a monetary account, the account currency code must be the same as the transaction currency code.
=> The currency code of the account's company must be equal to the base currency for the transaction.
RESOLUTION: Change the AAI to use a different account or revise the currency codes involved."
will be set if for either or for both of the companies any of the multicurrency AAIs have a blank in their business unit fields. The multicurrency AAIs are the following:
Note: The RC and RB AAIs are included in this list, because, although not technically multicurrency AAIs, the business unit is mandatory for these as well.
Answer 8: G/L accounts that are defined on the alternate currency AAI items RY, RZ and R7 are not supposed to be set up as monetary accounts. Setting up these accounts as monetary accounts limits the transactions only to the designated currency code, and ALL other currency transactions cannot be posted to the accounts. Therefore it is not recommended to attach monetary accounts to the RY, RZ and R7 AAIs.