Why CommerceML is deprecated and how to replace it

Three months ago, an acquaintance called me - the owner of a wholesale company selling industrial oils and lubricants. Catalog for sixteen thousand positions, WooCommerce, seven years of operation of the site, stable traffic, orders are coming. It would seem that everything is fine. But he didn’t call because his life was good. “Listen,” he says, “my catalog is broken again. The exchange with 1C froze halfway, half of the goods were gone, the pictures were gone, the prices were old. Managers manually check each item. We spend three days restoring what should have been updated in an hour. Maybe there is something instead of CommerceML, or is this normal and everyone lives like this?

I didn’t tell him that “everyone lives like this.” Because it's not true. This is how people live who are stuck in 2005, the year when the CommerceML format was created. Yes, you heard right: the technology that thousands of online stores use today to exchange data between 1C and the site was designed twenty-one years ago. In an era when the iPhone did not yet exist, Google had just gone public, and the word “cloud” meant an exclusively atmospheric phenomenon. And this format, born in a completely different technological era, still remains the de facto standard for integrating 1C with online stores in Russia and the CIS. I think it's time to have an honest conversation about why this happened, why it no longer works, and what to do about it.

I am not a theorist or evangelist for any particular technology. I lived with CommerceML for seven years in real production - with its glitches, breaks, duplicate products and sleepless nights when I urgently needed to fix the catalog before the morning mailing. And at some point I realized that it was pointless to treat the symptoms - you need to change the entire approach. This article is the story of how we came to this decision, what we went through, and what we got in the end. If you are also struggling with the exchange of 1C and the site, perhaps it will save you those same three days of nervous catalog restoration.

How we got to this point of life: seven years on CommerceML

To understand why CommerceML is a problem, you first need to understand how it works. The idea is simple: 1C generates XML files of a certain structure - product catalog, offers (prices and balances), images - and uploads them to the site through a special PHP script. The site, in turn, parses these XML files and updates the database. Sounds logical, right? In 2005 it was even elegant. XML was fashionable, the REST API had not yet become a standard, and online store catalogs rarely exceeded a couple thousand items.

The problem is that the world has changed, but CommerceML has not. The format remained almost the same as it was created. Yes, there were minor updates, yes, version 2.10 appeared, but architecturally it’s still the same approach: generate a giant XML, transfer it entirely to the site, parse it entirely and update the database. It's like emailing a colleague the entire file every time you want to update one row in a ten-thousand-row Excel spreadsheet. Sounds absurd? But that's exactly how CommerceML works.

When we started with this project, the catalog consisted of about four thousand items. CommerceML did the job. The exchange took about fifteen to twenty minutes, mistakes were rare, and it was livable. We used one of the most popular plugins for WooCommerce - woocommerce-synchronization-1c. He did his job honestly: he accepted XML from 1C, parsed it, created products, updated prices. Over seven years, it went through dozens of updates to WordPress, WooCommerce, PHP - and every time something broke, but on the whole it worked.

And then the catalog grew to sixteen thousand items. And all hell broke loose.

The first thing we encountered was the exchange time. Completely unloading a catalog no longer took twenty minutes, but two to three hours. Sometimes four. Moreover, CommerceML is designed in such a way that each exchange is, in fact, a complete unload. Yes, formally there is a “change exchange” mechanism, but in practice it works so unreliably that most 1C settings use full unloading. And just imagine: every night (and the exchange has to be set up at night, because during the day it creates a load on the server and slows down the site) 1C uploads sixteen thousand products into XML files with a total volume of about a gigabyte, then uploads them to the server, and the PHP script tries to process it all. PHP, which by default has a limit on script execution time of thirty seconds and memory limit of 256 megabytes. Of course, we increased the limits - both to 512 and to a gigabyte - but these are crutches, not a solution.

The second is duplicate products. This is perhaps the most painful problem with CommerceML, and for some reason few people talk about it openly. The mechanism is this: each product in 1C has a unique identifier (GUID). When uploading, this GUID is transmitted to the site, and the plugin uses it to search for an existing product to update. Sounds reliable? No matter how it is. As soon as a product in 1C changes in a certain way - for example, it was moved to another group, or the item type was changed, or some kind of internal reorganization of the directory occurred - and the GUID may change. Or, even worse, remain the same, but the plugin doesn’t find it due to meta fields being out of sync in WordPress. Result: a duplicate appears on the site. Product with the same name but different ID. And when you have sixteen thousand positions, it is almost impossible to catch such duplicates manually. We found situations where the same motor oil was present on the site in triplicate - with different prices, different stocks and different URLs. This is a disaster for SEO, confusion for users, and a headache for managers.

The third problem is images. CommerceML delivers product images along with XML files as binary attachments. In theory, this is convenient - everything is in one package. In practice, with a catalog of sixteen thousand positions, where each product has from one to five images, the volume of unloading becomes monstrous. But that's not even the main thing. The main thing is the image update mechanism. CommerceML does not have a reliable way to determine whether a product image has changed or not. Therefore, many implementations simply re-upload all images with each exchange. These are gigabytes of traffic, hours of script work and, most unpleasantly, periodic loss of images. We regularly discovered that pictures of some products disappeared after exchange. Sometimes due to a timeout, sometimes due to a parsing error, sometimes for no apparent reason. Managers spent hours manually uploading images that the exchange “lost.”

The fourth problem is custom fields. This is what finally convinced me that I needed to end CommerceML. Our company sells industrial oils and lubricants - a product with complex technical characteristics. Viscosity at different temperatures, pour point, flash point, ISO viscosity class, equipment manufacturer approvals, GOST or TU, type of base (mineral, synthetic, semi-synthetic), density, area of ​​application - each product has dozens of specific parameters. In 1C, all these parameters are stored as “additional details” - a flexible system that allows you to create arbitrary characteristics for any type of item. Now try to convey all this through CommerceML.

CommerceML has a rigid schema. There is a certain set of fields that it can transfer: title, description, article, group, images, price, balance, and several standard details. Custom fields? Formally - through the mechanism of “properties” and “property values”. But the implementation is so inflexible that in practice it is almost impossible to transmit complex structured data - such as several types of viscosity at different temperatures - without serious customization of processing on the 1C side. And customization of processing requires a 1C programmer, who costs from three thousand rubles per hour, and who needs to explain the structure of your site. And every time you add a new product parameter in 1C, this customization needs to be updated. A vicious circle.

I remember the moment when we tried to add a new attribute to the site - manufacturer approvals (that is, a list of brands of equipment for which this oil is suitable). In 1C this was stored as a tabular section listing tolerances. CommerceML simply doesn't know how to pass table parts. We spent two weeks negotiating with a 1C programmer who tried to “package” this data into standard CommerceML properties, creating a complex system of composite values, which then had to be parsed on the site side. The result worked, but was so fragile that it broke every second 1C update.

And fifth - breaks with large directories. This is a technical problem, but it has direct business implications. The PHP script that processes the XML from CommerceML works within a single HTTP request. Yes, many implementations break the processing into chunks and use step-by-step imports, but the basic mechanism remains the same: the script must read the XML, parse it, match it with existing products in the database, update or create new records - all within the constraints of PHP. With a catalog of sixteen thousand positions with dozens of attributes for each product, the script regularly crashed. Sometimes silently - it simply stopped working due to a timeout, leaving the directory in a half-updated state. Sometimes with memory error. Sometimes due to a database lock - because sixteen thousand INSERT/UPDATE queries in a row create a serious load on MySQL. And each such failure meant that some products were updated, but others were not. The prices of some products are current, while others are yesterday's. The remainder has been updated in some places, not in others. Managers do not know what data on the site can be trusted. Buyers place orders for goods that are no longer in stock. These are not technical inconveniences - these are losses of money and reputation.

When I stopped treating symptoms

Here's the thing: for a long time I tried to solve each problem separately. Duplicate products? Let's write a script for checking duplicates. Lost images? Let's add logging and reloading. Timeouts? Let's increase PHP limits and split the exchange into smaller portions. Custom fields? We will hire a 1C programmer to customize processing. Each time - another patch on the old blanket. And each patch added complexity, created new points of failure and required support. At one point, we had such a custom exchange system that no new developer could figure it out without a week of immersion. Of course, there was no documentation - because the system grew organically, from problem to problem, and no one planned for it to become so complex.

The turning point came when we lost a large order. A corporate client placed an order for a batch of hydraulic oil - two hundred liters, a decent amount. The site showed “in stock” because the exchange with 1C froze last night and the balances were not updated. But in reality, this oil was no longer in the warehouse - it was shipped to another client the day before. The manager called the client, apologized, and offered to wait for delivery - the client refused and went to a competitor. Not because we have a bad product or high prices - but because our data exchange system was unable to update the balance of one product in time. I then thought: how many of these cases do we not even notice? How many customers see “in stock”, add the item to their cart, and then the manager calls them back with an apology? And how many of them simply silently leave without leaving an order?

That's when I started looking seriously at alternatives. Not another plugin for CommerceML - there are many of them, but they are all limited by the capabilities of the format itself. And on a fundamentally different approach to the integration of 1C and the site. And here I first noticed OData.

For those who haven't come across it: OData is a standard protocol for creating and using REST APIs. It was developed by Microsoft and is widely used around the world to access data. The key word here is “standard”. This is not a proprietary format of one company, nor a makeshift solution for a specific task. It's an open protocol with a clear specification, support for pagination, filters, sorting, selecting specific fields - everything you'd expect from a modern API. And here’s what’s important: 1C supports OData out of the box. Starting from version 8.3, any 1C configuration can provide access to its data through the OData interface. Without additional processing, without third-party components - just enable OData publishing in the 1C web server settings, and you get a full-fledged REST API to all directories, documents, and registers of your database.

When I first tried to query an item catalog through OData, I was amazed. Instead of waiting for 1C to generate a gigabyte-sized XML file, I sent an HTTP request and a second later received JSON with the first hundred products. I sent the following request and received the next hundred. And each request returned exactly the data that I needed: not the entire catalog, but specific fields for specific products, filtered by specific criteria. I could ask “give me all the products in the Hydraulic Oils group that have changed in price in the last two hours” and get a response in a couple of seconds. Try this with CommerceML.

But let me not idealize. OData is not a magic “do well” button. This is a tool that requires a different approach to integration. And switching to it is not just replacing one plugin with another. This is a change in the architecture of data exchange between 1C and the site. Let's figure out what the fundamental difference is.

CommerceML works on the principle of "batch upload". 1C generates a data package (XML files), uploads it to the site, and the site processes it. This is a batch, one-way, offline operation. 1C does not know what is happening on the site. The site does not know what happens in 1C between exchanges. Data is synchronized with a delay - from an hour to a day, depending on the schedule. OData works differently. This is an API - a programming interface for direct access to data. The site can access 1C at any time and receive up-to-date information: the current price of the product, the current balance in the warehouse, a list of characteristics, images. No need to wait for uploading, no need to parse XML, no need to store intermediate files. Data is available in real time.

And here the first question that everyone asks me arises: “What about the load on 1C? If the site constantly pulls 1C requests, it will kill the database!” Fair question. Answer: you don’t need to pull 1C every time you view a product on the site. Proper architecture looks different. Product data is imported from 1C into the site database via OData - exactly the same as with CommerceML. The difference is that with OData you can do this incrementally. Do not download the entire catalog, but only request changes: “give me products whose modification date is greater than the last synchronization time.” For a catalog of sixteen thousand items, where ten to twenty items typically change per hour, this means processing ten to twenty entries instead of sixteen thousand. The difference in performance is two to three orders of magnitude.

Now add webhooks to this. Webhook is a mechanism in which 1C itself notifies the site about changes. Has the price of the product changed? 1C sends a POST request to the site: “product such and such, new price such and such.” Has the stock in stock been updated? Another POST request. The site receives a notification and updates the specific product within milliseconds. There is no need to wait for scheduled exchanges, no need to go through the entire directory looking for changes. The data on the site is up-to-date in real time - with a delay of seconds, not hours. Remember that case with the lost order due to out-of-date balances? It wouldn't happen with webhooks. The balance would be updated on the website at the time the goods are shipped in 1C.

I have to be honest: setting up webhooks from 1C is not a trivial task. In boxed configurations (UT, ERP, KA) there is no such mechanism. You need to either write a subscription to an event in 1C, which will send an HTTP request when a product changes, or use an extension. We use an extension that is triggered when documents are processed that affect balances and prices, and sends a notification to the site. The development took a couple of days, but the result is worth it - now the rest of the site is updated within five to ten seconds after posting the document in 1C. Managers stopped manually checking the relevance of data on the site. Clients stopped receiving apology calls. This is not just a technical improvement - it is a qualitative change in the way the business operates.

Mapping that doesn't break with every sneeze

One of the most painful topics in the integration of 1C and the site is the correspondence of fields. In 1C, data is stored in one structure, on the website - in another. CommerceML offers a rigid scheme: the product name is in the “Name” field, the description is in the “Description” field, the article is in the “Article” field, and so on. If your data structure differs even slightly from what CommerceML assumes, problems begin.

Here is a specific example from our practice. In 1C, our product “Hydraulic oil HVLP 46” has the full name “Hydraulic oil HVLP 46 (200 l barrel)” and the short name “HVLP 46”. CommerceML passes one field “Name” - which one? The default is full. But on the website we want to show one name in the product title, another in the catalog, and a third in breadcrumbs. With CommerceML, for this you need to either change the unloading processing in 1C, or parse the strings on the site side, extracting the volume and unit of measurement from the full name. Both options are crutches. With OData, I simply query both fields: “Description” and “NameFull” - and map them to the required WooCommerce fields. One in the title, the other in the meta field. No 1C customization, no string parsing, no fragile regulars.

But this is a simple example. The situation with additional details is much more interesting. As I already said, in 1C our products have dozens of technical characteristics. Viscosity, density, temperatures, tolerances - all this is stored in the “Additional Details” tabular part of the item item. Each attribute has a key (GUID of the characteristic type) and a value (string, number or link to a directory element). CommerceML does not know how to work with this structure directly - you need a 1C programmer who will write a processing that “expands” the tabular part into the CommerceML property set. And every time a new attribute is added to 1C, this processing needs to be updated.

Not so with OData. OData provides additional details as a nested array of objects - each with a key and a value. On the site side, we simply read this array and map each attribute to the corresponding WooCommerce attribute. And here comes the fun part - auto-discover. Our module, when connecting to 1C for the first time via OData, automatically scans the database metadata, finds all types of product characteristics and offers mapping: “Found 99 unique characteristics in 1C. Here they are. Which ones should I create as WooCommerce attributes? What kind of meta fields? Which ones should I ignore? You set up the match once, and then it works automatically. Have you added a new attribute “NAS Cleanliness Class” to 1C? During the next synchronization, the module will detect a new attribute and offer to create an attribute for it on the site. Without a 1C programmer, without updating processing, without manual configuration.

We found 99 unique characteristics in the 1C database and created 121 taxonomies from them in WooCommerce. Why 121 and not 99? Because some characteristics were multi-valued—for example, “manufacturer approvals” contained multiple values ​​for a single product—and for such characteristics it was more convenient to create separate taxonomies with multiple choice capabilities. With CommerceML, such flexibility simply does not exist: you get what the upload processing gives, and you cannot change the mapping logic on the fly.

I would also like to say something about customizability. In CommerceML, mapping is baked into the plugin code or into 1C processing. If you want to change which 1C field goes where on the site, you need to go into the PHP code or into the 1C configuration. With OData, mapping is a setting in the site admin panel. You see a table: on the left are 1C fields, on the right are WooCommerce fields. Drag, change, add transformation rules (for example, “if the value of the “Oil Type” field is “Mineral,” write the value “Mineral” to the “Base Type” attribute”). Changes are applied instantly, without deploying code, without restarting the exchange. This is something that a catalog manager can do, not just a developer.

I've been wondering why CommerceML remained the standard for so long, despite all its limitations. And I came to the conclusion that the reason is inertia. CommerceML is built into standard 1C configurations. It works “out of the box” - turn on the exchange, specify the site address, press the button. No need to understand the API, no need to write code. For a small store with a couple of hundred products, this is really enough. But when the catalog grows, when complex attributes appear, when a business needs real-time data relevance, the limitations of CommerceML start to cost money. Real money - in the form of lost orders, manual labor of managers and payment for hours of 1C programmers.

What the transition looks like in practice

I understand that at this point the reader may be wondering, “Okay, OData is better than CommerceML, I get it. But how to go? I have already set up an exchange, the products are synchronized, the catalog is working. Do we really need to tear everything down and rebuild it?”

No, it's not necessary. And this is perhaps the main argument in favor of the OData approach: the transition can be done gradually. You don't disable CommerceML on day one. You connect the OData module in parallel, set up mapping, run test synchronization, compare the results - and only when you are sure that everything is working correctly, disable the old exchange.

That's exactly what we did. The first stage is connecting to OData 1C and migrating existing connections. We had 16,844 products in our WordPress database, each of which had a meta field_id_1cwith old ID from CommerceML. The module went through all the products, compared them with records in 1C via OData and created a mapping in a separate table - 18,850 records (including variations). This process took about two hours, but it was a one-time operation.

The second step is to configure incremental synchronization. We configured the OData module to update only changed products. Every fifteen minutes the module asks 1C: “What products have changed since the last check?” OData allows you to make such a request in one line - filter by modification date. The response is a JSON with ten to twenty products, which are updated in WooCommerce in a few seconds. Compare this to a full catalog upload via CommerceML, which took three hours.

The third stage is setting up webhooks for critical data. Prices and balances now come to the site instantly, through POST requests from 1C. This required a little modification on the 1C side - an extension that is triggered when posting sales documents, receipts and price adjustments. But this modification is done once, and then it works automatically.

Stage four - disabling CommerceML. We did this a month after launching the OData module, when we were convinced that all data was synchronized correctly. We deactivated the old woocommerce-synchronization-1c plugin and disabled exchange processing in 1C. The site continued to work as if nothing had happened - because the data now came in a different way.

What did we get as a result? Let's look at specific numbers. The time for full directory synchronization has been reduced from three to four hours to twenty minutes - while full synchronization is only needed during initial setup or after major changes in the 1C directory structure. In normal mode, there is an incremental update that takes seconds. The delay in updating prices and balances has decreased from a day (exchange once a day) to seconds (webhooks). The number of product duplicates for three months is zero. Because OData uses stable 1C identifiers (Ref_Key), which do not change when a product is moved between groups or when its properties change. The number of lost images is zero. Because images are loaded through a separate endpoint, with the file hash checked, and are updated only when there is a real change. The number of calls to a 1C programmer to customize an exchange is zero over the last six months. Because mapping is configured in the site admin panel, and auto-discover finds new details itself.

But beyond the numbers, there is another change that is difficult to quantify, but which may be even more important. Managers are no longer afraid of the catalogue. Previously, the morning of each working day began with a check: “was the exchange successful? is everything in place? Are the prices current? Now they just work. The data on the site is always up to date, products are not lost or duplicated, attributes are updated automatically. This freed up a significant amount of working time that was previously spent on manual checking and correcting exchange errors.

Separately, I would like to talk about the setup wizard - what we call the Wizard. One of the reasons CommerceML is so popular is its ease of initial setup. I turned on the exchange in 1C, specified the address - it works. For OData, the entry threshold is higher: you need to enable OData publishing on the 1C web server, configure user rights, and understand the endpoints. We spent a lot of time trying to lower this threshold and ended up creating a step-by-step wizard that walks the user through the entire setup in fifteen minutes. Step one is to provide the OData URL and credentials. The wizard checks the connection, shows the 1C version and the name of the database. Step two is to select reference books for synchronization (nomenclature, characteristics, units of measurement). The wizard scans 1C metadata and shows available entities. Step three is to configure the field mapping. The wizard offers a default mapping (which covers 90% of cases) and gives the opportunity to change it. Step four is to run a test import of ten products and check the result. Step five is to run a full import. All. Fifteen minutes, no 1C programmer, no processing settings.

To be honest, when we showed this Wizard to the first users, the reaction was unexpected. I expected questions like “where is the upload setting in 1C?” or “how can I change the exchange processing?” Instead, people asked, “Wait, is that all? I just indicated the address, and it found my goods by itself? Where's the catch? There is no catch. OData is a standard 1C interface that provides data in a structured format. There is no need to configure anything on the 1C side (except for enabling OData publishing and creating a user with the necessary rights). All settings are on the site side, in the familiar WordPress admin panel.

Honest conversation about the cons

I would be dishonest if I presented the OData approach as a solution without drawbacks. It has its limitations, and they should be discussed openly.

First, OData in 1C is not ideal. It is slower than direct queries to the 1C database because it works over HTTP and goes through a business logic layer. For a query against a directory with hundreds of thousands of elements, this can be noticeable. We solve this by pagination - we request data in portions of 300 records, and process each portion through the Action Scheduler (task scheduler built into WooCommerce). This allows you to spread the load over time and not block either 1C or the site.

Second, not all data is accessible through OData equally conveniently. For example, subordinate directories (like “Item Characteristics” in UT) may not support standard filtering and field selection operations. We are faced with the fact that a request with parameters$selector$filterreturned HTTP 400 to the characteristics directory. I had to download all the entire records and filter on the PHP side. Not critical, but you need to be aware of such features.

Third, images. OData in 1C does not send binary data of attached files through a standard endpoint/$value. At least it didn't work in our configuration. I had to use an additional extension (HTTP service) to receive image files. This is not technically difficult, but requires minimal modification on the 1C side.

Fourth, webhooks also require 1C improvements. Typical configurations do not have a built-in mechanism for sending notifications when data changes. You need to write an extension. For a person who is familiar with 1C, this is a task that will take several hours, but for those who only work with the website and do not touch 1C, this is an additional barrier. However, webhooks are optional: you can only work with incremental synchronization via OData, just with a slightly longer data update delay.

Fifth - OData requires that a web service be published on the 1C server. This means that IIS or Apache must be configured to serve HTTP requests to the 1C database. On most 1C servers this has already been done (for example, for a thin client via the web), but there are cases when web publishing is not configured. Then you need to involve a 1C administrator for the initial setup.

All of these limitations are real, but none of them outweigh the benefits of OData over CommerceML. It's like comparing an electric car with a steam locomotive: yes, an electric car needs to charge its battery, and there are still fewer charging stations than gasoline stations. But this does not mean that you need to continue to ride a steam locomotive, because firewood for it can be found in any forest.

Another question that is often asked: “What if I have a Bitrix/OpenCart/custom website, and not WooCommerce?” OData is a universal protocol. It is not tied to WordPress or WooCommerce. Any platform that can send HTTP requests and parse JSON can work with OData 1C. The specific module I'm talking about is implemented as part of a WooCommerce plugin, but the principles are the same: REST API instead of XML files, incremental updates instead of full unloading, custom mapping instead of a rigid schema. If you work with another platform, look for similar solutions or implement the integration yourself, since OData provides a clean and documented API.

What if you look at it from the other side - from the side of 1C franchisees and 1C developers? I talked with several 1C partners, and their reaction to the OData approach was mixed. On the one hand, they understand the limitations of CommerceML - they experience them themselves every day. On the other hand, CommerceML is their bread and butter. Customizing exchange processing, setting up uploads, fixing synchronization errors - these are regular paid hours. The transition to OData deprives them of part of their income, because the client can set up the integration himself, without a 1C programmer. This is not a conspiracy or malice—just economic reality. But for a business that pays for integration, this is an argument in favor of OData: less dependence on a contractor, lower support costs, more control.

Do you know what surprises me most about this whole story? The non-technical advantages of OData are obvious to anyone who has even a little understanding of web technologies. I'm surprised the transition took so long. We struggled with CommerceML for seven years, knowing its limitations, and each time we found a reason not to change our approach. “Now is not the time,” “it works, don’t touch it,” “what if it gets worse.” Classic reasons for maintaining the status quo. It was only when the loss of a specific order made the cost of inaction obvious that we finally took the plunge.

There is another aspect that is rarely talked about, but which in practice turns out to be critically important - debugging and diagnosing problems. When something breaks in the CommerceML exchange (and it breaks regularly), the diagnosis turns into a detective story. An XML file of tens of megabytes in which you need to find the problem node. PHP logs that only say “Parse error” without specifying a specific location. 1C logs that write “Exchange completed with errors” - and what kind of errors, figure it out yourself. We spent hours trying to figure out why a specific product wasn't updated or why a specific group of products had lost images. Sometimes the reason turned out to be trivial - for example, a special character in the product name that broke the XML parser. Sometimes it is mysterious, related to the order of file processing or server time zones.

Diagnostics are transparent with OData. You send a specific request and receive a specific response. Error? It is in an HTTP response with clear code and description. Product not updated? Look at the request and response in the log - everything is visible. We log each synchronization operation into a separate table (wpaic_1c_sync_log) with details: what product, what fields were updated, how long it took, whether there was an error. The manager can go to the admin panel and see the synchronization history of each product. This is not just convenience - it is another level of control over the process.

And here’s something else I noticed after the transition. When the data on the site is always up to date, when the exchange works reliably and predictably, the entire team’s attitude towards the site changes. Previously, the site was perceived as “a showcase that sometimes shows the correct data.” Managers duplicated information in Excel because “the site cannot be trusted.” Customers called to check availability because “it may not be current on the website.” Now the site is a source of truth. Managers refer to it when communicating with clients. Customers place orders on their own without calling back. Management looks at sales analytics on the website, knowing that the data is reliable. This change is difficult to overestimate - it affects the efficiency of the entire business, and not just the work of the IT department.

I also want to address the issue of security because it comes up a lot in conversations about replacing CommerceML. “OData allows access to the 1C database via the Internet - this is a security hole!” A fair concern, but let's figure it out. CommerceML also works via HTTP - the same PHP script on the site that accepts XML from 1C is accessible from the Internet. And often it is protected only by a login and password, which are transmitted in clear text. OData can be configured more securely: HTTPS with mandatory TLS, authentication via Basic Auth or OAuth, restricting access by IP address, a separate 1C user with minimal rights (only reading the necessary directories). Moreover, you can use a VPN between the 1C and website servers, completely closing the OData-endpoint from external access. So from a security point of view, OData is a step forward rather than backward.

I am sure that in three to five years CommerceML will become as anachronistic as FTP file upload to hosting or spreadsheet layout is today. Technology evolves, business demands grow, and the format created twenty-one years ago for a world that no longer exists will inevitably give way to modern approaches. The only question is whether you will make this transition now - or wait until you lose your “large order”.

If you are currently working with CommerceML and have identified your problems in this article, then you are ready for a change. There is no need to be afraid of the transition. There is no need to break what works in one day. Start small: enable OData on your 1C server, try sending the first request, look at your catalog data in JSON format. You will see your products, your prices, your details - only in a convenient, readable, modern format. And then you will understand that there will be no return to gigabyte-sized XML files.

We have collected all our experience - both positive and negative - into a 1C integration module via OData for WooCommerce. Setup wizard, auto-discover attributes, incremental synchronization, webhook support, flexible field mapping - everything I talked about in this article. If you are interested in seeing how this works in practice, take a look at the module page on our website. And if you have questions about the integration of 1C and WooCommerce, write, I’m always happy to share my experience. Because every store that moves away from CommerceML makes the entire e-commerce market a little more modern.