Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Sales taken in Odoo POS reach Comarch Optima as accounting-ready records and product and price data returns, so the shop floor and the accounts stop being reconciled by hand at the end of every day.
A retail day ends twice: once when the shop closes and once when somebody types the takings into the accounting system. Odoo POS records every transaction, payment type and refund, and Comarch Optima needs those figures as postable entries with the right coding. Between them sits a daily manual routine, which is where discrepancies appear and where a busy week becomes a month of unreconciled sessions. Connecting Comarch Optima and Odoo POS through Alumio replaces the routine: session totals arrive as structured records, product data flows the other way.
DATA THAT FLOWS BETWEEN THEM
POS sessions
Sales transactions
Payment types
Refunds
Product records
Price updates
Stock movements
Session totals reach Comarch Optima as structured records, so the shop's day ends when the till is cashed up rather than when somebody retypes the figures the next morning.
Card, cash and voucher takings arrive distinguished rather than merged, so bank reconciliation matches what was actually settled instead of one combined daily figure.
Product and price updates flow to Odoo POS, so the price at the counter matches the one the business intended without staff editing products locally on the terminal.
Because entries arrive continuously, a busy trading period no longer leaves weeks of unreconciled sessions waiting for somebody to find a quiet afternoon to clear them.
When an Odoo POS session is closed, Alumio delivers its totals by payment type to Comarch Optima as structured records, so the accounts reflect the trading day without anyone transcribing a till report into finance by hand.
A refund processed at the till is passed through as its own record rather than netted off the day's takings, so the accounts show what was sold and what was returned instead of one figure that quietly hides both.
A price update maintained centrally is delivered to Odoo POS, so the terminal charges the intended amount from the moment the change takes effect and staff are not applying overrides to correct a stale price at the counter.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
.svg){kind=icon}
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
More can be connected, and retailers on this pairing usually add their e-commerce platform next, because the same products and stock have to serve the shop and the webshop without either overselling. Alumio keeps one flow of product and price data outward and collects sales from both directions, so a second channel does not create a second reconciliation routine.
Yes. Session and transaction data is collected as sessions close and delivered to Comarch Optima in the structure and file format your accounting process expects, with CSV and XML both on Alumio's published format list. Payment types stay separated, which is what makes the resulting entries reconcilable against the bank rather than merely accurate in total.
Alumio connects to each system through its available interface and the mapping is configured, which replaces the daily manual entry this pairing depends on. Accounting setups differ by country and by business, so the coding rules stay yours to define, and custom logic can be added through the Code Transformer where a required output format needs shaping before it is delivered.
Nobody should have to, beyond reviewing exceptions. Once session totals arrive as structured records split by payment type, the accounting side receives figures that already agree with the till rather than a summary to be checked against a printout. Alumio surfaces anything that failed to post as an exception, so the daily task becomes reviewing a short list instead of re-adding a day of trade.
A trading day is never posted twice and never skipped. Alumio logs each session record with its content, monitors both connections live, and alerts the finance team immediately when one is rejected, showing the session and the reason returned. Retries run automatically where configured, and an unposted session stays flagged in the queue rather than being silently missed at month end.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.
.svg)
