Skip navigation

remark.jpgThe remark field (RMK) in the F0411Z1 table is used to populate generic information on the voucher into the F0411 table when the voucher is created using Voucher Match Automation.  This is a generic field that can be used by customers to provide further details on the transaction created at voucher match.  There is no edit or validation on this data item, so users can input any information in this field to further describe the transaction being created, as long as it is within the 30 character limit defined in the data dictionary.  Voucher Match Automation has recently been enhanced to change the functionality of how this field is populated in the F0411 from the F0411Z1 when either a blank value was entered or a manual input was entered either by the user or from a 3rd party system that creates the F0411Z1 record. Prior to this fix, if a blank value was populated in the RMK field in the F0411Z1 table, the Supplier’s Name would always be populated in the F0411 created when running Voucher Match Automation. If multiple F0411Z1 records were processed and the RMK value was manually populated, the same value was populated in all F0411 records that was created.  Normally, when using the Interactive Application (P4314), this value would default from the value input on the PO Header (F4301) and can be manually overridden by the user after selecting the receipt/order to match.  A change was made in the following objects to allow further flexibility when creating a voucher using Voucher Match Automation:


Voucher Match Automation Driver UBE - R4304010

Generate Automatic Voucher Match Cache - B4304000


After this fix, if a blank value is populated in the F0411Z1 table, this blank value will be retained when Voucher Match Automation is ran and the F0411 record is created.  If the RMK field is populated in the F0411Z1 table, either manually by the end user or is brought in from a 3rd party system, this value will be populated in the F0411 table for each F0411Z1 record processed.  This provides further flexibility for customers to properly populate this generic text field in the F0411 to provide more details on the voucher created. Please reference KM Document E1: 43: Voucher Match Automation Retains Blank Value in Remark (RMK) in Voucher Transactions - Batch Upload (F0411Z1) and Accounts Payable Ledger (F0411) (Doc ID 2388687.1 for further details. This includes the link to Bug 27894875 : VOUCHER MATCH AUTOMATION BLANK REMARK IN F0411 & F0411Z1, which fixed this issue.

Managing financial commitments is a very important task for customers needing to track expenditures, either in the public or private sector.  Financial commitments can have a huge impact in controlling expenses for the year and to allow budget amounts to stay on track.  Often times, we see discrepancies between the commitment amounts from what is committed on the order versus the amount open on the order. There can be numerous factors that cause these integrity issues, which can be covered in another topic.  This blog is to provide a best practice for managing these commitment integrity issues and how to properly fix these integrity issues.


Identifying Commitment Integrity:


To properly identify if an account has an integrity issue, it is recommended to run the R40910 (Commitment Integrity Report) on a regular basis.  This report compares data from the F4311 (Open Amount) to the F43199 (PA Ledgers – Committed Amounts), as well as the F43199 (PA Ledgers – Committed Amounts) to the F0902 PA ledger amounts.  This report can be ran to display all accounts, but the output of the report can be greatly reduced by setting a processing option to display only the accounts that have an integrity issue (Processing Option #1 on the Process tab).  It’s often asked how often this report should be ran.  There really isn’t a right or wrong answer to this question.  It really depends on how many transactions are being processed that affect commitments.  For some customers, running this report once a week may be sufficient, while other customers find they have to run it multiple times a day.  What you want to avoid is turning on financial commitments, processing transactions for a year and then decide to run this report. Trying to play catch-up in fixing integrity issues can be a difficult task.  Having recent data in the system will more likely allow for the ability to determine what caused the commitment integrity (process related, data related, etc.).  All batches that affect commitments (receipts and voucher batches) should be posted prior to running this report.  Otherwise, false variance will appear on the output of this report.


Fixing Commitment Integrity Issues:


Once valid commitment integrity issue has been identified, the next steps to resolve the issue is running the purge, rebuild and repost process.  Most customers familiar with processing their financial commitments are familiar with this process, but as a reminder, information on this process can be found in Encumbrance Purge / Rebuild / Repost Process (Doc ID 625633.1).  What I would like to discuss in this blog are best practices when running this process. First, you must decide on what data selection should be used throughout the process.  Was the commitment integrity issue caused by only one document? If so, it may be best to data select on this one document in the R43199P and R00993.  The issue is that the R00932 only allows data selection on the F0901 table, so the account number on the order would need to be known to complete this process.  If you believe this issue may be related to many different transactions, then the account number can be used throughout the entire process.  What should be avoided is running this process wide open and rebuilding and/or reposting transactions that are already correct.  Another piece of advice is to double check that all of the batch applications are properly executing.  Any easy way of doing this is to keep the P40230A open for inquiry during the purge and rebuild process.  Once the R43199P (Purge) is ran, the P40230A should not display any records for that account or document (depending on the data selection used).  These records should reappear when the R00993 is executed. You should also see the program id of the F43199 records being updated with the R00993 value after the rebuild is done.  The same can be said for the F0902 PA ledger records after the R00932 is ran.


Hopefully, the above tips will help you manage your commitments.  Staying on top of these transactions to ensure that the transactions are being processed without integrity issues will make life easier with this complex process.  If you’re new to this process, another helpful document to review is Checklist for Troubleshooting Commitment / Encumbrance Integrity Issues (Doc ID 657403.1).  And as always, feel free to interact with other users in the Distribution - JDE1 (MOSC) Community or work with Global Customer Support by opening a service request to assist with these commitment issues.

Today's business climate is changing very quickly. Many managers and employees may not always be at their desk to perform daily tasks, such as approving purchase orders or requisitions. What if a Purchasing Manager was at home after hours, but a high priority purchase order was entered to request a new server, as a server had crashed?  This new purchase order may require immediate approval, in order to get the order sent out to the vendor.  Before mobile applications, the approvers would either need to drive back into the office or approve the order the next day, which could cause a delay in the order process.  With mobile approvals, this allows end users to immediately take action on the approval request from anywhere in the world that has an internet connection (home, airport, coffee shop, etc.).  EnterpriseOne offers mobile approvals for both a tablet and a smart phone.  This feature is available for standard approvals (system 43) and Requisition Self Service (system 43E).   There are two types of mobile approvals available.  The first, which is the first generation, released back in release 9.0 (commonly referred to as ADF), is really just a link (URL) to a mobile application.  The latest (commonly referred to as AIS), was released in 9.1 and above.  These are actual applications that are downloaded to a device from either the Apple Applications Store or Google Play.  This is the future of our mobile solution and many different applications are continually being released.  I would encourage you to take a look at the mobile approvals, along with many different mobile product offerings in the links below on MOS:

JD Edwards EnterpriseOne Mobile Applications (Doc ID 1637232.2)

Mobile Solutions for EnterpriseOne Applications - What They Are and When to Use Them (Doc ID 2101624.2)

Mobile purchasing and requisition approval applications help to streamline your business by giving users the ability to quickly act on approval requests without having access to a laptop or desktop. Please feel free to share your experiences with these products and as always, please feel free to post general questions in Distribution - JDE1 (MOSC).

Filter Blog

By date: By tag:

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.