В практике работы государственных учреждений, особенно в сфере социального обслуживания, часто возникает ситуация, когда одним документом Приходный кассовый ордер необходимо отразить поступление денежных средств от множества различных контрагентов (например, оплата услуг по списку жильцов или подопечных). Стандартная логика программы 1С:Бухгалтерия государственного учреждения 2.0 (БГУ 2.0) предполагает, что в проводках по дебету счета 201.34 и кредиту счетов расчетов (205.ХХ, 209.ХХ) подставляется тот контрагент, который указан в «шапке» документа. Однако для корректного ведения взаиморасчетов бухгалтерии требуется, чтобы в субконто счета расчетов попадали контрагенты, соответствующие договорам из табличной части документа.
Рассмотрим детально, как реализовать эту задачу технически, и разберем методологические последствия такого решения.
Главная особенность БГУ 2.0 заключается в том, что алгоритмы формирования бухгалтерских проводок не «зашиты» жестко в программный код модулей документов. Вместо этого используется механизм типовых операций. Это справочник, в котором для каждого вида документа описаны правила заполнения дебета, кредита и их субконто.
Проанализируем шаги, необходимые для изменения логики заполнения контрагента:
Типовые операции (раздел «Администрирование» — «Настройка параметров учета» или непосредственно из формы документа через выбор операции).Контрагенты.В стандартной настройке для этого субконто указано значение Объект.Контрагент. Это означает, что система берет значение из реквизита «Контрагент», расположенного в основной части (шапке) документа. Чтобы система брала данные из строк, нам нужно изменить формулу.
Поскольку ПКО может содержать многострочную табличную часть «Расшифровка платежа», система при формировании проводок совершает цикл по этой таблице. В контексте типовой операции мы можем обращаться к данным текущей строки.
Проанализируем ситуацию: если в табличной части ПКО есть колонка Договор, то контрагент является владельцем этого договора. Следовательно, в настройке субконто вместо Объект.Контрагент мы можем прописать путь к данным через договор. Выражение будет выглядеть следующим образом:
Строка.Договор.Владелец
Где Строка — это итератор текущей строки табличной части документа, Договор — реквизит строки, а Владелец — системное поле справочника «Договоры», в котором и хранится ссылка на контрагента.
Важный момент: если вы планируете выводить контрагента в саму табличную часть как отдельную колонку (чего изначально нет в типовой конфигурации для ПКО), то обращение будет идти напрямую к реквизиту строки: Строка.Контрагент.
Часто программисты сталкиваются с проблемой: в конфигураторе в составе табличной части РасшифровкаПлатежа реквизиты есть, а на форме в режиме «1С:Предприятие» они отсутствуют. Выясним причину этого поведения.
В БГУ 2.0 интерфейс документов часто строится динамически. Управление видимостью колонок может осуществляться:
ПриСозданииНаСервере. Если логика документа предполагает, что для определенного вида операции (например, «Поступление от покупателя») договор не нужен, программа может скрывать эту колонку.Если вам необходимо добавить новую колонку (например, «Контрагент») непосредственно в таблицу расшифровки, вам придется зайти в модуль формы и проверить настройки размещения элементов. Рассмотрим пример программного добавления колонки, если она отсутствует в метаданных формы, но есть в объекте:
// Пример логики в ПриСозданииНаСервере (упрощенно)
НовыйЭлемент = Элементы.Добавить("РасшифровкаПлатежаКонтрагент", Тип("ПолеФормы"), Элементы.РасшифровкаПлатежа);
НовыйЭлемент.Вид = ВидПоляФормы.ПолеВвода;
НовыйЭлемент.ПутьКДанным = "Объект.РасшифровкаПлатежа.Контрагент";
Несмотря на техническую возможность «схлопнуть» 2000 записей в один документ ПКО, рассмотрим, почему это может быть опасным с точки зрения законодательства.
Во-первых, согласно требованиям кассовой дисциплины, ПКО оформляется на фактически принятую сумму от конкретного лица. В печатной форме ПКО (КО-1) есть поле «Принято от», где должна стоять фамилия плательщика. Если в одном ПКО у вас 100 человек, печатная форма не позволит корректно отобразить их всех, что является нарушением требований Минфина (Приказ № 52н).
Во-вторых, в соответствии с 54-ФЗ, при приеме наличных денег от физических лиц учреждение обязано выдать кассовый чек. Чек должен содержать информацию о конкретном плательщике и услуге. Один общий ПКО на общую сумму не позволяет сформировать корректные чеки для каждого клиента.
Вместо того чтобы мучить документ ПКО, разберем более современный и правильный способ автоматизации массовых поступлений:
Чек ККМ. Он создается гораздо быстрее, чем ПКО, и позволяет выбрать конкретного контрагента и договор.Чеков ККМ в конце дня формируется документ Отчет по кассовой смене.Отчет по кассовой смене автоматически сформирует сводный Приходный кассовый ордер для отражения общей суммы выручки в кассовой книге, но при этом детальная аналитика по контрагентам сохранится в учете благодаря первичным чекам.Если данные загружаются из сторонней программы (например, специализированной системы учета соц. услуг), рекомендуется рассмотреть вариант загрузки не в ПКО, а в документ Кассовое поступление (если оплата идет через банк) или использовать промежуточный реестр, на основании которого программа сама создаст нужное количество документов Чек ККМ.
Резюме: Технически задача решается правкой типовой операции и изменением пути к данным субконто на Строка.Договор.Владелец. Однако перед внедрением этого решения обязательно обсудите с главным бухгалтером риски нарушения кассовой дисциплины и требования по применению ККТ.