大约三个月前，一位熟人给我打电话——他经营一家工业化学品网上商店，大约有四千个SKU，两名经理，在莫斯科地区有一个仓库。声音很疲倦，背景中你可以听到有人在仓库里咒骂。 “听着，”他说，“我需要帮助。我们又把缺货的东西卖掉了。客户付款了，订单处理了，货架却空了。这是一周内的第三次。经理说 1C 的余额昨晚更新了，但在网站上仍然显示有库存。我这样会毁掉生意的。”我问他1C和网站之间的连接是如何建立的。事实证明，这是一个标准方案：根据时间表，每天晚上通过 CommerceML 上传一次。如果幸运的话，交换器不会冻结，文件将被解析，并且产品将被更新。如果你运气不好——而且你经常不走运——经理早上就会发现一半的价格是旧的，没有新的商品，而且由于某种原因，被删除的产品又回到了网站。
这个故事也不例外。我什至会说这是规则。在俄罗斯，每一个在 1C 中保存记录的在线商店所有者（根据各种估计，这一比例为 70% 到 80%）迟早都会面临这样一个事实：在会计系统和网站之间同步数据会成为一个单独的难题。这不是一个副业，而是一个消耗时间、精力和金钱的问题。而最令人反感的是，这个问题早就在技术上得到了解决。只是绝大多数人仍然使用十五年前的工具，因为“好吧，它以某种方式工作”和“还有其他东西吗？”
是的，有。我想详细谈谈我们在 COS WP Woo 插件中开发 1C 集成模块时是如何完成这项任务的，为什么我们选择了一条根本不同的路径，以及这在实践中给我们的客户带来了什么。不是以广告小册子的形式，而是诚实地 - 用我们收集的耙子，用事实证明并不明显的解决方案，以及可以测量的结果。
为什么 CommerceML 是上世纪的协议
我现在要说的话可能看起来很明确，但我确信它的正确性：CommerceML 作为 1C 和在线商店之间的数据交换格式大约十年前就已经过时了。它是在 2000 年代初期设计的，当时的在线商店只是一个带有目录和“订购”按钮的展示柜，每周更新一次价格标签被认为是常态，实时同步的想法似乎是一时兴起。然后 CommerceML 完美地解决了这个问题：它生成一个包含产品和价格的 XML 文件，将其放在 FTP 上的文件夹中，CMS 获取它，解析它并更新目录。简单、可靠、易于理解。
但世界已经改变。今天，客户期望如果他在网站上看到“5 件库存”，那么确实有 5 件库存。他们不是昨天躺在那儿，也不是三小时前躺在那儿，而是现在。因为同时，同一种产品可以通过另一个渠道销售——通过电话下订单的经理、通过市场、通过零售店。如果你的同步每小时运行一次（或者像我的朋友一样，每天一次），那么你就是在销售空气。然后打电话给客户说：“抱歉，出现错误，没有产品，让我们退还您的钱。”每一次这样的电话不仅仅是一次销售损失。这是破碎的信任。这是一个负面评论。这是一个不会再来找你的客户。
我知道公司雇佣了一个单独的人 - 事实上，一个“同步经理”，他每天早上检查交换是否完成，手工纠正错误，致电 1C 部门，并处理重复的货物。这相当于每月四万到六万卢布的工资。只是为了确保数据从一个系统正确流入另一个系统。荒诞？不，这就是数千家俄罗斯网上商店的现实。
让我们诚实地列出我个人遇到的 CommerceML 问题 - 在实际项目中，而不是在理论讨论中。重复产品是该类型的经典。 CommerceML 通过 1C 的内部 GUID 来识别产品，如果您的数据库出现问题，如果您恢复了备份，如果 1C 重新创建了项目目录 - 就是这样，GUID 消失了，重复项出现在网站上。丢失图像也是一个常见的情况：CommerceML 将图像作为 XML 中的二进制附件传输，并且目录很大，交换文件会增长到数百兆字节，PHP 由于解析过程中超时或内存不足而崩溃。无法传输自定义字段是另一个痛苦：如果 1C 中的产品有 20 个附加详细信息（粘度、倾点、证书、制造商批准），CommerceML 交换器根本不知道如何处理它们。最大 - 将“描述”转储到一个文本字段中。也许，最令人不快的事情是：如果交换在中间中断（对于大型目录，这种情况经常发生），您会得到半更新的目录，其中一些产品有新价格，有些产品有旧价格。而且没有日志，无法了解到底更新了什么、没有更新什么。
当我从自己的经验中认识到这一切时 - 并且在过去几年中我在多个项目中经历了 1C 与站点的集成 - 我意识到需要一种根本不同的方法。不是“改进的 CommerceML”，也不是“拄着拐杖的 CommerceML v2”，而是完全不同的数据交换架构。
OData：当 1C 讲 HTTP 时
严格来说，这项技术在 1C 中已经存在很长时间了（从 8.3 版开始），但由于某种原因，绝大多数在线商店开发人员都顽固地忽视了这项技术。我说的是 1C 提供的开箱即用的 OData 接口。要点很简单：您的 1C 数据库成为 REST API 服务器。您可以通过 HTTP 访问它、接收 JSON 格式的数据、过滤、排序、分页——所有这些早已成为 Web 开发领域的标准。 FTP 上没有 XML 文件。没有“预定上传”。实时直接连接到会计系统的实时数据。
老实说，当我第一次尝试 1C OData 界面时，我经历了一种奇怪的感觉 - 混合着喜悦和恼怒。很高兴——因为它确实有效。您向 1C 发出 HTTP GET 请求，并接收包含产品、价格、余额、特征（数据库中的所有内容）的 JSON。烦恼 - 因为这个功能已经存在很多年了，而且我们一直在与 CommerceML 作斗争。为什么？我认为有几个原因。首先，OData 是关于编程的，而不是“按一个按钮 - 获取文件”。您需要了解 HTTP 请求，需要能够使用 REST API，需要编写代码。其次，温和地说，OData 的 1C 文档远非理想。尝试找到如何通过 OData 获取其他项目详细信息的清晰说明 - 我花了两天时间在这方面。第三，大多数“1C-nicks”是生活在1C世界的人，对现代网络的运作方式知之甚少。因此，大多数 Web 开发人员都回避 1C，因为它是难以理解的东西。这两个世界之间非常缺乏联系。
我们在 COS WP Woo 中开发 1C 模块时解决了这个问题。这个想法很简单：创建一个桥梁，一方面用其语言与 1C 对话（对标准接口的 OData 查询），另一方面用其语言与 WooCommerce 对话（WordPress API、WooCommerce 挂钩、自定义表）。并且以商店所有者不需要理解 OData、REST API 或 HTTP 请求的方式进行操作。我设置了连接并且它有效。
这就是技术上的样子，没有任何简化。我们的 OnecSync 模块通过标准 HTTP 连接到 1C：贸易管理 (1C:UT) 的 OData 接口。连接地址看起来像常规 URL - 类似于 http://your-server/your-database/odata/standard.odata。授权 - 基本身份验证，HTTP 标准。没有特殊的连接器、COM 对象、下载处理 - 一切都通过常规 HTTP 请求进行，WordPress 可以通过 wp_remote_get/wp_remote_post 发送这些请求。这是非常重要的一点：您的主机不需要任何特殊的 PHP 扩展、COM 模块、第三方库。如果您的 WordPress 可以发出 HTTP 请求（而且总是可以），那么集成就会起作用。
我们从 1C 获取的数据通过组件系统。 OnecDataFetcher 负责接收原始数据 - 产品、价格、余额、特征。 OnecProductImporter 获取这些数据并将其转换为 WooCommerce 结构 - 创建或更新产品、设置价格、绑定类别和属性。 OnecAttributeMapper 是一个单独的组件，用于将 1C 属性（附加项目详细信息）与 WooCommerce 分类法进行比较。因此，OnecCategoryMapper 对类别执行相同的操作。所有这些都包含在一个 OnecSync 外观中，它协调组件的工作并确保事务性：如果在导入过程中出现问题，系统知道哪些内容已被处理，哪些内容尚未处理。
一万九千种产品：它在实践中如何运作
你知道，谈论架构是一回事。但展示它如何在真实目录上工作是完全不同的。我将告诉您我们自己的经验，因为我们为我们的客户（一家拥有 19202 个产品目录的润滑油在线商店）集成了 1C:UT 与 WooCommerce。这不是一个拥有 20 个位置的小型测试商店 - 它是一个成熟的工业目录，其中包含数十个类别、数百个品牌以及每种产品的许多特性：粘度、闪点、倾点、汽车制造商批准、GOST 和 TU 合格证书。
我们遇到的第一件事就是数量。一万九千个产品不能简单地通过一个请求下载。 1C OData 接口支持分页（参数 $top 和 $skip），但即使使用分页，同时处理这样的卷也是无法在常规 WordPress HTTP 请求框架内解决的任务。标准 PHP 超时为三十秒，有时在托管时为六十秒。进口一万九千种具有特征、价格和余额的商品只需几分钟，甚至几十分钟。
这就是 Action Scheduler 发挥作用的地方，它是 WooCommerce 中内置的后台任务系统。我们将导入分成三百个产品的块，并将每个块设置为单独的后台任务。 Action Scheduler 从队列中获取这些任务并按顺序执行它们，每个任务都在其自己的 HTTP 请求中，并具有自己的超时时间。如果一个块掉落，仍会处理下一个块。如果服务器重新启动，队列将保存在数据库中，处理将从中断处继续。这是与 CommerceML 方法的根本区别，在 CommerceML 方法中，如果交换在中间中断，就这样，重新开始。在我们这里，每种产品都有自己的加工状态，当恢复进口时，只有那些尚未加工的产品才会被加工。
第二个主要挑战是属性映射。在 1C:UT 中，产品可以有数十个附加详细信息，每个详细信息都有自己的类型、自己的名称和自己的一组可接受的值。在 WooCommerce 中，属性是分类法，有自己的 slugs、term_id 和其他 WordPress 美食系统。用手将一根绳子绑在另一根绳子上是一项需要数天甚至数周时间的工作。因此，我们进行了自动映射（自动发现）：当您第一次连接到 1C 时，该模块会分析所有其他项目详细信息并自动在 WooCommerce 中创建相应的分类法。在我们的实际案例中，在 490 个 1C 属性中，有 99 个自动映射到 121 个 WooCommerce 分类法。数字差异的原因是，某些 1C 属性被分为多个 WooCommerce 分类法（例如，1C 中的“制造商批准”变成了每个制造商的单独分类法）。其余属性并未刻意映射 - 这些是 1C 服务详细信息，在网站上没有任何意义。
我记得我们第一次实时启动完全导入。我坐下来，每三十秒更新一次仪表板页面，看着加工货物的计数器不断增长：三百、六百、九百……当达到三千时，我已经放松了——很明显，系统很稳定，没有错误，每个块在七到十秒内处理完毕。距离结束还有大约一个小时。我去喝咖啡了。当我回来时，WooCommerce 中有 19202 个产品，包含价格、余额、类别和属性。没有一张重复的图片，没有一张丢失的图片（好吧，说实话，这些图片是一个单独的故事，我稍后会告诉你），没有一个价格错误的产品。您知道，这样的时刻值得编写代码。
但导入只是任务的一半。进口一次货物就像搬进新公寓：主要工作还在后面。接下来，您需要保持数据最新。 1C价格每天都在变化，货物到达仓库，货物离开仓库，新商品出现，有些已经停产。所有这些变化都应该反映在网站上——不是一天或一个小时，最好是几分钟。
Webhook 模型：让 1C 本身告诉你发生了什么变化
这是我们做出的关键架构决策之一，它将我们的方法与 90% 的现有集成区分开来。大多数同步插件都按照轮询原则工作：每 N 分钟（五、十、三十、六十）WordPress 向 1C 发出请求并检查是否有任何更改。就好像你每五分钟给仓库打电话并询问：“嗯，你带了什么新东西吗？”打完十个这样的电话后，店主就会停止接听电话——他是对的。
轮询方法的问题在于规模。如果您有一千种产品，每五分钟检查一次所有产品是一个相对较小的负担。但是如果您有两万种产品怎么办？十万？在每次轮询迭代中，您的 WordPress 都会向 1C 发送数十个请求，1C 处理它们，返回数据，WordPress 将它们与数据库中的内容进行比较 - 在 95% 的情况下，它发现没有任何变化。所有这些数据交换都是毫无意义的。这是1C服务器上的负载，WordPress托管上的负载，浪费流量，浪费服务器资源。尽管如此，1C 的实际更改与其在网站上的反映之间存在长达五分钟的延迟。对于许多企业来说，这至关重要。
我们采取了不同的路线。我们的模块实现了一个 webhook 模型：1C 本身通知站点有关更改的信息。产品价格发生变化 - 1C 向您的网站发送 HTTP 请求，其中包含有关哪些产品已更改以及具体更改内容的信息。货物已到达仓库 - 1C 发送包含更新余额的 Webhook。已创建新产品 - 1C 将此情况报告给网站。该站点收到通知并仅处理那些实际发生更改的产品。两万个位置不空搜。 1C 上没有来自持续请求的负载。
据我了解，经验丰富的 1C 开发人员现在可能会有一个疑问：“这在 1C 端是如何实现的？”这是一个有效的问题，回答这个问题是您需要诚实面对复杂性的地方之一。开箱即用的 1C OData 接口不支持 Webhook 订阅，其实现方式与在 Stripe 或 GitHub 中的实现方式相同。对于成熟的 webhook 模型，需要在 1C 端进行修改 - 订阅事件并在数据更改时发送 HTTP 请求。这可以通过事件订阅、后台作业、配置扩展来实现。我们 WordPress 端的 OnecWebhookHooks 模块接收这些通知并处理它们。在 1C 方面，我们提供配置 Webhooks 发送的处理。是的，这需要在 1C 端进行某些配置，但这是一次性设置，任何有能力的 1C 专家都可以在几个小时内完成。
对于 Webhook 模型无法实现的情况（例如，客户端不想或无法修改 1C），我们有一个后备方案 - OnecStockSync 组件，它按计划运行，但比常规轮询更智能。他没有检查所有产品，而是只要求 1C 更改最后一个周期的产品。 OData支持按修改日期过滤：我们只查询自上次同步以来发生更改的记录。这比完整的搜索有效几个数量级 - 处理的不是两万个产品，而是十到二十个实际上已经发生变化的产品。
但让我告诉你另一件事，看似一件小事，但实际上却省去了很多麻烦——映射表。当您链接两个目录（在 1C 和 WooCommerce 中）时，您需要一种可靠的方法来确定 1C 中的哪个产品对应于网站上的哪个产品。看起来这个任务很简单：我们获取这篇文章，在两个系统中通过它找到产品，然后就完成了。但实际上一切都更加复杂。文章的拼写可能有所不同（空格、大小写、特殊字符）。有些产品可能没有货号。 1C 中的产品可以有多个商品（主要商品和供应商商品）。可能根本没有文章——只有名称和内部代码。
因此，我们制作了一个单独的映射表 - wpaic_1c_map - 存储 1C 产品和 WooCommerce 之间的关系。连接可以通过商品、UUID（1C 中的 Ref_Key）、条形码或手动匹配进行。首次导入时，系统会尝试自动按SKU匹配产品。无法自动映射的可以在管理界面中手动映射。安装映射后，它将永久保存 - 在后续同步期间，系统确切地知道哪个 1C 产品对应于哪个 WooCommerce 产品，并更新它，而无需不必要的搜索和比较。在我们有 19000 个产品的情况下，映射迁移（从在 postmeta 中存储关系的旧插件）需要几分钟，之后每次同步都会顺利进行 - 系统不会“猜测”匹配，而是从表中获取匹配。
现在谈谈乍一看似乎矛盾的事情：导入期间的 SEO 保护。看起来，如果我们从 1C 同步数据，我们就会同步所有内容 - 名称、描述、价格、余额、特征。但实际上这是一个灾难性的错误。 1C 中的产品名称是内部会计名称，通常难以辨认：“合成机油。壳牌喜力 HX8 5W30 A3/B4 4l 罐。”在网站上，同一个名称针对搜索和人类感知进行了优化：“壳牌喜力 HX8 5W-30 发动机油 - 合成，4 升，A3/B4 认证。”如果在每次同步期间，1C 名称覆盖站点名称 - 再见，SEO 优化。告别营销人员所做的所有改善标题的工作。告别由 Google 和 Yandex 索引的 URL slug 中的关键字。
因此，我们的模块具有自定义 update_fields - 同步期间更新的字段列表。默认情况下，仅更新价格和余额 - 真正需要实时更新的内容。标题、描述和slug 受到保护，不被覆盖。如果您也想更新它们，则需要在设置中明确启用此功能。但我们警告您：如果您花时间进行了产品卡片的 SEO 优化，请不要在与 1C 同步时启用标题和描述更新。让会计系统管理它所管理的内容 - 价格和余额，并且网站上的内容仍然处于营销人员的控制之下。
1C 的变化、特征和主要陷阱
一个单独且非常重要的主题是产品变体。在 WooCommerce 中，变体是具有子变体的可变产品，每个子变体都有自己的属性、价格和平衡。典型示例：可选择尺码和颜色的 T 恤。在 1C 中，变体的类似物是项目的特征 - 与产品（或项目类型）相关联并描述执行的特定变体的从属目录。
这就是乐趣的开始。 1C:UT 中的特征结构可能是整个集成中最重要的地方之一。特征可以与特定产品（项目的 Ref_Key）相关联，也可以是整个项目类型（Item_Key 的 Type）所共有的。也就是说，如果您有“机油”类型，并且该类型定义了“体积”特性（1L、4L、5L、20L、208L），则该类型的所有产品都会继承这些特性。但特定产品可能有其自身与类型无关的特征。我们实现了我所说的“双重所有者查找”：导入产品时，系统首先通过产品本身的 Ref_Key 检查特征，然后通过 Item Type_Key 检查特征。这涵盖了这两种情况。
另一个重要细节：1C 中的下级目录 Catalog_CharacteristicsNomenclature 不支持标准 OData 参数 $select 和 $filter。我们通过实验发现了这一点 - 使用 $filter 的请求返回 HTTP 400，并且 1C 文档没有在任何地方对此发出警告。解决方案是完全下载所有特征并在 PHP 端进行过滤。它的性能并不完美，但工作可靠，对我们来说，可靠性比优雅更重要。
我想了很长时间是否值得在面向商业读者的文章中讨论这些技术细微差别。我认为这是值得的——原因很简单。当您选择用于同步 1C 和 WooCommerce 的插件时，系统会告诉您：“我们已与 1C 集成！”但整合则不同。一次集成就可以转移名称和价格。另一种完全适用于特征、变化、多种价格、仓库余额和自定义属性。它们之间的区别在于“我们的网站以某种方式显示来自1C的数据”和“我们的网站完全反映了会计系统的现实，我们可以信任它”之间的区别。
让我告诉您我们在生产中已经发现的另一个陷阱，涉及真实数据和真实客户。导入具有特征的商品时进行重复数据删除。想象一下：在 1C 中有一种产品“Shell Helix HX8 5W-30 Oil”，其容量特征（变化）为：1 升、4 升、20 升。但从历史上看，在 WooCommerce 网站上，该产品并未列为一种可变产品，而是列为三种单独的简单产品：“Shell Helix HX8 5W-30 Oil (1 l.)”、“Shell Helix HX8 5W-30 Oil (4 l.)”、“Shell Helix HX8 5W-30 Oil (20 l.)”。这是一种非常常见的情况 - 许多商店最初将产品列为“平面清单”，没有变化。如果从 1C 导入时，我们创建了一种具有变体的可变产品“Shell Helix HX8 5W-30 Oil”，则网站上将会出现重复项：旧的“扁平”产品和新的可变产品。具有不同的 URL，具有不同的 SEO 权重，购物车中存在潜在冲突。
我们通过初步检查解决了这个问题：在导入具有特征的产品之前，系统会检查网站上是否存在具有相应名称的包装产品。如果找到匹配项，父产品不会作为重复项导入，而是链接到现有职位。这是一件小事，但却可以防止内容历史悠久的网站出现严重问题。
现在让我们谈谈双向交换——很多人忘记的部分。同步不仅仅是“从1C到站点”。这也是“来自1C网站”。当客户在网站上下订单时，该订单必须进入 1C 进行进一步处理 - 开具发票、预订货物、生成货运单据。我们的 OnecOrderHooks 模块拦截 WooCommerce 事件 - 订单创建、状态更改、付款 - 并在 1C 中生成相应的文档。网站订单 = 1C:UT 买家订单。现场付款=收到资金。这使管理人员无需手动传输订单——每天处理 50 个订单需要花费几个小时。
我知道很多人关心安全问题：如果我们为HTTP请求开放1C OData接口，数据库是否会变得脆弱？这是一个合理的担忧，我们会认真对待。对于 OData 连接，将创建一个具有最小权限的单独 1C 用户 - 仅读取同步所需的目录和寄存器。该用户无法更改配置、删除数据或执行任意代码。连接可以通过 IP 进行限制 - 只允许从您的 WordPress 主机的 IP 地址进行访问。所有交换都可以通过 HTTPS 完成，因此数据在传输过程中是加密的。最后，OData 用户具有针对多次失败的身份验证尝试的阻止机制 - 防止密码暴力破解。顺便说一下，我们在实践中遇到过这样的情况：在调试过程中，我们多次输入密码错误，导致 OData 帐户被封锁十五分钟。这虽然令人不快，但有安全好处。
既然我们谈论的是实际的事情，我就谈谈日志记录。这就是专业工具与工艺品的区别。每个同步操作 - 每个对 1C 的请求、每个处理的产品、每个错误 - 都记录在 wpaic_1c_sync_log 表中。在模块的仪表板中，您可以看到完整的历史记录：上次同步是什么时候、处理了多少产品、有多少错误以及哪些产品导致了问题。如果经理打电话说“产品 X 的价格错误” - 您打开日志，找到该产品，查看其上次更新时间、1C 的价格，并了解问题所在。如果没有日志记录，任何集成都是一个黑匣子：数据去向某个地方，来自某个地方，如果出现问题，您只能猜测故障发生在哪个阶段。
我记得在开发的早期阶段之一，我们在没有详细记录的情况下启动了同步，两天后我们发现有 200 个产品的价格为零。事实证明，在 1C 中，这些商品的价格以“零售”价格类型记录在“商品价格”寄存器中，而我们请求“站点零售价格”类型（这就是设置中的名称）。没有所需价格类型记录的 200 个产品的得分为零。如果我们有日志，我们就会看到警告“未找到产品 X 的价格”，并且会在五分钟内（而不是两天内）了解问题。这次事件发生后，我们尽可能详细地记录日志，并对每种异常情况进行警告。现在，系统会对没有价格的产品、没有类别的产品、零余额的产品、映射不一致的产品发出警告 - 关于所有可能成为潜在问题的内容。
首次导入前十五分钟：设置向导
我特别自豪的事情之一就是向导。我思考了很长时间为什么与 1C 的集成被认为是“一项需要程序员的复杂任务”。我得出的结论是，这不是技术复杂性本身的问题，而是如何将该任务呈现给用户的问题。设置 1C 和 WooCommerce 交换的典型说明是一份长达十页的文档，其中包含术语“Infobase 发布 URL”、“HTTP 服务参数”、“设置交换计划”。非 1C 开发人员可以在第二页关闭此说明。
我们创建了一个分步向导，指导用户完成整个设置过程。第一步是输入 1C 服务器地址和凭据。系统检查连接并显示：“连接已建立。基础：贸易管理，版本 11.5.16，组织：LLC“您的公司”。第二步是选择产品目录和价格类型。系统显示1C的可用目录和价格类型，用户选择他需要的。第三步，设置映射：系统自动逐项匹配产品并显示结果。第四步是选择同步字段并设置时间表。第五步是对十种产品进行试运行，以确保一切正常。整个过程需要十到十五分钟。不是十小时，不是三天——十五分钟。当然，前提是您已经在 1C 端配置了 OData 接口。如果不配置的话，1C管理员又要工作半个小时；我们为此提供了分步说明。
你知道我在实践中注意到了什么吗？设置集成时最常见的问题不是技术问题。不是“如何配置 OData”，也不是“如何映射属性”。最常见的问题是：“您确定网站上不会出现任何问题吗？”人们担心集成会覆盖现有数据、破坏目录并删除产品。这是一种可以理解的恐惧 - 许多人在 CommerceML 方面都有过负面经历，在一次不成功的交换之后，他们不得不从备份中恢复数据库。这就是为什么我们采取了多层保护措施。 “仅查看”模式（试运行）- 系统显示将要执行的操作，但不进行更改。对十种产品进行测试导入以确保映射正确。默认情况下禁用防止覆盖 SEO 字段的保护。当然，记录每个操作，以便在发生某些情况时可以回滚。
我经常听到竞争对手说：“我们的插件也做同样的事情。”让我不同意。当您购买“1C 和 WooCommerce 集成插件”时，请仔细查看它的实际用途。它支持 OData，还是仅通过 CommerceML 工作？它是否处理项目特征并创建变体，还是仅导入简单的项目？是否有自动发现属性，还是需要手动注册各个字段的对应关系？错误是如何处理的——它们是默默地被吞掉还是记录了详细信息？有复制保护吗？反向同步是否有效（来自 1C 网站的订单）？所有这些问题都不是“额外的好处”，而是正常融入的基本要求。
你知道这个故事最让我惊讶的是什么吗？公司花费多少时间和金钱来解决技术上解决的问题。 1C OData 接口已经存在很多年了。 WordPress 从第一天起就可以发出 HTTP 请求。 WooCommerce 提供用于创建和更新产品的挂钩。 Action Scheduler解决了大批量的问题。所有的积木都已就位很长时间了 - 您只需正确组装它们即可。但“正确”是关键词。正确意味着考虑 1C 的真实特征（而不是理论特征），处理所有边缘情况（重复、包装、缺失价格），防止破坏性行为并进行详细记录。这正是我们在 COS WP Woo 中所做的。
回到我的朋友，他有一家工业化学品在线商店，我们帮助他从 CommerceML 切换到 OData 集成。花了两天时间：一天在 1C 端设置 OData（他们已经有一名全职 1C 专家），一天在 COS WP Woo 中设置模块。第一次全面进口在一夜之间完成——四千种货物的价格和余额。此后，余额同步开始通过 webhook 进行：1C 的更改意味着网站上的更新只需几秒钟。转型后的第一个月，“卖了不存在的东西”的情况从每周三四次减少到零。完全为零。过去，经理早上要花两个小时检查交易，现在只需花五分钟打开仪表板，确保一切都正常，然后就可以开始工作了。顺便说一句，同一位经理现在正在处理订单 - 这是比两个系统之间的日常手动数据核对更有用、更高效的活动。仅他的工作时间每月就节省了十五个小时左右，这还是一个保守的估计。
我并不是说我们的解决方案是完美的。它有局限性。它与 1C：贸易管理 (1C:UT) 配合使用 - 这是贸易公司最常见的配置。如果您有 1C:Accounting 或其他非标准配置，则需要进行一些修改。 OData接口需要在1C端进行配置和发布——这是一个一次性但必要的操作，需要1C管理员。 Webhook模型需要在1C方面进行改进（发送通知的处理）。最后，对于大型目录（超过一万个产品），第一次完全导入需要时间 - 从三十分钟到几个小时，具体取决于 1C 服务器的速度和数据量。
但所有这些限制都是可以解决的。而且它们比您在 CommerceML 上遇到的问题要小得多：重复、数据丢失、一天的延迟、缺乏反馈、无法传输自定义字段。我见过足够多的项目，可以说通过普通工具进行 OData 集成并不是一种奢侈或“高级选项”。对于任何认真与 1C 合作并希望其网站反映现实而不是过时副本的在线商店来说，这是必要的。
有时在我看来，1C和网站整合的问题根本不是技术问题。这是两个世界之间差距的问题：会计系统的世界（1C 昵称所在的地方）和 Web 开发的世界（“网站开发人员”所在的地方）。每个世界都知道自己的乐器，说着自己的语言，但对对方却知之甚少。 CommerceML 是这些世界之间的桥梁 - 笨重、过时，但双方都可以理解。 OData是新一代的桥梁：更快、更可靠、更灵活，但要求双方愿意向对方迈出一步。我们在 COS WP Woo 中的模块试图使此步骤尽可能简单。向导，他会牵着你的手引导你。自动发现，它将处理属性本身。 SEO 保护可防止您破坏现有功能。详细的日志将显示每次同步期间到底发生了什么。
如果您现在坐着思考：“我有四百种产品，CommerceML 可以处理它们，为什么我需要这一切？” - 我会这样回答。如果您的业务没有增长，如果您没有添加新的销售渠道，如果客户不关心网站上的余额是否是最新的，那么就真的没有必要。但是，如果您计划增长，如果产品目录会增加，如果您需要同时通过多个渠道（网站、市场、社交网络）进行销售并在各处拥有最新数据 - 那么通过 OData 过渡到正常集成就不是“如果”，而是“何时”。最好在开始销售空气和失去客户之前这样做，而不是之后。因为重新获得您向其出售不存在的产品的客户的信任比花费两天时间建立正常的集成要花费更多的费用。
试用 COS WP Woo - 免费 14 天。1C 集成模块包含在所有资费中。安装向导将在十五分钟内引导您从安装插件到首次导入产品。不需要特殊知识 - 如果您拥有 1C：贸易管理和 WooCommerce，一切都会正常进行。如果您有任何疑问，我们的团队将帮助您在 1C 端设置 OData 并进行首次导入。