Web-to-Print and MIS/ERP: Which Data Flows Where

A web-to-print store takes the order; an MIS prints it; an ERP bills it. Between the three, the same order is often typed in twice or three times, and every copy is a chance for a wrong quantity or a lost file. This article shows which data belongs to which system and how it moves, as part of the print API integration guide, which explains when an app is enough and when to integrate.

Which system owns which data?

Each system should own the data it creates. The web-to-print store owns the order, the product options, the customer's design and the print-ready file. The MIS owns the job ticket, the production schedule and job costing. The ERP owns the invoice, the payment, the customer account and stock. A field with two owners ends up with two values, and nobody knows which one is right.

A print MIS, or management information system, runs the production side of a print business: estimates, job tickets, scheduling, materials and job costs. An ERP, enterprise resource planning software, runs the business as a whole: finance, invoicing, purchasing and inventory. Small print shops often have one tool doing both; larger ones keep them apart.

Embed this graphic

Copy this HTML to show the graphic on your site with a link to the source.

<a href="https://solution.printcart.com/insight/web-to-print-and-mis-erp-data-flows"><img src="https://solution.printcart.com/insight/web-to-print-and-mis-erp-data-flows/field-ownership-matrix.webp" alt="Matrix of six data items against store, MIS and ERP, showing which system owns each one" width="1440" height="1080"></a><br>Source: <a href="https://solution.printcart.com/insight/web-to-print-and-mis-erp-data-flows">Printcart</a>

How does an order move from the store to the MIS and the ERP?

An order moves from the store to the MIS and the ERP through events. When the order is created or changed, the store sends a webhook; an integration receives it, verifies it, maps the fields and creates the job in the MIS and the order or invoice in the ERP. Production status then flows back to the store, so the customer sees it.

Embed this graphic

Copy this HTML to show the graphic on your site with a link to the source.

<a href="https://solution.printcart.com/insight/web-to-print-and-mis-erp-data-flows"><img src="https://solution.printcart.com/insight/web-to-print-and-mis-erp-data-flows/order-to-erp-flow.webp" alt="Six steps: order in the store, Printcart webhook, integration verifies and maps, MIS job, status back, ERP invoice" width="1440" height="1080"></a><br>Source: <a href="https://solution.printcart.com/insight/web-to-print-and-mis-erp-data-flows">Printcart</a>

Printcart webhooks follow fixed rules, all from the Printcart developer documentation:

1. One subscription covers one topic and one event. Topics are products, sides, designs, templates, projects (orders) and user; events are POST, PUT and DELETE and their batch versions.
2. The body is the resource as the API returned it, wrapped in a data object; batch events carry a list.
3. Every delivery has a Signature header: an HMAC-SHA256 of the raw body, keyed with the store's sid and secret, which the receiver must check before trusting the request.
4. A failed delivery is retried up to three times with exponential backoff, and each attempt times out after three seconds, so the receiver should answer fast and do the work afterwards.

Because there is no delivery log and no replay endpoint, an integration should not rely on webhooks alone. A scheduled job that lists recent orders through the Printcart API and compares them with the MIS catches anything a missed delivery left behind.

What changes when the MIS expects job tickets in a standard format?

When the MIS expects job tickets in a standard format, the integration has to build them from the order. JDF, the Job Definition Format maintained by the CIP4 organisation, is an XML format for describing print jobs between systems. An MIS that reads JDF or its own import format needs the order's options, quantities and file link translated into that format, field by field.

That translation is where most of the scoping time goes. Product options in a store are written for buyers ("Matte, 350 gsm, 500 cards"); an MIS needs its own stock codes, press and finishing steps. A mapping table, kept with the integration and updated when products change, avoids silent errors. The more products share the same options, the smaller that table gets.

How do you scope a store to MIS or ERP connection?

You scope a store to MIS or ERP connection by writing down, before any code, what each system owns, which events start a sync, how each field maps, which way it flows and how missed events are repaired. The six steps below turn those decisions into a written scope that a developer, the Printcart team or your own, can build and test.

Where does Printcart fit in this flow?

Printcart fits as the order and file source. It syncs orders and products natively with WooCommerce, Shopify and Wix, generates a print-ready file for every order, and exposes orders, designs and status changes through its REST API and webhooks. Connections to an MIS, ERP or accounting system have no packaged connector: they are built for each customer on that API.

In a Printcart full store, webhooks come with every package (3 on Store, 20 on Store B2B and Store Marketplace, no limit on Enterprise), API keys with an origin allowlist start at Store B2B, and the ERP or MIS connection with per-customer B2B portals is part of Enterprise. The B2B print store, in build, is the store edition for business clients who order on account.

When the connection is built by the Printcart team, it is a quoted project. MIS and production workflow integration delivers jobs and print-ready files to your MIS with status back to the store; ERP and accounting integration syncs orders and customers with your finance system; both start with discovery of your systems. The integration services page lists the rest. Status that reaches the store also helps the team that answers customers, as customer service for print orders explains, and proof decisions are covered in the proof approval workflow.