DISBURSE VENDOR PAYMENTS#
Wiki handles payments to Accounts Payable vendors for selected employee deductions. This process extracts from closed employee pays and populates the disbursement tables so that individual vendors can be paid. Vendors reside in a separate ‘Payroll Code’ and can be paid in a separate pay cycle from regular employees. Vendor payments may also be extracted for payment in some other supporting system. This capability is of course unique in each situation. This process describes how vendor payments are placed into the disbursement tables and not how they are actually paid.
There is a separate section, Child Support Direct Deposit, that outlines the setup needed to use the ACH interface for direct payment to vendors for Child Support Payments.
Pay Component Setup Requirements#
The Define Pay Component (
IPPC) screen determines which components are to be picked up by
UPVEND.
On the ‘Accts/Arrears’ tab, record the default Vendor number. This vendor could be simply a ‘Dummy’ vendor if the same pay component is used for multiple vendors. In this situation, the vendor is entered in IPSN or in IPPH when the transaction is keyed.
This technique is often used for Child Support payments; otherwise a separate pay component would be required for each child support item.
UPDISBV_01.JPG
Pay Component Rules Setup Requirements#
On the PC Rules tab, the reference column must be marked as ‘Enter Vendor Code’
UPDISBV_02.JPG
Accounts Payable Vendors Lexicon#
The list of valid vendor numbers is stored in a user-defined lexicon with the lexicon name ‘X_AP_VENDORS’. These vendor numbers must be the exact vendor number to be passed to the external Accounts Payable system when any interface file is required.
Both the ‘Display Value’ and the ‘Meaning’ should contain the vendor name.
UPDISBV_03.JPG
Vendor Payment Transactions#
Recurring AP transactions can either be entered on the Maintain Sundry Pay/Deductions (
IPSN) screen, or entered individually as transactions in
IPPH. The vendor number is supplied on the Line Info tab.
UPDISBV_04.JPG
Vendor Payrolls#
All vendors MUST be in a separate payroll from any other employees. The payroll can share a check series with the regular payroll or use a separate series.
If vendors are paid on difference frequencies, then separate Vendor payrolls can be set up. In this situation, the vendors must be processed in separate execution of UPDISBV.
UPDISBV_05.JPG
Vendor Units#
Within the Define Units
IDUN screen, vendors must be set up in separate units from regular employees.
UPDISBV_06.JPG
Vendor Groups#
Within the Define Groups
IDGR screen, vendors must be set up in separate groups from regular employees.
UPDISBV_07.JPG
Vendor Job Codes#
Within the Define Jobs
IDJB screen, vendors must be set up in separate jobs from regular employees.
UPDISBV_08.JPG
Vendor Department Codes #
Within the Define Departments
IDDP screen, vendors must be set up in separate departments from regular employees.
UPDISBV_09.JPG
Vendor Location Codes#
Vendors must be set up in separate locations from regular employees.
UPDISBV_10.JPG
Vendor Employee Records (IEHR)#
When UPDISBV is executed, vendors with a person code equal to the letter ‘V’ plus the vendor number are eligible to be processed. For example, if the vendor number id 2311, then UPDISBV looks for an employee with the person code ‘V2311’. If located, then a disbursement is created.
UPDISBV – Disburse Vendor Payments#
All vendors must be in a separate payroll from regular employees. Multiple vendor payrolls can be used if vendors are paid on a different cycle. Vendors can be individually selected for processing, or all can be processed in a single execution.
Vendor Pay Period must be selected and all disbursement records and pays created will be in this pay period.
All output from this process enters the vendor pay cycle as fully disbursed and is then ready for checks to be printed through UPSTUBV and/or deposits to be processed through UUPDTB.
Undisburse Pay Runs(s)#
Overview
In situations where UPDISBV has been executed and must be backed out, the Undisburse Vendor Payments (UPUNDISB) screen can be executed to ‘Undo’ the work from a previous execution of UPDISBV. UPUNDISB can also be used to undo executions of regular employee UPCALC executions.
One or more pay runs can be handled in one execution of UPUNDISB.
Child Support ACH Direct Deposit#
Overview
This feature provides for the ability to pay Child Support deductions directly to the vendor (likely the mother), through the ACH interface in payroll. These vendors (recipients) are set up in the same manner as any other vendor that receives direct payment through payroll.
In addition to the payment record, these particular direct deposits will have an ACH ‘Addenda Record’ sent along with the payment record. This event is triggered by the existence of any of the Child Support user fields documented in the pages following. The UPDISBV process therefore will not create this special addenda record unless the information needed is supplied in the IPSN form where the recurring deduction is maintained.
Child Support User Fields#
There are four user fields that can be added to the table ‘P2K_PR_SUNDRY_LINES’ as shown below. Remember to refer to lexicon ‘X_YES_NO’ on the medical indicator, so that the value entered in IPSN can only be ‘Y’ or ‘N’. Case Number is mandatory, and the other three are optional. If these are set up without any data provided in IPSN, then the UPVEND process will use the correct defaults without any problem. The names of these user fields must be exactly as shown.
Sundry Entry for ACH Child Support Data#
Illustrated below is a sample Child Support payment that can be sent via ACH direct deposit.
Disbursement Addenda User Fields#
UPDISBV will insert the ACH ‘Addenda Information’ as a user field named ‘ACH ADDENDA DATA’ attached to the disbursement. It can be viewed with the ‘UDF’ button in IPDS. This user field does not have to be added manually since UPDISBV will create it automatically the first time it is needed.
When UPDTB is executed to create the ACH interface file, an extra addenda record will be written if the above user field contains data. If the user field is empty, then the addenda record will not be created.