Magento plentymarkets: Synchronize Orders, Stock and Articles Between Shop and plentyONE

plentymarkets is the long-used name of a retail software that manages article master, warehouses, customer master, orders and shipping in a cloud solution. The vendor now appears under the name plentyONE. In daily speech many still say plentymarkets, and this name is also common when searching for an integration. For the technical integration the renaming makes no difference.

For Magento plentymarkets that means: the Magento shop becomes one sales channel among others. Articles, prices and stock come from plentymarkets into the shop, orders and customers go from the shop into plentymarkets, and shipping and invoice status come back. The advantage is that your employees keep working in the familiar environment and do not enter orders anew.

Businesses that use plentymarkets often sell through several channels at the same time. That makes the common stock the central question of every integration. Magento plentymarkets therefore begins with clarifying which channels exist, how the stock is distributed and which processes in plentymarkets are automated and must not be disturbed.

Whoever uses plentymarkets knows strength and limit at the same time: it bundles many tasks in one system, and precisely for that reason an additional sales channel should fit into its processes instead of bringing its own rules. In plentymarkets orders pass through statuses that your employees know. The integration maps these statuses and does not invent its own so that nobody has to rethink.

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

Not every Magento plentymarkets project needs all five areas. Often it begins with orders and stock and later grows by article maintenance and invoices. 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 plentymarkets 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 variants, units and tax rates an assignment table that the department and the developers review together is worthwhile.

For Magento plentymarkets the vendor provides a REST interface through which applications read and write data such as orders, articles, customers and warehouses. The technical documentation for developers describes it. An application logs in and receives a time-limited authorization that has to be renewed regularly. The integration takes this into account so that transfers do not fail because of an expired login.

Which functions are available in your client and which permissions the integration needs depends on your configuration. We work with a separate access that has only the rights the integration needs, and before the quote we check which queries and volume limits apply to your volume.

Besides the programming interface plentymarkets offers options for import and export of data as a table. For one-time transfers, for example at the start, that can make sense. For the ongoing synchronization we prefer the interface because it allows status feedback and error handling.

For the connection of plentymarkets with shop systems there are add-on products and service providers. Whether one of them fits your process we check honestly before a decision. If an existing product covers your requirements, it is often the more economical choice, and we will tell you so. With every ready-made product pay attention to how it is maintained, what happens on updates and how far it can be adapted.

An individual development for Magento plentymarkets pays off if your processes deviate from the standard: special price rules, several warehouses, bundles, own attributes 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, plentymarkets, a product information system and shipping providers. The decision aid is in the guide to ERP integration.

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 plentymarkets we add settings in the admin, for example assignments of payment methods, shipping methods and tax classes, so that changes need no development.

With plentymarkets variants are the central building block, so we assign them in Magento in such a way that stock and price per variant are correct. For this Magento plentymarkets gets an assignment table in the admin that you can maintain yourself when attributes or warehouses change.

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

• Variants

  The structure of the variants in plentymarkets does not fit Magento one to one and needs a clean assignment.

• Common stock

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

• Expiring login

  The authorization for the interface expires and the transfer stops silently.

• Unclear data ownership

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

• Missing monitoring

  A failed transfer is noticed only after days because nobody looks at the log.

• Special cases

  Partial deliveries, returns, credit notes and foreign orders are missing in the concept.

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 plentymarkets, 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 plentymarkets projects, not statements about particular customers. The first is a merchant who has so far sold through marketplaces and a simple shop and now builds a more powerful Magento shop. plentymarkets remains the center. At the center are the common stock and a clean assignment of the article numbers so that nothing is sold twice or not at all.

The second constellation is a merchant with a large range and many variants. The challenge lies in the volume: the first synchronization must run in steps, and the ongoing update must not overload the interface. We define early what is transferred completely and what only on change.

The third constellation is a business with B2B customers who have their own prices and payment terms. The shop is to show the right prices after login, and orders are to arrive in plentymarkets without retyping. What such requirements look like in the shop is described in the guide to the B2B shop.

Common to the three constellations is that most of the effort lies not in the transfer itself but in clarifying the rules: who leads, what happens in a conflict, how do we deal with special cases? This clarification is the part that saves the most trouble later.

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 plentymarkets 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 plentymarkets 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 plentymarkets, 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 plentymarkets 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 plentymarkets 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 plentymarkets 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.