General Features

AP1

The system will be able to handle on-line data entry for:

*  vendor details

*  voucher entry

*  payment processing

Vendor Information

AP1

Vendor codes will be alphanumeric with a minimum of 4 characters.

AP2

The vendor code will be either system generated or manually entered.

AP3

A short name, mnemonic or vendor codes will be used to access vendors during transaction entry and enquiries.

AP4

The system will cater for the following information on the vendor record:

*  vendor code

*  vendor short name

*  vendor name

*  vendor address

*  vendor telephone

*  vendor facsimile number

*  vendor contact person

*  vendor type

*  optional or user-defined multiple credit terms or contract  information

*  currency details

*  payment method

*  credit limit

*  last date of activity

*  lead time

*  history

*  GL codes for purchases, creditors and cash

AP5

It will be possible to set up an "irregular suppliers" account for processing transaction for rarely used suppliers or one-time vendors.

AP6

The system will produce a listing of vendors with no activity for a specified period of time.

The system will provide:

*  invoice register facilities

*  certification of invoice values

The system will optionally register and certify the invoice at the same time.

The system will record to whom invoices have been sent for either approval, GL coding or adjustment.

The system will allow for the following fields in the transaction record:

*  vendor code

*  vendor reference invoice number

*  transaction reference for internal use

*  invoice type

*  terms

*  invoice date

*  invoice receipt date

*  posting date

*  due date

*  period

*  gross amount

*  discount

*  net amount

*  optional quantity

*  optional unit price

*  transaction currency

*  currency rates

*  payment method e.g. cheque

*  bank details

*  order number and link to order details e.g.. item code, type, order quantity

*  GL code

*  hold information - before updating GL

*  status code - delivered or not

*  flag prepaid for items

The system will check for duplicate vendor invoice numbers.

There is no limit to the number of lines per invoice.

General ledger code distributions will be entered on:

*  purchase orders

*  vendor record

*  individual lines on an invoice

GL distribution codes will be validated online in the AP and invalid transactions rejected.

The system will check that the total recorded against the distribution lines equals the total invoice sum.

The system will be able to handle discounts as either a percentage or an amount.

The system will automatically post a discount to the correct general ledger account for discounts.

It will be possible for a group of invoices to be authorised for payment together.

Matching will be available for both:

*  the whole invoice and

*  line by line

It will be possible to process and authorise a goods received note.

A credit note can be matched with parts of one invoice

Amount transactions entered on-line can be posted at the end of the day or period.

Posting will update the

*  accounts payable

*  general ledger

AP1

The system will allow processing of more than one accounting period typically previous and future periods.

AP2

The system will handle accruals with automatic reversal in the next period.

AP3

The system accept open item accounting.

AP4

It will be possible to search using:

*  supplier name

*  supplier short name

*  invoice number

*  invoice reference

*  purchase order number

*  cheque number

*  transaction date

Payments

AP1

It will be possible to process manual cheques and they will appear on the cheque register.

AP2

The system will provide automatic processing of recurring payment transactions.

AP3

It  will be possible to specify an end date for recurring payments.

AP4

It will be possible to report automatic payment on a separate payment register.

AP5

It will be possible to pay more than one cheque for a vendor.

AP6

It will be possible to stop payment of a specific invoice temporarily.

AP7

It will be possible to make a payment during the same processing cycle that the invoice was entered.

AP8

It will be possible  to pay invoices as specified without regard to the payment scheduled date.

AP9

The system will allow for part payments to be made.

AP10

It will be possible for individual items to be paid on the next payment date to be listed in advance of the cheque processing cycle.

AP11

Duplicate payments will be identified and alerted.

AP12

Individual general ledger codes will be specified for each bank account.

AP13

The system handle advance payments.

AP14

The interface with the general ledger will allow the cheque number reference to be passed into the general ledger to assist with bank reconciliation's.

AP15

If a posted payment is voided, the GL posting will automatically be reversed.

Cheque Printing

AP1

The system will print cheques with the remittance advice above the cheque.

AP2

Customisation will be possible.

AP3

The cheque printing routine will print asterisks characters to fill up the numeric and description blocks not being used in the amount and word fields of the cheque.

AP4

There will be a line up facility for the beginning of the cheque printing process.

AP5

There will be a recovery procedure in the event of a failure in the cheque printing process.

AP6

The system will have controls to prevent the same cheque from being printed in both the original and the recovery process run.

Cheque Reconciliation

AP1

The system will provide cheque reconciliation capabilities.

AP2

Gaps in cheque sequence will be identified and reported.

AP3

A listing of outstanding cheques will be provided.

AP4

Voided, cancelled or returned cheques will be reconciled.

AP5

During reconciliation, the system will calculate uncleared payments by vendor.

Cash Management

AP1

A report will be generated before the payments run to list payments to each vendor.

AP2

Current invoices input be can be temporarily and selectively held.

AP3

There a will be a cheque voiding routine to delete a payment from the run.

AP4

The system will produce comprehensive cash requirements reports:

*  by period planned payment run date

*  by bank

AP5

The system will show amounts expected to be paid in all planned payment runs in a user specified period.

AP6

cash requirements reports and enquiries will take into account projected payments in respect of goods received but not invoiced.

Purchase Order Processing

AP1

The system will facilitate matching, of purchase orders, receiving reports and vendor invoices.

AP2

Matching will be available for both:

*  the whole invoice and

*  manual matching.

AP3

The system will produce exception reports of unmatched invoices.

Foreign Currency

AP1

The system will maintain open items in both local and foreign currency (if the need arises).

AP2

The system will maintain standard currency exchange rates for each foreign currency.

AP3

For exchange rate the following decimal places will be used for:

*  input (at least 3)

*  calculations (at least 7)

*  output/reporting (At least 3)

AP4

The system will handle multiple standard exchange rates for a given currency based upon effective dates.

AP5

It will be possible to override the standard currency exchange rate with each input transaction.

AP6

When the standard exchange rate is overridden, an output report will be generated showing:

*  the standard exchange rate

*  the overridden exchange rate

*  the person entering the override transaction.

AP7

For user-defined items postings and account balances will be maintained in both local currency and user-defined foreign currencies.

AP8

The system will calculate foreign exchange gains/losses.

AP9

The system will post foreign exchange gains and losses to a user defined general ledger code at either:

*  payment generation or

*  after reconciliation of a payment

Interfaces

AP1

The user will have the option to post to the general ledger:

*  at the detail level and

*  summary level by voucher

AP2

The general ledger will be posted at the same time as the accounts payable subsidiary ledger is posted.

AP3

The system will support interfaces to other systems including:

*  purchasing

*  receiving

*  general ledger

*  stock control

Generic Capabilities

AP1

It will be possible to request standard output records by:

*  range of vendor numbers

*  range of posting dates

*  due dates

Vendor Purchase Analysis (Reports)

AP1

It will be possible to report a purchase according to the following options:

*  major vendors

*  foreign

AP2

There will be a report summarising purchase and payment history by vendor.

AP3

There will be a report listing open items and paid items.

AP4

There will be a report of unmatched invoices.

AP5

The system will print vendor statements.

AP6

The system will produce a vendor ledger listing:

*  by vendor number

*  alphabetically

AP7

The system will be able to produce an accounts payable invoice/voucher register.

AP8

The system will produce an aged outstanding balance report by vendor in both detail and summary.

AP9

Aging bands ( e.g.. 30,60, 90 days)

Enquires

AP1

On-line enquiry capabilities will exist to report:

*  all open invoices per vendor

*  vendor payments activity

*  standard terms

*  vendor purchase activity:

   -   this period

   -   previous periods

   -   previous years

*  payments matched to specific invoices

*  transactions with different status indicators

AP2

The system will perform on-line sorted enquiries whereby all vendor information is presented at the user's option:

*  in posting date sequence

*  in voucher number sequence

*  in due date sequence

*  in payment status sequence

Audit Listings

AP1

A register of cheque numbers will be maintained by the system.

Adjustments and Corrections

AP1

The system will print debit/credit memos

AP2

The system will automatically generate and post debit/credit notes to the general ledger.

AP3

The system will be able to relate a debit/credit note to a number of invoices for one vendor.

1.1 Ledger structure

(a)

The sales ledger will be fully integrated with the general ledger and cash book. 

(b)

The structure will have a facility for third party (employer or insurer) billing so as to ensure the correct company or insurer is billed.

(c)

All employees under one company or a particular medical cover will have individual accounts.

(d)

The structure will allow covered claimables to be billed separately to the responsible third party and non-covered (e.g. telephone) items to be billed to the individuals.

(e)

When an employee leaves a company it will be possible to delete them from the scheme but still maintain any outstanding bills to that company.

(f)

The patient numbers will be system generated at the OPD by OPD system (3^rd Party SW)

(g)

It will be possible for a mnemonic abbreviation to be set up for use in accessing accounts during:

* transaction entry,

* enquiry.

(h)

There will be a facility for patients to be linked where they form part of a group e.g. company cover.  Such a facility will not be dependent on the account code.

(i)

Periods for accumulating and reporting purposes will be defined as calendar months within a one year reporting framework.  It will be possible for the user to define other periods if desired.

(j)

The sales ledger will be an open item, i.e. all transactions will be retained on the system until cleared.

(k)

It will be possible to post to all nominal ledger accounts through the sales ledger.

(l)

The sales ledger will be able to receive transactions automatically from a separate invoicing module.

(m)

The following types of transactions will be for:

* inpatient invoices,

* inpatient credit notes,

* adjustment journals,

* cash receipts,

* cash refunds.

1.2 Patient masterfile record

(a)

The following user maintainable fields are required on the patient record:

* patient number,

* patient name,

* date of birth

* patient address,

* patients next of kin,

* next of kin contact - telephone, fax, email, pager

* name of company or insurer liable

* contact of company or insurer

* contact person at company or insurer institution

* credit terms,

* cover limit,

* invoice address

* is the patient covered for outpatient or only inpatient.

Additional items for inpatient

* attending physician

* some patients are covered for inpatient and others not.

* optional - the mothers bed charges

(b)

It will be possible to append comments to a patient record, and for such comments to be appended without accessing the patient file maintenance menu (e.g. during invoice entry).

(c)

It will be possible to modify and delete a patient, company or insurer when patients are no longer covered or the company/insurer withdraw from their scheme from Mohammad Dossary Hospital Co.

(d)

It will not be possible to delete a patient, company or insurer account unless there is no account balance or transaction activity on the account.

(e)

It will be possible to record an annual sales budget against each company or insurer account.

1.3 Irregular patients

(a)

It will be possible to set up an "irregular patients" account for processing transactions with one-off patients so as to obviate the need to set up individual master file records.

(b)

For these accounts, the identity of the patient will be shown against each transaction:

* on account enquiry,

* in cash allocation.

1.4 Invoice input

(a)

If transaction batching is used by the system, it will support batch control on input.  Agreement of batch controls will be mandatory before batches are accepted for posting.

(b)

Batch numbers will be allocated by the system.

(c)

Batches will be limited to:

* a single period,

* a single transaction type.

(d)

The minimum number of transactions required to constitute a batch will be one.

(e)

Batches will be written to a holding file, and will be available for recall and modification before posting.

(f)

Agreement of batch controls will be mandatory before batches are accepted for posting.  

(g)

It will be possible for valid batches to be posted selectively by the user.

(h)

It is anticipated that the following fields will be input for generation of invoices if sales order processing is not used:

* patient number,

* invoice reference,

* invoice date,

* due date,

* period of service delivery,

* value,

* sales ledger narrative (minimum 20 characters),

General ledger breakdown:

* general ledger account code,

* general ledger narrative,

* value,

* debit/credit indicator,

* quantity (optional field),

* stock code and description,

* analysis code.

(i)

The system will calculate the due date from the patient's, company's or insurer's credit terms for any invoices input.

(j)

The calculated due date can be overridden by the user.

1.5 Cash posting and allocation

(a)

Cash can be posted and allocated in one step.

(b)

Allocations within an account can be based on any of:

* allocated to specific transactions,

* allocated to oldest transactions,

* allocated to whole account.

(c)

Transactions can be part paid as well as fully paid.

(d)

During the allocation, the system will display all unallocated transactions on the screen, or a user defined range of such transactions.

(e)

Where more than one screen of transactions is displayed, the user will be able to move rapidly backwards and forwards between screens.

(f)

Items for allocation will be selected by cursor movement or by entering a line number, rather than keying in the reference number of each item.

(g)

A facility will be available, suitably protected for undoing allocations previously carried out on an account - it will be done before updating the nominal ledger, thereafter it will be a journal adjustment.

(h)

It will be possible during screen enquiries on cleared transactions, to see which transactions have been cleared against each other on an account.

1.6 Data output

1.6.1

Posting to general ledger

(a)

Items entered into the sales ledger will be posted to the general ledger automatically.

(b)

It will be possible to post sales ledger transaction information to the nominal ledger in detail or in summary form.

(c)

It will be possible to post to previous and future general ledger periods as well as the current period from the sales ledger.

1.6.2

Enquiries

(a)

The following information will be available on specification of a patient, company or insure number or code:

* patient, company or insurer name and address and
   other static data,

* account balance analysed by period,

* individual transaction details in date sequence (including items paid but not yet cleared from the transaction file).

(b)

The fields displayed at item level will include:

* reference,

* type,

* description,

* date,

* due date,

* initial value,

* outstanding value,

* early settlement date,

* discount available,

(c)

The system will be able to display the general ledger postings arising from a selected transaction, without having to exit from the sales ledger module to the general ledger.

(d)

It will be possible to ask for selective display of transactions by:

* period,

* transaction dates,

* payment status,

* transaction type,

* transaction reference,

* batch,

* combination of the above.

1.6.3

Reporting

(a)

A debtors report will be produced on demand showing outstanding balances for:

* all debtors,

* user defined range of debtors,

* optionally including open items supporting the balances.

(b)

An aged debtors report will be produced on demand for:

* all debtors,

* user defined range of debtors (either individual or third party),

* account balances aged over current and three earlier periods,

* aged by transaction date,

* aged by due date,

* displaying account balances only, or all uncleared transactions within the accounts as well as the balances.

(c)

Transaction aging periods will be user definable by month rather than by accounting period.

(d)

The system will provide a report of unallocated cash, credit notes and credit adjustments.

(e)

The system will provide a projected cash inflow report based on invoice due dates, analysed by periods.

(f)

Statements will be printed on demand.

(g)

Statements will be selective by:

* all open item debtors,

* user defined range of debtors.

(h)

A statement will show uncleared transactions from the previous month's statement and all the current month's items.  The system will have the option of suppressing cleared transactions for previous periods or printing them.

(i)

Transaction information shown on a statement will include:

* invoice date,

* invoice reference,

* original value,

* where there is part payment, both invoices & receipts,

* debit and credit values in separate columns,

* aging analysis over current, 1, 2 and 3+ months,

* highlighting on overdue items.

* patients name

(j)

It will be possible for statements to be suppressed for specific customers (part of customer setup master details).

(k)

The system will produce standard chasing letters, based on the age of the debt.  It will be possible to specify:

* choice of letter,

* age of debt,

* customers to be suppressed.