Стоит ли выбирать 1С:УТ только ради сайта?
Нужна ли 1С:Управление торговлей, если компания собирается открыть интернет-магазин? Это программа для оперативного и управленческого учёта торговых операций: закупок, запасов, продаж и расчётов. Выбирать её разумно по устройству торговли, а связь с сайтом планировать как отдельную часть работы.
Рассмотрим оптово-розничную торговлю со складом и интернет-магазином. Сотрудники принимают заказы по нескольким каналам, а покупатель на сайте видит часть общего ассортимента. Главный вопрос здесь — где ведутся достоверные сведения о товаре и доступном количестве. Если разные сотрудники независимо меняют остатки в таблице и на сайте, установка новой программы оставит прежний спор о данных, пока компания не назначит место учёта и правила передачи изменений между системами, которыми она пользуется каждый день.
Программа отвечает за торговые операции
В описании 1С:УТ перечислены оперативный учёт и планирование торговли. Для руководителя это означает возможность обсуждать закупку, движение товара и исполнение заказа на общих данных. Конкретный состав функций подбирают под работу компании: ненужные возможности можно скрывать функциональными опциями, чтобы сотрудники не разбирали лишние поля ради простой отгрузки.
Если требуется только небольшая витрина с редкими заказами, сначала оцените, окупится ли отдельная торговая система организационно: кто будет вести справочники, оформлять операции и разбирать ошибки. Выбор более простого учёта может быть разумнее, пока сложность торговли не выросла, а запуск УТ без сотрудников и правил создаст ещё одно место, куда переносят данные вручную.
Как отделить УТ от бухгалтерии и CRM
В УТ можно вести работу с клиентами, но выбор CRM определяется способом продаж: когда продавцам нужны общая переписка, задачи по обращениям и отдельная воронка, эти потребности стоит сравнить с возможностями выбранных продуктов. Два инструмента допустимы, если заранее определено, где редактируют контакт, заказ и результат разговора. Иначе одинаковые записи начнут расходиться, а менеджеры будут выбирать удобную версию вместо достоверной.
1С описывает передачу данных в «1С:Бухгалтерию 8». Поэтому торговый учёт и регламентированный учёт следует обсуждать вместе с бухгалтером, но не объединять в одну неопределённую задачу «всё будет в 1С». Название фирмы-разработчика не объясняет, в какой программе сотрудник оформляет операцию и кто отвечает за итоговый документ. Одинаковые названия мешают договориться. Лучше записать название продукта полностью и связать его с действиями ответственного сотрудника, чтобы в смете внедрения не потерялась работа по обмену с бухгалтерией.
По каким признакам УТ подходит торговле
Потребность в программе заметнее по операциям, чем по обороту. Компания может продавать немного дорогих товаров и иметь сложные условия поставки, а может обрабатывать много простых заказов. Начните с проблемных операций. Их описание связывает выбор с конкретной работой, а не с впечатлением, что крупной компании положена большая программа.
Запасы и склады
Складской раздел продукта поддерживает учёт на нескольких складах. Это существенно для сайта: наличие на удалённом складе может означать другой срок получения, чем наличие в точке выдачи. Показывать одно общее число удобно только тогда, когда оно соответствует обещанию покупателю, а перемещение товара не скрывает дополнительное ожидание.
В том же описании названы перемещения товаров и инвентаризация, во время которой сотрудники находят расхождения между записями и фактическим наличием, исправляют учёт и разбирают причины потерь. Интернет-магазину полезен уже исправленный доступный остаток, а не любой показатель из учётной базы. Название передаваемого количества исполнитель объясняет на товаре, который числится на складе, но зарезервирован под другой заказ: именно здесь видна разница между наличием вообще и возможностью обещать покупку новому человеку.
Цены и условия продажи
Для разных покупателей могут действовать разные цены. В описании оптовых продаж названы виды цен и соглашения об условиях продаж. На сайте требуется решить, кто увидит конкретную цену: любой посетитель, авторизованный оптовик или только менеджер. Автоматическая выгрузка всех цен без правила показа может раскрыть внутренние условия, которые компания предназначала определённому кругу клиентов.
Полезнее начать с одной публичной цены, чем сразу включать сложные персональные условия, которые сотрудники не смогут объяснить, а отдельный оптовый режим добавить после описания покупателя, скидки и момента пересчёта заказа. Тогда разработчик сможет показать ожидаемое поведение, а руководитель поймёт, какие данные влияют на итоговую сумму.
Какие данные нужны магазину
Фактическое наличие
Что учтено на складах компании.
Резерв
Какая часть уже предназначена для других заказов.
Доступно к продаже
Что можно предложить новому покупателю по выбранным правилам.
Что именно связывают с интернет-магазином
Товар движется из учёта в каталог, заказ с сайта поступает в торговую программу, а сведения о его обработке могут возвращаться покупателю — обмен соединяет несколько потоков данных. Для каждого потока нужен свой ответ о составе, направлении и частоте передачи, поскольку успешное обновление картинки ничего не говорит о получении оплаты или резерве товара.
Содержание каталога
Формат CommerceML 2 назван в описании интеграции 1С-Битрикс. Он описывает коммерческие данные в XML-сообщениях. Заказчику не требуется читать такие файлы, но полезно знать название формата и потребовать подтверждения совместимости конкретных версий программы, модуля и сайта. Даже при поддержке формата нужно отдельно назвать поле, которое получит витрина.
В задании удобно отдельно назвать наименование, артикул, вариант товара, изображение, цену и доступное количество, а описания для покупателей иногда редактировать на сайте, потому что внутреннее складское название слишком короткое или непонятное. В таком случае сохраняйте за сайтом право на эти тексты: полная загрузка каталога не должна стирать работу редактора при каждом сеансе, когда кладовщик меняет остаток.
Заказ и его изменения
В описании интеграции предусмотрен обмен по расписанию. Поэтому заказ при таком способе не всегда появляется в базе в ту же секунду, когда человек нажал кнопку на сайте, а частоту сеансов определяют отдельно. Для небольшого потока заказов приемлем периодический обмен, если менеджер видит обращение вовремя и не обещает моментальную отгрузку до его обработки.
Для товара, который быстро заканчивается, выбирайте более частое обновление доступности или другой способ подтверждения. Иначе между сеансами сайт примет несколько обещаний на один остаток. Универсального интервала для любой торговли нет: его выбирают по скорости движения товара, времени работы менеджеров и тому, какое ожидание честно показать покупателю. Чаще означает больше сеансов. До изменения расписания полезно оценить, успевает ли предыдущая передача закончиться и кто заметит очередь незавершённых обновлений.
Направления обмена
УТ → сайт
Каталог, цены и доступность.
Сайт → УТ
Оформленный заказ и нужные для исполнения сведения.
УТ → сайт
Сведения об обработке заказа в согласованном составе.
Какие сведения подготовить до оценки работ
Без описания данных подрядчик оценит только предположение о торговле. На встречу стоит принести несколько реальных карточек товаров без лишних персональных сведений и показать, как оформляется заказ. Особенно полезны неудобные варианты: товар с характеристиками, позиция без остатка, отгрузка частями и возврат, поскольку по простому товару трудно увидеть будущую границу автоматизации.
Образец задания на обмен
- Источник каталога: УТ. На сайт передаются только выбранные группы, чтобы служебные позиции не попадали в продажу.
- Владелец описаний: редактор сайта. Обмен обновляет учётные поля, сохраняя тексты, которые покупатель уже видит в карточке.
- Доступность: согласованный показатель с учётом резервов и разрешённых складов. Исполнитель показывает смысл количества на товаре, зарезервированном другому покупателю.
- Цена: выбранный вид цены для открытой витрины. Правила персонального показа описываются отдельной задачей.
- Заказ: состав, количество, способ получения и необходимые контактные сведения. Передаются только данные, требуемые для исполнения покупки.
- Изменения: названы допустимые статусы и владелец редактирования состава. Повторный сеанс не создаёт новый заказ вместо обновления прежнего.
- Сбой: назначены получатель уведомления и порядок повторной передачи. Общий идентификатор позволяет точно найти потерянный заказ без сопоставления похожих фамилий.
Этот образец заполняют своими названиями полей. Он полезнее просьбы «сделать стандартную интеграцию», поскольку делает видимыми решения, которые иначе подрядчик примет без участия торговли. После заполнения станет понятно, какая часть закрывается готовым модулем, а какая действительно требует доработки и дальнейшего обслуживания, поэтому предложения подрядчиков можно будет сравнивать по одному составу и видеть, какие работы изменяют цену.
Кто принимает решения внутри компании
Каталог согласует сотрудник, который ведёт номенклатуру. Доступность и резерв обсуждают со складом и продажами, а бухгалтер участвует там, где обмен затрагивает документы и расчёты. Общий ответственный собирает решения и разрешает противоречия: передавать программисту спор двух отделов как техническое задание нельзя, потому что код лишь закрепит один из вариантов работы, который другая сторона продолжит считать ошибочным. Нужен один владелец решения.
Как принять результат на пробном ассортименте
Первую загрузку лучше проводить отдельно от работающего магазина: если неверно сопоставить позиции, одинаковый товар может превратиться в несколько карточек, а старые ссылки потеряются. Пробный ассортимент берут небольшим, но разнообразным по устройству: количество позиций здесь менее существенно, чем наличие всех вариантов, с которыми сотрудники реально сталкиваются при продаже.
Сценарии, которые выявляют расхождения
Новый товар появляется с нужным артикулом. Изменённая цена обновляется в предназначенном поле. Резерв уменьшает количество, которое можно обещать следующему покупателю. Заказ с сайта попадает в нужное место обработки и сохраняет связь с исходным номером. Затем повторяют обмен без новых действий, чтобы убедиться, что он обновляет прежние записи, а не размножает товары и документы.
Отдельно нужен разбор прерванного сеанса: исполнитель показывает, где видно завершение, кто получает сообщение об ошибке и как безопасно повторить передачу. После успешного ручного запуска остаётся испытать вечерний сбой, когда обновление не завершилось, специалиста уже нет рядом, а менеджер продолжает принимать заказы по устаревшему наличию, не зная о задержке и не получив уведомления. Журнал помогает найти причину. Однако в нём нужны понятные время и результат последнего сеанса, чтобы дежурный сотрудник отличил задержку от успешного обновления без изменений и передал специалисту точные сведения.
Документы после приёмки
Сохраните список версий, установленных модулей, расписание, ответственных и границы поддержки. Для обновления программы пригодится перечень изменений, которые испытывают повторно. Особенно это касается доработанных полей: новый выпуск УТ или сайта может изменить поведение обмена, и команде нужен короткий набор испытаний, связанный с её продажами, а не воспоминание о том, что несколько месяцев назад всё однажды загрузилось.
Готовый модуль предпочтительнее собственной разработки, если он выполняет описанные сценарии. Дополнительный код оправдан конкретным недостающим действием, потому что его придётся поддерживать при следующих обновлениях обеих систем, оплачивать диагностику и повторять испытания после изменений, влияющих на товар или заказ.
Пробный запуск перед основной загрузкой
Набор товаров
Включает варианты, резерв и отсутствие остатка.
Действия
Изменить цену, оформить заказ, повторить сеанс.
Сопоставление
Сравнить карточки, количество и связь заказов.
Если правила учёта оставить на потом
Самая дорогая ошибка — автоматизировать спорные сведения, поскольку разное понимание резерва, цены и доступного склада сайт будет лишь быстрее передавать покупателю, увеличивая число заказов, которые менеджеру придётся исправить вручную. Обмен способен увеличить скорость распространения ошибки, поэтому сначала требуется единое решение о том, какой товар компания действительно готова продать на показанных условиях.
С чего начать обсуждение внедрения
Для оптово-розничной торговли полезно описать один путь: поступление товара, появление доступного остатка, заказ, резерв, оплату и отгрузку, чтобы владельцы этих действий могли объяснить их на общих данных. Тогда выбор становится предметным. Если же разговор начинается только с цены лицензии, за рамками оценки останутся подготовка каталога, обучение, перенос остатков и поддержка — работы, без которых программа не станет рабочим учётом компании.
Сначала договоритесь о данных. Тогда интернет-магазин будет продолжением торговли, а ошибки можно будет разбирать по операции и ответственному, сохраняя понятную связь между обещанием на сайте и фактическим исполнением заказа.
Источники и полезные ссылки
- 1С:Управление торговлей: описание ↗
- 1С: складской учёт ↗
- 1С: оптовые продажи ↗
- 1С-Битрикс: интеграция интернет-магазина с 1С ↗
Интерфейсы и возможности сервисов могут меняться. Перед настройкой сверяйтесь с актуальной документацией.


