← На главную

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

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

Почему возникает ложная связь: техническая сторона вопроса

Прежде чем переходить к практическим действиям, проанализируем, как в системе 1С:УПП устроен механизм связанных документов. Отчет «Структура подчиненности» строится динамически на основе специального объекта метаданных — КритерийОтбора.СвязанныеДокументы. Этот критерий сканирует реквизиты всех документов в базе данных в поисках ссылок на выбранный документ.

Связь между документами ЗаявкаНаРасходованиеСредств (Заявка на расходование денежных средств) и ПлатежноеПоручениеИсходящее (Платежное поручение исходящее) устанавливается через реквизит ДокументПланированияПлатежа, который физически расположен в табличной части РасшифровкаПлатежа платежного поручения.

Если платежное поручение отображается в списке связанных документов для неоплаченной заявки, это однозначно указывает на то, что внутри базы данных в табличной части этого платежного поручения записана ссылка на данную заявку. Это может происходить по трем основным причинам:

1. Использование режима «Списком» в платежке: На форме платежного поручения установлен флаг «Список». В табличной части «Расшифровка платежа» добавлено несколько строк для распределения оплаты по разным сделкам или заявкам. Если в одну из строк была случайно выбрана вторая (неоплаченная) заявка, связь зафиксируется в базе данных.
2. «Фантомные» строки в базе данных: Это наиболее частая и скрытая причина. Пользователь мог изначально заполнять платежное поручение в режиме «Списком», выбрать туда несколько заявок, а затем передумать, снять флаг «Список» и провести документ в одиночном режиме. При снятии флага «Список» на форме визуально отображается только первая строка, но в самой табличной части в базе данных физически остаются «зависшие» скрытые строки со ссылками на другие заявки. Критерий отбора продолжает их видеть и выводить в структуру подчиненности.
3. Автоматическое распределение при импорте из «Клиент-Банка»: При загрузке выписок через обработку обмена с банком система пытается автоматически сопоставить платежи с документами планирования по контрагенту и договору. Алгоритм автоподбора может ошибочно привязать «лишнюю» заявку к строке выписки.

Способ 1. Ручное исправление через режим списка (самый надежный способ)

Рассмотрим подробнее, как очистить скрытые или ошибочные связи непосредственно в документе оплаты. Этот способ подходит, если период редактирования документов открыт и платежных поручений с ошибками относительно немного.

Выполним следующие действия по шагам:

1. Найдите и откройте проблемное ПлатежноеПоручениеИсходящее (это можно сделать прямо из структуры подчиненности неоплаченной заявки).
2. Обратите внимание на форму документа, где находится флаг «Список» (рядом с полем «Договор» или в области расшифровки платежа).
3. Даже если этот флаг снят, установите его принудительно. Перед вами развернется табличная часть «Расшифровка платежа».
4. Проанализируйте состав строк в табличной части. Вы увидите строку, в колонке «Документ планирования» которой выбрана та самая неоплаченная заявка. Часто у такой строки может быть нулевая сумма или некорректная статья движения денежных средств.
5. Выделите ошибочную строку и удалите её с помощью клавиши Del или кнопки удаления на панели инструментов. Также можно просто очистить поле «Документ планирования» в этой строке, если сама сумма платежа должна остаться, но без привязки к заявке.
6. Если платеж действительно должен быть одиночным (по одной заявке), снимите флаг «Список» обратно. На форме останется только одна, корректная строка.
7. Перепроведите документ, нажав кнопку «ОК» или «Провести».

Важное предупреждение: Категорически не рекомендуется очищать реквизиты документов программным путем без их последующего перепроведения. Документ ПлатежноеПоручениеИсходящее при проведении делает важные движения по регистрам накопления, таким как ЗаявкиНаРасходованиеСредств (закрывает потребность в оплате) и ДвиженияДенежныхСредств. Если вы просто удалите ссылку в базе данных обработкой без перепроведения, структура подчиненности исправится, но регистры останутся в некорректном состоянии, что приведет к расхождению в отчетах казначейства.

Способ 2. Групповое исправление для большого объема документов

Если ложных связей накопилось много, ручная обработка каждого документа займет слишком много времени. В таком случае мы можем использовать стандартную групповую обработку.

Разберем алгоритм по шагам:

1. Откройте обработку «Групповое изменение реквизитов» (в зависимости от интерфейса и прав доступа она может находиться в меню «Сервис» или в дополнительных обработках).
2. В поле «Изменять объекты» выберите тип данных Платежное поручение исходящее.
3. Настройте отбор, чтобы случайно не изменить лишние документы. Рекомендуется установить отбор по конкретному контрагенту, организации и периоду (например, текущий месяц).
4. В списке доступных для изменения реквизитов найдите табличную часть Расшифровка платежа.
5. Найдите реквизит ДокументПланированияПлатежа (в некоторых локализациях он может называться «Документ планирования» или «Заявка»).
6. Установите для него действие «Очистить» или укажите пустое значение (если требуется полностью убрать связь) либо укажите верную заявку.
7. Перейдите в настройки обработки (кнопка «Параметры») и обязательно включите флаги «Выполнять в транзакции» и «Проводить при записи». Это гарантирует, что система пересчитает движения по регистрам накопления в соответствии с новыми данными.
8. Запустите процесс изменения. По окончании работы обработки проверьте структуру подчиненности — ложные связи исчезнут, а регистры будут содержать корректные данные.

Методологический аспект взаимоотношений с бухгалтерией

Часто споры вокруг структуры подчиненности возникают из-за непонимания бухгалтерами методологии учета в 1С:УПП. Выясним, как правильно объяснить ситуацию пользователям, если они требуют «невозможного».

Необходимо разделять две принципиально разные ситуации:

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

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

Если бухгалтеры категорически возражают против такого отображения, предложите им изменить методологию работы с банком. Чтобы связи не пересекались, необходимо строго придерживаться правила: «Одна заявка = Одно платежное поручение». В таком случае объединение платежей в один банковский документ станет невозможным, и структура подчиненности всегда будет линейной и прозрачной.