[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f9sa9g3d266bx":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-uchetnoy-sistemoy-kak-podgotovit-dannye-k-obmenu","Интеграция интернет-магазина с учётной системой",true,"2024-04-27T10:00:00+03:00","2026-09-06T16:09:02.309Z","Статьи","Статья о подготовке данных к обмену между интернет-магазином и учётной системой. Рассмотрены источники данных, идентификаторы, статусы заказов и обработка ош...","\u002Fcontent-media\u002Farticles\u002Fintegratsiya-internet-magazina-s-uchetnoy-sistemoy-kak-podgotovit-dannye-k-obmenu\u002Fassets\u002Fbf41ab034e70.webp",[],"lc_6316594a4cd60a626d4a6233e4aa9582","Покупатель оформил заказ, а менеджер видит его в учётной системе только после ручной проверки. В каталоге остаётся товар, которого уже нет в наличии. Цена изменилась в рабочей базе, но на витрине отображается прежнее значение. Такие ситуации редко решаются одной настройкой обмена: причина обычно лежит в данных, правилах их обновления и неописанных исключениях.\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\nДо настройки обмена готовят примеры: обычный товар, товар с вариантами, набор, позицию без изображения, временно недоступный товар и товар с неполными характеристиками. Для каждого примера описывают ожидаемый результат на сайте и в заказе.\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### Можно ли передавать на сайт только остатки и цены?\n\nДа, если каталог ведётся на сайте, а правила разделения ответственности зафиксированы. При этом товар в обеих системах должен надёжно сопоставляться. Иначе обновление остатка может попасть не в ту карточку или не выполниться без понятного сигнала.\n\n### Что делать, если данные на сайте и в учётной системе различаются?\n\nСначала установите источник для конкретного поля. Затем проверьте журнал обмена, идентификаторы и момент последнего изменения. Ручное исправление без поиска причины может временно скрыть проблему, но следующая выгрузка повторит расхождение.\n\n### Нужно ли передавать все статусы заказа?\n\nНет. Передают только статусы с согласованным значением для сайта и учётной системы. Если внутренний этап не должен быть виден покупателю, его оставляют отдельным состоянием без обратной передачи на витрину.\n\n### Какие тесты провести перед запуском обмена?\n\nПроверьте создание и обновление товара, изменение цены и остатка, варианты товара, удалённую или недоступную позицию, повторную передачу, новый заказ, отмену и изменение состава заказа. Для каждого теста заранее запишите ожидаемый результат в обеих системах.","\u003Cp>Покупатель оформил заказ, а менеджер видит его в учётной системе только после ручной проверки. В каталоге остаётся товар, которого уже нет в наличии. Цена изменилась в рабочей базе, но на витрине отображается прежнее значение. Такие ситуации редко решаются одной настройкой обмена: причина обычно лежит в данных, правилах их обновления и неописанных исключениях.\u003C\u002Fp>\n\u003Cp>Интеграция интернет-магазина с учётной системой начинается не с выбора модуля или формата файлов. Сначала определяют источник для каждого типа данных, состав передачи и способ обнаружить ошибку до того, как она повлияет на заказ.\u003C\u002Fp>\n\u003Ch2>Какие данные передавать между интернет-магазином и учётной системой\u003C\u002Fh2>\n\u003Cp>Не все сведения должны передаваться в обе стороны. Каталог, остатки, цены, заказы, статусы, покупатели, скидки и документы — разные сущности с разными правилами изменения.\u003C\u002Fp>\n\u003Cp>Для каждого объекта составляют таблицу: поле, источник, получатель, направление передачи, периодичность обновления и ответственный за корректность. Например, наименование товара может поступать из учётной системы, а описание для покупателя — редактироваться на сайте. Без такого разделения очередная выгрузка может заменить подготовленный текст техническим названием или пустым значением.\u003C\u002Fp>\n\u003Cp>Отдельно фиксируют состав товарной карточки: артикул, варианты, единицы измерения, изображения, характеристики, цену и доступность к заказу. Поле может существовать в исходной системе, но не иметь назначения на сайте. Передавать его без сценария использования не стоит: лишние данные усложняют проверку и разбор ошибок.\u003C\u002Fp>\n\u003Ch2>Источник данных для каталога, цен и остатков\u003C\u002Fh2>\n\u003Cp>У одного товара может быть несколько источников данных. Учётная система хранит номенклатуру и остатки, сайт — тексты, фотографии и структуру разделов, сотрудник вручную уточняет отдельные условия продажи. Такая схема работает, когда правила описаны до настройки обмена.\u003C\u002Fp>\n\u003Cp>Нужно определить, что произойдёт при одновременном изменении карточки на сайте и в учётной системе. Можно ли создавать товар только на сайте? Должна ли нулевая доступность скрывать позицию, запрещать оформление или запускать другой сценарий? Как обрабатываются товары под заказ, комплекты и варианты одного товара?\u003C\u002Fp>\n\u003Cp>Для цен определяют не только поле-источник, но и контекст применения. Если значение зависит от варианта, количества, региона, склада или статуса покупателя, это отражают в правилах передачи. Иначе на сайт может попасть технически корректное значение, которое не соответствует сценарию покупки.\u003C\u002Fp>\n\u003Ch2>Идентификаторы товаров и проблема дублей\u003C\u002Fh2>\n\u003Cp>Наименование товара не подходит для сопоставления: его меняют, сокращают, переводят и дополняют характеристиками. Артикул тоже не всегда уникален: один код иногда используют для группы вариантов, комплекта или позиций разных поставщиков.\u003C\u002Fp>\n\u003Cp>Для обмена нужен устойчивый идентификатор, одинаково понятный обеим системам. Его выбирают отдельно для товара, варианта, раздела, покупателя и заказа. В документации проекта фиксируют место хранения идентификатора, порядок его создания и возможность изменения.\u003C\u002Fp>\n\u003Cp>Отдельного правила требуют дубли. Если товар удалили, а затем завели заново с тем же названием, система не должна считать его прежней позицией без проверки. То же относится к покупателям: телефон, почта и имя могут быть заполнены неполно или записаны в разном формате. Правило объединения записей задают явно, иначе расхождения будут выглядеть случайными.\u003C\u002Fp>\n\u003Ch2>Подготовка структуры каталога к обмену\u003C\u002Fh2>\n\u003Cp>Структуру в учётной системе часто создают для внутренней работы: по поставщикам, направлениям закупки или группам хранения. Покупатель ищет товар иначе — по назначению, характеристикам, совместимости или бренду. Копирование внутреннего классификатора на сайт без проверки может сделать каталог неудобным, а правила выгрузки — хрупкими.\u003C\u002Fp>\n\u003Cp>До настройки обмена готовят примеры: обычный товар, товар с вариантами, набор, позицию без изображения, временно недоступный товар и товар с неполными характеристиками. Для каждого примера описывают ожидаемый результат на сайте и в заказе.\u003C\u002Fp>\n\u003Cp>Если для сайта используется «1С-Битрикс: Управление сайтом», правила обмена описывают применительно к структуре каталога, карточкам и отображению данных на витрине. Внутренние процессы сотрудников рассматривают отдельно от модели данных сайта.\u003C\u002Fp>\n\u003Ch2>Обмен заказами: состав, статусы и изменения после оформления\u003C\u002Fh2>\n\u003Cp>Передача заказа не ограничивается номером, списком товаров и контактами покупателя. Нужно согласовать, какие сведения уходят в учётную систему: состав заказа, вариант доставки, комментарий, промокод, стоимость услуг, данные получателя и параметры оплаты. Для каждого поля определяют обязательность и сценарий для незаполненного значения.\u003C\u002Fp>\n\u003Cp>Статусы требуют отдельной схемы сопоставления. Одно название может обозначать разные действия: заказ принят, подтверждён сотрудником, собран, передан в доставку или отменён. Обмен должен передавать согласованное состояние и понятное действие для покупателя и оператора.\u003C\u002Fp>\n\u003Cp>Не меньше вопросов возникает после оформления. Покупатель может отменить заказ, менеджер — заменить товар, склад — подтвердить отсутствие части позиций. Заранее определяют, кто изменяет состав, какие сведения возвращаются на сайт и как фиксируется расхождение между заказом в интернет-магазине и документом в учётной системе.\u003C\u002Fp>\n\u003Ch2>Ошибки обмена и контроль данных\u003C\u002Fh2>\n\u003Cp>При обмене возникают ситуации с недоступностью внешней системы, неверным форматом поля, отсутствующим товаром или правами доступа. У каждой ошибки должен быть владелец. В проекте определяют, где появляется сообщение о сбое, кто его видит, какие данные нужны для разбора и какие действия допустимы вручную.\u003C\u002Fp>\n\u003Cp>Разделите ошибки на две группы. Первая не позволяет передать объект: например, у товара нет обязательного идентификатора. Вторая допускает передачу, но требует проверки: не пришло изображение, не заполнена дополнительная характеристика, не удалось сопоставить статус. Для каждой группы нужен свой сценарий, а не общая формулировка «исправить при необходимости».\u003C\u002Fp>\n\u003Cp>Проверку проводят на данных, похожих на рабочие: с длинными названиями, вариантами, отменами, пустыми полями и повторной отправкой одного заказа. Результаты фиксируют списком: сценарий, ожидаемое поведение, фактическое поведение, ответственный и решение.\u003C\u002Fp>\n\u003Ch2>Вопросы к подрядчику перед интеграцией учётной системы с сайтом\u003C\u002Fh2>\n\u003Cp>Оцените, объясняет ли исполнитель состав объектов, правила сопоставления, обработку повторных передач и порядок разбора ошибок. Ответы должны показывать, какие данные участвуют в обмене, где хранятся правила и кто отвечает за разбор сбоев.\u003C\u002Fp>\n\u003Cp>Стоит запросить перечень предположений: какие поля уже есть в учётной системе, какие права доступа потребуются, кто предоставит тестовые данные и какие сценарии останутся ручными. Неопределённость сама по себе не мешает работе. Проблема появляется, когда её скрывают за общей формулировкой «настроить интеграцию».\u003C\u002Fp>\n\u003Cp>Граница работ тоже должна быть наблюдаемой. Настройка передачи каталога, подготовка карточек, исправление исходных данных и ежедневный контроль обмена — разные задачи. Их не стоит объединять в одну операцию только потому, что все они относятся к каталогу.\u003C\u002Fp>\n\u003Ch2>Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3>Как понять, готова ли учётная система к обмену с интернет-магазином?\u003C\u002Fh3>\n\u003Cp>Проверьте не название программы, а данные и правила работы с ними: есть ли устойчивые идентификаторы, заполнены ли обязательные поля, различаются ли товары и варианты, кто меняет цены и остатки. Подготовьте несколько реальных примеров и проследите путь каждого поля до сайта и обратно.\u003C\u002Fp>\n\u003Ch3>Можно ли передавать на сайт только остатки и цены?\u003C\u002Fh3>\n\u003Cp>Да, если каталог ведётся на сайте, а правила разделения ответственности зафиксированы. При этом товар в обеих системах должен надёжно сопоставляться. Иначе обновление остатка может попасть не в ту карточку или не выполниться без понятного сигнала.\u003C\u002Fp>\n\u003Ch3>Что делать, если данные на сайте и в учётной системе различаются?\u003C\u002Fh3>\n\u003Cp>Сначала установите источник для конкретного поля. Затем проверьте журнал обмена, идентификаторы и момент последнего изменения. Ручное исправление без поиска причины может временно скрыть проблему, но следующая выгрузка повторит расхождение.\u003C\u002Fp>\n\u003Ch3>Нужно ли передавать все статусы заказа?\u003C\u002Fh3>\n\u003Cp>Нет. Передают только статусы с согласованным значением для сайта и учётной системы. Если внутренний этап не должен быть виден покупателю, его оставляют отдельным состоянием без обратной передачи на витрину.\u003C\u002Fp>\n\u003Ch3>Какие тесты провести перед запуском обмена?\u003C\u002Fh3>\n\u003Cp>Проверьте создание и обновление товара, изменение цены и остатка, варианты товара, удалённую или недоступную позицию, повторную передачу, новый заказ, отмену и изменение состава заказа. Для каждого теста заранее запишите ожидаемый результат в обеих системах.\u003C\u002Fp>\n"]