Pre-Disbursement Processor (PDP) Operating Procedures


SUBJECT:

Departmental Use of the Pre-Disbursement Processor (PDP)

SOURCE:

Operations Department, FMS

ORIGINAL DATE
OF ISSUE:
October, 2006
DATE OF
LAST REVISION:
May, 2014
ASOP NO: 1.0
RATIONALE:

The Pre-Disbursement Processor (PDP) may be used by authorized departments to submit payments outside of the normal procurement (EPIC) or disbursement voucher (DV) process.  Submitting payments directly to PDP is an exception to normal disbursement processing and comes with risks to both Indiana University and departments.  To ensure that an audit trail exists and that adequate internal controls are in place the following procedures must be followed for payments made through PDP.

An annual review of PDP payments will be conducted to determine adherence to institutional policies for procurement.  As part of the review, departments using PDP will receive and complete the Pre-Disbursement Processor Application form certifying the nature of transactions submitted to PDP and adherence to the policies and procedures outlined in this document.

ASOP: Format of PDP Payment Files:The Pre-Disbursement Processor (PDP) uses XML as the format for payment files.  A specific XML schema is used to define the file (layout and valid values) that may be uploaded to the system.  The XML schema can be obtained at the following URL: https://uisapp2.iu.edu/kfs-prd/static/xsd/pdp/payment.xsdThe following data elements, required/optional fields (required – R, Optional – O), and expected values must be present on a PDP payment to ensure that:  the payment can be processed through the university’s accounting system; delivered to the proper location; and clearly identified the purpose of the disbursement:
  1. Chart (R): Chart of the submitting organization
  2. Organization (R): Organization code of the unit submitting payments
  3. Sub Unit (R): Further breakdown by organization in the event of multiple feeds
  4. Creation Date (R): Date payment file was created
  5. Payment Date (O): If not supplied the payment date will be the day following submission to PDP
  6. Invoice Date (O): Invoice date
  7. Source Document Number (R): The unique identifying number form the host system which can be used as a tracking number
  8. Purchase Order Number (O): PO number if applicable
  9. Invoice Number (O): Invoice number if applicable
  10. Requisition Number (O): Requisition number if applicable
  11. Org Document Number (O): Departmental number
  12. Org Reference ID (O): Departmental number
  13. Project Code (O): Project code
  14. Payee Name (R): Name of the entity receiving payment
Important Payee ID Type and Number Requirements:A payee identification number (Employee ID, SSN, Vendor ID, or Payee ID) is required for payments that are reportable as 1099 income to the recipient. Common examples of 1099 reportable income include: Rent, Rights, Royalties, Compensation for Services, Legal Fees, and Medical Services
  1. Payee ID Type and Number: Combination of ID Type and Number (i.e. Type of “E” employee ID, and number 10001234567)
  2. Payee Ownership Code (O): Identifies the type of entity receiving payment (sole proprietor, corporation, etc.)
  3. Customer IU Identification Number (O): The number the payee uses to identify Indiana University
Important Payee Address Requirements: A complete payee mailing address is required for PDP payments. At a minimum address line 1 is required; however, the payee address may be submitted using any combination of the address lines (1-4), city, state, zip, and country fields listed below.
  1. Address Line 1: First line of the payee’s address
  2. Address Line 2: Second line of the payee’s address
  3. Address Line 3: Third line of payee’s address
  4. Address Line 4: Fourth line of payee’s address
  5. City: Payee city
  6. State: Payee state
  7. Zip: Payee Zip
  8. Country: Optional
  9. Campus Address Indicator (O): Identifies an on campus address
  10. Attachment Indicator (O): Identifies payment as needing an attachment
  11. Special Handling Indicator (O): Identifies payment as needing special handling
  12. Immediate Indicator (O): Signifies an immediate print
  13. Original Invoice Amount (O): Original invoice amount
  14. Net Payment Amount (O): Original invoice amount – discounts + shipping – other credits + other debits
  15. Invoice Discount Amount (O): Discount amount
  16. Invoice Shipping Amount (O): Shipping costs
  17. Invoice Other Debits (O): Other costs
  18. Invoice Other Credits (O): Other reductions in cost
  19. Taxable Indicator (O): If payment is taxable
  20. NRA Indicator (O): Identifies a payment to a Non-Resident Alien
  21. Combine Group Indicator (O): Identifies payments that can be combined for a common vendor ID, vendor name, and address – by default PDP payments are combinable
  22. Chart of Accounts (R): Chart of account making payment
  23. Account Number (R): Account making payment
  24. Sub Account (O): Sub account making payment
  25. Object Code (R): Object code of payment
  26. Sub Object (O): Sub object code of payment
Important Payment Text Requirements: Unless the reason for the payment is self evident, the payment description must explain the payment’s purpose and clarify issues that can reasonably be expected to be questioned.
  1. Payment Text: Payment explanation
  2. Payment Amount (R): Amount of payment for the accounting string – the sum of these amounts must equal the net payment amount
  3. Detail Count (R): Number of payments in the payment file
  4. Detail Amount (R): Amount of the payments in the file

Submitting Payment Files to PDP:A file can be submitted to PDP in one of two ways: either by manually uploading the payment file via the OneStart web portal, or by dropping the payment file on a server for automatic upload. The automatic upload will occur four times a day (2:00 am, 5:00 am, 11:00 am, and 3:00 pm), Monday through Friday. Each option for file submission is detailed below:

Manual Upload – For this method the person wishing to load the XML payment file will login to OneStart (http://onestart.iu.edu) and click on the ‘Services’ tab and from the left-hand menu bar select ‘Financials (KFS)” and then ‘All Financial Services.’ Within KFS select the 'Reference and Maintenance' tab then scroll down to the 'Pre-Disbursement Processor' section.Once you’ve located the PDP section click on the ‘Payment File Batch Upload' link, select a file to upload, assign it a File Identifier (for your reference) and click 'add'.

Dropping a File (Non-enterprise batch – customer’s application can not access UIS ES nodes) – The non-enterprise application that creates the XML payment file will use Secure Copy (SCP) with public key authentication to drop the file to the IU server ‘dtt.iu.edu’ (for test)/ dtp.iu.edu (for prod) in the directory ‘/HOME/KFS/pdp/paymentImport/’. Once the file has been completely transferred, the non-enterprise application will drop a ‘.done’ file to indicate the complete XML payment file has been transferred.  Later after the file is processed, a file containg a summary of the results can be found in /home/KFS/pdp/paymentLoadSummary/.  The file will have the same name as your data file.

Dropping a File (Enterprise batch – customer’s application can access UIS ES nodes (escbstst & escbs03) – The enterprise application that creates the XML payment file will drop the payment file with a ‘.dat’ extension (by SCP if the application is on a different node) to the UIS server ESCBSTST (for test)/ESCBS03 (for prod) in the directory ‘/staging/ KFS/pdp/paymentImport’. Once the XML file transmission is complete the enterprise application will drop a ‘.done’ file to indicate the complete XML payment file has been transferred. Enterprise applications can then check for a ‘.done’ file in the ‘/staging/ KFS/pdp/paymentLoadSummary/’ directory after the scheduled file upload times. They can also pick up an outputted XML file with a ‘.dat’ extension from the same outgoing directory. The outputted XML ‘.dat’ file will contain the following information about the file upload:

SUCCESS
MESSAGE123
10.00

...
...
You may contact Sterling George at (812) 855-6107 or send email to sgeorge@indiana.edu if you have questions about the file submission methods discussed above.

Proper Naming of a PDP Payment File:The file name specifications are: chart_org_subunit_yyyymmddhhmmss.dat and chart_org_subunit_yyyymmddhhmmss.done A different chart, org, and subunit will be assigned to each customer and entered into a profile maintained in the PDP application.

Conditions that will Cause a PDP Payment File to be Rejected:A file will be rejected if any of the following conditions are true:

  1. The user submitting the file is not authorized
  2. The XML file is not valid according to the PDP XML schema (invalid version number, improper file format, invalid values, etc…)
  3. The file is a duplicate file that appears to have already been submitted (based on identical total payment count, total payment amount, and the submission date in the file for a specific customer)
  4. A payment date in a payment group is not a valid date or is not blank
  5. An invoice date in a payment detail is not a valid date or is not blank
  6. The sum of payment detail amounts for a specific group is less than zero
  7. The number of payment text lines and payment detail records for a specific group are over the maximum allowed by the system (the number of payment text lines and payment detail records must not exceed 27 for a given group – there is a physical limitation of what can be printed on a check stub)
  8. The account amounts in each detail record do not add up to the net payment amount in the corresponding detail record (if it is present in the file)
  9. The total detail record count in the XML trailer does not equal the actual number of detail records in the file
  10. The total detail record amount in the XML trailer does not equal the calculated detail record amount for the file
  11. Special characters, such as ', ", &,must be escaped or the file will be rejected.

Important General Rule: Do not include XML tags for a field if there is no data for the field on the record being processed. Example: Do not include the XML tags for sub account,, if there is not a sub account.

Conditions that will Result in a Warning Message when a PDP Payment File is Submitted:A file will be processed but warnings will be returned (via an email sent to the email addresses set up in the customer’s profile and via the web browser if you choose to manually upload a payment file) for each of the following conditions:

  1. An account number is invalid, expired, or closed (all accounting data will be replaced with defaults from the customer’s profile)
  2. An object code is invalid or inactive (all accounting data will be replaced with defaults from customer’s profile)
  3. A sub account number is invalid or inactive (the sub account number will be replaced with dashes: ‘-----‘)
  4. A sub object code is invalid or inactive (the sub object code will be replaced with dashes: ‘---‘)
  5. A project code is invalid (the project code will be replaced with dashes: ‘----------‘)
  6. If a payment detail amount is greater than the payment detail threshold amount as set up in the customer’s profile
  7. If the payment file amount is greater than the payment file threshold amount as set up in the customer’s profile
  8. If a payment group has a blank payment date (the payment date will be set to the next calendar day)
  9. If a payment group has a payment date that is either 30 days prior to the current date or 30 days after the current date

Acknowledgement that a PDP Payment File Has Been Processed: If the manual upload process is being used in KFS the screen will show the user if their file had a successful or unsuccessful upload and then it will display the reasoning. If the file was successful but had warnings, the warnings will be displayed on the web page.For any of the three submission methods (manual upload, non-enterprise batch, and enterprise batch) an email will be sent to the customer process e-mail address identified in the customer’s PDP profile. The email will contain a status of the upload (successful or unsuccessful), an explanation if the attempt was unsuccessful, and file statistics if the submission was successful (record count, dollar totals, create date, warning messages, etc.).

Customer Profile Information:Here is a list of values that can be set up for each customer. The following attributes will be maintained by PDP system administrators and must be set up prior to file submission:

  1. Primary Contact Name: Functional contact in the event of data problems
  2. Customer Process E-Mail Address: Receives email confirmation when file is processed (probably an email list)
  3. Payment Threshold Amount: If payments exceed this amount a warning message will be generated – Payment will process
  4. Payment Threshold E-Mail Address: PDP will send warning message to this address when amount is exceeded -
  5. File Threshold Amount: If file total exceeds this amount a warning message will be generated – File will process
  6. File Threshold E-Mail Address: PDP will send warning message to this address when amount is exceeded -
  7. Advice Heading Text: General information about Payments that appear in the body of the Direct Deposit e-mail
  8. Advice Subject Line Text: Appears in the subject line of the Direct Deposit e-mail
  9. Advice Return E-Mail Address: Shows as the from address on the Direct Deposit e-mail
  10. ACH Payment Detail Description: Identifies the type of payment being made – Example: Bloomington Campus Bursar Refund
  11. Default Chart: Default used if accounting string error found
  12. Default Account #: Default used if accounting string error found
  13. Default Sub Account #: Default used if accounting string error found
  14. Default Object Code: Default used if accounting string error found
  15. Default Sub Object Code: Default used if accounting string error found
  16. Address Line 1: Address of customer
  17. Address Line 2: Address of customer
  18. Address Line 3: Address of customer
  19. Address Line 4: Address of customer
  20. City: City of customer
  21. State: State of customer
  22. Zip: Zip of customer
  23. Country: Country of customer
  24. Check Header Note Line 1: Message that appears at the top of the check stub (first line)
  25. Check Header Note Line 2: Message that appears at the top of the check stub (second line)
  26. Check Header Note Line 3: Message that appears at the top of the check stub (third line)
  27. Check Header Note Line 4: Message that appears at the top of the check stub (fourth line)
  28. Additional Check Note Line 1: Additional message at top of check stub (fifth line)
  29. Additional Check Note Line 2:  Additional message at top of check stub (sixth line)
  30. Additional Check Note Line 3:  Additional message at top of check stub (seventh line)
  31. Additional Check Note Line 4:  Additional message at top of check stub (eighth line)

Processing Payments as Check or ACH via PDP:Unless the customer is expressly identified as allowing ACH transactions, all payments from that customer will be paid via a check. If the customer has been approved to allow ACH payments an ACH identifier will be entered on the customer’s profile by the PDP system administrator. The ACH identifier from the customer’s profile and the payee ID type and payee ID number from the payment record are used to match to the direct deposit sign up data to determine if a payment should be made via ACH.In addition, any payment flagged as special handling, as an attachment, or as an immediate print will be paid via a check. PDP will also force a check to be written if there is a negative payment within a payment group (i.e. a credit memo).

Holding or Canceling a PDP Payment File:To hold or cancel a batch of payments that were just submitted, please contact FMS Operations at fms_operations@indiana.edu or call Sterling George at (812) 855-6107. Please provide the customer’s chart, org, and sub unit, the creation timestamp or the transmission date for the PDP payment file, and the file total counts and amounts if available. A batch can be held or cancelled if check or ACH payments have not been generated for the batch.

Adherence to Institutional Policy:

  1. Procurement:  It is the responsibility of the buying department to follow all Purchasing policies, which can be found at this URL:  http://www.indiana.edu/~purchase/policies/policies.shtml
  1. Internal Controls:  It is the responsibility of the buying department to ensure all internal controls are in place, which includes but is not limited to:  separation of duties between the person making the purchase and the erson making the payment.
  1. Audit Documentation:  It is the responsibility of the buying department to ensure that all documentation is available for the audit trail.  This must follow policy, which can be found at this URL: http://policies.iu.edu/policies/categories/financial/purchasing/FIN-PUR-5.7-documentation.shtml
  1. Year-end Payables:  It is the responsibility of all buying departments to ensure that at fiscal year-end, the payables are booked into KFS.
  1. Institutional Policies:  It is the responsibility of the buying department to follow all institutional policies, which can be found at this URL: http://www.indiana.edu/~policies/

DEFINITIONS:

N/A

CROSS
REFERENCE:

The Pre-Disbursement Processor Application may be obtained by contacting Sterling George in Financial Management Services at (812) 855-6107 or by sending email to fms_operations@indiana.edu.

RESPONSIBLE
ORGANIZATION:

Financial Management Services and Purchasing