В процессе взаимодействия государственных учреждений с органами Федерального казначейства (ФК) часто возникает необходимость выгрузки кода экономической классификации — КЭК (КОСГУ) — в файл обмена платежного поручения. Поскольку КЭК по умолчанию не входит в структуру стандартного 20-значного кода бюджетной классификации (КБК), типовые механизмы обмена не всегда передают его автоматически. Из-за этого региональные казначейские системы (такие как «Бюджет-СМАРТ», «Смарт ВебБюджет» или локальные версии СУФД) могут отвергать файлы обмена, требуя наличия КЭК в строго определенных полях.
В рамках этой статьи мы подробно разберем, как правильно настроить формат выгрузки платежных поручений в «1С:Бухгалтерия государственного учреждения 1.0» (БГУ 1.0) для передачи КЭК как в простых (однострочных) документах, так и в сложных многострочных поручениях. Также мы проанализируем и устраним популярную ошибку проведения документа «КЭК дебита не заполнен», которая часто возникает у пользователей после изменения настроек обмена.
Прежде чем приступать к конфигурированию правил обмена в 1С, выясним технические требования конкретного отделения Федерального казначейства. Разные региональные органы могут настраивать свои приемные комплексы по-разному. Чаще всего код КЭК (КОСГУ) требуют помещать в следующие поля файла обмена:
Для того чтобы точно определить целевое поле, выполним простое действие: сформируем и успешно заполним платежное поручение вручную непосредственно в интерфейсе СУФД, сохраним его в файл импорта и откроем этот файл обычным текстовым редактором (например, Блокнотом). Посмотрев, в каком именно теге или позиции строки находится КЭК, мы поймем, какое поле формата БГУ нам нужно корректировать.
Рассмотрим ситуацию, когда ваше учреждение формирует исключительно однострочные платежные поручения (то есть на вкладке «Расшифровка платежа» всегда присутствует ровно одна строка). В этом случае мы можем применить быстрое решение через прямое обращение к первому элементу табличной части документа.
Для этого в справочнике настройки форматов обмена найдем целевое поле (например, PPST.REZERV) и в колонке «Значение» укажем следующее пользовательское выражение:
Объект.РасшифровкаПлатежа[0].КОСГУНазначениеПлатежа
Этот способ крайне прост в реализации, однако имеет критический недостаток. Проанализируем ситуацию: если в документе появится вторая строка с другим кодом КОСГУ, программа проигнорирует её и во все строки выгружаемого файла подставит значение КЭК из самой первой строки табличной части. Это приведет к недостоверности передаваемых данных. Поэтому мы настоятельно рекомендуем использовать второй, универсальный метод.
Чтобы программа корректно обрабатывала любое количество строк в платежном поручении, нам необходимо задействовать штатный механизм циклического обхода табличной части, заложенный в обработку выгрузки 1С. Разберем этот алгоритм по шагам.
PPST.KBK (в зависимости от версии формата она может находиться под разными номерами, например, 53).*ТЧДокумента_ДопКл установим специализированную пометку: *ТЧДокумента_ДопКл_КЭК.ТЧ..PPST.REZERV) и вместо жесткого индексированного пути укажем динамическое выражение: ТЧ.КЭК.Посмотрим на пример того, как система обрабатывает эту настройку изнутри при формировании текстового файла выгрузки:
// Пример логики работы выгрузки при использовании пометки *ТЧДокумента_ДопКл_КЭК
Для Каждого СтрокаТЧ Из Объект.РасшифровкаПлатежа Цикл
Если ЗначениеЗаполнено(СтрокаТЧ.КЭК) Тогда
// Программа сопоставляет строку файла с текущей строкой ТЧ
ЗначениеПоляРезерв = СтрокаТЧ.КЭК.Код;
// Происходит запись значения КЭК для каждой строки индивидуально
КонецЕсли;
КонецЦикла;
Использование этого метода гарантирует, что сколько бы строк ни содержала табличная часть вашего платежного поручения, каждая из них будет выгружена со своим уникальным кодом КЭК (КОСГУ).
Часто после успешной настройки экспорта и работы с форматами обмена пользователи сталкиваются со следующей проблемой: при попытке провести измененное или новое платежное поручение программа выдает ошибку проведения: «Проводка 1: Не заполнен КЭК дебита» (или аналогичную по кредиту), и бухгалтерские проводки не формируются.
Выясним причину этой ошибки. Она не связана напрямую с выгружаемым файлом, а сигнализирует о внутренних расхождениях в аналитическом учете самой информационной базы. Рассмотрим четыре основные причины этой ошибки и методы их устранения.
В БГУ 1.0 для каждого балансового счета жестко закреплены допустимые коды КЭК для дебетовых и кредитовых оборотов. Например, для счета расчетов с поставщиками 302.26 по дебету должен автоматически подставляться КЭК 830 (уменьшение кредиторской задолженности), а по кредиту — 730 (увеличение задолженности).
Если автоматическое определение КЭК ломается, проверим настройки плана счетов:
206.00).Выбор корректных корреспондирующих счетов (и, соответственно, КЭК к ним) напрямую зависит от настройки авансов в платежном поручении. Если на вкладке «Параметры платежа» неверно установлен признак аванса, программа попытается сделать проводку по дебету счета 206.00 вместо счета 302.00. Если для счета авансов в системе не заполнена аналитика по КЭК, проведение завершится ошибкой. Внимательно проверьте этот флаг в проблемном документе.
Проанализируем табличную часть самого платежного поручения на вкладке «Расшифровка платежа». Если документ многострочный, необходимо убедиться, что колонка «КЭК» заполнена абсолютно во всех строках без исключения. Если хотя бы в одной строке поле осталось пустым, проведение документа будет заблокировано с ошибкой незаполненного КЭК дебита.
Проверьте выбранную в нижней части документа типовую операцию (например, «Оплата поставщикам (302.00, 206.00)»). Если операция выбрана неверно или ее параметры были случайно изменены, алгоритм проведения не сможет корректно сопоставить корреспондирующие счета с субконто КЭК. В качестве решения рекомендуется перевыбрать типовую операцию заново из справочника, очистить и заново заполнить субконто документа.