Как изменить логику перемещения денежных средств из банка в кассу в 1С:УНФ 1.6

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

Анализируем стандартную логику 1С:УНФ

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

В УНФ основным регистром для учета денег является регистр накопления ДенежныеСредства. Когда мы проводим Поступление в кассу, система делает две записи в этот регистр:

1. Приход по ресурсу «Организация» с указанием кассы.
2. Расход по ресурсу «Организация» с указанием банковского счета.

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

Решение №1: Использование механизма «Деньги в пути» (Методологическое)

Если ваша задача — разделить ответственность (например, когда бухгалтер отражает списание со счета, а кассир — приход в кассу через несколько часов или дней), самым правильным решением будет использование промежуточного счета. В бухгалтерском учете это счет 57, в УНФ мы можем создать виртуальную «кассу» или использовать аналитику «Деньги в пути».

Рассмотрим по шагам, как это реализовать без изменения программного кода:

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

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

Решение №2: Программное изменение логики (Для программистов)

Если клиент настаивает на том, чтобы именно документ Расход со счета формировал движения по банку, нам придется «расцепить» стандартную связь документов. Рассмотрим, как это реализовать в коде.

Выясним причину отсутствия движений: в модуле объекта документа Расход со счета при выбранном виде операции «Снятие наличных» жестко прописано условие, отключающее формирование записей по регистру ДенежныеСредства. Чтобы это изменить, необходимо внести правки в процедуру ОбработкаПроведения.

Внимание: При таком подходе вам ОБЯЗАТЕЛЬНО нужно изменить логику документа Поступление в кассу, чтобы он перестал делать расход по банку, иначе вы получите задвоение.

Пример логики изменения в коде (условно):

// В документе РасходСоСчета включаем движения
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
    // Стандартный код формирования движений...
    Движения.ДенежныеСредства.Записывать = Истина;
    // Удаляем или комментируем условие, которое обнуляет движения для операции СнятиеНаличных
КонецПроцедуры

Затем в документе Поступление в кассу нужно найти участок кода, отвечающий за корреспондирующий счет (банк), и отключить его:

// В документе ПоступлениеВКассу отключаем движение по банку
Если Объект.ВидОперации = Перечисления.ВидыОперацийПоступлениеВКассу.ПолучениеНаличныхВБанке Тогда
    // Оставляем только Приход в кассу
    // Движение по расходу с банковского счета блокируем
КонецЕсли;

Проблемы и риски «допила» (Важно!)

Разберем основные опасности, с которыми вы столкнетесь после такого изменения:

• Синхронизация с 1С:Бухгалтерией: Это самый критичный момент. Штатный обмен УНФ -> БП настроен на стандартную логику. Если в УНФ движения делает банковский документ, а в БП — кассовый, то после выгрузки вы получите дублирование проводок 50-51 в бухгалтерской базе. Вам придется переписывать правила обмена в DataExchange.
• Отчеты: Отчет «Денежные средства» может начать выводить пустые аналитики, если связь документов будет нарушена. Проверьте заполнение реквизита ДокументПодтверждение.
• Человеческий фактор: Если бухгалтер создаст Расход со счета, а кассир забудет создать Поступление в кассу, деньги «исчезнут» из системы (с банка списались, в кассу не пришли). В стандартной логике УНФ такая ошибка невозможна, так как документ один.

Рекомендация по использованию УНФ 3.0

Проанализируем ситуацию в новых версиях системы. В УНФ 3.0 (и последних релизах 1.6) разработчики добавили возможность более гибкой привязки банковской выписки к кассовым документам. Мы рекомендуем не «ломать» проведение документов, а использовать функционал «Связанные документы». В банковской выписке, загруженной из клиент-банка, можно просто указать ссылку на уже созданный документ Поступление в кассу. Это сохранит чистоту учета и обеспечит корректную работу всех отчетов.

Заключение

Усложнение упрощенного расхода в УНФ — задача, требующая понимания архитектуры регистров. Если ваша цель — прозрачный контроль, используйте схему с промежуточным счетом (деньги в пути). Это наиболее безопасный и профессиональный метод. Если же вы решите прибегнуть к программированию, помните о необходимости синхронной правки обоих документов (и банка, и кассы) и обязательной корректировке правил обмена с бухгалтерией.