Unless stated otherwise, all points listed here were incorporated as part of Phase 1, and are functional. Later phases will build upon existing functionality.

Transaction double-entry accounting

The principle of double-entry accounting is used, so that the status of all stock can be easily and accurately obtained at any point in time – both in the present and for past stock movements. Any transactions relating to physical cargo movements must adhere to this standard. It must be possible to recreate stock balances at any point in the cargo supply-chain at any point in time. The vendor will be expected to produce detailed documentation around the ledgers and transactions being used, to assist any later development. Accounting Patterns in CATS describes the pattern implemented to support double-entry inventory managment for CATS.

Online/offline

CATS must be able to operate under conditions of poor &/or unreliable connectivity. This includes the ability to:

Allow data entry (restricted where appropriate)
Report on all previously synchronized data
Transfer data based on physical media: attachments that can be transferred by physical media or by email (often operational even when other internet connectivity is down); or to/from remote sites by bar-code

Portioning

As a result of the Online/Offline requirement, the areas that can be updated by an individual when operating under offline conditions must be strictly defined. If, for example, a person with administrator privileges is using an off-line database, they must not be allowed to change any data that will affect any contemporaneous changes by other users (e.g., the changing of location names, drop-down lists, etc.).

Record-level version control

Also as a result of the Online/Offline requirement, all records must have appropriate version control, to allow merging and conflict resolution when the offline database regains connectivity. This must be independent of the date/time on the computer and server, as this can be manipulated.

Twin date-stamps

Where relevant, records are to have at least two date/time stamps. The first records the time the transaction is recorded, and the second is the effective date of the transaction.

Conflict resolution mechanism

Also as a result of the Online/Offline requirement, if/when the same record is edited contemporaneously in two separate events, a conflict resolution mechanism must be available.

Interface language

The user-selection can select their preferred interface language (English, Amharic, etc.).

Data validation

There are two main types of pre-entered information visible to the user:

Lists where clean data is critical to reporting, and is not usually added to in everyday use (Commodity names, FDP/ Wereda/ Zone/ Regions, etc.): Should be selected from a list administered by an administrator at the Addis level.
Lists where information is added to regularly and is not critical to reporting (Transport Company name; Driver name, etc.): This information can be added directly by the user. It is recommended that standards be taught to the users, to reduce the frequency of duplicate (misspelt) entries. A mechanism to combine multiple entries is recommended, but not critical.

Soft-coding of key information

Wherever possible, information to appear on reports and screens should be soft-coded, and changeable by the appropriate user. This includes (but is not restricted to): Report and screen titles (The name “NDRMC” for example has changed a number of times in the past).

Ethiopic dates

The user interface will support the entry of Ethiopian dates, to be stored as Gregorian dates in the database.

User manuals

Following the acceptance of a phase, user guides are to be developed, with versions in both English and Amharic.

Amharic/Gee`z script data entry

The user interface will support the use of Amharic script for data-entry purposes on selected fields.

Followup mechanism

Selected screens will allow the user to ‘escalate’ an issue to a role or person

Automated database propagation

Changes to the central database structure are to be automatically propagated to the hub databases.

Automated remote application update

Changes to application components that reside on the hub servers (allowing offline access in the event that connectivity between Addis and the hubs is down) will propagate automatically