Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Comarch Optima issues the invoice number and the WooCommerce order records the one it was given, so a sequence in the books stays whole instead of developing gaps nobody can account for later.
Invoice numbers in Comarch Optima run as a sequence within a series, and a sequence with a hole in it is a question somebody has to answer at the end of the year. A WooCommerce shop generating its own numbers, or a manual entry made twice, produces exactly that: two documents with one number, or a number issued and then abandoned. It is discovered late and reconstructed slowly. Connecting WooCommerce and Comarch Optima settles where the number comes from, so the accounting system issues the number, the shop records what it was given, and the sequence never depends on two systems agreeing.
DATA THAT FLOWS BETWEEN THEM
Web orders
Sales invoices
Invoice numbers
VAT rates
Customer records
Payment records
Comarch Optima issues the invoice number and Alumio records it against the WooCommerce order, so the shop never generates a number of its own for the books to accommodate.
Because a document is created once and its number returned, a retry cannot produce two invoices carrying the same number or leave a number issued against nothing.
Rates and customer detail travel with the order, so the invoice Comarch Optima produces is one the accountant accepts rather than one they correct line by line.
Alumio connects to Comarch Optima through its available API, as it would any reachable system, so orders post without an export anybody prepares by hand each morning.
When a WooCommerce order is placed, Alumio creates the sales invoice in Comarch Optima and writes the number it issued back onto the order, so the customer and the books are referring to one and the same document.
An order that fails on the way in is retried without a second invoice being created, because the number is issued by Comarch Optima once and recorded against the WooCommerce order rather than generated ahead of time.
Payments recorded against the WooCommerce order reach Comarch Optima matched to the invoice they settle, so the receivables position is current without anybody reconciling a payment list against a document list.
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.
Which local obligation arrives with the order is the question that decides the next connection, and for a shop shipping on delivery terms it is the money the courier collects. A courier reconciliation feed is the common addition, because Comarch Optima needs the payment matched to its invoice and the courier holds the collection record. Alumio holds both connections, so a WooCommerce order, its invoice and the cash all line up.
The numbering is settled before anything posts, because it is the thing that cannot be corrected quietly later. Alumio creates the invoice in Comarch Optima, which issues the number, and writes that number back against the WooCommerce order. Nothing is pre-numbered on the shop side, so a retry cannot leave a gap or a duplicate in the series.
No, and the numbering is not a place for anybody's own logic. The series each document type uses, and which Comarch Optima document a WooCommerce order becomes, are settings in Alumio's interface, because a sequence has to be issued by the system that keeps the books. Where a business runs more than one series by channel, that routing is configuration too.
From Comarch Optima, and letting the shop invent one is the decision nobody makes deliberately. A number series runs in sequence, so a number generated in WooCommerce and then rejected by the accounting system leaves a hole, and one generated twice leaves a duplicate, and both are found in a year-end review rather than on the day. Having the accounting system issue it and the shop record it removes the question.
The invoice number out of sequence is the failure to prevent; the failure is spotted live; each attempt is recorded with the WooCommerce order it carried; an alert fires at once naming the order and the reason Comarch Optima refused it; retries run where configured and cannot create a second document; unresolved orders stay listed, so nothing is invoiced twice and no number goes missing.
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)
