Session Overview

Session Overview

Day 5

Session 18

Session overview:

When Data Entry Operator (DEO) captures the data in the system, it has no accounting impact till the same has been authorised and posted by some higher officials than the DEOs. This process is necessary in computerized database in order to maintain the correctness of data and integrity of the database. Once the data is authorised and posted in the system, no one can change the data. The only method to effect the data is through Transfer Entry. In the VLC System of UP, there are three status of data viz. E(Entered), A(Authorised) and P (Posted). When DEO capture the data, the status of the data is E and it has no accounting impact in the system. When higher officials authorised the data after proper verification as per the monetary limit authorised to them, the Status of data becomes A. Once the data is in status A, the DEO cannot change the data. If data is posted applying posting rules the status of data becomes P and it has its accounting impact in the system and now data cannot be modified by any one. The instructor may show the screen for the purpose and if possible may give live demonstration in VLC system.

In cases of missing vouchers or vouchers having unauthorized or incorrect heads of account, the same has been kept in OB suspense by flagging the voucher in the system. When details from account rendering unit is received, the OB item is adjusted in the system as provided.

Learning Objective:

At the end of session, the participants understand the process of authorization of data by higher officials than the Data Entry Operator and how to deal with Objection items.

Session Structure:

Authorization of data by higher officials than to Data Entry Opeartor.

Dealing with Objection items.

Exercise 18.1 and Group discussion.

Authorisation Of Data Captured

Authorisation of Data
  1. Introduction

This process involves authorising the data captured from accounts rendered by the accounting sources, in the preceding processes. The authorising authority will be higher than the level of data entry operator, generally the supervisor. It will be possible for the authorising authority to make any modifications to the data captured. The functionary authorising the records would be able to authorise the records upto a particular monetary limit only as set in the ‘Authorising/ posting limits data store’.

Once authorised and the authorisation flag being set, the system shall not allow update of the record by anyone. If any changes are required at all, then the status of the authorisation flag will be reverted back to 'E' (entered/ unauthorised) and changes carried out. These changes will be carried out by higher level functionary and not the data entry operator. The changes can be effected only till the time that the data has not been posted i.e. the authorisation flag can be set/ reset, if the record has not been posted.

Each level (role) in the hierarchy will be identified with monetary limits for authorisation for each input type. The inputs (vouchers / challans / TE etc) will be displayed for authorisation if the Gross amount falls within the limits specified, for the functionary. Monetary limits will not be specified for LOP/ Cash Account. For an account source, for a month, LOP & Cash Account will be authorised in single step and not individual head of account wise. By default, the functionary would be given only those documents for authorisation, which fall within his monetary limit. However, a particular functionary, can also authorise the documents of the monetary limit lower than his minimum limit.

The report of data in error(for the records with status- captured) , generated earlier, will be used to aid the authorising authority.

  1. Inputs
  • Covering Memo (Hard Copy)
  • List of Payment & Cash account (Hard Copy)
  • Vouchers (Hard Copy)
  • Challans (Hard Copy)
  • Transfer Entries (Hard Copy)
  • Compiled Accounts (in case of PAO / LO / PPO) (Hard Copy)
  • Report of Data in Error (Hard Copy)

Parameters passed

  • Month of account
  • Account source
  • Entities for authorisation – Covering Memo / LoP / Cash Account/ Vouchers / Challans / Transfer Entries / Compiled Accounts Part I / Compiled Account Part II

Data stores used:

  • Covering Memo
  • Treasury Accounts
  • Vouchers
  • Challans
  • Transfer Entry
  • User Process
  • TC Setup parameters
  • Major Head details
  • Authorising / Posting limits
  • Monthly Progress Monitoring Parameters( LoP and CA reconciled)
  • Classification
  • Account Source
  • DDO
  • Domain Master

c.Validations

  • General validations to be done against the following Masters- Classification, Account Source, DDO and Domain Master.
  • LoP and Cash Account should be reconciled successfully (as per MPMP) prior to authorisation.
  • List of Payment and Cash account for a particular treasury can be authorised only collectively.
  • No external TE can be authorised in the month of account after the close of the Stage-I of the Monthly closing (after generation of Monthly civil accounts).
  • Internal TEs (within the same major head) can be authorised between the Stage-I and Stage-II of the month closing if the Major head Stage-II has already not been closed.
  • No vouchers / challans can be authorised for the account source/ A.G. as a whole if the Major head for the account source/ for the A.G. as a whole has been closed as per MPMP data store.

d.Processing

  • Authorisation will be done for both accounting and non-accounting records. The authorisation of accounting records will make them eligible for posting.
  • The authorising authority will be able to view the list of records pending his authorisation at any given point of time if the Gross amounts falls in the limits identified against his level (Authorisation / limits data store) and can view / modify the individual data items keyed in by his section’s personnel, if required. Records of pending authorisation will be classified into two different categories:

I) vouchers/ challan / TE entered at the own section

Ii) vouchers / challan /TE entered by other sections

  • Besides those identified to be in error, the authorising authority also has the flexibility to query on any of the entities (vouchers / challans etc) at his discretion, e.g. amount greater than specified amount, or self-drawal vouchers etc. and to make changes to the data as appropriate. However, the records will be displayed only to the extent to which they fall within the limit identified to the authorising authority.
  • An erroneous record can also be authorised if the supervisor desires to do so. The erroneous records should be sorted error type wise and presented to the authorising authority. However, if the error reason is the Grant and Major head mismatch, the voucher record would not be allowed to be authorised till the authorising authority gives in the correct combination of Grant and Major head as specified in the TC set up parameters data store. Additionally, if the voucher being authorised is a loan voucher and the head of account mentioned on the voucher is detailed loan head of account and the Sanction Order Number and date mentioned on the voucher does not match with the ones mentioned in the Sanction Order data store,(due to missing sanction order, or due to sanction order number and date mismatch) a warning should be flashed to the authorising authority for all such cases individually, the SLR Number would not be generated for such cases at the time of posting the vouchers. To avoid this, the corrective action would be:
  • Enter the sanction order details in the Sanction Order data store
  • Enter the sanction order details in the voucher
  • Rectify the sanction order number and date mismatch between the voucher and Sanction order data stores
  • Provision will be made to authorise collectively for a set of records i.e all vouchers / challans can be authorised in one go. Provision will also be provided to exclude selectively on screen, if desired. Facility will be provided during initial setup to restrict collective authorisation in TC set up parameters data store.
  • The authorisation flag can be set/reset by the same or higher level authority to allow for rectification of mistakes trapped in authorisation before posting to accounts. In such cases where the authorisation flag is reset, then such records will be required to be authorised again ( the record should not have been posted). To reset the authorisation flag means to change the status of the flag from ‘A’ – authorised to the ‘E’- Entered and then the record would have to be authorised afresh. The rectifications in such cases should be made by the authorising authority himself/ herself.

Additional processing in case of multiple authorisations

  • In cases of mis-classified vouchers / challans entered at a different section or Transfer Entries effecting some other section’s heads also, after authorisation at the originating section, the voucher / challan / TE will be available to the destination section’s authorising authority for his scrutiny. Only after the destination authority authorised the transaction, would the transaction be ready for posting to the books of accounts.
  • For these cases, if the destination section’s authorisation authority decides that the vouchers do not pertain to his section’s Major Heads, then the record can be marked as Authorisation rejected and the record will be routed back to the Source section for further action. Such records will not be treated as authorised, for purposes of posting.
  • In cases of Transfer Entries affecting some other section, once authorised at the originating section, the TE will be available to the destination section’s authorising authority for his scrutiny only after authorisation by the Book Section . Only after he too has authorised the transaction, would the transaction be ready for posting to the books of accounts. This third level of authorisation (Book section) can be set through the domain master data store for the selected types of TEs.
  • For some TE types, it would be possible to have a third final authorising authority, e.g. Book section, whose authorisation will be treated as final. All such TE types will have their Authorising authority set. Such types of TEs would be identified in the domain master data store.
  • The process of authorisation will be complete only when all required levels of authorisation has been completed. The process thus eliminates the need for manual despatch of vouchers and Suspense Slips to right section in cases of misclassifications.
  • In case of a TE having multiple destination heads of account being dealt in different sections, the TE would be considered to be authorised only when all the destination sections authorise the TE. If even a single destination section does not authorise the TE, the TE as whole would not be allowed to be posted. TE will be available for authorisation to all the destination sections simultaneously. A flag for authorisation will be set at the individual head of account level, by the respective section. Destination section can reject the TE by specifying the reason for rejection or it can redirect the TE to another section by updating the destination section and the destination head of account.

Post authorisation processing carried out after final authorisation

For missing vouchers / challans, where the Missing voucher / challan flag is set in Voucher / Challan data store, the authorisation will update the OB flag in Voucher / Challan data store, for the identified record.

  • All vouchers and challans against which errors have been set, will be added in Objection Book and Adjustment register data store.
  • Based on TE Updations, details entered during Transfer Entry capture will be updated to other data stores, such as Vouchers for Contingency Fund, Central GIA etc.
  • TE General Number will be updated for Contra TEs.

e.Outputs

  • Update Covering Memo data store
  • Updated Voucher data store
  • Update Challan data store
  • Updated Treasury Accounts ( LoP/CA/MA)data store
  • Updated Transfer Entry data store
  • Update Objection Book and Adjustment register data store
  • Update Central GIA data store
  • Update MPMP (authorisation status of LoP and CA)

Dealing With Objection Items

Generation of Objection Memo

a.Introduction

In cases of missing vouchers, submission of vouchers which have illegible head of account / amount, the details of the same are compiled from the corresponding Covering Schedule with the OB indicator set. Intimation of these items kept under objection is to be sent to the respective account-rendering source.

This process is also used to intimate the district departmental officers for want of pending DC bills & utilisation certificates.

This process generates the Objection Memo to be issued to the Treasuries, who have submitted erroneous vouchers or have to send the vouchers not sent for compilation during the earlier months.

b.Inputs

Parameters passed:

  • Month of account or
  • Objection Book item reference number or
  • Account source code

Data stores used:

  • Voucher
  • Challan
  • Objection Book & Adjustment register
  • Monthly progress monitoring parameters( to see if all the vouchers/challans have been posted for the Account source for the MoA)
  • Drawing & Disbursing Officer

c.Validations

  • General field validations of checking against corresponding master and valid values of domain applicable.
  • The data for the month of account, passed as parameter, should have been authorised.

d.Processing

  • Provision will be given to generate Objection Memo for individual objection items or for all items corresponding to a particular treasury &/ or for a month of account.
  • If account source code is passed as parameter, generate the Objection memo, listing the details of the booking section, Account source code and description, month of account, Head of Account (Receipts / payments) and finally the total amount kept in objection under the items.
  • For each Objection memo issued, a running serial number is to be generated.
  • Generate a hard copy of the Objection memo to be issued.
  • These details of Objection memos issued are to be updated against the corresponding entries of the Objection items in the Objection Book & Adjustment Register.

e.Output

  • Updated Objection Book & Adjustment register
  • Hard copy of Objection memo.
15.Capture adjustments for Objections from Treasury
  1. Introduction

This process captures the adjustments received from the accounting sources, in response to the objection raised by AGO. The process is initiated when the concerned treasury submits a wanting voucher / DC Bill to clear the objection or clarification for erroneous LoP/Cash a/c or Covering memo.

  1. Inputs
  • Voucher / challan (Hard copy)
  • DC bill (Hard copy)

Parameters passed:

  • Objection item reference number or
  • Account source code or
  • Month of objection and
  • Objection memo reference number

Data stores used:

  • Objection Book & Adjustment Register
  • Treasury Accounts
  • Accounts distribution
  1. Validations
  • All validations discussed under the process of capture of data from vouchers/ challans.
  1. Processing
  • Corrections are made to LoP / Cash account and Covering memo which were earlier marked to be under error.
  • TEs shall be required for clearance of treasury/OB suspense and booking the amount under proper service head of account.
  • The details of adjustment (adjustment date / month of adjustment, TE number if Transfer Entry booked to adjust Objection item, adjusted amount) are recorded against the corresponding Objection item in the Objection Book & Adjustment Register.
  1. Output
  • Updated Objection Book & Adjustment Register.
  • Updated LoP / Cash Account /Covering Memo data store.

Regional Training Institute, Allahabad

Top View