Склад 15 и 1С: создание бизнес-процессов приемки товаров

Типовой функционал приемки в «Склад 15», построенный на базе стандартных документов 1С (например, «Поступление товаров и услуг»), предназначен для решения 80% общих складских задач, но критически недостаточен для уникальных требований бизнеса, ориентированного на высокую точность и минимизацию потерь. Основной финансовый риск для владельца или директора заключается в том, что стандартная процедура позволяет оператору Терминала Сбора Данных (ТСД) лишь зафиксировать факт считывания штрихкода, не обеспечивая дополнительного верификационного контроля. На практике это приводит к приёмке некондиционного товара, несоответствию фактического веса или, что критично в Московском регионе, к нарушению регламентов работы с товарами, подлежащими обязательной маркировке (ГИС МТ). Без уникальной логики контроля ошибки оператора превращаются в прямые финансовые потери в виде штрафов и необходимости дорогостоящих пересчетов и инвентаризаций.

Как отсутствие уникальной логики контроля ведет к потере прибыли?

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

По опыту внедрений Команды IT-Rush в логистических и производственных компаниях Москвы, внедрение контроля веса на ТСД сокращает годовые потери от ошибок оператора и пересортицы в среднем на 4–6% от общего объема списаний по инвентаризации, что многократно окупает стоимость доработки.

Примеры уникальных проверок, которые не реализованы «из коробки»

1. Проверка фактического веса товара. Сравнение веса, введенного оператором или полученного с интегрированных весов, с эталонным весом, который хранится в номенклатурной карточке 1С. Требует запроса и обработки данных в 1С в режиме реального времени.
2. Дополнительный контроль маркировки/реквизитов. Проверка уникальных кодов или характеристик, не предусмотренных типовым обменом Mobile SMARTS и 1С, например, обязательная запись номера партии/срока годности в нестандартный регистр сведений 1С.
3. Автоматическое заполнение нестандартного реквизита. Запись в документ 1С дополнительного параметра (например, номер пломбы, статус целостности упаковки), обязательного для внутреннего регламента компании, сразу после сканирования.

Эволюционный путь кастомизации 1С: как мы пришли к устойчивой архитектуре доработок?

Исторически, в 1С-сообществе доработки типового функционала чаще всего выполнялись путем прямого изменения модулей конфигурации — так называемое «снятие с поддержки». Этот подход был максимально прост для реализации, но имел катастрофические последствия при выходе нового релиза 1С. Основной компромисс: выбирая скорость и простоту доработки через изменение типового кода, мы неизбежно жертвуем устойчивостью к обновлениям. Каждый новый релиз требовал рутинного и дорогостоящего слияния/сравнения конфигураций, где уникальный код мог быть перезаписан или требовал адаптации. Этот процесс превращал плановое обновление в многочасовой, непредсказуемый процесс, что и послужило толчком к развитию более элегантных и безопасных архитектурных решений.

Недостатки «снятия с поддержки»: почему этот подход признан тупиковым?

Этот подход — тупиковая ветвь эволюции сопровождения 1С, поскольку он напрямую противоречит принципу сохранения гарантий вендора и делает систему чрезвычайно хрупкой. Главный недостаток — высокая TCO (Total Cost of Ownership). Любая сложная доработка, внесенная в типовой модуль, усложняет будущие обновления в геометрической прогрессии. Кроме того, этот метод исключает использование автоматических обновлений и требует присутствия высококвалифицированного 1С-программиста для каждой интеграции. Множество компаний пробовали альтернативы вроде «гибридного режима», но только появление современных механизмов подписок на события, Внешних Обработок и, наконец, Расширений Конфигурации позволило окончательно решить проблему.

Принцип модульности: как ВО решают проблему «слетающего» кода?

Современная и наиболее безопасная архитектура для интеграции сторонних систем (таких как «Склад 15») с уникальной логикой — это использование Внешних Обработок (ВО) 1С, регистрируемых через стандартный механизм подсистемы «Дополнительные отчеты и обработки». Этот подход обеспечивает абсолютное разделение ответственности между типовой конфигурацией и кодом доработки. В «Склад 15» предусмотрен оператор «Вызов метода 1С», который способен вызывать экспортируемый метод из зарегистрированной ВО. Таким образом, код уникальной проверки физически находится вне типовой конфигурации, и даже полное обновление не затронет его, что является прямым выполнением нашего УТП: Уникальная логика приемки, устойчивая к обновлениям.

Совет от команды IT-Rush, Архитектор 1С-решений: «Многие разработчики, стремясь сэкономить время, прописывают логику кастомизации прямо в типовых общих модулях 1С. Это мина замедленного действия. Запомните: Каждая функция, вызываемая извне (из ‘Склад 15’), должна быть реализована в отдельной Внешней Обработке или в Расширении Конфигурации. Это не только гарантирует устойчивость к обновлениям, но и значительно упрощает тестирование, отладку и сопровождение системы.»

Архитектура устойчивости: где и как хранить код доработки для «Склад 15» в 1С?

Ключевой принцип создания устойчивой к обновлениям архитектуры заключается в том, чтобы никогда не модифицировать типовые модули, которые вызываются из «Склад 15». Вместо этого, разработчик должен создать свою собственную библиотеку функций в виде Внешней Обработки и зарегистрировать ее в 1С. Код для обработки событий «Склад 15» должен храниться в регистрируемых Внешних Обработках (подсистема Дополнительные отчеты и обработки), а не в типовых модулях конфигурации, для обеспечения полной независимости от обновлений.

Механизм вызова 1С из «Склад 15»: как работают обработчики событий Mobile SMARTS?

«Склад 15» (Mobile SMARTS) использует событийную модель: в ключевых точках бизнес-процесса (например, при сканировании штрихкода, перед завершением документа) он может инициировать вызов экспортируемого метода 1С. Этот вызов передает в 1С все необходимые параметры (данные о документе, строке, товаре, сеансе ТСД) и ожидает ответа, который может содержать команду для ТСД: Error (вывести сообщение об ошибке), Success/Continue (продолжить процесс) или NewData (обновить данные на экране ТСД).

Таблица 1: Спецификация параметров вызова 1С из «Склад 15» (Mobile SMARTS)

Параметр (Имя в 1С)	Тип данных	Назначение	Обязательность
DocumentRef	СсылкаНаОбъект	Ссылка на документ 1С, с которым работает ТСД (напр., ПоступлениеТоваровИУслуг).	Обязателен
CurrentRow	Структура	Данные текущей строки ТЧ (Номенклатура, Количество, Характеристика, Серия).	Обязателен
ExternalData	Произвольный	Структура с дополнительными данными, введенными оператором (напр., ФактическийВес).	Зависит от БП
MessageText	Строка (Возврат)	Сообщение для отображения на ТСД (ошибка или предупреждение).	Необязателен
ActionCommand	Строка (Возврат)	Команда для ТСД («Error», «Continue», «Next»).	Обязателен

Подготовка Внешней Обработки в Конфигураторе 1С: пошаговый алгоритм

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

1. Создание и структура: В режиме конфигуратора 1С создается новая Внешняя Обработка (файл *.epf). В модуле объекта этой обработки необходимо создать экспортируемую функцию, которая будет вызываться из системы «Склад 15».
2. Именование и доступ: Имя функции должно быть CustomValidation_AcceptanceWeight.
3. Инициализация и проверка ввода:
   • Функция принимает структуру параметров (Параметры).
   • Проводится проверка наличия критически важных данных, в частности, ссылки на Номенклатура в Параметры.CurrentRow и ФактическийВес в Параметры.ExternalData. При отсутствии данных возвращается ошибка (ActionCommand = «Error»).
4. Получение эталонного веса:
   • Эталонный вес извлекается путем прямого обращения к свойствуВес объекта номенклатуры, который передан в структуре параметров вызова: ЭталонныйВес = Параметры.CurrentRow.Номенклатура.Вес;.
5. Валидация эталонного веса:
   • Происходит проверка, что извлеченный эталонный вес заполнен и больше нуля. Если эталонный вес отсутствует или равен нулю, возвращается ошибка, так как проверка становится невозможной.
6. Логика сравнения с допуском:
   • Устанавливается пороговый допуск (например, 5% или 0.05).
   • Происходит сравнение фактического веса с эталонным с учетом допуска. Используется функция Абс() для сравнения абсолютного отклонения:
     ∣ФактическийВес−ЭталонныйВес∣>(ЭталонныйВес×ДопускВПроцентах)∣ФактическийВес−ЭталонныйВес∣>(ЭталонныйВес×ДопускВПроцентах)
7. Возврат результата:
   • Формируется структура с результатами. Если отклонение превышает допуск, устанавливается ActionCommand = «Error», а в MessageText передается форматированный текст ошибки, содержащий эталонный и фактический вес.
   • Если проверка успешно пройдена или отклонение в пределах допуска, возвращается ActionCommand = «Continue».
8. Регистрация в пользовательском режиме: В пользовательском режиме 1С (через меню «НСИ и Администрирование» → «Дополнительные отчеты и обработки») регистрируется созданный файл *.epf. Обработка должна быть доступна для использования в системе Mobile SMARTS (или в соответствующей подсистеме).

Фрагмент концептуального кода 1С (Модуль объекта Внешней Обработки):

// Экспортируемая функция для вызова из «Склад 15»

Функция CustomValidation_AcceptanceWeight(Параметры) Экспорт

Результат = Новый Структура;

Результат.Вставить(«ActionCommand», «Continue»);

Результат.Вставить(«MessageText», «»);

// Проверка наличия данных

Если Не Параметры.Свойство(«CurrentRow») ИЛИ Не Параметры.CurrentRow.Свойство(«Номенклатура») Тогда

Результат.ActionCommand = «Error»;

Результат.MessageText = «Критическая ошибка: не передана номенклатура.»;

Возврат Результат;

КонецЕсли;

// Проверка ExternalData

Если Не Параметры.Свойство(«ExternalData») ИЛИ Не Параметры.ExternalData.Свойство(«ФактическийВес») Тогда

Результат.ActionCommand = «Error»;

Результат.MessageText = «Критическая ошибка: не передан фактический вес.»;

Возврат Результат;

КонецЕсли;

// Получение эталонного веса из справочника номенклатуры

Номенклатура = Параметры.CurrentRow.Номенклатура;

ЭталонныйВес = Номенклатура.Вес;

// Проверка наличия эталонного веса

Если Не ЗначениеЗаполнено(ЭталонныйВес) ИЛИ ЭталонныйВес = 0 Тогда

Результат.ActionCommand = «Error»;

Результат.MessageText = «Ошибка: для номенклатуры не указан эталонный вес.»;

Возврат Результат;

КонецЕсли;

ФактическийВес = Параметры.ExternalData.ФактическийВес;

// Логика сравнения с допуском

ДопускВПроцентах = 0.05; // 5% допуск

Если Абс(ФактическийВес — ЭталонныйВес) > (ЭталонныйВес * ДопускВПроцентах) Тогда

Результат.ActionCommand = «Error»;

Результат.MessageText = СтрШаблон(

«ВНИМАНИЕ! Фактический вес (%1 кг) не соответствует эталону (%2 кг). Отклонение превышает %3%%.»,

Формат(ФактическийВес, «ЧЦ=15; ЧДЦ=3»),

Формат(ЭталонныйВес, «ЧЦ=15; ЧДЦ=3»),

Формат(ДопускВПроцентах * 100, «ЧЦ=15; ЧДЦ=1»)

);

КонецЕсли;

Возврат Результат;

КонецФункции

 

Пошаговый процесс: создание кастомного бизнес-процесса приемки с проверкой веса

Этот раздел описывает, как связать написанный код 1С с логикой ТСД через Конструктор Бизнес-Процессов «Склад 15».

Шаг 1. Формулирование бизнес-требования (Проверка веса)

Мини-Кейс (Situation): Крупный московский дистрибьютор электроники столкнулся с регулярной недостачей в дорогих комплектующих. Проблема — операторы ТСД регистрируют плановое количество, не проверяя фактический вес. Примененное решение (Action): Внедрение обязательного шага «Контроль Веса» в БП приемки. Результат (Result): За первые 3 месяца внедрения выявлено 17 случаев расхождения веса на сумму, превышающую 1.2 млн рублей (вместо 0 случаев в типовой приемке).

Шаг 2. Проектирование нового шага в Конструкторе «Склад 15»

В Конструкторе БП создается новый бизнес-процесс (или модифицируется существующий «Приемка»).

1. Создать Шаг: Добавить новый шаг в ветку сразу после сканирования товара и его идентификации (оператор «ПроверитьКод»). Назовем его «Контроль_Веса».
2. Сбор данных: В шаге «Контроль_Веса» первым действием должен быть оператор «Ввод данных». Настроить ввод данных: Тип поля — «Число», Название — «ФактическийВес».

Шаг 3. Добавление оператора «Вызов метода 1С»

Сразу после ввода данных добавляется оператор: «Вызов метода 1С».

• Имя обработки: Указать имя файла Внешней Обработки, зарегистрированного в 1С (например, EO_CustomValidation.epf).
• Имя метода: Указать экспортируемое имя функции из 1С: CustomValidation_AcceptanceWeight.
• Передача параметров: В настройках оператора указать, какие данные ТСД передаются в 1С. Обязательно передать DocumentRef, CurrentRow и новое введенное поле «ФактическийВес» (которое будет передано в структуру ExternalData).
• Обработка результата: В конструкторе БП настраиваются две ветки на основании возвращенного 1С параметра ActionCommand:
  • ЕСЛИ ActionCommand = «Error», то Оператор «Сообщение» выводит MessageText и цикл возвращается на ввод товара/сканирование.
  • ЕСЛИ ActionCommand = «Continue», то переход к следующему шагу БП (например, «Размещение в ячейку»).

3 типичных заблуждения при доработке «Склад 15»

Использование только Конструктора БП для сложной логики

• Суть ошибки: Попытка создать сложные, ветвящиеся процессы, включающие обращения к нетиповым данным 1С, исключительно средствами Конструктора «Склад 15».
• Почему так делают: Желание избежать привлечения 1С-программиста и сократить бюджет.
• Цена ошибки: Тупик в развитии автоматизации и потерянное время. Логика быстро становится нечитаемой, а главное — не получает доступа к критически важным данным 1С. В итоге приходится переделывать процесс с нуля, уже с привлечением разработчика, умножая изначальные затраты на внедрение в 1.5–2 раза.

Редактирование типового модуля для скорости

• Суть ошибки: Для быстрого вызова из ТСД, разработчик добавляет свой код прямо в типовые общие модули, которые уже используются Mobile SMARTS (например, ОбменСМобильнымиУстройствами).
• Почему так делают: Это самый быстрый путь, так как не нужно регистрировать внешнюю обработку и настраивать права.
• Цена ошибки: Гарантированный «слет» кода и простой склада при обновлении. При выходе нового релиза 1С или обновления Mobile SMARTS, типовой модуль будет обновлен, и весь уникальный код будет потерян. В зависимости от сложности, восстановление работоспособности склада может занять от 8 до 40 рабочих часов, что в денежном выражении для московской IT-команды составляет сотни тысяч рублей, не считая убытков от простоя и срыва поставок.

Игнорирование механизма блокировок и транзакций 1С при работе с ТСД

• Суть ошибки: В коде внешней обработки 1С разработчик не использует БлокировкаДанных перед записью критических данных, что позволяет нескольким операторам ТСД одновременно изменять один и тот же документ или ресурс.
• Почему так делают: Недооценка многопользовательского режима работы склада и отсутствие опыта в серверной разработке 1С.
• Цена ошибки: Порча данных и «призрачные» ошибки. Ситуация, когда два оператора одновременно пытаются списать или принять одну и ту же товарную позицию. Это приводит к неверным остаткам, расхождениям между учетными и фактическими данными и требует дорогостоящего аудита базы данных для выявления и устранения поврежденных документов.

Сравнение подходов: код 1С vs. Конструктор БП «Склад 15»

Когда достаточно конструктора, а когда необходим прямой вызов 1С?

Выбор инструмента должен основываться на принципе Инженерного Компромисса: Выбирая быстроту настройки в Конструкторе, мы неизбежно жертвуем возможностью работы с данными 1С в режиме реального времени.

Таблица 2: Сравнительный анализ методов кастомизации «Склад 15»

Параметр	Конструктор Бизнес-Процессов (Без кода)	Вызов Метода 1С (Через Внешнюю Обработку)
Сложность логики	Простая (ввод, сравнение, переход, сообщение).	Высокая (Запросы к базе, сложные расчеты, транзакции, изменение документов 1С).
Устойчивость к обновлениям 1С	100% устойчив (код только в Склад 15).	99% устойчив (код в отдельном файле .epf/Расширении).
Доступ к данным 1С	Ограничен (только текущие данные документа на ТСД).	Полный доступ (любые регистры, справочники, документы 1С).
Скорость внедрения	Высокая (настраивается не-программистом).	Средняя/Низкая (требует 1С-программиста).
Стоимость поддержки	Низкая.	Средняя (зависит от сложности кода и его документирования).

Аргумент против архитектуры Внешних Обработок

Центральный тезис статьи — Внешняя Обработка (ВО) как основа устойчивой архитектуры. Самый сильный аргумент против этого подхода заключается в следующем: ВО, в отличие от Расширений Конфигурации, не является полноценной частью конфигурации и требует отдельной регистрации, контроля версий и специфической настройки прав доступа для пользователей. Это усложняет сопровождение: вместо единого места хранения кода, разработчик должен управлять отдельными файлами .epf и их регистрацией в каждой базе. Для крупных корпоративных систем с множеством баз это может стать источником путаницы. Аргумент — «Дополнительные объекты усложняют сопровождение и требуют отдельной регистрации». Контраргумент — Риск потери кода при редактировании типовой конфигурации в разы выше.

В каких случаях расширения 1С предпочтительнее внешней обработки?

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

1. Необходимо изменять формы типовых документов 1С (например, добавить кнопку для вызова обработки с ТСД).
2. Нужна модификация типового интерфейса или добавление новых реквизитов к существующим объектам.
3. Необходимо обеспечить единый контроль версий для всех доработок, привязанных к конфигурации.

Однако, для решения узкой задачи «Вызов метода из сторонней системы (‘Склад 15’)» Внешняя Обработка остается более практичным, быстрым и безопасным компромиссом для большинства средних компаний.

Что должен знать владелец бизнеса о кастомизации «Склад 15»?

Для владельца бизнеса ключевой метрикой является ROI (возврат инвестиций). Недостаточно просто автоматизировать процесс; необходимо внедрять контрольные механизмы, которые предотвращают финансовые потери.

1. Кастомизация — это не затраты, а страховка: Доработка, например, проверки веса или контроля маркировки, предотвращает потери, которые в 10–20 раз превышают стоимость самой доработки. Это инвестиция в качество данных и снижение рисков.
2. Требуйте «Обновляемой» Архитектуры: Настаивайте на том, чтобы ваш разработчик или подрядчик использовал только Внешние Обработки или Расширения 1С для работы с Mobile SMARTS. Прямое изменение типового кода означает, что вы платите дважды: за создание доработки и за ее гарантированное восстановление после каждого обновления.
3. Сфокусируйтесь на Цене Ошибки: Каждый новый бизнес-процесс должен быть нацелен на устранение конкретного риска: штраф (маркировка), хищение (вес), репутационные потери (брак). Если доработка не предотвращает конкретный, измеримый риск, ее ценность сомнительна.

Больше интересных статей для вас:

1. 1С:Фреш и «Склад 15»: архитектурный анализ и пошаговый план настройки обмена через Интернет
2. Чек-лист безопасного обновления «Склад 15» и 1С-обработки с сохранением всех доработок
3. Архитектура «Умной довыгрузки» справочника номенклатуры между 1С и Склад 15
4. Обмен 1С: УТ 11 и «Склад 15» онлайн: пошаговая настройка Web-сервиса