General features

AR1

The system handle on-line data entry for:

*  Customers and

*  Billing/Invoicing

AR2

The system will maintain paid items in the open item file until month-end.

AR3

With the appropriate security it will be possible to purge all paid invoices on file for a user-defined period.

AR4

The system will be able to display the open item/balance forward status and aging for a customer.

AR5

The system will allow invoices, credit/debit notes and payments to be entered.

AR6

The system will automatically generate invoice information from orders existing on the system.

AR7

Customer statements will be generated at period end.

AR8

Invoice numbers will be generated by the system.

AR9

The system will maintain customer balances on open item basis.

AR10

It will be possible to define the following aging categories: current, 30, 60, 90,120,180 days.

AR11

Adjustments to the AR module will be recorded including a reference number and reason.

AR12

With appropriate controls the system will display:

*  Customer name and address

*  Telephone number

*  All open items and paid items for the current and previous months.

*  Aged balances

Credit management

AR1

The will system track full exposure by customer (i.e. customer credit limit minus outstanding receivables).

AR2

The system will permit authorised users to override customer credit limits.

AR3

The system will permit credit note entries to update accounts receivable and sales analysis.

Credit/Debit Memos and Adjustments

AR1

Debit and credit note entries will be handled individually.

AR2

The system will be able to handle internal adjustment (e.g. negative credit notes).

AR3

Credit note numbers will be generated either by the system or manually.

AR4

Any credit notes generated within the system will affect  invoice balances.

AR5

Debit /credit notes can be printed on request.

Billing

AR1

The system will allow for partial billing of an invoice amount.

AR2

The system will maintain daily AR billing control totals with supporting details.

AR3

It will be possible to generate tear-off remittance advices to be returned with payment.

Cash Application

AR1

The system will post cash receipts on-line.

AR2

The system will display all open customer invoices during payment posting.

AR3

The system will allow for partial payments to be applied.

AR4

It will be possible to write-off a receivable amount at the time of cash application.

AR6

It will be possible to use cash deposits to credit an open invoice.

AR7

It will be possible to store partial payments and over-payments as separate open items against the original invoice amount until the invoice is fully cleared.

Inquiries

AR1

It will be possible to search and view customer data by:

*  Customer code

*  Customer name

AR2

It will be possible to review on-line, all customer accounts above their assigned credit limits.

AR3

It will be possible to review on-line all customer accounts past due.

AR4

It will be possible to review on-line activity for specific accounts.

AR5

It will be possible to review on-line customer aging and other statistic data such as last payment date.

AR6

It will be possible to review on-line all static document data for customer accounts by:

*  Customer number

*  Receipt numbers

AR7

It will be possible to review on-line all static data relating to payment by:

• Cheque number

• Customer number

• Date of document

Reports

AR1

The system will produce the following standard reports:

*  Billing Statements, including beginning open items, new charges, credits and payments, ending open balance and aging recap.  Other details include invoice number, date and date due, customer name, patients name, staff number, admission number and hospital number.

*  Detailed Aging Trial Balance for each active customer showing open invoice and AR activity (e.g. payments, debit and credit memos, write-off, comments) and summary total balance across all customers .

*  Customer Master List for all active customers including name, address, telephone number and contact person information.

*  AR Invoice Register - list of automated and manually entered invoices with control totals .

*  Credit/debit Notes Register for all memos generated .

*  Billing and Payment History for all invoices, adjustments and payments by customer for a user-specified period of time.

*  Cash Receipts Journal, list all payments received each day by either customer or receipt number.

*  Sale Journal, list invoices sent by customer, invoice number, customer code, amount due and related general ledger account.

*  General Ledger Distribution to summarise the distribution of AR general ledger transactions by account and date.

Data items required for the systems

AR1

Customer Data:

*  Customer number

*  Customer name and address

*  Contact name

*  Credit limits

*  Customer type

*  Customer group

*  Credit and payment records

*  Date account open

*  Year-to-date sales

*  Last year sales amount

*  Last date activity

AR2

Customer billing and payment history:

*  Date and amount of last billing

*  Date and amount of last payment

*  Year-to-date billing and payment

AR3

Invoice information:

*  Admission date

*  Discharge date

*  Patient name and number

*  Third party name and details

*  Surgicals and drugs

*  Theatre fees

*  Use of machines fee

*  Optional consultation fee

*  Optional resident mother fee

*  NHIF rebate

*  Miscellaneous charges

AR4

Credit Note information:

*  Customer number

*  Invoice number

*  Amount of credit

*  Reason for credit

*  Autorisation reference

*  GL account distribution

AR5

Cash receipts:

*  Cheque number

*  Amount

*  Date of payment

*  Date of entry

*  Account number

*  Allocation of cash received against various invoices.

Interfaces

AR1

The system will support interfaces to/from other systems including:

*  General Ledger - cash receipts, sales invoices, and credit notes.

*  Inventory

*  Order Entry/Invoicing - invoices and credit notes posted  to AR accounts.

*  Sales Analysis - sales and credit note information will be automatically provided to the sales analysis
   application

AR2

The user will have the option to automatically post to the GL at:

*  a detail level

*  a summary level by period

Audit Trails

AR1

The system will produce an audit trail of all entries or changes to:

*  Invoices

*  Credit Notes

*  Debit Notes

*  Cheques/Payments

2.3.63

The system will print portions of the audit trail for:

*  Specified customer accounts

*  Specified GL account

General requirements

C1

Patients information will be picked from the casualty department. Admission Module (3^rd Party SW)

C2

This information should include: (3^rd Party SW)

*  Patients names

*  Date of birth

*  Consultant

*  Ward patient is admitted to

*  Bed number

*  Admitted by

*  Sex

*  Religion

*  Residential address

*  Saudi resident or non-Saudi resident

*  Next of kin

*  Next of kin address

*  Identification of the person, institution or medical
    scheme paying the bill

C3

The admissions module should have a facility for printing adhesive labels with necessary demographic information such as patients name, ward, bed number, date of admission, age and estimated discharge date.

C4

The admissions module should have a provision for Gosi no entries.

C5

The system will have a provision for deposits to be paid.

C6

There should be a provision for following dates and time:

*  Admission date

*  Discharge date

*  Date of departure

*  Admission and discharge time for day care cases.

C7

The system should be able to hold information about the following modes of payment:

*  Cash

*  Credit card - at least 12 digits

*  Cheque

C8

Third party billing will cater for payments by:

*  Company

*  Medical card

*  Insurance cover

C9

There will be different ward charges for the following:

*  Child's bed/cot daily rate

*  Mothers bed daily rate - either lodger or resident

*  Special Care Unit daily rate

*  Late discharge rate

C10

The system will have a facility to charge different rates for the same services rendered depending on the customer classification i.e. KSA resident, non-resident  or insured.

C11

Daily rate charges will be numeric.

C12

The daily charge rate will cover accommodation or  and meals.

C14

Charges will be picked on-line from the following departments:

*  Pharmacy

*  Drug store

*  Laboratory department

*  X-ray department

*  Theatre

*  Casualty - outpatient

*  Miscellaneous - from items used in ward e.g. cotton wool, spirit, and accommodation.

C15

The invoice will pick up patients details from either casualty or admissions.

C16

The invoice will pick up the following daily charges:

*  Bed charges

*  Drugs and dressings

*  Theatre drugs

*  Theatre fee

*  Laboratory fee

*  Medical officer

*  X-ray fee

*  Resident mother charges for child patients

*  Cannula fees

*  Incubator fee

*  Admission fee

*  Clinics

*  Sundries

Machines

*  Theatre gas charges

*  Cardiac monitor fee

*  Servo Ventilator

*  Nebulized oxygen

*  Phototherapy

*  Groupette

*  Heater

*  Steam

*  Airshield warmer fee

*  etc. will be decided at the time of implementation

C17

All charges are numeric.

C18

The net amount due will total all daily charges and deduct the deposit paid from the total due.

C20

The inpatient system will have a reservations module to facilitate advance booking.

C21

Cashiers will receive money under sundries for the following:

*  Telephone calls made at the main reception

*  Salary advance repayments

*  Rent from the doctors

*  Any other cash paid in

C22

The system will alert cashiers when patients have overpaid.

Data input

C1

The system will allow for rebates on bed charges.

C2

The following details will be input for the person paying the bill:

*  Mode of  payment

*  Name of paying person or company

*  Address

*  Telephone number(s)

C4

If the mode of payment requires a card or company letter to be submitted, there will be an indication.

C5

The system will have a provision for financial notes for details such as payment arrangements, poor track record of paying, details of guarantors.

C6

Well wisher (mother) will have the option to be either resident or lodgers.

C7

For resident well wisher (mother), the system will hold the following information:

*  name

*  Patients name

*  Mode of  payment

*  Name of paying person or company

*  Credit card name and number (when applicable)

*  Date of admission

*  Ward of admission

*  Admission number

C8

It will be possible to enter the following all relevant charges.

C9

All charges are numeric and greater than 10

C10

Reservations will have the following features:

*  Bed reservations

*  Theatre scheduling and slot allocations

*  Occupancy projections

*  Confirmation letters, fasting instructions incase of  surgery patients

C11

Cashiers will receive money under sundries for the following:

*  Telephone calls made at the main reception

*  Salary advance repayments

*  Rent from the doctors

*  Any other cash paid in

C12

The system will hold the following forms:

*  Admissions

*  Discharge

*  Company claim form

C13

It will be possible to enter and delete names of employees and their dependants.

C14

Over weekends the cashiers give out funds for emergency purchases, the system will have a provision for this.

Data stored

C1

The deposit field will not be less than 999.99

C2

If the mode of payment requires a card or company letter to be submitted, the system will flag.

C3

When theatre appointments are entered, the system will display the number of times the procedure has been performed, its average duration and the average length of stay this and last year for the consultant in question and for all consultants.

C4

The theatre diary will be optionally available online.

C5

The system will contain a list of all companies who provide cover for their employees.

C6

The system will contain a list of all employees (in the medical schemes) and their dependants.

Data output

C1

The module will calculate a daily rate total and net amount due.

C2

It will be possible to print unnumbered interim invoices for in-patients on request.

C3

Doctors receive their cheques from the cashiers.  The system will be able to print a list of all doctors in this list and print a pick-up list which the doctors will sign.

Reports

C4

It will be possible to print any of the following reports as the need arises:

*  A daily record of all admissions

*  A daily record of all discharges

*  Admissions register

*  Discharge register

*  Daily and monthly deposits paid

*  Daily, weekly and monthly credit card summaries

*  Doctors bill

*  Inpatient invoices

*  Liability form

*  Cheques

*  Daily and monthly revenues with a facility to display  or print in detail and summary.

    -  by department

    -  by consultant

    -  by service type or account code

*  Bed occupancy with dates admitted and estimated discharge date, accumulated charges, by ward and
    consultant.

1.1 General requirements of an hospital

(a)

The system will be capable of maintaining up to unlimited current and deposit accounts.

(b)

The cash book will receive automatic postings from the purchase and sales ledgers and the payroll system, together with manual batch posting of other payments and receipts.

(c)

The cash book will be integrated with the general ledger.  Postings will update specified general ledger accounts and general ledger cash book balances.

(d)

The system will facilitate bank reconciliations, using bank statements input either manually or automatically.

(e)

Receipts and payments from the sales and purchase ledgers and the payroll will be posted as separate posting runs.

(f)

A full audit trail of cash book transactions will be produced automatically.

1.2 Data input

(a)

The system will support input on a batch basis. Batch numbers will be system by users.

(b)

The following references will be posted to the cashbook:

* customer/supplier account number,

* transaction reference number,

* general ledger full code,

* transaction amount.

(c)

Bank giro credit references will be made up of the customer account number and the transaction reference number; the customer name will be brought up automatically on input of the customer account number.

(d)

For manual receipts and payments there will be fields for:

* cheque number (for payments),

* narrative to allow for payee name or narrative on receipts,

* general ledger code(s),

* amount.

(e)

Batch totals will equate with banking amounts to enable matching by the system on the automatic bank reconciliation.

(f)

When entering a bank statement, either automatically or manually, there will be fields for:

* cheque number,

* amount,

* date on statement,

* reference number for bank giro credits.

1.3 Data stored

(a)

The following data will be stored within the system:

* balance on each bank account,

* uncleared cheques,

* standing orders and direct debits,

* bank account details for payments by direct debit.

(b)

The system will aggregate totals of payments and receipts on a daily, weekly and monthly basis on the following classification:

* sales ledger,

* purchase ledger,

* other receipts,

* other payments.

(c)

The system will maintain totals for other receipts and other payments by general ledger posting code and this information will be available on enquiry.

(d)

It will be possible to load onto the system a budgeted cashflow following these main categories and for the system to report actual cashflow against budget showing variances for these main categories. It will be possible to alter the forecast.

1.4 Data output

(a)

The following reports will be produced:

* a daily position report on each account including details of receipts and payments with totals for each, and for all accounts aggregated,

* full audit trail reports on a monthly basis,

* bank reconciliation report for each bank account

* general ledger distribution report with total for each general ledger account

* automatic cheques,

* remittance advices,

* a cashflow position report against budgeted cashflow.

(b)

It will be possible for the user to access  the individual payee names for automatic cheque runs without having to access the purchase ledger or payroll modules.