Сайт и учётная система компании: где хранить цены, остатки и данные заказов

Главный источник выбирают для каждого вида данных

Две программы не могут независимо назначать окончательную цену одной покупки. Интеграция сайта с ERP начинается с распределения ответственности: где ведут товар, цену и доступность, откуда приходит заказ и какая система сообщает исполнение. Разберём интернет-магазин, который принимает покупки на сайте, а учётная система управляет ассортиментом и обработкой заказов. Настройка конкретной платформы здесь не рассматривается.

Не назначайте одну систему главной для всего. Учёт удобно использовать для товарных сведений и коммерческих данных, а сайт — для материала, который видит посетитель: описаний, иллюстраций и структуры страниц. Для заказа первоначальным источником может быть сайт, но дальнейшее состояние изменяет сотрудник в учёте. Если это не разделить, обмен начнёт возвращать в программу её же старые значения, и сотрудники будут объяснять противоречие ручными поправками.

Направления видны на примере онлайн-торговли МоегоСклада: заказы передаются в учёт, а цены и остатки — на площадки. Это иллюстрация общего принципа, а не инструкция внедрения именно этого сервиса. В своей ERP компания составляет такой же перечень по видам сведений и подтверждает его с ответственными сотрудниками до обсуждения способов передачи. Направление важнее общего названия интеграции. Если подрядчик обещает синхронизацию всего сайта без перечня владельцев полей, сотрудники не смогут определить, какое изменение считать окончательным, а исправление цены в одной программе снова будет отменяться данными другой стороны после очередной передачи.

Один товар сохраняет связь после переименования

Название помогает человеку, но плохо связывает две системы. Одинаковая строка может относиться к разным размерам, упаковкам или вариантам товара.

Для обмена требуется устойчивый идентификатор. В документации импорта МоегоСклада UUID обозначает уникальный идентификатор товара. Заказчику не нужно выбирать внутренний формат своей ERP: специалист описывает, какой признак сохраняет связь при смене названия и какой относится к отдельному варианту, чтобы изменение описания не создало новую карточку на сайте.

Артикул можно использовать лишь при принятом правиле его уникальности и постоянства. Если поставщики повторяют коды, а сотрудники редактируют их вручную, одной этой строки недостаточно для автоматического решения. Лучше до запуска составить карту соответствия на небольшом наборе товаров, включая похожие названия и несколько вариантов, чем исправлять дубли после передачи всего каталога.

Старую связь не переиспользуют молча. Если товар снят с продажи, а вместо него добавлен другой, новая запись получает собственный смысл, даже когда отделу хочется сохранить прежний красивый адрес карточки.

Цена в каталоге и цена принятого заказа различаются

Изменение прайс-листа не означает пересчёт всех старых покупок. Каталог сообщает текущее предложение, а заказ хранит условия, которые покупатель уже подтвердил.

В описании импорта в документ МоегоСклада цена позиции документа может браться из переданного столбца «Цена», а не из карточки товара. Этот пример показывает, почему цену принятой покупки нужно обсуждать отдельно от текущего каталога. Если обмен заменяет её новым прайсом после оформления, клиент увидит одну сумму, а сотрудник — другую, хотя оба будут считать свои данные актуальными. Покупка сохраняет принятое предложение. Когда новый прайс приходит после оформления, сайт обновляет каталог для следующих посетителей, а связанная запись заказа получает цену подтверждённого состава, чтобы передача в учёт не превращалась в скрытое изменение суммы, которую человек уже увидел перед покупкой.

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

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

Доступность — не просто число на складе

Физический остаток и количество, доступное новой покупке, могут различаться. Часть товара уже обещана другим клиентам или относится к месту, откуда сайт не продаёт.

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

Определите доступность словами. Например, показывать остатки выбранных складов с учётом действующих резервов, отдельно обозначать товары под заказ и запрещать продажу недоступного варианта. Это условие будущего обмена. Формулу и момент обновления исполнитель согласует с учётом, потому что простое вычитание любого встреченного резерва способно дважды уменьшить количество, если входящий показатель уже его учитывает.

«Склад» в форме документа МоегоСклада выделен отдельно от поля «Организация». Для общей интеграции это полезное напоминание о двух границах: где находится товар и от чьего имени ведётся операция. Если компания работает с несколькими местами хранения или юридическими лицами, в задании прямо называют разрешённые источники данных для сайта.

Заказ проходит между системами без второго создания

Повтор передачи после сбоя — обычное состояние обмена. Покупателю нужен один заказ, даже если техническая отправка повторилась.

В задании закрепите устойчивый номер связи для покупки. Сайт передаёт состав, количество, цену принятия и сведения для исполнения. Учёт сохраняет соответствие со своей записью. Если ответ задержался, повтор находит ту же покупку, а не создаёт вторую, потому что отсутствие подтверждения отправителю ещё не означает отсутствие уже принятой записи у получателя.

Состояние заказа передаётся по смыслу. Внутренняя отметка учёта может описывать подготовку документа, тогда как покупатель ждёт подтверждения сборки или отправления. Поэтому отдельная карта определяет, какие состояния выходят наружу и каким текстом они объясняются. Названия сотрудников и внутренних операций не стоит автоматически показывать клиенту: они не всегда сообщают, что происходит с его покупкой.

В документации МоегоСклада резерв снимается связанной с заказом отгрузкой или розничной продажей. Для заказчика важна именно связь документов. Если интеграция создаст независимую отгрузку без связи с исходной покупкой, часть логики учёта может не получить ожидаемого продолжения, хотя сайт уже покажет отправленный заказ.

Сбой требует известного действия сотрудника

Ночной обмен может завершиться без передачи части товаров. Общая зелёная отметка не объяснит, какая цена осталась старой и какие заказы ещё не попали в работу.

Команда получает сведения о последнем успешном обновлении и списке необработанных объектов. Для каждого расхождения полезны направление, товар или заказ, причина и доступное действие: повторить, исправить данные либо передать специалисту. Если показан только общий текст об ошибке соединения, сотрудник не сможет отличить задержку от потерянной покупки и будет проверять весь учёт вручную. Последний успех хранится отдельно. Когда сегодняшняя попытка завершилась с ошибкой, время её запуска не сообщает, насколько устарели сведения витрины, поэтому сотрудник видит последнюю принятую передачу и объекты, которые остались без обновления после неё.

Ручное исправление также требует правила. Если цену обычно ведут в ERP, временная правка на сайте исчезнет при следующем обновлении, если не предусмотрен отдельный порядок. Лучше исправить источник или явно остановить передачу затронутого поля на время разбора, чем позволить двум сотрудникам поддерживать разные версии с уверенностью, что они устранили проблему.

Две независимые правки вернут расхождение

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

Для приёмки возьмите один товар и одну покупку. Переименуйте товар, измените текущую цену, оформите тестовый заказ, повторите его передачу и проведите связанное исполнение. Затем создайте временный сбой и покажите восстановление. Результат объясняется по карте: связь товара сохранилась, каталог обновился, цена принятия заказа осталась понятной, а повтор не создал вторую покупку. Каждый повтор относится к прежнему заказу.

После этого компания сохраняет карту полей, направления и порядок реакции на сбои. Эти сведения понадобятся при смене сотрудника учёта или исполнителя сайта, поскольку будущий разработчик не узнает из наличия работающего соединения, кто вправе менять цену и почему резерв влияет на доступность. В задачу на интеграцию сайта стоит передать именно эту модель, а уже затем уточнять платформу и способ обмена.