Usually applications are designed to be fail-safe: it is assumed that everything works and all data is entered correctly and is consistent. In the case of failure, experts have to search for the cause and check for damages. The user usually notices the problem. The reality is that applications sometimes fail.

In contrast ALFOX ERP II is designed to be safe-fail. Every transaction can be repeated and regenerated. Most failures are identified by the system and the user can attempt to fix the problem. If recovery is not possible, the error is isolated and the rest of the system continues to work. Transaction de-coupling design is the basis for this ability.

An example: The transaction substructure of the transaction 'cash sale of a product over the counter' is:

• Material Transaction (adjust inventory)
• Generate Material Accounting (for each Accounting Schema)
• Post
• Invoice Transaction (calculate tax & create invoice)
• Generate Invoice Accounting (for each Accounting Schema)
• Post
• Receipt Transaction (create receipt for invoice)
• Generate Receipt Accounting (for each Accounting Schema)
• Post

To have ten or more transactions rather than one or two may seem to look like overkill, but it is actually faster and much more reliable than the standard approach:

When committing, only two sub-transactions are performed, the material and invoice transaction. This ensures a fast return, so that the user can continue with entering the next transaction. The remaining sub-transactions are scheduled, optionally batched and are executed asynchronously in parallel. This allows deploying load-balancing rules to ensure fast online response.

Each transaction only performs one task. This is easier to stabilize; the impact of failure is isolated and easy to identify.

The communication between the individual transactions is message driven, allowing asynchronous batching of transactions.

Additional functionality is much easier to implement. The cost of adding new functionality in ALFOX ERP II is much less as in other Applications.

The user can continue working with little restriction, if the main transaction (e.g. inventory adjustment) is successful. The remaining transactions can be generated, after problem is fixed.

The system checks regularly if a transaction is complete. If a transaction is not complete and consistent due to system failure, the administrator and user are informed.

As applications become more complex with ever growing combinations, potential error causes grow exponentially. ALFOX ERP II provides an extensive validation framework and in case that it fails isolates the problem ensuring high availability of the core functions.