Разберем одну из весьма распространенных и неочевидных проблем, с которой могут столкнуться пользователи и разработчики 1С:ERP, а также аналогичных конфигураций, таких как "Управление торговлей" и "Комплексная автоматизация". Мы говорим о ситуации, когда оформленные заказы клиентов, содержащие номенклатуру типа "Работа", упорно не попадают в рабочее место менеджера по доставке, несмотря на, казалось бы, корректные статусы и настройки.
Наш анализ покажет, что причина кроется в специфике типового функционала платформы, который по-разному обрабатывает различные типы номенклатуры, особенно в контексте логистики и складского учета. Мы выясним, какие регистры задействованы в процессе формирования распоряжений на доставку и почему номенклатура типа "Работа" выпадает из этого процесса.
Предположим, у нас есть заказ клиента, в котором предусмотрена доставка нашим транспортом. Адрес доставки указан, статус заказа — "К отгрузке". Однако, при переходе в рабочее место менеджера по доставке, этот заказ, содержащий позицию с типом номенклатуры "Работа", не отображается как распоряжение на доставку. Это вызывает недоумение, поскольку все видимые настройки кажутся правильными.
Давайте подробнее рассмотрим, почему номенклатура типа "Работа" является камнем преткновения в данном сценарии.
Первое, на что мы обращаем внимание, это содержание табличной части "Товары" в документе "Заказ клиента". Типовой функционал 1С:ERP (особенно актуально для версии 2.5) изначально разработан таким образом, что механизмы складского учета и доставки ориентированы на физические объекты: "Товар" и "Тара". Номенклатура типа "Работа", несмотря на то, что она может быть включена в заказ клиента, несет иную смысловую нагрузку. Она представляет собой нечто, что нельзя "отгрузить" в классическом понимании, измерить весом или габаритами без дополнительных настроек.
Именно этот фундаментальный подход программы лежит в основе нашей проблемы. Разработчики системы изначально не предусматривали прямую доставку "работ" как физических товаров, требующих транспортного обеспечения, хотя на практике такая потребность у клиентов может возникать (например, доставка монтажных работ, наладки оборудования и т.д.).
Ключевым звеном в механизме формирования распоряжений на доставку является регистр накопления Товары к отгрузке. Этот регистр служит своего рода буфером, обеспечивающим согласованность между складским и финансовым контурами учета. Он фиксирует обязательства по отгрузке товаров, которые должны быть физически перемещены со склада.
Когда мы проводим документ "Заказ клиента", типовой механизм системы пытается сформировать движения в этом регистре. Однако, если в табличной части заказа присутствует номенклатура типа "Работа", документ Заказ клиента просто не видит эту номенклатуру как "товар, подлежащий отгрузке". Следовательно, никаких записей в регистре Товары к отгрузке по такой позиции не формируется. Без этих записей система не может понять, что есть что-то, что нужно доставлять.
// Пример упрощенной логики в модуле проведения Заказа клиента
// (псевдокод, для демонстрации принципа)
Для Каждого СтрокаТовары Из ТабличнаяЧастьТовары Цикл
Если СтрокаТовары.Номенклатура.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Товар ИЛИ
СтрокаТовары.Номенклатура.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Тара Тогда
// Формируем движения по регистру ТоварыКОтгрузке
Движение = Движения.ТоварыКОтгрузке.Добавить();
Движение.Номенклатура = СтрокаТовары.Номенклатура;
Движение.Количество = СтрокаТовары.Количество;
// ... другие реквизиты
Иначе
// Номенклатура типа 'Работа' или 'Услуга' игнорируется для отгрузки
КонецЕсли;
КонецЦикла;
Рабочее место менеджера по доставке получает информацию о распоряжениях на доставку из регистра сведений Состояния и реквизиты доставки. Этот регистр агрегирует данные о всех планируемых и текущих доставках, включая информацию о заказах, их статусах, адресах и прочих реквизитах, необходимых для планирования маршрутов и заданий на перевозку.
В нашем случае, поскольку Заказ клиента не сформировал записи в регистре Товары к отгрузке для номенклатуры типа "Работа", он также не может корректно сформировать полную запись в регистре Состояния и реквизиты доставки, которая бы указывала на необходимость физической доставки этой "работы". Даже если под отладчиком мы видим попытку добавить запись в этот регистр в процессе проведения заказа, после его завершения записи могут отсутствовать или быть неполными именно потому, что ключевые данные об "отгружаемом товаре" не были переданы из регистра Товары к отгрузке.
Таким образом, цепочка прерывается на уровне обработки номенклатуры: "Работа" -> нет движений в Товары к отгрузке -> нет корректных данных в Состояния и реквизиты доставки -> нет отображения в рабочем месте менеджера по доставке.
В процессе поиска решения пользователи часто пробуют стандартные подходы, которые оказываются неэффективными в данной специфической ситуации. Давайте проанализируем их:
Одним из распространенных предположений является необходимость провести "Реализацию товаров и услуг" перед доставкой. Это логично, поскольку именно реализация фиксирует факт перехода права собственности и готовность к отгрузке.
Однако, как показывает опыт, даже оформление документа Реализация товаров и услуг на основании заказа с номенклатурой типа "Работа" не решает проблему. Если "Работа" изначально не воспринимается системой как объект для физической отгрузки, то реализация, хотя и списывает ее с управленческого учета как выполненную, не инициирует механизм доставки, предназначенный для товаров.
Важно отметить, что отгрузка с отложенным переходом права собственности (например, при доставке) типовым функционалом 1С:ERP (до версии 2.5) предусмотрена только для типов номенклатуры "Товар" и "Набор". Для "Услуги" или "Работы" возможно оформление только обычной реализации, которая не подразумевает логистических операций.
Пользователи могут экспериментировать с различными схемами оплаты (предоплата, постоплата/товарный кредит) и отгрузки (ордерная, неордерная). К сожалению, изменение этих параметров также не влияет на фундаментальное ограничение, связанное с типом номенклатуры "Работа". Механизмы доставки остаются неизменными независимо от финансовой составляющей или способа оформления складских документов, если речь идет о "работе" в классическом понимании 1С.
Отметим, что при ордерной схеме документооборота фактическая отгрузка товаров со склада регистрируется Расходным ордером на товары. Если этот ордер не оформлен или имеет неверный статус, это, конечно, помешает доставке. Но для "Работы" проблема глубже: ордер просто не будет создан, так как нет физического товара.
Интересный момент, который был выявлен в ходе обсуждения, это корректное отображение документа Поручение экспедитору в рабочем месте менеджера по доставке. Мы должны понимать, что Поручение экспедитору – это отдельный документ, предназначенный для формирования произвольных заданий транспортной службе, который может использоваться для транспортировки персонала, документов или грузов, не привязанных к конкретным складским движениям или номенклатуре. Он не учитывает весо-габаритные характеристики груза и не связан напрямую с регистрами Товары к отгрузке. Его работа подтверждает, что сам механизм рабочего места доставки функционирует, но проблема кроется именно в *источнике* распоряжений для товаров.
Поскольку типовой функционал 1С:ERP не предусматривает прямую доставку номенклатуры типа "Работа" в том же контуре, что и товары, наиболее эффективным и, зачастую, единственным решением является доработка (кастомизация) конфигурации. Автор исходной проблемы, столкнувшись с этим, подтвердил, что "запилил" решение.
Рассмотрим, какие шаги могут быть предприняты при доработке:
Первый и часто необходимый шаг – это расширение справочника "Номенклатура" или связанных с ним объектов, чтобы номенклатура типа "Работа" могла хранить весо-габаритные характеристики (вес, объем, габариты упаковки). Без этих данных система доставки не сможет адекватно планировать загрузку транспорта.
Мы можем реализовать это, например, через:
Следующий критически важный шаг – это изменение логики проведения документов, таких как Заказ клиента и Реализация товаров и услуг. Нам необходимо "научить" эти документы формировать движения в регистре Товары к отгрузке (или аналогичном регистре, который будет использоваться для "работ") для номенклатуры типа "Работа".
Мы можем создать расширение конфигурации и перехватить обработчики проведения. В этих обработчиках мы должны будем:
Товары к отгрузке, заполняя необходимые поля, включая искусственно добавленные весо-габаритные характеристики.Состояния и реквизиты доставки. Возможно, потребуется также доработка формирования записей в этот регистр.
// Пример псевдокода для доработки проведения Заказа клиента через расширение
// В событии "ОбработкаПроведения" документа "ЗаказКлиента"
Для Каждого СтрокаТовары Из Движения.ТоварыКОтгрузке.Выгрузить() Цикл
// Проверяем, если номенклатура типа 'Работа' и она не попала в типовые движения
Если СтрокаТовары.Номенклатура.ТипНоменклатуры = Перечисления.ТипыНоменклатуры.Работа И
НЕ СтрокаТовары.ПроведеноТиповымМеханизмом Тогда // Допустим, мы добавили такой флаг
НовоеДвижение = Движения.ТоварыКОтгрузке.Добавить();
НовоеДвижение.ВидДвижения = ВидДвиженияНакопления.Приход;
НовоеДвижение.Период = Дата;
НовоеДвижение.ДокументОснование = Ссылка;
НовоеДвижение.Номенклатура = СтрокаТовары.Номенклатура;
НовоеДвижение.Количество = СтрокаТовары.Количество;
НовоеДвижение.Склад = СкладОтгрузки; // Предполагаемый склад или логический склад для работ
// Добавляем заполнение веса, объема, если они были 'запилены'
// НовоеДвижение.Вес = ПолучитьВесРаботы(СтрокаТовары.Номенклатура);
// НовоеДвижение.Объем = ПолучитьОбъемРаботы(СтрокаТовары.Номенклатура);
// ...
КонецЕсли;
КонецЦикла;
// После формирования всех движений, необходимо убедиться, что они
// будут учтены при формировании записей в регистре СостоянияИРеквизитыДоставки.
// Возможно, потребуется аналогичная доработка или вызов типовых функций,
// которые смогут обработать наши 'искусственные' движения.
Мы должны помнить, что особенности старых версий конфигураций, а также национальных локализаций (например, украинской, как в нашем случае) могут вносить свои нюансы. В некоторых случаях, функционал мог быть реализован иначе или содержать ошибки, которые были исправлены в более поздних релизах. Мы рекомендуем перед началом глобальных доработок провести тщательный анализ кода в вашей конкретной версии и убедиться, что проблемы не связаны с известными ошибками или устаревшим функционалом, который можно обновить.
Хотя основная причина нашей проблемы лежит в обработке номенклатуры типа "Работа", мы все же не должны забывать о базовых настройках подсистемы "Управление доставкой". Убедимся, что они корректны:
Мы должны проверить, что опция "Управление доставкой" активирована в разделе "НСИ и администрирование" - "Настройка НСИ и разделов" - "Склад и доставка" - "Доставка".
Мы проверяем, что все необходимые справочники, такие как "Типы транспортных средств", "Зоны доставки" и "Транспортные средства", заполнены и актуальны. Без них система не сможет планировать маршруты.
Мы контролируем статусы документов. Например, "Заказ клиента" или "Реализация товаров и услуг" должны находиться в статусе, который подразумевает готовность к отгрузке (например, "К отгрузке"). В ордерной схеме документооборота мы должны убедиться, что "Расходный ордер на товары" имеет статус "К отгрузке" после сборки товаров.
Мы анализируем схему работы складов. На неордерных складах отгрузка часто происходит непосредственно по реализации, минуя ордера. Однако, это не снимает ограничения по типу номенклатуры "Работа" для включения в логистические процессы.
Для глубокого понимания ситуации и выявления точных мест, где прерывается логика, мы рекомендуем использовать средства отладки 1С:
Мы устанавливаем точку останова в модуле проведения документа "Заказ клиента" или "Реализация товаров и услуг" и последовательно отслеживаем формирование движений по регистрам, особенно по Товары к отгрузке и Состояния и реквизиты доставки. Мы обращаем внимание на то, какие строки табличной части обрабатываются, и какие движения по каким регистрам формируются.
После проведения документа мы вручную проверяем содержание регистров Товары к отгрузке и Состояния и реквизиты доставки через "Все функции" или стандартные отчеты. Отсутствие записей или неполные записи для номенклатуры типа "Работа" будет прямым подтверждением проблемы.
Мы выяснили, что не попадание заказов с номенклатурой типа "Работа" в рабочее место менеджера по доставке в 1С:ERP является системным ограничением, обусловленным типовой логикой обработки номенклатуры и регистров учета Товары к отгрузке и Состояния и реквизиты доставки. Система по умолчанию не воспринимает "работу" как физический объект, требующий транспортного обеспечения.
Единственным эффективным решением этой проблемы является доработка конфигурации. Она будет включать в себя модификацию справочника "Номенклатура" для добавления весо-габаритных характеристик к типу "Работа" и изменение логики проведения документов для корректного формирования движений в регистрах, отвечающих за доставку. При этом мы обязательно учитываем версию конфигурации и особенности локализации, так как это может повлиять на объем и сложность необходимых изменений. Только такой комплексный подход позволит полноценно интегрировать "доставку работ" в логистический контур 1С:ERP.