From a delivered service to a settled invoice.

01

Challenge

Delivering a service, issuing an invoice and receiving payment are distinct events. A payment could arrive in advance, settle part of a debt or require currency conversion. Each amount needed to remain connected to its customer, service and document, allowing subsequent operations to use information already entered.

02

Our contribution

I.V.A. designed and implemented the application on its own Miracle16 platform. The work covered data structures, interaction between applications, calculation rules, input forms and user documentation. In 1999, AeroMar received a non-exclusive licence for Miracle.

03

Solution

IMS — Invoice-Mutual Settlement — combined reference applications, document processing and analytical applications. Reference records defined customers, bank details, currencies, operations and settlement terms. Operational applications created source documents, invoices, payments, tax invoices and the sales ledger. The design provided for preparing data for SunSystems through an export journal and an external file. The system connected two flows: records of goods and services supplied and incoming payments recorded in bank documents.

04

Working with shared data

Several operators worked with shared information. When another user changed data, a flashing indicator appeared in the relevant window. Double-clicking it acknowledged the changed data and refreshed the display. The application thus made a change to shared information visible to someone already viewing it. The project also provided editor and viewer versions of the customer journal. These address different aspects of working together: an application’s purpose determines the available actions, while the indicator signals changes to shared data.

05

Document processing controls

Controls also governed the sequence of document processing. Source amounts were included in an invoice with protection against billing them again in another invoice. Final printing locked the invoice against changes; a preview print without registration left it editable. Payment tracking distinguished unpaid, partially paid and fully paid invoices. These application rules defined a document’s lifecycle: when an operation was permitted and how its result would be used next.

06

Configurable calculations

Calculation settings operated at several levels. Customers and their subtypes could have their own currencies, periods and markups. Algorithms calculated additional amounts, and the user guide allowed enterprise specialists to modify them. Accounting policies had effective dates, linking the selection of a tax-invoice rule to the document date. IMS retained both amounts and the conditions under which they were processed.

07

Outcome

IMS applications and detailed operating instructions were developed for recording services, issuing invoices, allocating payments and handling advances. Surviving screens show the system’s interface and its connection to Miracle. Separate proposals addressed further development of the financial manager; they are not included here as confirmed capabilities.

08

Historical assessment

The project’s significance in the late 1990s lies in applying a proprietary component platform to a specific financial workflow. Its notable features include coordinated applications, notifications of shared-data changes and controlled transitions between document states. Databases of that period already supported concurrent access; the engineering task in IMS was to express the enterprise’s rules and make them understandable to users.

From company records

Materials

• Miracle — the platform behind IMS ↗