Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Item codes and currency price lists maintained in Sage reach Pimcore directly, so the specification a dealer reads and the price they are quoted both come from the same place as each other.
Sage holds the item codes, tax treatment and currency price lists that a sale depends on, while Pimcore holds the specifications, assets and translations a buyer actually reads. Kept apart, a dealer portal shows a datasheet from one system and a price somebody pasted in from the other, and the two drift by market. Sales then quote defensively and the catalog gets a reputation nobody trusts. The Sage to Pimcore integration makes the commercial data part of the product itself, so a dealer sees the specification and the price for their own currency together and nobody maintains a parallel price sheet.
DATA THAT FLOWS BETWEEN THEM
Item codes
Price lists
Currency prices
Units of measure
Tax codes
Stock availability
Dealers read the Pimcore specification and the Sage price for their market in one place, so a quote no longer depends on somebody reconciling two systems by hand.
The spreadsheet that carries dealer pricing per country is retired, because Sage price lists reach Pimcore per currency and the catalog becomes the place those figures are read.
Currency-specific prices from Sage each get their own place in Pimcore, so a market without its own price is visibly missing one rather than showing a figure from elsewhere.
Because Pimcore products carry the Sage item code, what a dealer selects in the catalog is the thing the invoice will name, and order queries stop starting with a translation step.
A price list is revised in Sage. Alumio updates the matching currency price on each Pimcore product, so dealers in that market open the catalog and read the new figure without waiting for a circulated spreadsheet.
A new item code created in Sage arrives in Pimcore ready for content, so product managers add specifications and assets to something that already carries its commercial data rather than creating a duplicate of it.
A market is opened and its Sage price list reaches Pimcore as its own currency price, so the catalog serves local figures from the very first day of trading and nobody ends up quoting the base currency by accident.
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.
A dealer portal is the usual third, because the Pimcore catalog and the Sage pricing agree by then and the people who need them are outside the business. Alumio holds those connections centrally, so the portal reads the same product rather than receiving an export, and a dealer sees the specification, the price for their currency and current availability in one place.
Yes, and currency is the dimension that has to be modelled deliberately. Alumio reads Sage over the interface it exposes, the same as any other system it can reach, and a price list there is held per currency and per customer group, so each is mapped to its own place in Pimcore rather than collapsed into one price. A market's figure then updates on its own, and the catalog shows which markets are genuinely priced.
No, this is configured rather than coded. Price list selection, currency handling and item code matching into Pimcore are set up once in Alumio, replacing the export and paste routine that dealer pricing usually runs on. Sage price lists are structured differently from one business to the next, so where a discount rule falls outside what configuration can describe, the Code Transformer carries that calculation instead.
They see the parent's value unless it is modelled to prevent that, which is the trap worth knowing about. Pimcore objects inherit values from the one above them, so an empty currency price does not render as blank, it quietly resolves to whatever sits above it. Giving each Sage currency its own place, and treating absence as absence, keeps a base-currency figure from being read as a local price.
One currency updates in Sage and another does not, which is the failure that reaches a dealer, because the entry still looks complete and the base price is perfectly correct. Alumio monitors each update live and records what it wrote, so a price Pimcore refuses raises an immediate alert naming the item and the currency involved. Retries run automatically where configured, and the affected price stays flagged, so no market is quietly left reading last quarter's figure.
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)
