[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f3fsi1jwb2od9y":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":11,"previewImage":11,"headMarkup":12,"lifecycleId":13,"bodyMd":14,"bodyHtml":15},"integratsiya-internet-magazina-s-1s-kakie-dannye-i-pravila-obmena-soglasovat","Интеграция интернет-магазина с 1С: правила обмена",true,"2024-04-18T10:00:00+03:00","2026-09-06T16:09:00.035Z","Статьи","Обмен между интернет-магазином и 1С требует согласованных правил для каталога, цен, остатков и заказов. В статье собраны вопросы, которые фиксируют до настро...","\u002Fcontent-media\u002Farticles\u002Fintegratsiya-internet-magazina-s-1s-kakie-dannye-i-pravila-obmena-soglasovat\u002Fassets\u002Ff0d4d161cbda.webp",[],"lc_f7a29eaa94c4d41d8f023ef4e671cb80","Покупатель оформляет товар, который показан как доступный, а менеджер позже сообщает об отсутствии. Или в карточке указана одна цена, а в учётной системе — другая. Такие расхождения возникают не из-за самого факта обмена, а из-за незафиксированных правил: откуда брать данные, что считать актуальным и кто исправляет ошибки.\n\nИнтеграция интернет-магазина с 1С начинается не с настройки модуля, а с описания данных и сценариев. Один и тот же товар может иметь варианты, разные единицы измерения, остатки по складам, особые условия продажи и неполное описание. Если не учесть это до запуска, автоматический обмен быстрее распространит некорректные сведения.\n\n## Какие данные передавать между интернет-магазином и 1С\n\nСначала составляют перечень объектов обмена. Обычно в него входят товары, группы каталога, характеристики, варианты, изображения, цены, остатки, заказы, покупатели и статусы обработки. Но включать все сущности сразу необязательно: набор зависит от того, какие операции сотрудники выполняют вручную и какие данные должны совпадать в системах.\n\nДля каждого объекта определяют:\n\n- источник данных;\n- получателя;\n- направление обмена;\n- признак создания, изменения или удаления;\n- допустимую задержку обновления;\n- способ проверки результата.\n\nНапример, описание товара может редактироваться на сайте, а артикул и учётная единица — в 1С. В таком случае нельзя безоговорочно перезаписывать карточку товара при каждом обмене: нужно определить поля, которыми управляет каждая сторона.\n\nОтдельно описывают сведения, которые не должны попадать на сайт: внутренние пометки, технические позиции, архивные товары, служебные характеристики и данные для сотрудников.\n\n## Интеграция каталога интернет-магазина с 1С: товары, варианты и свойства\n\nТовар в учётной системе и карточка товара для покупателя не всегда совпадают по структуре. В 1С одна номенклатура может быть представлена несколькими вариантами, а на сайте покупателю требуется выбрать размер, цвет, объём или другую характеристику до добавления в корзину.\n\nДо настройки обмена согласуют:\n\n- что считается товаром, а что вариантом;\n- какие свойства участвуют в выборе варианта;\n- какие характеристики выводятся в карточке и фильтрах;\n- как передаются единицы измерения;\n- какие поля обязательны для публикации;\n- как обрабатываются товары без фотографии, описания или цены.\n\nЕсли у товара нет обязательного свойства, возможны разные правила: не выгружать его, показать без возможности заказа или направить на ручную проверку. Подход выбирают по сценарию продаж. Это поведение нужно зафиксировать до настройки обмена, а не оставлять значение по умолчанию.\n\nТакже проверяют дубли. Товары с одинаковым названием могут быть разными позициями, а одна позиция иногда меняет наименование. Для сопоставления нужен устойчивый идентификатор, а не название, которое редактируется для удобства покупателей.\n\n## Обмен ценами и остатками: откуда брать актуальные значения\n\nЦена и доступность влияют на решение о покупке, поэтому для них недостаточно формулировки «синхронизировать автоматически». Нужно определить, какие именно цены передаются, как они связаны с группами покупателей и что происходит при отсутствии значения.\n\nВопросы для согласования:\n\n- какие виды цен используются в заказе;\n- передаётся ли цена с налогами или без них;\n- есть ли зависимость цены от варианта товара;\n- какие остатки показываются покупателю;\n- требуется ли учитывать резерв;\n- можно ли оформить заказ при нулевом остатке;\n- что делать при временной недоступности обмена.\n\nЕсли в учётной системе ведутся остатки по нескольким складам, сайт не обязан отображать их так же. Для покупателя может быть нужен общий доступный остаток, а для некоторых товаров — только факт наличия. Это правило фиксируют отдельно: суммирование без учёта резервов и перемещений может показать товар доступным ошибочно.\n\n## Передача заказов из интернет-магазина в 1С\n\nЗаказ — это не просто строка с товарами. В обмене могут участвовать состав корзины, контакты покупателя, адрес, способ получения, комментарий, скидка, сумма, статус оплаты и внутренний номер документа. Для каждого поля решают, передаётся ли оно, можно ли его менять после отправки и какое действие выполняется при ошибке.\n\nПолезно описать реальные сценарии:\n\n1. Покупатель оформил заказ, все товары доступны.\n2. Один из товаров закончился до обработки.\n3. Покупатель изменил состав заказа после оформления.\n4. Менеджер заменил товар или скорректировал количество.\n5. Заказ отменён на сайте или в учётной системе.\n6. Один и тот же заказ был отправлен повторно после сбоя.\n\nОсобое внимание уделяют защите от дублей. При повторной отправке система должна распознавать уже созданный заказ по согласованному идентификатору, а не создавать новый документ. Также определяют, какие статусы передаются обратно на сайт и что каждый из них означает для покупателя.\n\n## Правила двустороннего обмена и конфликтов данных\n\nДвусторонний обмен нужен не всегда. Чем больше полей разрешено менять в обеих системах, тем выше риск конфликтов. Если сотрудник одновременно исправил товар в 1С, а контент-менеджер изменил его карточку на сайте, одна из версий может перезаписать другую.\n\nДля каждого поля выбирают одну из моделей:\n\n- данные редактируются только в 1С;\n- данные редактируются только на сайте;\n- изменение допускается с обеих сторон, но есть приоритет;\n- поле не участвует в обмене.\n\nПравило «последнее изменение побеждает» подходит не для всех данных. Оно может быть приемлемо для описания, но рискованно для цены, состава заказа или идентификатора товара. В конфликтных сценариях запись направляют на проверку либо запрещают изменение с одной стороны.\n\nУдаление также требует отдельного решения. Удалённый товар не всегда следует физически удалять на сайте: иногда его нужно скрыть из каталога, сохранить в старых заказах или пометить как недоступный. То же относится к отменённым заказам и архивным категориям.\n\n## Проверка интеграции интернет-магазина с 1С до запуска\n\nПроверять обмен следует на данных, похожих на рабочие. Демонстрационный каталог редко показывает проблемы с длинными названиями, большим числом вариантов, неполными характеристиками и товарами без изображений.\n\nКонтрольный набор может включать:\n\n- товар с одним вариантом и товар с несколькими вариантами;\n- позицию без остатка;\n- товар с временно отсутствующей ценой;\n- товар, который не должен публиковаться;\n- заказ с несколькими товарами;\n- заказ с изменением количества и отменой;\n- повторную передачу одного заказа;\n- ручное изменение данных с обеих сторон.\n\nПроверяют факт передачи и результат в интерфейсе: корректность цены, доступность товара, состав заказа, статус, отсутствие дублей. Для ошибок нужен понятный маршрут: кто видит уведомление, где ищет причину и как повторно запускает обработку после исправления данных.\n\n## Как выбрать способ интеграции интернет-магазина и 1С\n\nВыбор зависит от модели данных и требований к обмену, а не от названия системы. Для простого каталога с односторонней выгрузкой подходят одни механизмы, для заказов с изменениями, резервами, вариантами и несколькими складами — другие.\n\nПодрядчику передают выгрузку или примеры структуры каталога, описание обработки заказа, список статусов, правила работы с остатками и перечень ручных действий сотрудников. Заранее уточняют, как будут сопоставляться товары, фиксироваться ошибки, обрабатываться повторные сообщения и как будет ограничен доступ к служебным данным.\n\nРезультатом согласования должна стать таблица обмена, а не общая формулировка «связать сайт с 1С». В ней видно, какие данные участвуют в процессе, кто отвечает за их достоверность и по каким сценариям проверяют работу после изменений.\n\n## Часто задаваемые вопросы\n### Можно ли выгружать в интернет-магазин весь каталог из 1С?\n\nМожно, если все позиции подготовлены для показа покупателям. Часть номенклатуры может быть служебной, архивной или неполной. Для публикации задают критерии: наличие цены, изображения, обязательных характеристик, признака доступности и разрешения на продажу через сайт.\n\n### Что делать, если цену меняют и на сайте, и в 1С?\n\nНужно определить владельца каждого типа цены. Если изменения допускаются в обеих системах, фиксируют приоритет и порядок разрешения конфликта. Иначе очередной обмен может отменить ручную корректировку.\n\n### Передаются ли отменённые товары из заказа в 1С?\n\nЭто зависит от согласованной модели заказа. Можно передавать обновлённый состав, создавать отдельное изменение или оставлять исходный документ и фиксировать отмену отдельным действием. Выбор проверяют на сценарии, которым пользуются сотрудники при обработке.\n\n### Как избежать повторного создания одного заказа?\n\nДля обмена используют устойчивый идентификатор заказа и правило проверки перед созданием нового документа. Повторная отправка после сбоя должна распознаваться как обновление или подтверждение уже переданной записи, а не как новый заказ.\n\n### Нужно ли синхронизировать статусы заказа?\n\nТолько те статусы, которые нужны покупателю или сотрудникам для дальнейшей обработки. Для каждого статуса определяют источник, допустимый переход и смысл. Внутренние технические этапы не обязательно выводить на сайт.","\u003Cp>Покупатель оформляет товар, который показан как доступный, а менеджер позже сообщает об отсутствии. Или в карточке указана одна цена, а в учётной системе — другая. Такие расхождения возникают не из-за самого факта обмена, а из-за незафиксированных правил: откуда брать данные, что считать актуальным и кто исправляет ошибки.\u003C\u002Fp>\n\u003Cp>Интеграция интернет-магазина с 1С начинается не с настройки модуля, а с описания данных и сценариев. Один и тот же товар может иметь варианты, разные единицы измерения, остатки по складам, особые условия продажи и неполное описание. Если не учесть это до запуска, автоматический обмен быстрее распространит некорректные сведения.\u003C\u002Fp>\n\u003Ch2>Какие данные передавать между интернет-магазином и 1С\u003C\u002Fh2>\n\u003Cp>Сначала составляют перечень объектов обмена. Обычно в него входят товары, группы каталога, характеристики, варианты, изображения, цены, остатки, заказы, покупатели и статусы обработки. Но включать все сущности сразу необязательно: набор зависит от того, какие операции сотрудники выполняют вручную и какие данные должны совпадать в системах.\u003C\u002Fp>\n\u003Cp>Для каждого объекта определяют:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>источник данных;\u003C\u002Fli>\n\u003Cli>получателя;\u003C\u002Fli>\n\u003Cli>направление обмена;\u003C\u002Fli>\n\u003Cli>признак создания, изменения или удаления;\u003C\u002Fli>\n\u003Cli>допустимую задержку обновления;\u003C\u002Fli>\n\u003Cli>способ проверки результата.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Например, описание товара может редактироваться на сайте, а артикул и учётная единица — в 1С. В таком случае нельзя безоговорочно перезаписывать карточку товара при каждом обмене: нужно определить поля, которыми управляет каждая сторона.\u003C\u002Fp>\n\u003Cp>Отдельно описывают сведения, которые не должны попадать на сайт: внутренние пометки, технические позиции, архивные товары, служебные характеристики и данные для сотрудников.\u003C\u002Fp>\n\u003Ch2>Интеграция каталога интернет-магазина с 1С: товары, варианты и свойства\u003C\u002Fh2>\n\u003Cp>Товар в учётной системе и карточка товара для покупателя не всегда совпадают по структуре. В 1С одна номенклатура может быть представлена несколькими вариантами, а на сайте покупателю требуется выбрать размер, цвет, объём или другую характеристику до добавления в корзину.\u003C\u002Fp>\n\u003Cp>До настройки обмена согласуют:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>что считается товаром, а что вариантом;\u003C\u002Fli>\n\u003Cli>какие свойства участвуют в выборе варианта;\u003C\u002Fli>\n\u003Cli>какие характеристики выводятся в карточке и фильтрах;\u003C\u002Fli>\n\u003Cli>как передаются единицы измерения;\u003C\u002Fli>\n\u003Cli>какие поля обязательны для публикации;\u003C\u002Fli>\n\u003Cli>как обрабатываются товары без фотографии, описания или цены.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Если у товара нет обязательного свойства, возможны разные правила: не выгружать его, показать без возможности заказа или направить на ручную проверку. Подход выбирают по сценарию продаж. Это поведение нужно зафиксировать до настройки обмена, а не оставлять значение по умолчанию.\u003C\u002Fp>\n\u003Cp>Также проверяют дубли. Товары с одинаковым названием могут быть разными позициями, а одна позиция иногда меняет наименование. Для сопоставления нужен устойчивый идентификатор, а не название, которое редактируется для удобства покупателей.\u003C\u002Fp>\n\u003Ch2>Обмен ценами и остатками: откуда брать актуальные значения\u003C\u002Fh2>\n\u003Cp>Цена и доступность влияют на решение о покупке, поэтому для них недостаточно формулировки «синхронизировать автоматически». Нужно определить, какие именно цены передаются, как они связаны с группами покупателей и что происходит при отсутствии значения.\u003C\u002Fp>\n\u003Cp>Вопросы для согласования:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>какие виды цен используются в заказе;\u003C\u002Fli>\n\u003Cli>передаётся ли цена с налогами или без них;\u003C\u002Fli>\n\u003Cli>есть ли зависимость цены от варианта товара;\u003C\u002Fli>\n\u003Cli>какие остатки показываются покупателю;\u003C\u002Fli>\n\u003Cli>требуется ли учитывать резерв;\u003C\u002Fli>\n\u003Cli>можно ли оформить заказ при нулевом остатке;\u003C\u002Fli>\n\u003Cli>что делать при временной недоступности обмена.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Если в учётной системе ведутся остатки по нескольким складам, сайт не обязан отображать их так же. Для покупателя может быть нужен общий доступный остаток, а для некоторых товаров — только факт наличия. Это правило фиксируют отдельно: суммирование без учёта резервов и перемещений может показать товар доступным ошибочно.\u003C\u002Fp>\n\u003Ch2>Передача заказов из интернет-магазина в 1С\u003C\u002Fh2>\n\u003Cp>Заказ — это не просто строка с товарами. В обмене могут участвовать состав корзины, контакты покупателя, адрес, способ получения, комментарий, скидка, сумма, статус оплаты и внутренний номер документа. Для каждого поля решают, передаётся ли оно, можно ли его менять после отправки и какое действие выполняется при ошибке.\u003C\u002Fp>\n\u003Cp>Полезно описать реальные сценарии:\u003C\u002Fp>\n\u003Col>\n\u003Cli>Покупатель оформил заказ, все товары доступны.\u003C\u002Fli>\n\u003Cli>Один из товаров закончился до обработки.\u003C\u002Fli>\n\u003Cli>Покупатель изменил состав заказа после оформления.\u003C\u002Fli>\n\u003Cli>Менеджер заменил товар или скорректировал количество.\u003C\u002Fli>\n\u003Cli>Заказ отменён на сайте или в учётной системе.\u003C\u002Fli>\n\u003Cli>Один и тот же заказ был отправлен повторно после сбоя.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Особое внимание уделяют защите от дублей. При повторной отправке система должна распознавать уже созданный заказ по согласованному идентификатору, а не создавать новый документ. Также определяют, какие статусы передаются обратно на сайт и что каждый из них означает для покупателя.\u003C\u002Fp>\n\u003Ch2>Правила двустороннего обмена и конфликтов данных\u003C\u002Fh2>\n\u003Cp>Двусторонний обмен нужен не всегда. Чем больше полей разрешено менять в обеих системах, тем выше риск конфликтов. Если сотрудник одновременно исправил товар в 1С, а контент-менеджер изменил его карточку на сайте, одна из версий может перезаписать другую.\u003C\u002Fp>\n\u003Cp>Для каждого поля выбирают одну из моделей:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>данные редактируются только в 1С;\u003C\u002Fli>\n\u003Cli>данные редактируются только на сайте;\u003C\u002Fli>\n\u003Cli>изменение допускается с обеих сторон, но есть приоритет;\u003C\u002Fli>\n\u003Cli>поле не участвует в обмене.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Правило «последнее изменение побеждает» подходит не для всех данных. Оно может быть приемлемо для описания, но рискованно для цены, состава заказа или идентификатора товара. В конфликтных сценариях запись направляют на проверку либо запрещают изменение с одной стороны.\u003C\u002Fp>\n\u003Cp>Удаление также требует отдельного решения. Удалённый товар не всегда следует физически удалять на сайте: иногда его нужно скрыть из каталога, сохранить в старых заказах или пометить как недоступный. То же относится к отменённым заказам и архивным категориям.\u003C\u002Fp>\n\u003Ch2>Проверка интеграции интернет-магазина с 1С до запуска\u003C\u002Fh2>\n\u003Cp>Проверять обмен следует на данных, похожих на рабочие. Демонстрационный каталог редко показывает проблемы с длинными названиями, большим числом вариантов, неполными характеристиками и товарами без изображений.\u003C\u002Fp>\n\u003Cp>Контрольный набор может включать:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>товар с одним вариантом и товар с несколькими вариантами;\u003C\u002Fli>\n\u003Cli>позицию без остатка;\u003C\u002Fli>\n\u003Cli>товар с временно отсутствующей ценой;\u003C\u002Fli>\n\u003Cli>товар, который не должен публиковаться;\u003C\u002Fli>\n\u003Cli>заказ с несколькими товарами;\u003C\u002Fli>\n\u003Cli>заказ с изменением количества и отменой;\u003C\u002Fli>\n\u003Cli>повторную передачу одного заказа;\u003C\u002Fli>\n\u003Cli>ручное изменение данных с обеих сторон.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Проверяют факт передачи и результат в интерфейсе: корректность цены, доступность товара, состав заказа, статус, отсутствие дублей. Для ошибок нужен понятный маршрут: кто видит уведомление, где ищет причину и как повторно запускает обработку после исправления данных.\u003C\u002Fp>\n\u003Ch2>Как выбрать способ интеграции интернет-магазина и 1С\u003C\u002Fh2>\n\u003Cp>Выбор зависит от модели данных и требований к обмену, а не от названия системы. Для простого каталога с односторонней выгрузкой подходят одни механизмы, для заказов с изменениями, резервами, вариантами и несколькими складами — другие.\u003C\u002Fp>\n\u003Cp>Подрядчику передают выгрузку или примеры структуры каталога, описание обработки заказа, список статусов, правила работы с остатками и перечень ручных действий сотрудников. Заранее уточняют, как будут сопоставляться товары, фиксироваться ошибки, обрабатываться повторные сообщения и как будет ограничен доступ к служебным данным.\u003C\u002Fp>\n\u003Cp>Результатом согласования должна стать таблица обмена, а не общая формулировка «связать сайт с 1С». В ней видно, какие данные участвуют в процессе, кто отвечает за их достоверность и по каким сценариям проверяют работу после изменений.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Можно ли выгружать в интернет-магазин весь каталог из 1С?\u003C\u002Fh3>\n\u003Cp>Можно, если все позиции подготовлены для показа покупателям. Часть номенклатуры может быть служебной, архивной или неполной. Для публикации задают критерии: наличие цены, изображения, обязательных характеристик, признака доступности и разрешения на продажу через сайт.\u003C\u002Fp>\n\u003Ch3>Что делать, если цену меняют и на сайте, и в 1С?\u003C\u002Fh3>\n\u003Cp>Нужно определить владельца каждого типа цены. Если изменения допускаются в обеих системах, фиксируют приоритет и порядок разрешения конфликта. Иначе очередной обмен может отменить ручную корректировку.\u003C\u002Fp>\n\u003Ch3>Передаются ли отменённые товары из заказа в 1С?\u003C\u002Fh3>\n\u003Cp>Это зависит от согласованной модели заказа. Можно передавать обновлённый состав, создавать отдельное изменение или оставлять исходный документ и фиксировать отмену отдельным действием. Выбор проверяют на сценарии, которым пользуются сотрудники при обработке.\u003C\u002Fp>\n\u003Ch3>Как избежать повторного создания одного заказа?\u003C\u002Fh3>\n\u003Cp>Для обмена используют устойчивый идентификатор заказа и правило проверки перед созданием нового документа. Повторная отправка после сбоя должна распознаваться как обновление или подтверждение уже переданной записи, а не как новый заказ.\u003C\u002Fp>\n\u003Ch3>Нужно ли синхронизировать статусы заказа?\u003C\u002Fh3>\n\u003Cp>Только те статусы, которые нужны покупателю или сотрудникам для дальнейшей обработки. Для каждого статуса определяют источник, допустимый переход и смысл. Внутренние технические этапы не обязательно выводить на сайт.\u003C\u002Fp>\n"]