Разберем частую ситуацию, с которой сталкиваются пользователи и программисты при работе в 1С:ERP. Допустим, у нас есть документ ЗаказКлиента. В строках обеспечения установлены настройки: отгрузить, резервировать по мере поступления, обеспечивать обособленно. Дата отгрузки установлена, например, на 1 декабря.
Мы перемещаем нужные ТМЦ на склад под этот заказ уже сегодня. Однако, чтобы система «увидела» этот товар как готовый к отгрузке в отчете о состоянии выполнения, пользователю необходимо вручную зайти в состояние обеспечения заказа и нажать гиперссылку Резервировать раньше (или стрелку влево). Проанализируем, почему так происходит и как мы можем автоматизировать этот процесс, чтобы избавить пользователей от рутинных кликов.
Рассмотрим подробнее, что именно делает кнопка «Резервировать раньше» с технической точки зрения. При нажатии на эту гиперссылку система выполняет перезапись строк документа ЗаказКлиента. Вариант обеспечения меняется с Резервировать по мере поступления (или Резервировать к дате) на Резервировать на складе. При этом плановая дата отгрузки товара сдвигается (уменьшается), приближаясь к текущей дате, поскольку товар уже физически доступен на складе.
В последних релизах ERP 2.4 и 2.5 данные о резервах аккумулируются в сложном регистре сведений РаспределениеЗапасов, который строится на основе регистра накопления ЗапасыИПотребности. Рабочие места логистов и менеджеров читают информацию именно оттуда.
Когда мы проводим документ ПеремещениеТоваров (особенно при обособленном обеспечении), ТМЦ физически резервируются под конкретное назначение на уровне регистров. Но сам заказ клиента об этом автоматически не узнает. Табличная часть заказа и статусы обеспечения остаются прежними до тех пор, пока мы не обновим их вручную. Система ведет себя так специально — во избежание массовых блокировок документов и замедления работы базы при каждом складском движении.
Посмотрим на практические пути решения этой задачи. Поскольку типовой функционал не переводит статусы автоматически в реальном времени, нам потребуется доработать систему. Выделим два основных подхода.
Этот вариант считается наиболее безопасным с точки зрения производительности системы и вероятности возникновения блокировок. Разработаем небольшую обработку, которая будет выполняться по расписанию (например, каждые 15–30 минут).
Если бизнес-процесс требует мгновенного обновления статусов обеспечения сразу после поступления товара на склад, воспользуемся расширением конфигурации.
Мы создаем расширение, которое будет «слушать» обработку проведения складских документов, таких как ПеремещениеТоваров, ПоступлениеТоваровУслуг или ПриходныйОрдерНаТовары (если используется ордерная схема).
ОбработкаПроведения (или после нее) алгоритм находит заказ-основание (документ назначения).Важное предупреждение: При реализации второго метода необходимо тщательно контролировать транзакции и блокировки. Если несколько перемещений одновременно попытаются перезаписать один и тот же ЗаказКлиента, это приведет к ошибкам взаимоблокировок (deadlock).
Проанализируем ситуацию с настройкой Обеспечивать обособленно. В этом случае система изначально защищает товар от случайной продажи другим клиентам. Резервирование под «назначение» происходит на уровне складских регистров сразу при проведении поступления.
Ручное нажатие «Резервировать раньше» здесь требуется исключительно для того, чтобы актуализировать визуальные отчеты по отгрузке и перевести строку в статус Отгрузить, чтобы кладовщик увидел этот товар в рабочем месте оформления накладных. Для автоматизации работы с обособленными товарами часто применяют программное создание документа КорректировкаНазначенияТоваров, который позволяет гибко управлять резервами без необходимости напрямую перезаписывать исходный заказ клиента.
Подводя итог, выясним причину отсутствия автоматического сдвига резервов в коробке: это компромисс ради производительности. Выбор между фоновым заданием и подпиской на проведение зависит от ваших требований к скорости реакции системы и общей нагрузки на сервер 1С.