Synchronizing WooCommerce with 1C: Real-time Trade Management

About three months ago, an acquaintance called me - he runs an online store of industrial chemicals, about four thousand SKUs, two managers, a warehouse in the Moscow region. The voice is tired, in the background you can hear someone swearing in the warehouse. “Listen,” he says, “I need help. We again sold what was out of stock. The client paid, the order was processed, and the shelf was empty. This is the third time in a week. The manager says that in 1C the balances were updated last night, but on the website it still shows in stock. I’ll ruin the business like that.” I asked him how they set up the connection between 1C and the website. It turned out that it was a standard scheme: uploading via CommerceML once a day, at night, according to a schedule. If you're lucky, the exchanger won't freeze, the file will be parsed, and the products will be updated. If you’re unlucky—and you’re not lucky regularly—managers discover in the morning that half the prices are old, there are no new items, and for some reason the removed products have returned to the site.

This story is no exception. I would even say this is the rule. Every second owner of an online store in Russia who keeps records in 1C (and this, according to various estimates, from seventy to eighty percent) sooner or later faces the fact that synchronizing data between the accounting system and the site turns into a separate headache. Not a side task, but a problem that consumes time, nerves and money. And what’s most offensive is that this problem has long been solved technically. It’s just that the vast majority still use tools that were fifteen years old, because “well, it works somehow” and “is there something else?”

Yes, there is. And I want to talk in detail about how we approached this task when developing the 1C integration module in our COS WP Woo plugin, why we chose a fundamentally different path, and what this gave our clients in practice. Not in the format of an advertising booklet, but honestly - with the rake that we have collected, with solutions that turned out to be not obvious, and with results that can be measured.

Why CommerceML is a protocol from the last century

I’ll now say something that may seem categorical, but I am convinced of its correctness: CommerceML as a data exchange format between 1C and an online store became obsolete about ten years ago. It was designed in the early 2000s, when an online store was a showcase with a catalog and an “order” button, updating price tags once a week was considered the norm, and the idea of ​​real-time synchronization seemed like a whim. Then CommerceML solved the problem perfectly: it generated an XML file with products and prices, put it in a folder on FTP, the CMS took it, parsed it and updated the catalog. Simple, reliable, understandable.

But the world has changed. Today, the client expects that if he sees “5 pieces in stock” on the website, then there really are five pieces in stock. They weren’t lying there yesterday, they weren’t lying there three hours ago, but right now. Because at the same time, the same product can be sold through another channel - through the manager who placed the order by phone, through the marketplace, through a retail outlet. And if your synchronization works once an hour (or, like my friend, once a day), you are selling air. And then call the client and say: “Sorry, there was an error, there is no product, let us return your money.” Each such call is not just a lost sale. This is broken trust. This is a negative review. This is a client who will no longer come to you.

I know companies that employ a separate person - in fact, a “synchronization manager”, who checks every morning whether the exchange went through, corrects errors by hand, calls the 1C department, and deals with duplicate goods. This, for a second, is a salary of forty to sixty thousand rubles a month. Only to ensure that data from one system flows correctly into another. Absurd? No, this is the reality of thousands of Russian online stores.

Let's honestly list the CommerceML problems that I have encountered personally - in real projects, and not in theoretical discussions. Duplicate products are a classic of the genre. CommerceML identifies products by the internal GUID from 1C, and if something went wrong with your database, if you restored a backup, if 1C remade the item directory - that’s it, the GUIDs are gone, duplicates appear on the site. Losing images is also a common story: CommerceML transfers images as binary attachments in XML, and with a large directory, the exchange file grows to hundreds of megabytes, PHP crashes due to a timeout or out of memory in the middle of parsing. The inability to transfer custom fields is another pain: if your product in 1C has twenty additional details (viscosity, pour point, certificates, manufacturer approvals), the CommerceML exchanger simply does not know what to do with them. Maximum - will dump “description” into one text field. And, perhaps, the most unpleasant thing: if the exchange breaks in the middle (and with a large catalog this happens all the time), you get a half-updated catalog, where some of the products have new prices, and some have old prices. And no log, no way to understand what exactly was updated and what wasn’t.

When I realized all this from my own experience - and I went through the integration of 1C with the site on several projects over the past years - I realized that a fundamentally different approach was needed. Not “improved CommerceML”, not “CommerceML v2 with crutches”, but a completely different data exchange architecture.

OData: when 1C speaks HTTP

And here we come to a technology that, strictly speaking, has existed in 1C for a long time - since version 8.3 - but which the vast majority of online store developers for some reason stubbornly ignore. I'm talking about the OData interface that 1C provides out of the box. The point is simple: your 1C database becomes a REST API server. You can access it via HTTP, receive data in JSON format, filter, sort, paginate - everything that has long become a standard in the world of web development. No XML files on FTP. No “scheduled uploading”. Direct connection, in real time, to live data from your accounting system.

Honestly, when I first tried the 1C OData interface, I experienced a strange feeling - a mixture of delight and irritation. Delight - because it really works. You make an HTTP GET request to your 1C and receive JSON with products, prices, balances, characteristics - everything that is in the database. Annoyance - because this feature has existed for years, and we have been struggling with CommerceML all this time. Why? I think for several reasons. Firstly, OData is about programming, and not about “press a button - get a file.” You need to understand HTTP requests, you need to be able to work with the REST API, you need to write code. Secondly, the 1C documentation on OData, to put it mildly, is far from ideal. Try to find a clear description of how to obtain additional item details via OData - I spent two days on this. Thirdly, the majority of “1C-nicks” are people who live in the 1C world and have little idea of ​​how the modern web works. And most web developers, accordingly, shy away from 1C as something incomprehensible. The connection between the two worlds is something that is sorely lacking.

We solved this problem when developing the 1C module in COS WP Woo. The idea was simple: to create a bridge that, on the one hand, talks to 1C in its language (OData queries to the standard interface), and on the other hand, with WooCommerce in its language (WordPress API, WooCommerce hooks, custom tables). And do it in such a way that the store owner does not need to understand OData, REST API, or HTTP requests. I set up the connection and it works.

This is what it looks like technically, without any simplifications. Our OnecSync module connects to the OData interface of 1C: Trade Management (1C:UT) via standard HTTP. The connection address looks like a regular URL - something like http://your-server/your-database/odata/standard.odata. Authorization - Basic Auth, standard for HTTP. No special connectors, COM objects, download processing - everything works through regular HTTP requests, which WordPress can send via wp_remote_get/wp_remote_post. This is a fundamentally important point: your hosting does not need any special PHP extensions, no COM modules, no third-party libraries. If your WordPress can make HTTP requests (and it always can), the integration will work.

The data that we take from 1C passes through a system of components. OnecDataFetcher is responsible for receiving raw data - products, prices, balances, characteristics. OnecProductImporter takes this data and converts it into WooCommerce structures - creates or updates products, sets prices, binds categories and attributes. OnecAttributeMapper is a separate component that compares 1C attributes (additional item details) with WooCommerce taxonomies. OnecCategoryMapper, accordingly, does the same for categories. All this is wrapped in a single OnecSync facade, which coordinates the work of components and ensures transactionality: if something goes wrong in the middle of an import, the system knows what has already been processed and what has not yet been processed.

Nineteen thousand products: how it works in practice

You know, talking about architecture is one thing. But showing how it works on a real directory is completely different. I will tell you about our own experience, because we integrated 1C:UT with WooCommerce for our client - an online store of lubricants with a catalog of nineteen thousand two hundred two products. This is not a small test store with twenty positions - it is a full-fledged industrial catalog with dozens of categories, hundreds of brands and many characteristics for each product: viscosity, flash point, pour point, car manufacturer approvals, GOST and TU certificates of conformity.

The first thing we encountered was volume. Nineteen thousand products cannot simply be downloaded with one request. The 1C OData interface supports pagination (parameters $top and $skip), but even with pagination, simultaneous processing of such a volume is a task that cannot be solved within the framework of a regular WordPress HTTP request. The standard PHP timeout is thirty seconds, sometimes sixty on hosting. And importing nineteen thousand goods with characteristics, prices and balances takes minutes, if not tens of minutes.

This is where Action Scheduler comes into the picture, a background task system built into WooCommerce. We break the import into chunks of three hundred products and set each chunk as a separate background task. Action Scheduler takes these tasks from the queue and executes them sequentially, each within its own HTTP request, with its own timeout. If one chunk falls, the next one will still be processed. If the server reboots, the queue is saved in the database, processing will continue from where it left off. This is a fundamental difference from the CommerceML approach, where if the exchange is interrupted in the middle, that’s it, start over. With us, each product has its own processing status, and when imports resume, only those products that have not yet been processed are processed.

The second major challenge is attribute mapping. In 1C:UT, a product can have dozens of additional details, and each detail has its own type, its own name, and its own set of acceptable values. In WooCommerce, attributes are taxonomies, with their own system of slugs, term_id and other WordPress cuisine. Tying one to the other with your hands is a job that takes days, if not weeks. Therefore, we made automatic mapping (auto-discover): when you first connect to 1C, the module analyzes all additional item details and automatically creates the corresponding taxonomies in WooCommerce. In our real case, out of four hundred and ninety 1C attributes, ninety-nine were automatically mapped to one hundred and twenty-one WooCommerce taxonomies. The difference in numbers is explained by the fact that some 1C attributes are divided into several WooCommerce taxonomies (for example, “Manufacturer Approvals” from 1C turn into separate taxonomies for each manufacturer). The remaining attributes were not deliberately mapped - these are 1C service details that have no meaning on the site.

I remember the first time we launched full import on a live basis. I sat and updated the dashboard page every thirty seconds, watching the counter of processed goods grow: three hundred, six hundred, nine hundred... When it reached three thousand, I already relaxed - it became clear that the system was stable, there were no errors, each chunk was processed in seven to ten seconds. There was about an hour left until the end. I went to drink coffee. When I returned, nineteen thousand two hundred and two products were in WooCommerce, with prices, balances, categories and attributes. Not a single duplicate, not a single lost picture (well, to be honest, the pictures were a separate story, which I’ll tell you later), not a single product with the wrong price. You know, moments like these are worth writing code for.

But importing is only half the task. Importing goods once is like moving into a new apartment: the main work is ahead. Next, you need to keep the data up to date. Every day in 1C prices change, goods arrive at the warehouse, goods leave the warehouse, new items appear, some are discontinued. And all these changes should be reflected on the site - not in a day or an hour, but ideally in minutes.

Webhook model: let 1C itself tell you what has changed

This is where we come to one of the key architectural decisions that distinguishes our approach from ninety percent of existing integrations. Most synchronization plugins work on the polling principle: every N minutes (five, ten, thirty, sixty) WordPress makes a request to 1C and checks if anything has changed. It’s as if you called the warehouse every five minutes and asked: “Well, have you brought anything new?” After ten such calls, the storekeeper will stop answering the phone - and he will be right.

The problem with the polling approach is scale. If you have a thousand products, checking them all every five minutes is a relatively small burden. But what if you have twenty thousand products? One hundred thousand? At each iteration of polling, your WordPress sends dozens of requests to 1C, 1C processes them, returns data, WordPress compares them with what is in the database - and in ninety-five percent of cases it discovers that nothing has changed. All this data exchange is for nothing. This is the load on the 1C server, the load on WordPress hosting, wasted traffic, wasted server resources. And with all this, there is a delay of up to five minutes between a real change in 1C and its reflection on the site. For many businesses this is critical.

We took a different route. Our module implements a webhook model: 1C itself notifies the site about changes. There has been a change in the price of a product - 1C sends an HTTP request to your website with information about which product has changed and what exactly has changed. A shipment has arrived at the warehouse - 1C sends a webhook with updated balances. A new product has been created - 1C reports this to the site. The site receives a notification and processes only those products that have actually changed. No empty search of twenty thousand positions. No load on 1C from constant requests.

I understand that an experienced 1C developer may now have a question: “How is this implemented on the 1C side?” This is a valid question, and answering it is one of the places where you need to be honest about the complexities. The 1C OData interface out of the box does not support webhook subscriptions in the same way as it is implemented, say, in Stripe or GitHub. For a full-fledged webhook model, modifications are needed on the 1C side - subscribing to events and sending an HTTP request when data changes. This can be implemented through event subscriptions, through background jobs, through configuration extensions. Our OnecWebhookHooks module on the WordPress side receives these notifications and processes them. On the 1C side, we provide processing that configures the sending of webhooks. Yes, this requires certain configuration on the 1C side, but this is a one-time setup that any competent 1C specialist can do in a couple of hours.

For those cases when the webhook model is impossible (for example, the client does not want or cannot modify 1C), we have a fallback - the OnecStockSync component, which works on a schedule, but does it smarter than regular polling. Instead of going through all the products, he requests from 1C only changes for the last period. OData supports filtering by modification date: we only query records that have changed since the last synchronization. This is orders of magnitude more effective than a complete search - instead of twenty thousand products, ten to twenty are processed that have actually changed.

But let me tell you about one more thing that seems like a small thing, but in practice saves a huge amount of nerves - a mapping table. When you link two catalogs - in 1C and in WooCommerce - you need a reliable way to determine which product in 1C corresponds to which product on the site. It would seem that the task is trivial: we take the article, find the product by it in both systems, and you’re done. But in practice everything is more complicated. Articles may differ in spelling (spaces, case, special characters). Some products may not have article numbers. A product in 1C can have several articles (main and supplier). There may be no article at all - only a name and an internal code.

Therefore, we made a separate mapping table - wpaic_1c_map - which stores the relationship between 1C products and WooCommerce. The connection can be by article, by UUID (Ref_Key in 1C), by barcode or by manual matching. When importing for the first time, the system tries to automatically match products by SKU. Those that could not be mapped automatically can be mapped manually in the admin interface. Once the mapping is installed, it is saved forever - during subsequent synchronizations, the system knows exactly which 1C product corresponds to which WooCommerce product, and updates it without unnecessary searches and comparisons. In our case with nineteen thousand products, mapping migration (from the old plugin that stored the relationship in the postmeta) took several minutes, and after that each synchronization goes smoothly - the system does not “guess” the match, but takes it from the table.

And now about something that at first glance seems contradictory: SEO protection during import. It would seem that if we synchronize data from 1C, we synchronize everything - name, description, price, balances, characteristics. But in practice this is a catastrophic mistake. The product name in 1C is an internal name for accounting, often unreadable: “Synthetic motor oil. Shell Helix HX8 5W30 A3/B4 4l canister.” On the website, the same name is optimized for search and human perception: “Shell Helix HX8 5W-30 engine oil - synthetic, 4 liters, A3/B4 approval.” If, during each synchronization, the 1C name overwrites the site name - goodbye, SEO optimization. Goodbye to all the headline-improving work the marketer did. Goodbye to keywords in URL slugs that were indexed by Google and Yandex.

Therefore, our module has custom update_fields - a list of fields that are updated during synchronization. By default, only prices and balances are updated - what really needs to be up to date in real time. The title, description and slug are protected from being overwritten. If you want to update them too, you need to explicitly enable this in the settings. But we warn you: if you have spent time on SEO optimization of product cards, do not enable title and description updates when synchronizing with 1C. Let the accounting system manage what it manages well - prices and balances, and the content on the site remains under the control of the marketer.

Variations, characteristics and the main pitfall of 1C

A separate and very non-trivial topic is product variations. In WooCommerce, a variation is a variable product with child variations, each with its own attributes, price, and balance. A typical example: a T-shirt with a choice of size and color. In 1C, an analogue of variations is the characteristics of the item - a subordinate directory that is tied to the product (or to the type of item) and describes specific variants of execution.

And this is where the fun begins. The structure of characteristics in 1C:UT is perhaps one of the most non-trivial places in the entire integration. Characteristics can be tied to a specific product (Ref_Key of the item), or they can be common to the entire type of item (Type of Item_Key). That is, if you have the “Motor oils” type and this type has the “Volume” characteristics defined (1L, 4L, 5L, 20L, 208L), then all products of this type inherit these characteristics. But a specific product may have its own characteristics that are not related to the type. We have implemented what I call a “dual owner lookup”: when importing a product, the system checks the characteristics first by the Ref_Key of the product itself, then by the Item Type_Key. This covers both scenarios.

Another non-trivial detail: the subordinate directory Catalog_CharacteristicsNomenclature in 1C does not support the standard OData parameters $select and $filter. We discovered this experimentally - a request with $filter returns HTTP 400, and the 1C documentation does not warn about this anywhere. The solution is to download all characteristics entirely and filter on the PHP side. It's not perfect in terms of performance, but it works reliably, and for us, reliability is more important than elegance.

I thought for a long time whether it was even worth talking about such technical nuances in an article intended for a business audience. I decided that it was worth it - for one simple reason. When you choose a plugin for synchronizing 1C and WooCommerce, you are told: “We have integration with 1C!” But integration is different. One integration can transfer names and prices. The other one fully works with characteristics, variations, multiple prices, warehouse balances, and custom attributes. And the difference between them is the difference between “our site somehow shows data from 1C” and “our site fully reflects the reality of the accounting system, and we can trust it.”

Let me tell you about another pitfall that we discovered already in production, with real data and real clients. Deduplication when importing goods with characteristics. Imagine: in 1C there is a product “Shell Helix HX8 5W-30 Oil” with characteristics (variations) by volume: 1 liter, 4 liters, 20 liters. But historically, on the WooCommerce website, this product was not listed as one variable product, but as three separate simple products: “Shell Helix HX8 5W-30 Oil (1 l.)”, “Shell Helix HX8 5W-30 Oil (4 l.)”, “Shell Helix HX8 5W-30 Oil (20 l.)”. This is a very common situation - many stores initially listed products as a “flat list”, without variations. If, when importing from 1C, we create a variable product “Shell Helix HX8 5W-30 Oil” with variations, there will be duplicates on the site: both old “flat” products and a new variable one. With different URLs, with different SEO weight, with potential conflicts in the cart.

We solved this problem through a preliminary check: before importing a product with characteristics, the system checks whether there are packaging products with the corresponding name on the site. If a match is found, the parent product is not imported as a duplicate, but is linked to existing positions. It's a small thing, but a small thing that prevents serious problems on sites with a long history of content.

Now let's talk about two-way exchange - the part that many people forget. Synchronization is not only “from 1C to the site”. This is also “from the site in 1C”. When a client places an order on the website, this order must go into 1C for further processing - issuing an invoice, reserving goods, generating shipping documents. Our OnecOrderHooks module intercepts WooCommerce events - order creation, status change, payment - and generates the corresponding documents in 1C. Order on the website = buyer’s order in 1C:UT. Payment on the site = receipt of funds. This saves managers from manually transferring orders - work that takes several hours with fifty orders a day.

I know that many people are concerned about the security issue: if we open the 1C OData interface for HTTP requests, does the database become vulnerable? This is a valid concern and we take it seriously. For an OData connection, a separate 1C user is created with minimal rights - only reading directories and registers that are needed for synchronization. This user cannot change configuration, delete data, or execute arbitrary code. The connection can be restricted by IP - allowing access only from the IP address of your WordPress hosting. All exchange can be done over HTTPS, so the data is encrypted in transit. And finally, the OData user has a blocking mechanism for multiple failed authentication attempts - protection against password brute force. By the way, we encountered this in practice: during debugging we made a mistake with the password a couple of times, and the OData account was blocked for fifteen minutes. It's unpleasant, but it's a safety benefit.

And since we're talking about practical things, I'll talk about logging. This is what distinguishes a professional tool from a craft. Every synchronization operation - every request to 1C, every processed product, every error - is recorded in the wpaic_1c_sync_log table. In the module’s dashboard you see the full history: when was the last synchronization, how many products were processed, how many errors, and which products caused problems. If the manager calls and says “product X has the wrong price” - you open the log, find this product, see when it was last updated, what price came from 1C, and understand what the problem is. Without logging, any integration is a black box: data goes somewhere, comes from somewhere, and if something goes wrong, you can only guess at what stage the failure occurred.

I remember how, at one of the early stages of development, we launched synchronization without detailed logging, and two days later we discovered that two hundred products had zero prices. It turned out that in 1C for these goods the price was recorded in the “Item Prices” register with the “Retail” price type, and we requested the “SITE Retail Price” type (that’s what it was called in the settings). Two hundred products that did not have a record with the required price type received a zero. If we had a log, we would have seen the warning “price not found for product X” and would have understood the problem in five minutes, and not in two days. After this incident, we made logging as detailed as possible, with warnings for each abnormal situation. Now the system warns about products without a price, products without a category, products with zero balance, inconsistencies in mapping - about everything that could be a potential problem.

Fifteen minutes before first import: Settings Wizard

One of the things I'm particularly proud of is the Wizard. I thought for a long time about why integration with 1C is considered “a complex task requiring a programmer.” And I came to the conclusion that it’s not a matter of technical complexity in itself, but how this task is presented to the user. A typical instruction for setting up 1C and WooCommerce exchange is a ten-page document with the terms “Infobase publication URL”, “HTTP service parameters”, “setting up an exchange plan”. A person who is not a 1C developer closes this instruction on the second page.

We have created a step-by-step Wizard that guides the user through the entire setup process. The first step is to enter the 1C server address and credentials. The system checks the connection and shows: “Connection established. Base: Trade Management, version 11.5.16, organization: LLC “Your Company.” The second step is to select a product catalog and price type. The system shows available catalogs and types of prices from 1C, the user selects the ones he needs. The third step is setting up mapping: the system automatically matches products by item and shows the result. The fourth step is selecting fields for synchronization and setting up a schedule. And the fifth step is a trial run on ten products to make sure everything works correctly. The whole process takes ten to fifteen minutes. Not ten hours, not three days - fifteen minutes. Provided, of course, that you have already configured the OData interface on the 1C side. If it’s not configured, it’s another half hour of work for the 1C administrator; we provide step-by-step instructions for it.

Do you know what I noticed in practice? The most common question when setting up integration is not technical. Not “how to configure OData” and not “how to map attributes”. The most common question: “Are you sure nothing will break on the site?” People are afraid that integration will overwrite existing data, break the catalog, and delete products. And this is an understandable fear - many have had negative experiences with CommerceML, when after an unsuccessful exchange they had to restore the database from a backup. That is why we have made several levels of protection. “View only” mode (dry run) - the system shows what will be done, but does not make changes. Test import on ten products to make sure that the mapping is correct. Protection against overwriting of SEO fields is disabled by default. And, of course, logging every action so that if something happens you can roll back.

I often hear from competitors: “Our plugin does the same thing.” Let me disagree. When you buy a “1C and WooCommerce integration plugin,” look carefully at what it actually does. Does it support OData, or only works through CommerceML? Does it process item characteristics and create variations, or does it only import simple items? Is there an auto-discover of attributes, or do you need to manually register the correspondence of each field? How are errors handled - are they silently swallowed or are they logged with details? Is there duplication protection? Does reverse synchronization work (orders from the website in 1C)? All these questions are not “nice extras”, but basic requirements for normal integration.

Do you know what surprises me most about this story? How much time and money companies spend on solving a problem that is technically solved. The 1C OData interface has existed for many years. WordPress can make HTTP requests from day one. WooCommerce provides hooks for creating and updating products. Action Scheduler solves the problem of large volumes. All the bricks have been in place for a long time - you just need to assemble them correctly. But “correct” is the key word. Correctly means taking into account the real features of 1C (and not theoretical ones), with processing of all edge-cases (duplicates, packaging, missing prices), with protection from destructive actions and with detailed logging. That's exactly what we did in COS WP Woo.

Returning to my friend with an online store for industrial chemicals, we helped him switch from CommerceML to OData integration. It took two days: a day to set up OData on the 1C side (they already had a full-time 1C specialist), and a day to set up the module in COS WP Woo. The first full import took place overnight - four thousand goods with prices and balances. After this, synchronization of balances began to work via webhooks: a change in 1C means an update on the site in a matter of seconds. In the first month after the transition, the number of “sold something that is not there” situations decreased from three or four per week to zero. Completely zero. A manager who used to spend two hours in the morning checking the exchange now spends five minutes opening the dashboard, making sure everything is green, and going to work. By the way, the same manager is now processing orders - a more useful and productive activity than daily manual reconciliation of data between two systems. The savings in his work time alone are about fifteen hours per month, and this is a conservative estimate.

I'm not saying our solution is perfect. It has limitations. It works with 1C: Trade Management (1C:UT) - the most common configuration for trading companies. If you have 1C:Accounting or another non-standard configuration, some modification will be required. The OData interface needs to be configured and published on the 1C side - this is a one-time but necessary operation that requires a 1C administrator. The Webhook model requires improvement on the 1C side (processing for sending notifications). And finally, for large catalogs (more than ten thousand products), the first full import takes time - from thirty minutes to several hours, depending on the speed of the 1C server and the volume of data.

But all these restrictions are solvable. And they are incomparably smaller than the problems that you get by staying on CommerceML: duplicates, data loss, delays of a day, lack of feedback, inability to transfer custom fields. I have seen enough projects to say that OData integration through a normal tool is not a luxury or an “advanced option”. This is a necessity for any online store that seriously works with 1C and wants its website to reflect reality, and not an outdated copy of it.

Sometimes it seems to me that the problem of integrating 1C and websites is not a technical problem at all. This is the problem of the gap between two worlds: the world of accounting systems (where 1C nicknames live) and the world of web development (where “site developers” live). Each world knows its own instruments, speaks its own language and poorly understands the other. CommerceML was the bridge between these worlds - clunky, outdated, but understandable on both sides. OData is a new generation bridge: faster, more reliable, more flexible, but requiring both parties to be willing to take a step towards each other. Our module in COS WP Woo is an attempt to make this step as simple as possible. Wizard, who will lead you by the hand. Auto-discover, which will deal with the attributes itself. SEO protection that will prevent you from breaking what is already working. And a detailed log that will show what exactly happens during each synchronization.

If you are sitting now and thinking: “I have four hundred products, CommerceML can handle it, why do I need all this?” - I will answer this way. If your business is not growing, if you are not adding new sales channels, if customers don’t care whether the balances on the site are up to date, then there’s really no need. But if you plan to grow, if the catalog will increase, if you need to sell through several channels simultaneously (website, marketplaces, social networks) and have up-to-date data everywhere - then the transition to normal integration via OData is not “if”, but “when”. And it’s better to do this before you start selling air and losing customers, and not after. Because regaining the trust of a client to whom you sold a non-existent product costs much more than spending two days setting up a normal integration.

Try COS WP Woo - 14 days free.The 1C integration module is included in all tariffs. The setup wizard will take you from installing the plugin to importing products for the first time in fifteen minutes. No special knowledge is required - if you have 1C: Trade Management and WooCommerce, everything will work. And if you have any questions, our team will help with setting up OData on the 1C side and the first import.