Skip to main content
Skip table of contents

Extract Payments to Set - APRIEX

The extraction of payments from their payments definitions (APRIUP) is the goal when running the repetitive invoice process. The extraction process is where definitions are evaluated and used to create actual payments within an AP batch. The extraction process is run with the APRIEX menu option. This process will locate all qualified payment definitions whose next payment is due on or before the as-of date. The following section describes how the extraction process is run and the options available to the user.

Running the Extraction

To run the extraction of payments, execute the mask APRIEX.

Enter the 'as of' Date; RETURN=<date>: Only payments with a Next Due Date on or before the as-of date will be processed. The default date for this question is the current system date. The user may enter any valid date in response to this question.
Repetitive Selection Criteria:  If the user wishes to limit the extraction to a subset of qualified definitions, selection criteria may be specified here. Under normal circumstances, it is not necessary to specify any selection criteria as the extraction process has built-in logic to determine which payments should be generated. By default, the report will always limit the report to definitions within the current ledger and to AP division codes the user was given access to in Nucleus security.
Choose the type of batch to create: IP Immediate Pay or OH Open Hold (Default). The user may request that the resulting batch be created as an Open Hold or Immediate Pay batch type, depending on the procedures of the organization.
Would you like the Short Format? (Y/N): The report generated during the extraction process is identical to the report function discussed earlier (APRIRP). The question shown above determines which format is used for the report. The short format presents each payment definition on one line including these fields: definition ID, status, PEID, Payee name, invoice, pay count, start date, last due date, next due date, end date, and net payment amount.  The long format of the report prints all fields from the payment definition across four lines, with one additional line showing the net amount payment amount.
Is this a Trial Run? (Y/N): Choose Trial Run to see the potential results of the extraction process without actually updating the definition records or creating an AP batch.
Name of the Set to place the transactions: Respond to the above question with the name of the resulting AP batch. This value will also be used for the batch ID on each payment record.

Extraction Details

When payment definitions are processed for extraction, there are five steps involved: qualify for processing, validation, updating, printing, and finally writing the payment to the batch. Each of these steps will be covered in detail.

A. Qualification

In the process of qualifying for processing, each payment definition is checked for the following set of conditions. If any of these conditions are not met, the definition is skipped.

  • Status must be "AC"
  • End Date must be on or after the as-of date (i.e., payment term cannot have ended)
  • Start date must be on or before the as-of date (i.e., payment term must have started)
  • Next Due Date must be on or before the as-of date
  • If an End Date has not been specified, the payment count must be non-zero
  • The definition must pass selection criteria. This includes an automatic check of the ledger code and AP division code security.

B. Validation

The purpose of the validation step is to inform the user of any invalid definition values that cannot be validated during definition entry, or that must be revalidated before processing. The validations performed are not intended to be a duplication of the AP batch proof process. Each of the validations listed below will be performed on each payment definition record that passed the previous step of qualification. If a validation is not passed, an error message will be printed after the record on the report. Failure to pass a validation test will not prevent a payment from being processed and written to the AP batch. This is deliberate. Since each payment is being written to a batch (and not directly posted), the batch posting process will be the final validation step that prevents posting. This allows users to make corrections in the resulting AP batch after it has been created and before it is posted.

  • The PEID must exist in a BusinessPLUS-accessible name & address database, such as the PE module.
  • If a PO number has been provided, it must exist in the PO module with a status of "PO" or "PP", or exist in the EN module with an open status.
  • If the invoice begins with the letters "SYNO" (indicating a system seed), then the common code for that seed must be defined. For example, if the invoice number is "SYNOABC", then the common code SYNO/ABC is checked.
  • If the account number field contains a spread code, that spread code must be defined with a subsystem of "AP".
  • The division code must have been previously defined in APOHUPDV.
  • The check stock ID must have been defined on a CKID/XX common code.
  • If the miscellaneous code validation is turned on (via APOHUPGN), then the value of the Misc. code must be defined under common code OHMC.
  • If a value was entered into relate-to code 1, it must have been defined under common code RT01.
  • If a value was entered into relate-to code 2, it must have been defined under common code RT02.
  • If a charge code was used, it must have been defined under common code SYCH.
  • If a tax code was used, it must have been defined under common code SYTX.
  • The transaction format must be one of the following values: IN, NM, NI, IB, NB, or DX.
  • If a security code was used, it must be defined in APOHUPCD.

C. Updating

The updating of the payment definition record during extraction is almost identical to the update that occurs during the report (APRIRP). The only difference is that the payment schedule is also updated. The values that are updated by both processes are listed here again.

  • Payee address code and PEDB code (using the AP address hierarchy)
  • Discount amount, if terms were provided but an amount was not
  • Tax amount, if a tax code was provided but an amount was not
  • Description, if it was left blank
  • Next Due Date, if left blank

In addition, the extraction process updates the payment schedule by moving the Next Due Date into the Last Due Date field, then calculating a new Next Due Date. Since the payment definition has already qualified for the current extraction, this is the due date of the next due date that will be processed in the future. The Next Due Date is calculated simply by adding the number of days, weeks, months, or years to the Last Due Date. If a specific day of the month was entered, then the date is changed to that day. For example, if a monthly payment was calculated to be due on 7/14/20xx and the due day was specified as "15", then the date would be changed to 7/15/20xx. If the specified due day is greater than the number of days in the month, then the due date is set to the last day of the month. For payments in February, the last day of the month is always considered 28th. The final update to the payment definition record during the extraction process is to decrease the pay count field, if it is greater than zero.

D. Printing

The printing of each payment definition record is the same for both the report (APRIRP) and the extract (APRIEX) processes. The report is available in a short, one-line format as well as a full four-line format. The short format shows only the most critical fields that will fit on one line. The long format shows all fields on the definition. After each record is printed, any validation errors will follow. Up to 20 errors will be shown per record.

E. Writing Payment

The final step of the extraction process is to write the payment to the AP batch. Other than printing, this is perhaps the simplest step of the entire process. Each field of the definition is moved into its corresponding field within the AP batch record. The invoice total amount is calculated and used to calculate the batch total. If needed, the system-generated invoice number is created, and the posting code is derived according to the posting preferences defined in GL for the AP subsystem. The "prep ID" field is populated with the initials of the user processing the extraction. After the AP batch has been created, each record in it will be updated with the batch amount from the user's tape total.

If the common code APRI/NETSIGHT is defined, the payments will be written to the database instead of a file. The tables involved are ohh_batch_mstr, oh_bir_mstr, oh_ref_id_mstr, and ohb_batch_dtl. This will allow access to the payments using the web-based version of the AP data entry page.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close