The Encumbrance System

The Encumbrance system is used to recognize expected accounts payable obligations. In this system, the funds become encumbered by use of a purchase order or encumber an account directly within the EN system manually via Create/Update Set (ENBTUB) page. When the item(s) arrive and are invoiced into the system, the encumbrance is cleared. Encumbrances may be fully or partially cleared from the immediate payment system, open hold system, and/or void, typed, and reversed system.

The system will pre-encumber an account per the record's Requested date (pop_rqs_dt column of the pop-pv-dtl table), which is found within the Request tab of the PO Purchase Requests (POUPPR/POUPPE) page. Typically, users will define a Default Rules (NUUPDF) script to default the field to the current date. Yet if the record's Request date is blank, the system will use the current date. The Request date can be defined while creating a record--and is beneficial for creating orders near a fiscal year end. For orders that will be filled in the next fiscal year, users are encouraged to enter a future date within the next fiscal year. For instance, the date is June 28 and the order will be placed or received in the next fiscal year that begins July 1. Placing July 1 in the Requested Date will pre-encumber the given accounts on July 1st, not "today" within the present budget.

The record will become encumbered per the order's Print Date. The user may control the date the record is encumbered by modifying the Purchase Order date within the PO Print Purchase Orders (POPO) utility. The field defaults to the present date. Update the field to the date the record should be encumbered.

Which fiscal year is an account encumbered? Navigate to the EN Totals (ENUTAC) page and find the order per the Reference number and year (fiscal year). Note that a "Reference" is the PR number when the order Status is "PR," but is the PO number after the order has been printed and Status is "PO."

When the PR is generated in year 20XX and then encumbered in the following fiscal year, note that the system will block this order. Change the block to a warning with common code POPO/FYDT. This code overrides internal controls that aim to block printing a PO where the request date is outside of the current fiscal year.