Repetitive Invoice Processing - APRIUP

The Accounts Payable (AP) Repetitive Invoice Processing (APRIUP) page is a tool for managing payments that are made on a regular schedule for a specific or indefinite time. Invoice definitions are created once and then used repeatedly to create payments within the AP module.

The payment definition page allows users to set up the invoice details that will later appear on the actual payment records. Most of the commonly used fields of the AP invoice entry page are provided, including predefined and system-generated invoice numbers. Using the scheduling features makes each payment generated and payable on its own schedule for the effective period. The period may be set up with both the starting and ending dates, or a starting date and the number of payments.

A report of payment definitions is available to show some or all of the currently defined payments. The report offers basic selection criteria as well as short and long formats.  The payment extraction process evaluates all of the payment definitions and creates an AP batch containing the payments due at that time. When the extraction is run, the user is prompted for an "as-of" date. All active payments due on or before the as-of date are processed and written to the resulting AP batch.

Definition ID: This 16-character field is used to identify the payment definition. This is a required field and may be used in selection criteria when running the report or payment extraction. Each value entered into this field must be unique. By default, this field is disabled. To enable the field, click Add.
Status: This field indicates the status of the payment definition. A value of "AC" indicates the definition is active and may be used for payment extraction. A value of "IN" indicates the definition is inactive and will be skipped by the extraction process. A value of "DN" indicates the definition is done with its payment cycle, i.e. the number of payments or end date has been reached. The Extract process (APRIEX) will automatically set the status to "DN" when the last payment for the definition is extracted.
PEID: This field is used to identify the PE ID of the vendor to receive payment. Any value used in this field must have been previously defined in the Person/Entity Information (PEUPPE) page. Click the ellipsis (…) or use the Ctrl+L combination to use the lookup window.
Name & Address: These display-only fields show the name and address associated with the PE ID.
Addr: Select an address code used for vendor payment. Any value used here must exist as a defined address code for the PE ID.
Invoice: This 16 character, alphanumeric field holds the invoice number used on the extracted payments. Any value entered here will be repeated on every payment generated by this definition. To use an invoice number that increases by one with each payment extracted, a system seed may be used. To define an invoice using a system seed, the first four characters of the invoice field must be "SYNO" followed by the name of the seed. These seed values are defined in NU Common Codes (NUUPCD), under a Category/Value of SYNO/xxxxxxxx. For example, if a seed has been defined as SYNO RENT in common codes, then entering SYNORENT into the invoice field would direct the payment extraction process to use that seed to generate the actual invoice number. The system generated invoice numbers will only be used when the payment is actually extracted, not in trial mode or when running the report of payment definitions.
PO: This eight character, alphanumeric field holds an optional PO#, if the payment is to be applied to a PO. Any value entered into this field must exist in either the PO or EN subsystems.
Description: This 30-character field holds the description that will be placed on the resulting AP payment. If this field is left blank, the system will populate it with "Scheduled Payment" when the payment definition is processed.
Ledgers: The field before the account string indicates the ledger codes associated with the payment record. When adding a new payment definition, the codes default to the current ledgers for the user.
Account: This field holds the required account number for the payment. This is typically the expense account that the payment is being charged to. The format of the account is determined by the configuration of the GL and JL ledgers, and will be the same as other data entry pages.
Payment Amount: This numeric field holds the base amount of the payment. The final net value of the payment record will include the discount, tax, and charge amounts from the fields below. Note: this is the individual payment amount, not the total of all scheduled payments.
Disc Terms/Amount: This pair of numeric fields represent the discount to be applied to the payment. The first field holds the discount terms as a decimal representation of the percentage. For example, 15% is shown as ".1500". The second field holds the discount amount. If the user enters only a term value, the page will calculate the discount amount when the record is saved. When the net value of the payment is calculated, it is the discount amount that is used—the discount terms are only used to calculate an amount.
Tax Code/Amount: This pair of fields represent the tax rate and tax amount to be added to the payment amount. The first field is the tax code, which must be previously defined in NU Common Codes, Category of SYTX. If the user enters only a tax code, the system will calculate the tax amount when the payment record is processed. When the net value of the payment is calculated, it is always the tax amount that is used—the tax code is only used to calculate an amount.
Charge Code/Amount: This pair of fields represent the charge rate and charge amount to be added to the payment amount. The first field is the charge code, which must be previously defined in NU Common Codes, Category of SYCH. If the user enters only a charge code, the system will calculate the charge amount when the payment record is processed. When the net value of the payment is calculated, it is always the charge amount that is used—the charge code is only used to calculate an amount.
Division: Select the division code to be placed on the resulting AP payment. Code values are defined on the AP Division Codes (APOHUPDV) page.
Check ID: This field holds the check stock ID assigned to the payment. Code values are defined in NU Common Codes, Category/Value of CKID/XX. The check stock ID represents the bank account and GL cash account that the payment will be drawn against.
Trans Format: Select the static system code that directs the manner in which the description, as it would appear in the general ledger, is to be created by the system. The following describes each possible Transaction Format code and its meaning:

Relate To: Select the relate-to codes assigned to the payment. Relate-to codes must be previously defined in NU Common Codes under the categories RT01 and RT02. These relate-to codes may be used to indicate the 1099-MISC reporting for the payment, or to interface the payment to the AR module.
Second Ref: Up to 16 characters of additional information regarding the invoice.
Contract: If there is a Contract associated with a Vendor and it is recorded in the corresponding field on the Purchase Requests page, it will be extracted with the Purchase Order and displayed here. Otherwise, enter the alpha/numeric code you wish to have recorded as the Contract and it can be used to reference the transaction.
Vendor Account: If there is an open account with a Vendor and it is recorded in the corresponding field on the Purchase Requests (POUPPR or POUPPE) page, it will be extracted with the Purchase Order and displayed here. Otherwise, enter the number you wish to have recorded as the account number and it can be used to reference the transaction.
Misc Code: This four-character, alphanumeric field holds the miscellaneous code assigned to the payment. This value may or may not be validated, depending on the configuration in the AP General Information (APOHUPGN) page. If validation is turned on, any value used in the field must have been previously defined in NU Common Codes Category of OHMC. The validation is only enforced when the payment definition record is processed.
Security Code: A Security Code may be associated with the invoice. Most users will have their Security Code default automatically through managed security settings; this will trigger approvals as required for the Security Code entered. When required, the Security Code also determines what invoices the user can browse later. Users can be set up to have Read or Read/Write access to particular Security Codes. When creating an invoice, the user must have Write access for the Security Code used. To browse an invoice, the user must have Read or Write access to the Security Code. Additionally, if security codes are defined, a workflow model can be designed that will automatically create the required approvals for each invoice.
Start Date: This required date field represents the earliest date the scheduled payment should apply. A payment will only be extracted if the as-of date is on or after the start date.
End Date: This optional date field represents the latest date the scheduled payment should apply. A payment will only be extracted if the as-of date is on or before the end date (if specified). Either the end date or number of payments must be specified.
Number of Payments: This optional, numeric field holds the total number of payments to be made. This value will only be used when the End Date field is blank. As payments are made, the number of payments field is decremented until it reaches zero, at which point the payment will no longer be extracted. Either the end date or number of payments must be specified.
Every X Y: This required pair of fields specify the schedule for the payments. The first field is a number which must be greater than zero, and the second is a measure of time which may be D, W, M, or Y (for days, weeks, months, or years). For example, if a payment were made every month, the user would enter "1 M" for "once a month". If the payment were quarterly, the user would enter "3 M" for "three payments a month". The amount of time specified in these two fields will be added to the Last Due Date to give the Next Due Date.
Day of Month: If the payment is to be made on the same day of each month, enter that number here. For example, if the payment is made on the 7th of every month, a value of "7" is entered. Any value entered in this field must be between 1 and 31, inclusive. If the payment falls in a month with fewer days than specified in this field, the payment will be scheduled for the last day of that month. For example, if the Day of Month field is set to 31, the June payment will be made on the 30th. Note that using this field for payment schedules other than monthly may not produce the desired result.
Last Due Date: This date field indicates the previous date a payment was made. When a payment definition is first entered, this date should be left blank and the system will populate the date when the first payment is processed.
Next Due Date: This date field indicates the next date a payment will be made. When a payment definition is first entered, this date should be left blank and the system will populate the field with the Start Date when the first payment is processed.

Security and the Payment Definition Page

While the reporting and extraction processes inherit the existing security settings of the AP module, the payment definition page (APRIUP) is slightly different. The report and extraction process will enforce security by ledger and AP division code as defined for the OH-DIV-MSTR data set. If you wish to enforce AP division code security on the payment definition page, add a new entry to the Nucleus Database Access class for the user involved. This new entry should have a DB Name of "OHDB" and a Data set Name of "OHZREPEAT-MSTR". Then, use the Select codes 1 and 2 to specify a range of AP division codes to be included or excluded. This setting is very similar to the OH-DIV-MSTR security, with the exception of the Data set Name. Again, this new security setting is only necessary if you wish to restrict user access to payment definitions by division code on the APRIUP page.