Annexure A. Application Overview. Financial Suite - Accounts Payable

Transcription

1 Annexure A Application Overview Financial Suite - Accounts Payable 1

2 The Current System # The As-Is process understanding of UNHCR involved organizing multiple sessions with various UNHCR stakeholders. Also, the Project Management team was involved in providing some clarifications/inputs on the processes and provided access to the customization details. Given below is the summary of the as-is process understanding. UNHCR has only one legal entity UNHCR. UNHCR has organized its AP Business Units based on each county to support operations. All the BUs that are created, are not inactivated or removed in the system. UNHCR is utilizing the PeopleSoft delivered combo editing. Vendor Master UNHCR is using the vendor master to register the vendors in the system. The serial numbers for each of the vendors are based on the system generated numbers. There are different types of vendor classifications used by UNHCR, the classifications being: PO Suppliers, Employee Vendors, Implementation Partners, Consultants, Independent Contractors, Custodians, Local Field Staff, UN Volunteers and Beneficiaries. UNHCR has established a process to register the PO suppliers as vendors. A set of buyers as established in the system review the vendor registration request and subsequently passed on to the vendor review committee. This process is currently an offline process. Once vendor review committee approves the request, the PO suppliers are created in the system. UNHCR has implemented workflow for vendor approval in the system. The vendor approval process is heavily customized 2 step process. Currently any user with access to enter/certify a vendor of a given classification has got the access to enter/certify any vendor with that classification globally. UNHCR has implemented a customization to limit access to users to add locations to vendors. The below set of users only have the access to add locations to vendors. IPs, where any user with access to the classification can add locations. Certain limited users in HQ (AFS and DESS) who can add locations. There is no process for vendors which are getting inactivated; they are inactivated manually in the system. Voucher Processing Vouchers are created at both HQ and at field offices. AP vouchers can be prepared using any AP business unit, the related payments might be made from Field bank accounts or HQ bank accounts. At the various field offices, the vouchers for salary of employees are created manually. Currently only Regular, Journal 2

3 Voucher and Template voucher styles are used, rest of the voucher styles are not used by UNHCR. Currently the matching over ride access is provided to HQ based users only. The access for the same for the users based out of various field offices was revoked sometime back. But the users based out of field have the ability to do un-match; HQ staff also monitors matching exception on a monthly basis. For Services procurement, PO is raised based on amount. These vouchers go through the 3 way matching process. Due to the various needs, the matching rules have been customized. Non-PO Voucher Approval UNHCR has implemented workflow based approvals for non-po vouchers. The current Workflow is designed based on Origin and routed to the appropriate person(s).there is a two-step approval process for non-po vouchers: technical approval and then payment approval. Automatic notifications are only sent when vouchers are approved or denied. No notifications are sent on either when the vouchers go into recycle status or when they fail in budget check. Payments Processing UNHCR has mandated to use EFT Payments wherever possible and all modes of payments are being used. Currently EFT mode of payments are used for most employee related payments but not all. HQ employees are primarily paid through EFT payments. Salary for HQ and International staff are staff are processed by the HR system using the Global Payroll and the file is directly sent to the treasury and then to the bank. At various field offices, different types of payments are used including cash. While EFT is the clearly preferred method, in certain countries (Myanmar, Vietnam) local banking conditions make EFTs very difficult. The local portion of the payment of international staff will be paid out of AP based on the banking details maintained in AP, balance of the salary will still be paid out of HR/Payroll module. Most International Staff maintain at least two bank accounts, One HQ Bank account and another local bank account. The % of salary will be split between HQ bank and the local bank (the employee is currently at the local/field office and local currency is needed).when a person is assigned to the local office, the local office is responsible for updating the assigned staff s local bank details. Paycycle Processing The payments are processed using various pay cycles at both HQ level and field level. Each pay cycle is differentiated based on the source and/or BU used in the pay cycle selection criteria. HQ Pay Cycles pick up vouchers from all business units. But only those in which the HQ bank accounts were selected as the pay from accounts. Field Pay Cycles and SCB Pay Cycles pick up only vouchers created in the given business unit or in the HQ business unit. UNHCR has implemented access restriction for paycycle to users. The access to pay cycle is restricted to one set of users who have access to run all the paycycle (irrespective of Treasury, HQ or local). HQ and SCB Pay cycle files are approved from AP and released to 3

4 treasury. Treasury follows a 2 step approval process for all the payments that are sent to bank. EFT for SCB file is sent directly to bank after the approvals, EFT for UBS is manually placed into the UBS secure bank site after the approvals. The pay file release process to treasury is a customization. Key Challenges During the various As-Is process understanding sessions, various challenges in the existing system were mentioned by different stakeholders. Given below are the key challenges that were captured during the sessions. In-relation to Vendor Master Duplicate vendor data Unable to link agreements to the implementing partner payments. Need for maintaining one to one relation between a vendor and IP. Better audit trails on vendor changes Reason for vendor changes needs to be captured by attaching , or other documentary evidence as a proof. The current framework of vendor classifications needs to be reviewed. UNHCR needs to decide which classifications are needed and ensure that all vendors are classified appropriately. This may also be linked to the degree of control that needed to exert over the creation, update, certification and approval of vendors. There may be groups of vendors (e.g. HQ PO Suppliers, which only a few HQ users should have access to update. The ownership of each classification of vendor is yet to be established. Workflow improvements on vendor update, certification and approval. This is linked to the point above. It includes issues such as: Ensuring tight control on high value or high volume vendor records (against erroneous or fraudulent updates). Ensuring better quality control on the input of vendor banking data in the correct format (to make subsequent pay cycles run smoothly). Ensuring that approval of vendor additions / updates is done by those managers with the knowledge of the particular vendors and the appropriate documentation. In the case of local PO suppliers, there may still be a role for DESS approval if there are issues of the quality of standard goods that are to be supplied. If a vendor approver is approving an updated vendor, then s/he needs to be able to see very easily and clearly what data has been changed since the vendor was previously in approved status. Access restriction on vendor location and bank details needs to be improved. Flexibility of the system to maintain the past profile of the vendor (Say the vendor was previously an employee, now has become consultant or a vendor itself). This needs to be captured in history. 4

5 Blacklisted vendors registered in the system. Regular Vendor mass inactivation needed. Self-service for staff to update their details such as bank information. In-relation to Voucher and Payments Processing Attachment of documents while creating vouchers Budget check before approval - Validation for ChartField combo and budget exists. Such a check should only be advisory to indicate that sufficient budget currently exists and that the ChartField combo is valid. There should be an actual budget check process after the voucher is approved, at which stage the necessary entries in commitment control are triggered and the budget is blocked. The distinction is important as it is only the voucher approver who can approve that the given voucher charges the budget. Save as draft workflow and budget check should not be initiated. (In fact, there are only rare cases when a voucher should be saved as draft). Recurring voucher for rental/recurring payments. Prepaid vouchers for advance payments.. Pre-payment functionality needs to be activated with a linkage to purchase orders and subsequent payments of invoices are made after deduction of the prepaid amount. Duplicate invoice check- Similar invoices paid the last few months for the same vendor to avoid duplicate payment. Salary vouchers Automation Explore how the manual entry of salary vouchers can be automated Voucher approval workflow needs to be reviewed thoroughly including the possibility of a remote approval process (with attachment of supporting documentation) in designated locations to ensure that segregation of authority and adequate control is applied particularly for offices with very small number of staff. Examine the dynamic link between voucher and vendor data. Currently updated vendor data is automatically taken into a voucher (even one that is approved). Alert notification needs to be there on voucher failing budget check. Where a voucher fails a budget-check because incorrect chartfields have been entered, there should be an option to create a correct voucher without having to manually re-enter the whole voucher again. Possible options might be: a. Allow the voucher in budget error to be put back into the worklist of the preparer, where it can be corrected. b. Allow a new voucher to be created by copying from the old voucher (and then correcting), after which the old voucher can be deleted. Alert notification needs to be there on voucher failing budget check. Alert notification needs to be there on voucher going to recycle status. 5

6 Remittance advice to vendors - Need to make remittance advices -based and automatic for all payments. E mail address mandatory for vendors IBAN Validation for bank account numbers. If a vendor bank account is being created, and the bank account is held in an IBAN country, then it should be made impossible to certify and save the vendor unless the bank account number is a valid IBAN for that country (not just length but also check digits). The EFT file produced as output of the pay cycle should be in csv or xml format in addition to the pdf format. Void and reissue voucher: invoice date should be taken from the original voucher in order to ensure correct exchange rate, accounting date should be the current date Void and close voucher: invoice date and accounting date should be set to current date No approval process is in place currently for void and reissue of cheques. HQ Credit card disbursements. Manual recording of receipt accrual at the closing is cumbersome and prone to errors. UNHCR follows two step receipt accrual process and Timing difference between the first step and second step results in receipt accrual issues. Non-PO lines in PO Vouchers There is currently a control weakness. If the PO Lines are matched the whole voucher becomes approved, even though there is no specific approval on the non-po lines. One possible solution would be to force PO vouchers with non-po lines to pass through the normal non-po voucher approval process in addition to the matching process on the PO lines. An alternative option would be to prevent non-po lines entirely and force users to create separate non-po vouchers instead. In-relation to Payroll Payments International Staff salaries can be paid by Field Offices. A designated percentage can be paid through HQ Payroll and the remainder through the relevant field office. This applies to some staff who are deputed to the local field offices. 80% is paid by HQ Payroll. For the remaining 20%, an open liability is created at the local office level. A voucher is created at the local office for this amount, but this is paid by the HQ bank account and not the local field office bank account. This is against what is intended (i.e. if the field payroll ends up paying from a HQ bank account and not the field office bank account) In-relation to Paycycle Processing The EFT file coming out of local Paycycle should be in csv or xml format rather than pdf format. (The pdf output of HQ Paycycle is working fine.) 6

7 Accounting date / payment date issue in case of the HQ bank accounts. If the Accounting Date is 31 st March and payment date is 1 st April, the bank reconciliation does not automatically treat this as an upper exception. It has to be manually entered as a lower exception. To-Be Processes Vendor Master As part of the To-Be process, a system walkthrough and understanding session on the To-Be process sessions were conducted. Given below points will form the basis for the future system during the actual upgrade phase. Improvement in vendor maintenance using better process and enhancing workflow to support the process in line with the organization s internal control framework (FICF/DOAP). Reliable financial delegation of authority plan (DOAP) and security Configure workflow to include the vendor review committee as part of approval process. Configure two levels of approvals, with workflow to be triggered to the next level based on the approval at the previous level. Enable alerts for approvals and rejections. Audit functionality to monitor periodically all changes to vendor names Possibility of centralizing the vendor database Attaching documents for changes to the supplier details so that the approver can see the supporting documents. Enable alerts for the changes made to the vendor details as per need. Reorganize the different vendor classifications and phase out the unwanted classifications. An employee can be given different roles and can be created as vendor under different classifications. Hence there is a need with the ability to track changes to vendor classifications and generate a report for the same. This report will show the changes to the vendor classifications over a period of time. This will be a new custom report that will have to be developed. Integration with HR system to capture employee vendors so that there is real-time availability of HR employees who are registered as employee vendors in AP System. HR system will be the source for employee vendors. This will also eliminate the duplication of effort involved to enter employee vendor details in the AP module and eliminate the duplicate/incorrect data in AP system as compared to the HR system. Ability to capture IP code for IP vendors. IP code to be made mandatory while registering IP vendors in MSRP so that one to one relation between IP code and vendor is established. This control is essential to eliminate the multiple vendors being created for the same Implementation Partner. 7

8 The delivered audit functionality needs to be enabled to track the changes being made to the vendor details as defined by UNHCR. Automatic vendor inactivation process will be enabled so that based on the set criteria the vendors in the system are inactivated rather than doing it manually. UNHCR can explore the possibility of using the financial sanction validation feature provided by PeopleSoft to comply with financial sanction laws. Self-service for staff to update bank details System automated receipt accrual process Voucher Processing Create PO Vouchers for payment to suppliers. These vouchers will need to undergo 3 way matching. The matching rules will need to be configured appropriately. Monitor match related exceptions on a regular basis. Perform match related exceptions processing using the matching workbench. Enable alerts for matching exceptions to inform the appropriate users. Perform budget checking on these vouchers. Select the vouchers for payment by configuring pay cycle. Make the payment and post the payment. Create Non-PO vouchers. Create prepaid vouchers for advance payment, recurring vouchers for recurring payments. Create vouchers for employee payments manually or integrate HR system to create vouchers automatically by enabling the delivered EIP. Enable validation for agreements while creating vouchers for Implementation partner s payments. Attach documents in support of voucher. (like a scanned copy of the invoice) Use pre-budget functionality to check for the budget availability and take the necessary action in case budget is not available. Route the voucher for approval based on the pre-defined internal controls framework (FICF/DOAP) Review of the DOAP needs to be a continuous one to reflect the organization s roles and responsibilities assigned to each user. Enable alerts during the approval process as necessary. Perform budget checking after the approval so that the budget gets committed to the expense. The voucher approval can be enabled either before the voucher approval process or after the approval process. 8

9 The approval workflow needs to be implemented using the AWE in line with the latest feature/functionality provided by PeopleSoft. Save vouchers in draft mode without initiating the workflow or matching. Activate Prepayment functionality to process advance payments. Use recurring vouchers for recurring payments like rent etc., Improvement on the delivered duplicate invoice checking functionality is needed. Non-PO Lines in PO vouchers getting automatically approved Enable correct matching rules or force PO vouchers with non-po lines to pass through the normal non-po voucher approval process. An alternative option would be to prevent non-po lines entirely and force users to create separate non-po vouchers instead. Voucher approval workflow needs to be reviewed thoroughly including the possibility of a remote approval process (with attachment of supporting documentation) in designated locations to ensure that segregation of authority and adequate control is applied particularly for offices with very small number of staff. This will facilitate ppayment approval function are centralized under DFAM authority, in designated field locations, as appropriate and when needed. Prevent over receiving of goods and services. System automated receipt accrual process. Payment Processing UNHCR would like to record manual payments, make cheque payments and EFT payments. Pay cycle will be run out of both HQ and local field offices. EFT payments will be used for HQ pay cycles for UBS and SCB. HQ pay cycles generated Pay files (UBS and SCB pay cycles) will be released to the Treasury system which in turn transmits these files to the banks. The customizations related to the pay file release will need to be carried forward to PS 9.2 version Manual payment, Check payment and EFT files generated out of pay cycles will be the different modes of payment for field offices. Field office Pay cycles will generate pay files and will be authorized by the local signatories before the payment is made at the bank. Enable pay cycle by user id security as per need so that only one set of users can run pay cycles. Enable Pay cycle approval as necessary. Configure notifications to be sent to vendors so that the remittance advices are -based and automatic for all payments. 9