Остатки сайта отстают
Покупатель заказывает позицию, которую уже продали или зарезервировали в другом канале.
На складе товар закончился, а сайт продолжает продавать. Заказ появился в магазине, но сотрудник переносит его вручную. Настроим обмен с МойСклад по согласованным источникам и правилам обновления.

Покупатель заказывает позицию, которую уже продали или зарезервировали в другом канале.
Полное обновление товара заменяет тексты и изображения, которыми на сайте занимается редактор.
Сотрудник ищет соответствия товаров и клиентов при переносе в учётную систему.
Укажем источники цен, остатков, описаний и полей заказа, чтобы обновления не конфликтовали.
Определим устойчивые идентификаторы товаров, вариантов и заказов между системами.
Предусмотрим журнал, согласованные повторы и проверку изменённых данных.
Посмотрите последние проекты QuickLanding и работу с каталогами. Интеграцию МойСклад оценим по вашим данным и действиям сотрудников.

Интернет-магазин магнитов с разными сценариями для покупателя и компании. Каталог, условия заказа и направление изготовления помогают выбрать товар или обсудить нестандартную задачу.

Продуктовый сайт платформы интернет-магазинов. Демонстрация, шаблоны, возможности и инструкции помогают владельцу бизнеса изучить решение до обсуждения своего магазина.

Сайт CRM-продукта, который помогает изучить систему до обсуждения внедрения. Возможности, отраслевые решения и интеграции связываются с задачами работы с клиентами.
Интеграция сайта с МойСкладНачнём с нескольких товаров и рабочего заказа. Определим идентификаторы, нужные поля и направления обмена, затем подготовим оценку подключения.
Контрольные записи сопоставляются по согласованным идентификаторам.
Передаём утверждённое значение по нужной схеме, без догадки о процессе склада.
Обновление учитывает поля, которыми управляет редактор.
Смотрим несколько товаров, вариантов и заказ.
Определяем владельцев полей и нужные обновления.
Подключаем выбранные операции и связь записей.
Сверяем первый запуск, обновление и повтор.
Разработка стоит 2 900 ₽/час. Оценка зависит от выбранных данных, сопоставления, направлений обмена и текущей интеграции магазина.
Разделяем ответственность систем по каждому виду данных. Затем определяем идентификаторы, частоту обновления и действия при расхождениях.
Количество на складе и доступное к продаже значение могут различаться. Уточняем склады, резервы и правила магазина. Возможности работы с данными проверяем по API МойСклад.
Например, редактор улучшает описание на сайте, а кладовщик корректирует остаток в учётной системе. Обе правки нужны, и они не должны конкурировать. Указываем владельца каждого поля и рассматриваем новые карточки отдельно от существующих: первоначальное заполнение и регулярное обновление могут использовать разные правила.

Цена может приходить из учётной системы, а описание оставаться на сайте. Составляем таблицу ответственности. Переносим только согласованные значения, не заменяя всю карточку одним запросом.
Разбираем варианты, комплекты и повторяющиеся обозначения. Выбираем устойчивую связь записей и порядок для новых товаров. Неоднозначные совпадения требуют проверки.
Согласуем момент передачи, клиента, позиции и статусы. Отдельно разбираем изменение количества, отмену и повтор отправки уже созданного заказа.
Частоту подбираем по объёму и ограничениям API. Предусматриваем сверку после сбоев. Общие правила двустороннего обмена можно выделить в синхронизацию.
Для проверки выбираем товар с вариантами, позицию без остатка и заказ с изменённым количеством. Сверяем данные до и после обмена, включая защищённые поля сайта. Если обновление прервалось, журнал должен показать завершённые действия и место остановки, чтобы повтор не превратил восстановление в дополнительную продажу.
Работа стоит 2 900 ₽/час. Влияют склады, виды цен, объём каталога и направление обмена. Доступность функций аккаунта проверяем перед разработкой.

Владимир Николаев разберёт техническую связь с МойСклад. Зафиксируем, какая система отвечает за каждое поле, и проверим изменения на согласованной выборке.
На вопросы отвечает Владимир Николаев.
Да. Ограничим состав обмена нужными полями и сохраним данные, которыми управляют на сайте.
Если они принадлежат сайту, исключим их из обновления. Это правило фиксируем отдельно от остальных полей каталога.
Да, после определения доступного к продаже количества и правил выбора склада для заказа.
Проверим существующие идентификаторы и варианты. Для несовпадений подготовим список, который нельзя безопасно сопоставить автоматически.
Частоту выбираем по процессу и возможностям API. Для важных данных можно согласовать более частую проверку и дополнительную сверку.
Сохраним связь идентификаторов и проверим повторную передачу. Правила изменения уже созданного заказа зададим отдельно.

Менеджер обновил товар на сайте, а следующая выгрузка вернула старое описание. Такие ошибки начинаются с неясных правил обмена. Разберём вашу конфигурацию и согласуем, какие данные ведутся в 1С, какие на сайте и что должно происходить при обновлении.

Две системы меняют одну запись, и последнее обновление стирает полезную правку. Настроим обмен с понятными источниками: что можно обновлять, как сопоставлять записи и что делать при конфликте.

Таблица выглядит заполненной, но один артикул записан тремя способами, а в числовой колонке перемешаны единицы. Подготовим данные к импорту или анализу с понятными правилами и отчётом по изменениям.
Покажите товары, склады и путь заказа. Согласуем состав обмена и поля, которые нельзя перезаписывать.