Skip navigation

In Document Troubleshooting General Inventory (Doc ID 1552907.1), section Miscellaneous Issue 1 it states that the 2720 error will be resolved if you 'have both the current and the next fiscal years set up and we suggest that five years are created in this calendar and two years back.'


You have these past and future date patterns set for your company and yet you still receive the 2720 error when inquiring in the P4115 - Buyer's Information program.  Why are you still getting this error?


The 2720 error may still be generated even though you have the required past and future years set up in your Company Date Pattern Revisions.  This situation can occur when the Default Value of Data Dictionary Data Item #CYR is set with too low a value.  The default value in #CYR determines the last year of a floating 100 year window.   This is a newly discovered reason for the 2720 error and as a result information specific to this situation has been added to document 1552907.1.


Please be aware that when you change your #CYR Default Value you then need to run the P4028 - Effective Thru Date Update as noted in document 656831.1. The P4028 will update effective through dates of your existing records.


For more information related to #CYR, see document Effective-Thru Dates and #CYR P4028 (Doc ID 656831.1) and Effective-Thru Date and #CYR (P4028) FAQ (Doc ID 2355169.1).

All companies that uses JD Edwards software also purchase goods from various suppliers. These could be office supplies used for daily operations or could be raw materials used in a manufacturing process along with a long list of other possibilities.  You may also purchase the same material / item from more than one supplier.


But what happens when a supplier you have used in the past is no longer an option for these purchases?  There could be many reasons for this change, such as that supplier no longer carries the item or can no longer deliver the items in a timely fashion and you need to use a more reliable source.


Regardless of the reason, you need a way to block entry of new purchase orders for this specific supplier and since you use the JD Edwards World Procurement system for making these purchases you ask:


"What are your options for preventing creation of purchase orders from a specific supplier in JD Edwards World?"


The answer is dependent on your JD Edwards World release level as functionality related to this has changed.


The answers can be found in the following documents:


  • FAQ General Procurement (Doc ID 1534609.1) Question/Answer #2 provides the available options and workarounds based on your release level.
  • How to Prevent Creation of an Order for a Specific Customer or Supplier (Doc ID 1177503.1) provides similar information but also discusses prevention of sales orders again based on your release level.
  • How To Prevent Purchase Orders To Unauthorized Vendors? (Doc ID 1303709.1) provides additional detail specific to the functionality added in Release A9.1.


As you will see by reviewing these documents, prior to A9.1 the process was more of a workaround whereas in A9.1 and newer releases, you can actually 'deactivate' a supplier by setting the Hold Purchase Order flag in Address Book.

You may run into this periodically when running the P470412 and wonder why are you getting error 2475 - PO Line already Matched when the line you are attempting to voucher has not been matched?  You can inquire on the order/receipt in P4314 (with Match Type = 1) and it pulls in the sub-file data verifying the detail lines are available for / ready for voucher creation.  So why do you get this error?


There are a few reasons why you may be getting this error.  One of the most common and most missed reasons for this error is you are attempting to create a voucher for a partial receipt and the F47042 field 'No of Lines' (SZNLIN) does not have the correct value.


Details on this answer along with the other possible causes are detailed in WS: 47: Troubleshooting Inbound EDI Transaction Sets (Doc ID 1559493.1).


If you would like even more information on this and other errors as well as general information on the P470412, use the link below to view the recent Advisor Webcast on World program P470412.


Advisor Webcast Recording: JD Edwards World (JDE World) - JD Edwards World SCM Tips for Troubleshooting of P470412 Inbound 810: Invoice with Receipt Match held on April 16, 2019 [Video] (Doc ID 2502711.1).

Approval of purchase orders is a common, highly used process in World Procurement with many companies using multiple differing Approval Routes to establish and direct the approval requests to the appropriate levels / persons for approval.


Occasionally, due to attrition, change of responsibilities or changes in the level of approval needed, you may find you need to make changes to the 'approvers' on an approval route or may even need to delete an existing approval route as it is no longer needed.

When these changes/deletions are attempted, you may run into error 2788 - Delete Not Allowed, blocking you from making this change.


The Data Dictionary defines the 2788 error as follows:

Cause. . . . The person that you have attempted to remove from the approval table has pending orders which require his/her approval or rejection.
Resolution . . Either change the person responsible for the pending orders, or wait until the orders have been approved or rejected.


Note :  The "Orders Awaiting Approval" screen (P43081) is a helpful tool in determining which orders are awaiting approval by a specific approver.


So how do you resolve this error and continue on with you updates/changes/deletions to these approval routes?


As stated in the error text, this error is generated because the person or route you are attempting to change/delete has orders pending approval.  An Approval Route cannot be deleted, nor can an approver be removed from an Approval Route when the approver has orders pending their approval.


Troubleshooting Approval Processing Issues (Doc ID 1547635.1) addresses the 2788 error and provides options for making the desired changes or deleting the approval route.


The first step is to identify the approver who has a pending approval request and as the Data Dictionary error information states, the Orders Awaiting Approval screen (P43081) is a helpful tool in determining which orders are awaiting approval by a specific approver.  Another option for identifying these approvers is to review the data in the F4209 – Held Orders file.  A record in this file designating approval is pending from a specific approver is identified by a value of 2N in HOASTS - Approval Status field.


Once you have identified which approvers have orders awaiting their approval (App Sts = 2N), you have the following options:

  1. Have this approver actually approve or reject any pending approvals for the related route.
  2. Use the Approval Delegation process/program P43280 so that all orders pending this person’s approval can be delegated to a different approver.  The new approver can then approve or reject any orders that are pending their approval.
  3. If your intent is to delete the entire approval route, you will need to use one of the first two methods to approve / reject all orders that are pending approval for this route.  The existing approver must approve or reject all pending orders before you can remove him or her from the route or delete the entire route.   An Approval Route cannot be deleted, nor can an approver be removed from an Approval Route when the approver has orders pending their approval.


Once all pending approvals have been acted upon so that there are no pending approval records (F4209 HOASTS = 2N for this route), you can go to the P43008 - Approval Level Revisions, Inquire on the Order Type & Approval Route Code to pull the Approval Route record into the video and then delete it using the D Action Code. 

Full details on the set up and use of Approval Processing can be found in Approval Processing (Doc ID 626779.1) with additional topics discussed in FAQ: Approval Processing (Doc ID 1535323.1).

Many customers are not aware of the differences between Subcontract Management in World when compared to EnterpriseOne. There are of course many similarities, but it is these differences that require Subcontract data in World to first be converted prior to migrating the data over to EnterpriseOne.


Let’s take a look at some of these differences and similarities.

  • In World, Subcontract Management is System 44 and is separate from the Purchasing system whereas in EnterpriseOne, Subcontract Management is part of Purchasing, system 43.
  • In World, Subcontract orders are created using the P44001 - Subcontract Entry and P4402 - Commitment Revisions programs.  This is not the case in EnterpriseOne where Subcontracts are created using the P4311 - Enter Purchase Orders program.
  • One similarity is that both systems create records for Subcontract orders in the F4301 & F4311 files/tables, however the records are not populated the same for a handful of fields.
    • For example, World Subcontract orders do not have Last/Next Status Codes whereas EnterpriseOne Subcontracts will have a value in the PDLTTR & PDNXTR fields.
    • The conversion process will use information entered in the processing options to add the appropriate Last and Next Status Code values to the World files so that once migrated to EnterpriseOne, they can be further processed to create receipts and/or vouchers.


These are some of the differences dealt with by P44980 - Subcontract Conversion - World to EnterpriseOne.


Previously, document Subcontract Conversion from JD Edwards World to EnterpriseOne (Doc ID 625616.1) has provided the majority of the information and instruction available to assist you in this data conversion. This document has been updated over time to contain new, expanded information, however the process can still be confusing. In addition, this document was originally written for the A7.3 release so a good portion of the information in document would not pertain to you if you are on World A9.4 for example.


To hopefully clear up any confusion related to these differences, similarities and to offer more in depth instruction for the migration process, document Preparing World A9.4 Subcontracts for Conversion to EnterpriseOne (Case Study) (Doc ID 2397295.1) is now available.


This document offers explanation as to:

  • Why this conversion process is required
  • What prerequisites need to be validated
  • Which file ‘Triggers’ are needed and offers the commands to check for, add or delete these triggers
  • Provides step by step instructions for determining processing option settings


So if you are currently in the process of a migration, planning a migration or just considering a move from World to EnterpriseOne and you use World Subcontract Management, please review and become familiar with Preparing World A9.4 Subcontracts for Conversion to EnterpriseOne (Case Study) (Doc ID 2397295.1).  Use this as your guide through the process of setting the P44980 Subcontract Conversion - World to EnterpriseOne program correctly for successful conversion of your World A9.4 Subcontract data so that it can be then be migrated to your EnterpriseOne environment.

Have you gone to a program, performed an inquiry only to be presented with the P00IO - I/O Limit Exceeded window?


The P00IO is related to the number of records that can be read at one time during an inquiry and this can be user defined …with limits.


UDC Table 00/IO holds program numbers and a value for the number of records that can be “read” during the inquiry.  So you may think that making this number as big a value as the field will hold would be a good, one time solution to prevent the P00IO from disrupting your future inquiries.  Well, it is not that simple.  Each program has coding to set the maximum usable digits that can be set in the UDC and if exceeded, the value you enter could be seen by the system as zero.


Here is an example. If you update UDC 00/IO with a value of 100,000 for a program that has a maximum usable digits value of 5, 100,000 will actually be seen as zero.  This is due to truncating 100,000 from the LEFT to reduce the number of digits to the number defined in the program.  In this example, the 6 digit ‘100,000’ value will be reduced by dropping the 1, resulting in ‘00,000’ so the P00IO will be presented for any inquiry in that program. In contrast, if you used 999,999 for the same program, this 6 digit value would drop the left most “9” resulting in a value of 99,999 so the inquiry should produce better results.


So prior to adding new programs to or adjusting existing values in UDC 00/IO, you need to know the maximum usable digits for that program. IO Limit Exceeded Due to Excessive Amount of Records F5 F6 (Doc ID 827483.1) provides details related to how you can search the program code to find the maximum usable digits for the program you are using. Having this information so the program can be properly defined will help you to avoid the P00IO window from popping up in your future inquiries.

Are you running into problems when trying to delete a Purchasing Voucher using Match Voucher to Open Receipt (P4314)?


Are you receiving errors such as 0667: Record Has Already Been Voided/Deleted, 2417: Functional Server Header Level Error or if running an older version of JD Edwards World software Error 2521: Inquiry By Voucher Number Required First?


If so, then you are not alone.  You have a situation where the purchasing voucher was incorrectly deleted (or voided) using an Accounts Payable voucher program rather than the P4314 - Match Voucher to Open Receipt.


When this happens, the accounts payable (F0411) and general ledger (F0911) records are updated, but there is no corresponding update to the purchasing receiver files F43121 & F43121H.  This leaves you unable to delete the “purchasing” voucher as originally intended.


Help is available in both Troubleshooting Voucher Match (P4314) (Doc ID 1531063.1) which contains additional details related to these errors and Recovery of Purchase Order Voucher Deleted or Voided in A/P (Doc ID 626788.1) which provides details on how to correct this situation.


For details on the proper steps to receive and reverse receipts or match and delete purchasing vouchers, please see Reversing/Deleting Vouchers and Receipts in Purchasing (Doc ID 626785.1).


These documents also explain how you can set the processing options of your XT0411Z1 Accounts Payable Functional Server to prevent this from occurring in the future.

Have you struggled for a solution to error message 0027 - User Defined Code Error?  If so, you're not alone. Customers often log service requests and perform searches to understand and troubleshoot this error.


The challenge with the 0027 - User Defined Code Error which states: “The entered code was not found in the User Defined Codes” is that the Item/Account Number (UITM) or Description (DSC1) field is highlighted and neither field is associated to a user defined code (UDC).  Due to this you do not know which UDC is in need of correction.


Troubleshooting Voucher Match (P4314) (Doc ID 1531063.1) provides help with this issue. Section D. Error 0027: User Defined Code Error explains that this issue is new to the A9.2C1 release, and occurs when one of the address book category codes assigned to the supplier is not valid. Document 1531063.1 provides step by step instructions on how to identify and update the UDC table in error so the error is no longer given. The document also contains information about a list of UDC tables that do not contain blank as a valid value.  Adding the “blank” value to these tables may also help correct the 0027 error issue from occurring in the future.

Welcome to the My Oracle Support Community! We highly encourage you to personalize your community display name to make your activity more memorable. Please see for instructions.