INTERA connects information from existing business systems and presents it in a role-specific operational view.
It does not replace accounting, billing, CRM, ERP, ticketing, navigation, or other specialist systems. Instead, INTERA brings selected information from these systems together, applies operational rules, and shows each user what requires attention.
This chapter explains the main concepts used throughout INTERA.
Roles #
A Role represents a business responsibility within an organisation.
Examples include:
- Finance Manager
- Billing Operations Manager
- Fleet Manager
- Technical Superintendent
- Customer Support Manager
- Revenue Assurance Manager
A Role determines what information a user needs to see and what operational conditions are relevant to them.
Roles may define:
- dashboards and dashboard pages;
- assets and metrics visible to the user;
- reconciliation rules;
- triggers and notifications;
- scripts and recommended actions;
- access permissions.
A Role is not necessarily the same as a job title. Several employees may use the same Role, and one employee may be assigned more than one Role.
For example, a Finance Manager Role may include bank balances, overdue customer payments, supplier liabilities, cash-flow indicators, and reconciliation results from accounting and billing systems.
Integrations #
An Integration connects INTERA to an external system or data source.
Examples include:
- accounting systems;
- billing platforms;
- CRM systems;
- ERP systems;
- ticketing platforms;
- navigation and vessel-tracking systems;
- banking APIs;
- spreadsheets and data files;
- external data services.
An Integration defines how INTERA connects to the external system, authenticates, requests data, and interprets the returned information.
One Integration may provide several separate datasets. For example, an accounting integration may provide datasets for invoices, payments, suppliers, customers, and account balances.
INTERA normally reads information without changing the external system. Where supported and permitted, an Integration may also provide controlled write-back operations.
Assets and Asset Types #
An Asset is a business object that INTERA monitors, describes, or uses as a context for metrics.
Examples include:
- a customer;
- a vessel;
- a product;
- a supplier;
- a bank account;
- a vehicle;
- a service;
- a department;
- a network node.
An Asset does not need to be a physical object. It may represent any identifiable business entity that is useful for reporting or operational control.
An Asset Type defines the structure shared by a category of Assets.
For example, the Asset Type Vessel may define fields such as:
- vessel name;
- IMO number;
- fleet;
- vessel manager;
- operational status.
Individual Assets based on this type may then represent specific vessels.
Asset Types provide a consistent structure, while individual Assets contain the actual business data.
An Asset may receive information from one or several Integrations. INTERA maintains the connection between the local Asset and the corresponding records in external systems.
Metrics #
A Metric is a measurable value, state, or observation used to describe an Asset, a group of Assets, or an operational process.
Examples include:
- current bank balance;
- overdue invoice amount;
- active subscriber count;
- average ticket resolution time;
- vessel position;
- service availability;
- payment status;
- last synchronization time.
Metrics are the basic informational units displayed in dashboards and used by triggers, scripts, and reconciliation rules.
A Metric may contain more than its current value. Depending on its configuration, it may also include:
- timestamp of the latest update;
- data source;
- historical values;
- trend;
- threshold status;
- synchronization status;
- error information;
- unit or currency;
- display name defined by the Role package.
The same Metric may be presented differently in different Roles. For example, a technical dashboard may display a detailed service-availability value, while an executive dashboard may show the same information as a simplified operational status.
Types of Metrics #
Every Metric has a Metric Type that determines what kind of value it stores and how that value may be displayed or processed.
Common Metric Types include:
Number #
A numeric value without a currency.
Examples:
- number of open tickets;
- number of active customers;
- average response time;
- stock quantity.
Currency #
A monetary value associated with a currency.
Examples:
- bank balance;
- unpaid invoice amount;
- monthly revenue;
- supplier liability.
Percentage #
A value expressed as a proportion or percentage.
Examples:
- service availability;
- collection rate;
- completion percentage;
- dashboard health score.
Boolean #
A value with two possible states, such as true or false.
Examples:
- invoice approved;
- backup completed;
- service enabled.
Status #
A value selected from a predefined set of states.
Examples:
- paid, unpaid, overdue;
- active, suspended, cancelled;
- ready, not ready, in progress.
Date and Time #
A calendar date, time, or timestamp.
Examples:
- invoice due date;
- last successful synchronization;
- delivery date;
- contract expiry time.
Duration #
A measured period of time.
Examples:
- ticket resolution time;
- vessel waiting time;
- processing delay.
Text #
A descriptive or categorical value.
Examples:
- current location name;
- assigned manager;
- error description;
- supplier category.
Coordinates #
A geographical position.
Examples:
- vessel latitude and longitude;
- vehicle location;
- service-site position.
Composite Metric #
A value composed of several related values or attributes.
Examples:
- current, 30-day overdue, and 60-day overdue balances;
- minimum, average, and maximum response time;
- actual value, target value, and variance.
Metric Types help INTERA select suitable widgets, validation rules, formatting, calculations, and comparison methods.
Scripts #
A Script is a predefined sequence of actions or processing steps.
Scripts may be used to:
- calculate a derived Metric;
- transform data received from an Integration;
- prepare a notification;
- create an operational event;
- request additional information;
- execute a controlled action in an external system;
- guide a user through a standard response procedure.
Some Scripts run automatically, while others are started manually by a user.
For example, a Script may collect information from billing and accounting systems, calculate the difference, and prepare a notification when the difference exceeds an allowed limit.
Scripts are designed to make operational responses consistent and repeatable.
Triggers #
A Trigger defines when INTERA should evaluate or start an action.
A Trigger may respond to:
- a Metric crossing a threshold;
- a Metric changing value;
- an Asset changing status;
- new data arriving from an Integration;
- a synchronization error;
- a scheduled time;
- a reconciliation failure;
- a user action.
Examples include:
- trigger when overdue debt exceeds €50,000;
- trigger when a vessel has not reported its position for six hours;
- trigger when a bank balance falls below the required reserve;
- trigger every weekday at 09:00;
- trigger when billing and accounting totals no longer match.
A Trigger does not necessarily create a visible alert. It may start a Script, update another Metric, record an event, or send a notification.
Dashboards #
A Dashboard is the main visual workspace for a Role.
It brings together the assets, metrics, warnings, trends, reconciliation results, and actions relevant to a particular responsibility.
A dashboard may contain several pages. For example, a Finance dashboard may include separate pages for:
- cash position;
- collections;
- supplier payments;
- reconciliations;
- exceptions and overdue items.
Dashboards are composed of widgets. A widget may show a metric, a chart, an asset list, a status, a reconciliation result, or an action.
Dashboards do not normally display all available data. Their purpose is to highlight the information that matters to the Role.
Reconciliation Rules #
A Reconciliation Rule compares information from two or more sources to determine whether the values are consistent.
Reconciliation is commonly used when the same business fact appears in several systems.
Examples include:
- invoices in billing compared with invoices in accounting;
- active services in billing compared with active services in the network;
- customer payments compared with bank transactions;
- vessel data compared between a ship-management system and a tracking provider;
- stock quantities compared between warehouse and accounting systems.
A Reconciliation Rule defines:
- the sources being compared;
- the Assets or records included;
- the relevant time period;
- filters and matching conditions;
- acceptable differences or tolerances;
- the result to produce when values do not match.
Reconciliation results may be expressed as:
- matched;
- partially matched;
- mismatch detected;
- data unavailable;
- reconciliation could not be completed.
Reconciliation Rules are intended to highlight meaningful exceptions rather than reproduce large lists of raw data.
For example, instead of showing thousands of successfully matched invoices, a dashboard may show:
- reconciliation status: 98.7%;
- 14 unmatched invoices;
- total unmatched value: €23,400;
- oldest unresolved mismatch: 11 days.
