Product sheet

HANDSAL

EDI server for B2B

Demo at our end

The situation this answers

The messages go straight to the counterparty, with no hub in between. You see what arrived, not what never did, and a message type that fails disappears in silence. Each new counterparty means another protocol to run.

Fits best when

You exchange business messages directly with counterparties, not only through a central hub.
Every new counterparty has meant a new setup, with its own format and its own transport.
Nobody notices a missing message until someone on the other side asks for it.
The exchange runs on something built in-house that nobody monitors.
The traffic must not pass through an external message broker, whoever operates the server.

What you get

One infrastructure layer for multiple protocols
Faster access to new markets
An alert when a message fails to arrive, not just a receipt for what did
Messages that fail stop in quarantine, not in silence
Prices and invoices fetched on schedule, not by hand

HANDSAL stands on its own and requires no other modules.

What we do not cover: HANDSAL carries the messages but does not create them: no settlement, no invoicing, no master data.

HANDSAL · Product sheet

How it works

HANDSAL is Tvimenning's EDIFACT server for bilateral message exchange. In markets without a central hub, market messages still travel from party to party, in EDIFACT. That is not a transitional arrangement, it is how the market works, and anyone operating there has to handle it from day one. In Sweden the format is called Ediel. That makes HANDSAL the transport layer beneath SEFTA. SEFTA is our metering data handling, built for more than one market - but in an EDIFACT market the messages have to be carried by something, and that is the job HANDSAL does. The dependency runs one way: without a transport layer, the multi-country part of SEFTA does not work outside Norway. SEFTA has been run against synthetic, realistic data - not put into operation. For anyone who wants to influence the direction, now is when that is possible.

The functions in detail

We tell you when something did not arrive: Most EDI tools tell you what arrived. The expectation module lets you define when a message is due, and raises an alert when it fails to appear - across three levels, from a notice on the dashboard to escalation to the on-call group. The same idea appears in SEFTA's rule engine, as heartbeat. That is a design principle here, not a coincidence.
Nine message types in bilateral exchange: MSCONS, UTILTS, UTILMD, INVOIC, PRODAT, DELFOR, REQDOC, CONTRL and APERAK. The acknowledgements are included because they are half the work.
Quarantine instead of silence: Messages from unknown senders, or with syntax errors, are placed in quarantine with an interface where an operator can approve, reject or inspect the raw data. Together with the partner register and the address register, this is built by people who have operated EDI, not merely integrated it.
Complements SAMTYGD - no overlap: SAMTYGD handles regulated market messages toward central hubs such as Elhub. HANDSAL handles bilateral EDIFACT directly between market parties. Together they cover the whole communication picture.
The part that is not EDI, but always comes along: The scheduler fetches prices, invoices and files from external sources on a fixed schedule, over HTTP, FTP, SFTP or email. It is rarely what sells a system, and often what decides whether anyone actually escapes manual work.

The status, explained

Demo at our end: We can show it here. Not yet verified against market interfaces, so your input carries weight now.
Ready for the platform: Verified against simulated market interfaces, not in operation.
In production: In production with a customer today.

Works together with

SEFTA: Validation, estimation, and editing with versioned time series, traceability, and export-ready data.; Ready for the platform
SAMTYGD: A shared integration layer to the modules, the surrounding systems and market hubs such as Elhub.; In production
STUBB: Mock services that simulate external systems with realistic behaviour and real data formats.; Ready for the platform

Terms used here tvimenning.no/en/ordbok

EDI: Electronic Data Interchange - standardised electronic exchange of business documents between systems.
EDIFACT: Electronic Data Interchange For Administration, Commerce and Transport - UN standard for electronic data exchange.
Ediel: Nordic profile of the EDI EDIFACT standard - used for electronic message exchange in the Nordic power market via Elhub.
MSCONS: EDIFACT message format for exchange of metering data in the electricity market - used in Elhub to transmit hourly, daily and monthly values between market participants.
Message Type: Specific type of Ediel message with a defined format and business process in Elhub.