Magento Sage: Synchronize Orders, Stock and Documents Between Shop and Sage

Sage offers several product lines in Germany. Sage 50 is the solution for order processing, merchandise management and accounting of small and mid-sized businesses, and for larger companies there are further solutions. For Magento Sage the decisive question is which product and which version you use, because the interfaces and the possibilities of the integration depend on it.

According to its own statements Sage offers connections to online shops for Sage 50: an own web shop builder with an integrated interface and a connector for several shops and marketplaces that synchronizes products, stock, prices and documents and keeps the stock in both directions. These statements come from the product pages of the vendor. Whether they fit your Magento Sage setup we check in the individual case.

For further Sage products, for example in the upper mid-market, this applies: we check the interfaces per product and version before we suggest a way. Magento Sage therefore always begins with three questions: which product do you use, in which version, and who in your business works with the data?

The division of labor is also important: with many Sage users order processing lies in Sage, and the shop is to fit in there instead of bringing its own rules. We set up the integration as your employees work instead of adapting your processes to the interface.

Which data flows in Magento Sage you define with us in the inventory. Typically there are five areas.

Not every Magento Sage project needs all five areas. Often it begins with orders and stock and later grows by articles, prices and documents. This way you see results quickly and can use the budget in stages.

The table shows a typical pattern. In your business it may differ, and that is exactly what we clarify in the inventory.

With Magento Sage a clear rule on data ownership prevents most disputes. Whatever can be changed in both systems leads to contradictions sooner or later. That is why we define exactly one leading system per type of data and describe the rule for the conflict case. Especially with units, tax rates and document numbers an assignment table that the department and the developers review together is worthwhile.

Which interfaces are available at Sage depends strongly on the product. With Sage 50 the vendor names an integrated interface to its own web shop and a connector that synchronizes several shops and marketplaces with Sage 50. For a Magento shop that means: we check whether the vendor connector supports Magento or whether an own integration is needed.

For Sage products for which we have found no public interface information we do not work on assumptions. Before the quote we clarify with you and, if necessary, with the vendor or your Sage partner which access exists, for example programming interfaces, import functions or file exchange. That is an honest part of our approach: we tell you openly if a version sets limits.

We avoid direct access to the database of Sage wherever possible. It bypasses the rules of the software and can break on updates. If an official interface is not enough, we first look for another official way before we build a makeshift.

For the connection of Sage and Magento a connector of the vendor, an add-on product of a third-party vendor or an own development can come into question. Whether an existing product fits your process we check honestly before a decision. If it covers your requirements, it is often the more economical choice, and we will tell you so. With every product ask how it is maintained and what happens on updates.

An individual development for Magento Sage pays off if your processes deviate from the standard: special price rules, several warehouses, special articles or processes that a ready-made product does not know. It is more expensive at the start but fits exactly. Include the care as well, because an individual development needs someone who looks after it.

A middleware pays off if more than two systems are connected, for example shop, Sage, marketplaces and shipping providers. The decision aid is in the guide to ERP integration. On shipping read the page on the integration of shipping carriers. This applies to every Magento Sage project with several channels.

On the Magento side we build the integration as its own module according to the standards of the system, without interventions in the core. The module uses the interfaces and queues of Magento so that transfers run in the background and the shop does not become slower for visitors. Orders are placed in a queue on arrival and processed there until the ERP has confirmed them.

Prices by customer group, tier prices and several warehouses are mapped by Magento with its own functions that the integration fills. Where possible we use these standard functions instead of inventing our own tables. That keeps the shop update-capable and lets other developers join in later.

In the admin you see what was transferred: a log shows date, record and result, with a filter for errors. For the peculiarities of Sage we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With Sage order processing is often part of the same software. Magento Sage therefore has to define whether the shop only hands over orders or also receives articles, prices and stock from Sage, and who assigns the document numbers.

We see these points again and again in projects. They can be planned if they are known early.

• Product line and version

  A product is assumed whose interfaces are missing in the version in use.

• Two document numbers

  Shop and Sage both assign numbers, and nobody knows which one applies.

• Unclear data ownership

  Prices or texts are changed in both systems and overwrite each other.

• Several sales channels

  The stock is sold for marketplaces and shop at the same time.

• Updates of Sage

  After a version change the integration no longer works because it was not tested.

• Missing monitoring

  A failed transfer is noticed only after days.

An integration connects two systems with business data, so clear rules apply. The exchange runs encrypted, credentials do not lie in the source code but in the protected configuration, and the integration receives only the rights it needs. Access belongs to a separate service account, never to a private account of a person.

When testing we work with test data or anonymized data as far as possible. As soon as developers get access to personal data, for example customer accounts or orders from Sage, an agreement on commissioned data processing is needed. We clarify that before the start so that you are legally well set up.

The log of the integration contains what is necessary for operation but no credentials and no unnecessary personal data. Retention periods are defined with you. These notes are not legal advice, the concrete arrangement depends on your company.

We keep the start deliberately short so that you quickly know whether and how the integration is feasible.

The following constellations are examples from the practice of Magento Sage projects, not statements about particular customers. The first is a merchant who uses Sage 50 for orders and accounting and builds a Magento shop anew. Sage remains the center, the shop becomes a sales channel. At the center are the stock and a clean assignment of the article numbers.

The second constellation is a business that has already connected a simpler shop with Sage and switches to Magento. Here the existing connection is the benchmark: what it achieves today the new shop should at least achieve. Part of the work is the inventory of the old connection. How the switch itself runs is described on our page on migration.

The third constellation is a manufacturer with company customers and own prices. The shop is to show the right prices after login, and orders are to arrive in Sage without retyping. Here customer prices and payment terms are at the center of the Magento Sage project.

In all three cases a small trial pays off: before the integration runs productively, a few typical orders are transferred, including one with a discount, one with several items and one with a foreign delivery. Your employees check the result in Sage, and only then does operation start. This way assignment errors show up early and cost little.

An interface is not a one-off project but ongoing operation. After the start a log monitors every transfer: what was transferred when, what failed, what is repeated? Errors that cannot be fixed automatically are reported visibly so that nobody learns of them only through a customer complaint.

Updates change the situation. A Magento update, a new state at Sage or a change of the vendor interface can affect the integration. Therefore the planning includes an agreement on how updates are tested and who approves them. Ongoing care can be regulated through a maintenance contract that covers monitoring, updates and error fixing.

Documentation is part of the delivery. You receive a description of the data flows, the assignments and the rules for special cases so that your team or another provider understands the integration and can continue it. Source code and access stay with you.

A flat figure for Magento Sage would be unreliable because the effort depends on your constellation. It is determined by the number of data flows, the quality of the data in Sage, the number of special cases with prices, warehouses and customers and the required timeliness. A data flow in one direction is built much faster than a synchronization in both directions with conflict rules.

We work with an open hourly rate of 30 euros net, without emergency surcharge. After the inventory you receive a written estimate that lists the data flows individually so that you can control scope and order yourself. For clearly defined packages a fixed price is also possible. All prices are on the page pricing.

Besides the development, include the running items: hosting, maintenance and, where applicable, licenses or fees for Sage and for additional services. We show these items separately in the estimate so that you can compare quotes over several years.

An honest offer includes naming the limits. We do not sell a ready-made connector off the shelf but develop Magento Sage project by project according to your processes. That means: we implement exactly what you need, but not in a day and not for a flat price that cannot be calculated beforehand.

We are a web agency in which fixed freelancers work together, all from home offices. We are not a large agency with a hundred employees and cannot take on every project at every time. We tell you early whether and when we have capacity. We name customers only with their consent, and in the first conversation we gladly talk about comparable constellations.

We give no legal advice. Questions about commissioned data processing, data protection and the license terms of Sage you clarify with your legal adviser and the vendor. What is technically possible depends on version, operation and license of your system and is checked in the inventory.