real time financial management system - best … · web viewcommunication to the users 26 16....

REAL-TIME FINANCIAL MANAGEMENT

BEST PRACTICE MANUAL

V1 Rev 0 (19 May 2005)

1. TABLE OF CONTENTS

REAL-TIME FINANCIAL MANAGEMENTBEST PRACTICE MANUAL

1. TABLE OF CONTENTS.............................................................................2

2. PROCESSING CYCLE FOR REAL TIME FINANCIAL MANAGEMENT.................5

3. BUDGET FUNDAMENTALS.......................................................................7

3.1. Introduction..................................................................................................7

3.2. Sales Tax and VAT (Value Added Tax)..........................................................7

4. BUDGET ALLOCATION.............................................................................8

4.1. Purpose........................................................................................................8

4.2. Diagram.......................................................................................................8

4.3. Procedure.....................................................................................................8

5. PURCHASE REQUISITION........................................................................9

5.1. Purpose:.......................................................................................................9

5.2. Diagram.......................................................................................................9

5.3. Procedure.....................................................................................................9

6. PURCHASE ORDER CREATION................................................................11

6.1. Purpose......................................................................................................11

6.2. Diagram.....................................................................................................11

6.3. Procedure:..................................................................................................11

6.4. Amending an Order....................................................................................12

7. AUTHORISING/CONFIRMING AN ORDER..................................................13

7.1. Purpose......................................................................................................13

7.2. Diagram.....................................................................................................13

7.3. Procedure:..................................................................................................13

8. ORDERING...........................................................................................15

8.1. Purpose......................................................................................................15

8.2. Procedure:..................................................................................................15

8.3. Internal suppliers.......................................................................................16

9. GOODS RECEIPTING AND GOODS RETURN..............................................17

9.1. Purpose......................................................................................................17

9.2. Diagram.....................................................................................................17

9.3. Procedure...................................................................................................17

9.4. Goods Returning........................................................................................18

V1 Rev 1 – 27/07/2005 of 28


10. PAYMENT............................................................................................19

10.1. Purpose.....................................................................................................19

10.2. Introduction..............................................................................................19

10.3. Diagram....................................................................................................19

10.4. Procedure.................................................................................................19

10.5. Agreed Tolerances at ordering, receipting and matching.........................20

11. BUDGET REPORTING............................................................................21

11.1. Purpose.....................................................................................................21

11.2. Diagram....................................................................................................21

11.3. Procedure.................................................................................................21

12. BUDGET AMENDMENTS........................................................................22

12.1. Purpose.....................................................................................................22

12.2. Diagram....................................................................................................22

12.3. Procedure.................................................................................................22

13. EXCEPTIONS........................................................................................24

14. HOUSEKEEPING...................................................................................26

14.1. POP administrator.....................................................................................26

14.2. Finance.....................................................................................................26

15. USER GROUP.......................................................................................26

15.1. Scope........................................................................................................26

15.2. Who will attend?.......................................................................................26

15.3. Frequency of meetings.............................................................................26

15.4. Updates to the procedure.........................................................................26

15.5. Communication to the users.....................................................................26

16. OUTLINE OF REAL-TIME FINANCIAL MANAGEMENT JOB FUNCTIONS.........27

16.1. PI/ RESEACHERS.......................................................................................27

16.2. POP ADMINISTRATORS..............................................................................27

16.3. AUTHORISERS...........................................................................................27

16.4. FINANCE....................................................................................................28

16.5. HEAD OF SCHOOL.....................................................................................28

17. CODING CONVENTION..........................................................................29

17.1. R-Codes....................................................................................................29

V1 Rev 1 – 27/07/2005 of 28


V1 Rev 1 – 27/07/2005 of 28


2. PROCESSING CYCLE FOR REAL TIME FINANCIAL MANAGEMENT

Real Time Financial Management is a combination of:

- Procedures;

- Staff adequately trained;

- eFinancials Purchase Order Module;

- Regular Housekeeping;

- Business Objects reports

V1 Rev 1 – 27/07/2005 of 28


There are two aspects to purchasing:

- System: accuracy of data and accurate reporting;- Procurement

o Getting the best value for UCD;o Ensuring that expenditures are authorised by relevant authorities;o Freedom of information;

This procedure focuses on the System end of purchasing.

V1 Rev 1 – 27/07/2005 of 28


3. BUDGET FUNDAMENTALS

3.1.Introduction

3.1.1. Reminder:

Commitments = Orders authorised not receivedAccruals = Orders received not invoiced

3.1.2. Budget controlYou cannot spend more than your allocated budget.

3.1.3. Residual Budgeting provides on-line budget control within the Purchase Order Processing module.

Budget Amount- Actual Expenditure- Commitments (Orders authorised not received)- Accruals (Orders received not invoiced)

= Residual Budget

Residual Budgeting is invoked on order authorisation.

3.2.Sales Tax and VAT (Value Added Tax)

3.2.1. IntroductionGoods or services purchased by UCD are subject to VAT. UCD does not claim VAT back on a general basis. Some Research projects can claim VAT back. PIs will be made aware at budget approval. Most suppliers give prices exclusive of VAT since they claim VAT back. This has significant impact on the budget.

3.2.2. Purchases from IrelandVAT is paid to the supplier

3.2.3. Purchases from EuropeFor suppliers in Europe, VAT is paid to the Revenue.

3.2.4. Purchases from the United States of AmericaFor suppliers in the US, Tax is paid at point of entry.

It is important that departments organise for Tax payments to be ready when the goods are delivered

3.2.5. Budget implicationIt is important to ensure that Sales Tax or VAT is included in the price of goods or services when checking budgets.

V1 Rev 1 – 27/07/2005 of 28


4. BUDGET ALLOCATION

4.1.Purpose

4.1.1. To ensure budget allocation is set in eFinancials.

4.2.Diagram

4.3.Procedure

4.3.1. P.I. will submit a research grant to SFI for funding for a value of X.

4.3.2. SFI will decide whether or not to approve the grant. The approval may be for a different value (Value Y)

4.3.3. Upon approval, the Office of Funded Research Support Services will create an account in their database.

4.3.4. Office of Funded Research Support Services has a mechanism to transfer the projects to eFinancials. The Bursar’s office is informed by email when jobs are ready.

4.3.5. The bursars office will then load the research account to eFinancials

4.3.6. Office of Funded Research Support Services will then assign a budget in e-Financials. PI is formally informed.

4.3.7. PI can be assigned a login for Business Objects Reports for refreshing real time financial information.

V1 Rev 1 – 27/07/2005 of 28


5. PURCHASE REQUISITION

5.1.Purpose:

5.1.1. To ensure price accuracy of purchase orders raised in eFinancials.

5.2.Diagram

5.3.Procedure

5.3.1. The P.I. will ensure that budget is available. Note: To achieve value for money and compliance with Internal procedures, national and EU legislation, thresholds are in place:

€1,300 to €4,000: Min 2 verbal quotations €4,001 to €60,000: Min 3 written quotations Over €60,000: A competitive tender is required (advertise on the etenders

website) Over €236,945: EU tender procedure managed by procurement & contracts

office

5.3.2. Pricing is requested from the supplier.Note 1: Arrangements are in place with preferred suppliers. When possible, try to stick with them.Note 2: To avoid error correction, it is important to ensure the following are included:

Product references of goods/service required Delivery and other charges VAT and tax rate

V1 Rev 1 – 27/07/2005 of 28


5.3.3. If the quoted price is within the remaining budget, the PI will submit a Purchase requisition form to the POP administrator. The Purchase requisition form is either:

an Excel spreadsheet or a paper form or a requisitioning system

It is important to ensure the following are included: Itemised product references of goods/service required Supplier name, address and contact details Delivery and other charges Currency Delivery address VAT and tax rate cost centre/job and expenditure code to be charged.

Note: The method by which this Manual Requisitioning is enforced will be at the discretion of the Department or Research Centre.

5.3.4. The requisition is signed by the requester or emailed.

5.3.5. When budget is not available, permission must be sought from the funding organisation. The procedure is explained in an other chapter.

5.3.6. The requisition is forwarded to the POP Administrator who raises the order in eFinancials. The purchase order then undergoes the normal authorisation process.

V1 Rev 1 – 27/07/2005 of 28


6. PURCHASE ORDER CREATION

6.1.Purpose

6.1.1. To ensure the Purchase Order is accurately raised in eFinancials.

6.2.Diagram

6.3.Procedure:

6.3.1. The POP Administrator checks the supplier exists in eFinancials.

6.3.2. If the supplier does not exist, a request is submitted to the Accounts department for creation. Note 1: The request must be completed on a specific form.

Note 2: This is important to ensure that there are no duplicates.

6.3.3. The accounts department creates the supplier within 24 hours.Note: The accounts department will maintain regular housekeeping to ensure old suppliers are removed from the system.

6.3.4. The POP Administrator raises a purchase order for either Goods or Services in the Purchase Order Processing module of eFinancials.

Note: Purchase orders should not be requested over the phone as this may lead to errors at a later stage.

6.3.5. Order information is filled in on the e-Financials order header page including order type, sub-ledger, supplier, cost centre (& sometimes job), invoice and delivery address details.

6.3.6. The purchase order is itemised to detail each product or service being ordered on the e-Financials order details page. Details of quantity (& cost) or value and VAT rates are entered at this stage. An actual or estimated price (either cost or value)

V1 Rev 1 – 27/07/2005 of 28


should be entered against each item. This ensures on authorisation (see below) that a commitment can be raised against each line of the purchase order.

6.4.Amending an Order

6.4.1. If an order is not confirmed, amendments can be made to the order value within a certain tolerance range (imposed by eFinancials).

6.4.2. If an order has been confirmed amendments can only be made to the order value within a certain tolerance range.

6.4.3. If an amendment is made to an order that was confirmed the order must be re authorised by the designated authoriser.

V1 Rev 1 – 27/07/2005 of 28


7. AUTHORISING/CONFIRMING AN ORDER

7.1.Purpose

7.1.1. The most important and critical difference that using Real Time Financial Management dictates is that the sanctioning to spend the money takes place when the order is raised – rather than when the invoice is received and subsequently paid. This is why authorisation of the order is so important. Only on authorising the order does the commitment get raised against the cost centre or job.

7.2.Diagram

7.3.Procedure:

7.3.1. Good accounting practice (as well as common sense) dictates that the individual who requisitioned the order should not authorise the order. This good practice is adhered to in most departments at present where all orders raised are signed off by the Head of Department. eFinancials facilitates this practice via assigning roles against users so that some can only create orders whereas other can authorise them.

7.3.2. Where an order is amended – say an estimated price gets updated to an actual price - the order needs to be re authorised. The increased commitment against the cost centre in question will only take effect when the order has been re authorised.

7.3.3. The POP administrator is accountable for any order placed with the suppliers that have not been authorised.

7.3.4. The designated Authoriser logs onto to the EFinancials Purchase Order Processing module on a daily basis and performs a query on orders with a status of entered with an order type particular to the POP centre.

7.3.5. The Authoriser reviews the order and can either terminate the order if it is unsatisfactory or else Confirm the order.Note: If the order number was issued despite the order not being authorised, it must not be deleted for audit purposes. Contact The Finance department.

V1 Rev 1 – 27/07/2005 of 28


7.3.6. Confirming the order involves the Residual Budget checking processing ensuring that there is sufficient residual budget to meet the order.

7.3.7. Where there is sufficient Residual Budget the order is automatically confirmed, the commitment raised against the cost centre/job and the order ready for printing.

7.3.8. Where there isn’t sufficient Residual Budget at level 2 the Authoriser is informed via a message in eFinancials. Permission must be sought from Finance and in certain cases, the funding organisation. Refer to the budget amendment section.

V1 Rev 1 – 27/07/2005 of 28


8. ORDERING

8.1.Purpose

8.1.1. To order the goods or services, insuring that the suppliers – internal or external -are aware of the terms and conditions and order value.

8.1.2. Diagram

8.2.Procedure:

8.2.1. Once the purchase order has been confirmed it can be printed off either by the Authoriser – or the POP Administrator – which ever is more appropriate. Orders are printed on pre printed laser stationery. The order must be sent / Faxed / emailed to the supplier to ensure they are fully aware of billing and shipping and order value.

8.2.2. Where multiple copies of orders are required – then either photocopying the original order – or otherwise printing a number of times on pre-printed stationery. It is important that the supplier understand the terms and conditions as well as the amount authorised on the order. Preferred suppliers have already been through procurement process and don’t need to be reminded of terms and conditions.

8.2.3. Suppliers should be aware that no payment would be made if they do not comply.

8.2.4. Never sign the suppliers’ terms and conditions. Instead, contact the Procurement & Contracts Officer.

V1 Rev 1 – 27/07/2005 of 28


8.3.Internal suppliers

8.3.1. IntroductionIn the case of orders placed with internal suppliers e.g. Copi-Print, AVC, Restaurant, Computing Services, Biomedical Facilities etc. the above description of the order process operation is slightly different.

The internal charges system varies from the normal purchase order process in that there is no invoice issued.

Instead the charges are put through automatically to the department’s account via a journal transfer.

For this reason it is impossible to do the Invoice Entry and Matching step in e-Financials for this order type.

Because the e-Financials Purchase Order module involves receipting by the Department and invoice matching by the Accounts Payable some modification is needed in order to deal with internal charges type purchasing.

8.3.2. Method

The suggested method to raise an order against the internal supplier.

This will facilitate commitment accounting and also residual budget checking. The internal charges would still go through monthly as described above.

These Orders should not be Receipted on the System.

When the department receives its monthly report the POP Administrator should then check which internal orders have been paid by general transfer. The POP administrator must terminate the orders created for the purpose of commitment accounting on the system (i.e. remove the commitment).

If the order were not terminated then there would be double counting as the amount would both be in Commitments and Actuals.

V1 Rev 1 – 27/07/2005 of 28


9. GOODS RECEIPTING AND GOODS RETURN

9.1.Purpose

9.1.1. To ensure that goods receipted are acknowledged in eFinancials prior to being paid.

9.2.Diagram

9.3.Procedure

9.3.1. The goods are delivered to the location as indicated on the Purchase Order accompanied by a Delivery Note and received by an individual at that location. The suppliers delivery slip is stamped with the “GOODS RECEIVED NOT CHECKED”.

9.3.2. Where the receiver is not the POP Administrator then the Delivery Note (or Service Record Docket) must be forwarded to the POP Administrator who, having satisfied him/herself of the validity of the goods or service, performs the Goods Receipting on EFinancials.Note: There may not always be an official Delivery Note issued. Internal procedures & controls must be implemented so that the POP Administrator is aware of the satisfactory delivery of goods/completion of service. This internal procedure is at the discretion of the particular department or research centre implementing POP.

9.3.3. The Delivery Note must be sent to the POP Administrator in all cases i.e. whether goods are found to acceptable or unacceptable. The reason for this is that a Goods Receipt Note should be entered for all goods/services received in order to maintain a record of the delivery on the EFinancials system.

9.3.4. A Goods Received Note (OG) is raised for goods/services via the Goods Receipting screen in the Purchase Order Processing Module of EFinancials.

9.3.5. A Goods Received Note (OG) can be raised for full or partial receipt of an order.

V1 Rev 1 – 27/07/2005 of 28


9.3.6. Goods/services are receipted on a line item basis on the Goods Received Note details page. In general the goods receipting step will match against quantity for products and against value for services. In the case of receipting against value, the Net Amount (amount less Vat) is the value entered.

9.3.7. A Goods Received Note (OG) can be amended at any point prior to confirmation. A Goods Received Note (OG) cannot be amended after confirmation. Any new receipts or subsequent returns for an order must be entered on a new Goods Received Note (OG).

9.3.8. The entry and confirmation of a Goods Received Note (OG) (and subsequent running of Refresh Commitments Routine) removes the amount receipted out of Commitments and into Accruals (i.e. received not invoiced).

9.4.Goods Returning

9.4.1. A Goods Return Note (OR) should be raised in all cases where goods are found to be unacceptable. The procedure in all cases is to enter a goods receipt note for the value of the total delivery and then enter the goods return note to the value of the unacceptable goods/service as soon as they are discovered. Note: It is important for record purposes and ability to track the order that both sides of the transaction are entered on the system

9.4.2. If a Goods Return Note (OR) is entered against a confirmed Goods Received Note it will render the Goods Received Note void and invoice processing will be blocked until a new Goods Received Note is entered against the purchase order.

9.4.3. The entry of a Goods Return Note (OR) removes the amount returned out of Accruals (placed there by Goods Received Note) and back into Commitments (again the Refresh Commitments Routine needs to be run before this can be viewed).

V1 Rev 1 – 27/07/2005 of 28


10. PAYMENT

10.1. Purpose

10.2. Introduction

Under a Real Time Financial Management scenario Departments no longer see the physical invoice and the emphasis shifts from coding and invoice payment back to the ordering stage. The sanction for the expenditure is given when the order is raised & authorised and coding is implemented at that stage. The sanction to pay in respect of a particular order is given when the goods receipting is performed for that order.

10.3. Diagram

10.4. Procedure

10.4.1. The central Accounts Payable Office receives invoices in respect of orders raised by the Department/Research centre using Real Time Financial Management. Full invoice matching and payment can only take place where the POP Administrator has completed goods receipting for the order in question.

10.4.2. The invoices are entered and matched on Invoice Entry & Matching within the Purchasing Order Processing module of EFinancials.Note: Where matching of invoices is not successful, invoices can be stored temporarily in what is known as “the Invoice Register”.

10.4.3. Purchase Order Invoices (identifiable by their order number reference) are stamp dated upon receipt and grouped together into batches for entry purposes.

10.4.4. Batch Control totals (inclusive of Vat) are entered on the batch header screen before proceeding to the individual invoice entry stage.

10.4.5. The sum of all the transaction totals in the batch must equal the control totals in the batch header.

V1 Rev 1 – 27/07/2005 of 28


10.4.6. The invoices are then posted, which makes them available for payment. The payment process usually takes place once a week and involves the creation of a Payment batch, posting the Payment Batch and requesting a EFT/Cheque Run via the Payment Document Print & Control screen.

10.4.7. When scanning is in operation (expected end of 2005), the invoices will be scanned and an image copy will be available in eFinancials.

10.4.8. On a weekly basis a report should be run of from the Invoice Register on a cost centre basis, listing the invoices that could not be matched. A Business Object report will be made available to the POP Administrators so the lists of unmatched invoices are sent from Finance to the POP administrator for resolution.

10.5. Agreed Tolerances at ordering, receipting and matching

10.5.1. POP Administrators:

10.5.1.1. To facilitate POP administrators amending orders (and in the scenario where amended orders need to be reconfirmed in any case) the tolerance assigned against a POP Administrator for Order amendments is €635.

10.5.2. Accounts Payable:

10.5.2.1. Accounts Payable staff will have no Order Amendment tolerance as they have no requirement for it.

10.5.2.2. Accounts Payable staff will have no Receipting tolerance as they have no requirement for it.

10.5.2.3. Accounts Payable staff will have no Under/Over Invoice tolerance but will have an Invoice write off value of €5 (five). This is to facilitate where there may be minor price adjustments for items such as freight or carriage.However where there are price differences (especially where there are price increases) these must be referred back to the POP Administrator and the Invoice forwarded to the Invoice Register.

V1 Rev 1 – 27/07/2005 of 28


11. BUDGET REPORTING

11.1. Purpose

11.1.1. To ensure every user of Real Time Financial Management system is aware of their residual budget

11.2. Diagram

11.3. Procedure

11.3.1. The accounts department will formally be reporting Budget on a monthly basis

11.3.2. In addition, real-time reporting tools will be made available to P.I., POP administrators (business object)

V1 Rev 1 – 27/07/2005 of 28


12. BUDGET AMENDMENTS

12.1. Purpose

12.1.1. To ensure adequate budget control is in place.

Budget amendments may require approval from funding body.

12.2. Diagram

12.3. Procedure

12.3.1. As elucidated above the gross non pay budget and the detailed budgets for a POP centre will be determined jointly by the POP centre and the Finance Office and subsequently Finance Office staff will load the budgets.

12.3.2. For any amendments to those budgets a request must be sent into the Finance Office who will evaluate the request and then proceed or otherwise with a Budget journal. It is likely however that request to amend budgets will only arise in cases where the gross non pay budget needs to be exceeded – as this is the only case where the POP Administrator will be prevented from raising an order. Similarly it is likely that this request will come from the Dean of a Faculty rather than the Head of Department in question. Obviously where cost centres are prevented from exceeding their gross non pay budgets and where control of budgets and their amendment is a central function a procedure must be implemented within the Finance office to evaluate and in some cases facilitate budget amendment on a case by case basis.

12.3.3. Where a cost centre exceeds some of the detailed budgets (i.e. the Residual budget check at level 1) they will be permitted to proceed with the order provided they do not exceed the total non pay budget (the Residual budget check at level 2). This feature provides the POP centres with flexibility in respect of budgeting at the detailed level and will be useful particularly in cases where those detailed budgets are first guesses or estimates and may not be especially accurate.

V1 Rev 1 – 27/07/2005 of 28


13.EXCEPTIONS

13.1.1. Invoices sent to an individual or School instead of UCD Finance Officeo Should be forwarded to Accounts within 24 hourso Notification to supplier to amend invoice address details

13.1.2. Incomplete Supplier invoicesProcedure to be determined and formalised

13.1.3. Item ordered is discontinuedFollow the order amendment procedure

13.1.4. Goods received have nothing to do with the ordereg you order a table a receive a chairThe POP Administrator/Authoriser should deal with this matter

13.1.5. Dealing with internal suppliersSee standard procedure

13.1.6. Dealing with services (photocopiers etc)See standard procedure

13.1.7. Goods receipted against the wrong supplier

This happened due to a bug in CFACS (software in place before e-Financials). Should this happen again, report to the systems administrator who will liaise with the software supplier to fix the problem.

13.1.8. Credit Notes

Contact the Payments Supervisor for advice on dealing with Credit Notes

13.1.9. Dealing with multiple currencies eg Order in Sterling, supplier invoice in Euro

There is no issue dealing with multi-currencies. The currency should be determined at order entry point and agreed with the supplier. If for some reasons the currency were to change, the initial order must be cancelled and a new purchase order must be entered and authorised in the new currency.

13.1.10. Pro-Forma invoicing – pre payment PO Ccreation GRN Cheque issue

13.1.11. Year EndTransition between financial years dealt with using Period 13

13.1.12. Month endClosure of purchase order ledger

13.1.13. Discounts

V1 Rev 1 – 27/07/2005 of 28


Are not an issue when known at the point of order entryOrFollow standard PO amendment procedure

13.1.14. Order allocated to the wrong ledger codeOrder should be terminated and re-entered correctly

13.1.15. PO AmendmentTolerance order value of €635 allowed in systemIf value of order amendment required is greater than €635, contact the Payments Supervisor or Systems Accountant for assistance.

V1 Rev 1 – 27/07/2005 of 28


14.HOUSEKEEPING

14.1. POP Administrator Responsible

14.1.1. Non-authorised orders should be reviewed on a weekly basis and terminated accordingly from the system.

14.1.2. Confirmed orders not finalised

14.1.3. Orders over 30/60 days that are not complete, GRN not confirmed

14.1.4. Blank purchase orders

14.2. Finance

14.2.1. Old suppliers

15.USER GROUP

15.1. Scope

15.1.1. To improve and revise the procedures on an on-going basis.

15.2. Who should attend?

15.2.1. Finance + representative of users. Users will attend in rotation.

15.2.2. The user group will be split into 2 categories:

15.2.2.1. New users

15.2.2.2. Experienced users

15.2.3. Users will be invited to bring reports of orders with issues.

15.3. Frequency of meetings

15.3.1. Bi-monthly

15.4. Updates to the procedure

15.4.1. Use of the dedicated website

15.5. Communication to the users

15.5.1. Website (to be designed/developed)

15.5.2. Electronic Newsletter (at a later stage)

V1 Rev 1 – 27/07/2005 of 28


16.OUTLINE OF REAL-TIME FINANCIAL MANAGEMENT JOB FUNCTIONS

16.1. PI/ RESEACHERS

16.1.1. Description: Obtain comprehensive, accurate and budget friendly pricing from suppliers Ensure they give accurate pricing to the POP administrators Monitor the budget Comply to budget requirements Comply to procurement procedures (including freedom of information act) Join the user group Check emails and real time financial management website

16.1.2. Training required: Explain concept of Real-Time Financial Management, workflows Principals of budget management Business Objects Reporting Using Purchase Requisition form or quotes from suppliers Procurement: Negotiation, quotes from various suppliers etc.

16.2. POP ADMINISTRATORS

16.2.1. Description: Key in purchase orders in eFinancials Key in Goods Receipting in eFinancials Deal with case studies Liaise with the Finance department to solve issues Comply to procurement procedures (including freedom of information act) Join the user group Accountable for non-authorised expenditures Liaise with suppliers to resolve issues

16.2.2. Training required: Explain concept of Real-Time Financial Management, workflows Principals of budget management Understanding and using eFinancials Business Objects Reporting Procurement: Negotiation, quotes from various suppliers etc.

16.3. AUTHORISERS

16.3.1. Description: Authorise / Deny Purchase Orders in a timely manner in eFinancials Comply to procurement procedures (including freedom of information act)

16.3.2. Training required: Explain concept of Real-Time Financial Management, workflows Principals of budget management Understanding and using eFinancials for authorisers Business Objects Reporting

V1 Rev 1 – 27/07/2005 of 28


16.4. FINANCE

16.4.1. Payment

16.4.1.1. Description:o Pay supplierso Liaise with userso Co-host the user-group

16.4.1.2. Training required:o Explain concept of Real-Time Financial Management, workflowso Use of eFinancialso General processes and exception

16.4.2. Systems / Operations

16.4.2.1. Description:o Chair the user-groupo Provide e-Financials POP help line

16.4.2.2. Training required:o Explain concept of Real-Time Financial Management, workflowso Use of eFinancialso General processes and exception

16.5. HEAD OF SCHOOL

16.5.1. Description: Responsible for PI’s research Responsible for department’s budgets Ensure PI’s stay within funding limits

16.5.2. Training required: Explain concept of Real-Time Financial Management, workflows Understanding Business Objects reports Understanding the financial calendar

V1 Rev 1 – 27/07/2005 of 28


17.CODING CONVENTION

17.1. R-Codes

V1 Rev 1 – 27/07/2005 of 28

real time financial management system - best … · web viewcommunication to the users 26 16....

Documents