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