Billing and Cash:

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

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

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

The system will post cash receipts on-line.

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

The system will allow for partial payments to be applied.

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

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

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.

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 for each active customer showing open invoice 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.

·    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.

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

 

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

 

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

·    Cheque number

·    Customer number

·    Date of document

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

·    Miscellaneous charges

 

Cash receipts:

·    Cheque number

·    Amount

·    Date of payment

·    Date of entry

·    Account number

·    Allocation of cash received against various invoices.

 

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.

 

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

(The system will alert cashiers when patients have overpaid)

Medical Record:

The following functions are computerized:

Facility for entry and creation of a catalogue for International classification of codes for diseases (ICD-10) and International classification of codes for Procedures(ICP). This module provides facility for In Patients and Out Patients to enter ICD and ICP for diseases and diagnostics procedures and surgery procedures by users in Medical department.

This module will be integrated with Registration for picking up patient details on entry of patient ID. Facility will be provided by on-line help for users to view catalogue while entering.

Highly useful statistical report is generated under

- Surgery Medical Statistics

- OP Medical Statistics

- IP Medical Statistics

- ICD, Code wise Disease Statistics

Enterprise-wide Scheduling:

The enterprise-wide scheduler's primary job is to provide a convenient facility to.

Schedule tasks/assignments for the resources in a hospital, and,

Schedule services provided by a hospital to patients i.e., determine and reserves specific days and times for the services to be provided to the patient.

Resources can be active, e.g., doctors, nurses, lab technicians, or passive, e.g., rooms, beds, etc. Active resources have working hours outside of which tasks cannot be assigned to it. In addition, an active resource may mark certain days and times as non-working or busy (e.g., during vacations or personnel appointments), as and when required by resources. No tasks can be assigned during these times either.

There are several services that a hospital provides to its patients. The following examples of services provided by a hospital.

·    Lab investigations.

·    OPD consultations.

·    Radiology.

·    IP admission.

·    Services are available at pre-determined service centres.  The schedules can be :

o    One time schedule.

o    Repeat schedule.

o    Event driven schedule   etc.

It has the following functional modules.

·         Site specific customisable parameters.

·         Calendar manager.

·         Scheduling of service orders.

·         Managing waiting lists.

·         Cancelling schedule.

·         Re-scheduling a schedule.

·         Display of current schedule for a department.

·         Checking in a patient for a scheduled service.

·         Availability of the scheduler functionality.

·         Scheduling reports

Housekeeping:

The main functionality of the blood bank system is to effectively carry out the function of collection, storage & Dispensing of the blood / blood product, for the efficient running of the blood bank.

Blood Bank Module carries the following functions.

·         Recording site specific parameters for blood bank.

·         Donor Registration.

·         Lookup facility of available donors.

·         Processing donor visit.

·         Accepting blood samples.

·         Component separation.

·         Testing blood samples.

·         Blood bank as sub-store of main stores.

·         Blood inventory management.

·         Request processing.

·         Issue processing.

·         Handling outside procurements and outside transfers.

 

The main functionality of the Housekeeping Department is to manage the procurement, storage, retrieval, circulation, use and disposal of various Housekeeping items. In order to provide the highest quality housekeeping and linen management services to the Health care industry. A conscientiously applied Housekeeping program is necessary to provide a safe, pleasant and functional environment for both the patients and personnel.

·    Sub Stores - Inventory Management.

·    Raising Indents in Sub Stores.

·    Issuing Items.

·    Discarding Items.

·    Linen Sent for Cleaning.

·    Receiving Cleaned Linen.

·    Released Beds.

Financial Accounting

Chart of accounts

 

The chart of accounts will include:

 

 

Categories for assets, liabilities, revenue & expenditure

 

 
  • Cost & profit centres for

 

 

 

*  each ward

 

 

*  laboratory

 

 

*  theatre

 

 

*  catering

 

 

*  pharmacy

 

 

*  OPD

 

 

*  miscellaneous

 
  • Input details for each new account will include:

 

 

 

*  Code

 

 

*   Title

 

 

*   Description

 

 

*  Opening balance
         

Purchase ledger

1.1 Ledger structure

(a)

The purchase ledger will be fully integrated to the general ledger and the cash book.

(b)

The format of the supplier code will be at least eight alpha-numeric characters. 

(c)

The supplier codes in each ledger will be capable of being maintained in separate ranges.

(d)

It will be possible for mnemonic abbreviations to be set up for use in accessing supplier accounts during:

 

* transaction entry,

 

* enquiry

(e)

Periods for accumulating and reporting purposes will be defined as calendar months within a one year reporting framework.  

(f)

The following types of transaction will be allowed for:

 

* supplier invoices,

 

* supplier debit notes and credit notes,

 

* adjustment journals and quasi services for donations, bonuses and discounts,

 

* payments (both automatic and manual),

 

* cash receipts (refunds).

 

* returns outwards

 

 

1.2 Supplier master file record

(a)

A facility will be available to add, modify or delete supplier master file records at any time.

(b)

The following user maintainable fields will be on the supplier record:

 

* code,

 

* name,

 

* address,

 

* payee name (if different from the supplier),

 

* payment address (if there is a different payee),

 

* telephone number,

 

* fax number,

 

* credit terms,

 

* discount terms,

 

* payment method,

 

* currency of the account,

 

* contact names.

(c)

The due date of payment will be calculated from the transaction date plus the details for:

 

* standard credit terms,

 

* discount terms.

(d)

It will be possible to append comments to a supplier record, and for such comments to be amended without accessing the supplier file maintenance menu (e.g. during supplier enquiry).

(e)

The system will maintain an annual turnover field per supplier.

 

 

1.3 Irregular suppliers

(a)

It will be possible to set up an "irregular suppliers" account for processing transactions for rarely used suppliers so as to obviate the need to set up individual master file records.

(b)

It will be possible to see the identity against each transaction on enquiry on the "irregular suppliers" account.

(c)

It will be possible to pay invoices on the "irregular suppliers" account through the automatic payment processing function.

 

 

1.4 Invoice register

(a)

The system will incorporate an invoice register facility by which invoices can be logged prior to entry in the ledgers.

(b)

The system will record to whom invoices have been sent for approval and coding.

(c)

Invoices will be posted to the purchase and general ledgers only on input of the full general ledger coding.

(d)

It will be possible to input only the missing components to initiate posting to the purchase and general ledgers of invoices already input.

(e)

Reports will be generated showing:

 

* who is holding what invoices,

 

* the total value of invoices outstanding,

 

* invoices outstanding for more than a specified period,

 

* the date that the invoice was sent to an individual for approval.

 

 

1.5 Invoice input

(a)

The system will validate stocks so that it rejects input from the invoice if the pricing is different from the PO.

(b)

The purchase manager will be the sole person with authority to revise varied prices.

(c)

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 a posting.

(d)

Bar Codes will be allocated by the system.

(e)

Batches will be limited to:

 

* a single Expiry,

 

* a single Sales Price.

(f)

The minimum number of transactions required to constitute a Bar-Code will be one.

(g)

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

(h)

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

(i)

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

(j)

It will be possible for supplier accounts to be looked up during transaction entry, using the alpha abbreviation.

(k)

It is anticipated that the following fields will be input on supplier invoices if purchase order processing is not used:

 

Header level:

 

* supplier code,

 

* transaction reference (internal),

 

* supplier transaction reference,

 

* transaction date,

 

* due date calculated by the system from the credit terms,

 

* posting period,

 

* transaction value,

 

* order number (to which the invoice relates),

 

* narrative (for purchase ledger entry),

 

General ledger breakdown:

 

* general ledger account code,

 

* general ledger narrative,

 

* value,

 

* debit/credit indicator,

 

* quantity (optional field),

 

* analysis code (see general ledger requirements).

(l)

There will be no practical limitations to the number of general ledger postings which can be input on a transaction

(n)

It will possible for the calculated date to be overridden during data input (either at batch input or at full general ledger coding input) and to specify a different due date.

(o)

When a different due date is specified, there will be an exception report on the transaction flagged on the payment report.

(p)

It will be possible for transactions entered into the purchase ledger to be given a default status, e.g. `authorised for payment` or 'not yet authorised'.

1.6 Payment cycle

(a)

The payments procedure will use transaction discounts, and due dates to generate a list of proposed payments for approved invoices.

(b)

By default the system will exclude unmatched invoices, but have a facility to force such generation.

(c)

The proposed payment lists will be able to be run at any time.

(d)

It will be possible to select items for payment interactively by the following methods:

 

* all items older than an input date,

 

* all outstanding items on an account,

 

* individual items on an account,

 

* all items up to "X" Saudi Riyals in total.

(e)

The system will be able to prevent payments to suppliers of more than a user specified amount.

(f)

The criteria for a proposed payment run will be able to be stored so that they need not be entered several times during a run.

(g)

It will be possible to specify certain items as "suspended" and therefore not to be brought up for payment until unsuspended.

(h)

The proposed payment list will also show for each supplier authorised items not yet due for payment and suspended items.

(i)

This list will be used as the basis for selecting payments, but with facilities to modify or delete them as follows:

 

* specific exclusions:

 

 - by supplier,

 

 - by invoice,

 

* inclusion of items not yet due or suspended,

 

* part payments,

 

* additional discounts.

(j)

If a supplier item is selected for non-payment, such status will attach to the supplier or invoice until deleted, i.e. it must be specifically unset to allow payment in the future.

(k)

The payment list will show both the discount taken and the net cash due:

 

* by supplier,

 

* by invoice per supplier.

(l)

The system will automatically take account of debit notes or credit notes in determining the net amount due.

(m)

Payment will not send a supplier into a debit balance state, although this will be possible to override.

(n)

The payment will support automatic payment by:

 

* check,

 

* letter of credit,

 

* cash.

(o)

The system will produce a remittance advice for all payments made (irrespective of method of payment).

(p)

Cheques and remittance advices will be printed in the same sequence.

(q)

The remittance advice layout will be user defined.

(r)

The remittance advice will contain, at a minimum, the following information:

 

* supplier name and address,

 

* supplier account code (internal),

 

* transaction references (internal and external) and net amounts for items settled,

 

* net amount settled,

 

* where there has been part matching, all relevant transactions.

(s)

The system will maintain a cumulative register of cheques

(t)

In the event of a printer problem it will be possible to restart printing for the last good check.

(u)

It will be possible for a check printing run to be declared void after production of the cheques.

(v)

A check register print will be generated automatically immediately after printing.

(w)

The system will provide tight security controls to avoid check duplication.

(x)

Payments will be posted to the cash book automatically and will automatically update the general ledger:

 

* supplier ledger control account,

 

* bank account,

 

* settlement discount account,

 

* expense accounts.

(y)

It will be possible to specify from which bank account a payment run is made.

(z)

Cash payments generated during a run will be posted and allocated against the transactions to which they relate.

 

 

1.7 Allocation

(a)

Manual cash payments, purchase credit notes and adjustments entered into the purchase ledger will be allocated by the user at the time of input against unlearned transactions on the supplier account on one of the following bases:

 

* unallocated,

 

* allocate to specific transactions,

 

* allocate to a range of transactions,

 

* allocate to oldest transactions,

 

* allocate to whole account.

(b)

The system will provide a facility for allocating transactions already on an account against each other.

(c)

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

(d)

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

(e)

A facility will be available, suitably protected, to `undo` allocations previously carried out on an account.

(f)

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

 

 

1.8 Data output

1.8.1

Posting to general ledger

(a)

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

(b)

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

 

 

1.8.2

Enquiry facilities

(a)

The following information will be displayed on input of supplier code:

 

* supplier name, address and telephone number,

 

* payee name, address and telephone number (if different),

 

* credit terms,

 

* account balance analysed by period,

 

* individual transactions in date sequence, including paid items and suspended items,

 

* entries on the invoice register.

(b)

The fields shown at transaction level will include:

 

* transaction type (i.e. invoice, credit note, journal etc),

 

* transaction date,

 

* transaction period,

 

* transaction reference (internal),

 

* transaction reference (suppliers),

 

* order number,

 

* narrative (if any),

 

* net amount due.

(c)

The system will be able to display the items paid by a selected payment

(d)

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

(e)

It will be possible to enquire on the purchase ledger without exiting the application currently being worked on.

(f)

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

 

* period,

 

* date,

 

* payment status,

 

* transaction type,

 

* batch,

 

* combination of the above.

 

 

1.8.3

Reporting facilities

(a)

A creditors report will be produced on demand, showing balances for:

 

* all creditors,

 

* user defined range of creditors,

 

* optional inclusion of open items, supporting the balances.

(b)

An aged creditors report will be produced on demand for:

 

* all creditors,

 

* user defined range of creditors,

 

* account balances aged over 1 month, 2 months and 3 months & over.

 

* aged by transaction date,

 

* aged by due date.

(c)

The information on the aged creditors report will be available at transaction level as well as supplier level.

(d)

Transaction aging periods will be user definable.

(e)

An open item transaction report will be produced on demand for:

 

* all creditors,

 

* user defined range of creditors.

(f)

The system will provide a report of unallocated cash or credit notes.

(g)

The system will provide a projected cash outflow report based on invoice due date analysed by future period.  The user will be able to vary the periods to fit in with the payment cycle.

(h)

A turnover report will be available listing the turnover by supplier for the current financial year.

Page 1 - 2 - 3 - 4 - 5 - 6 -7 -8 - 9