В современной практике ведения бухгалтерского учета в 1С:Бухгалтерия 3.0 пользователи все чаще сталкиваются с необходимостью изменения привычных алгоритмов работы. Одной из таких задач является переход на использование счета 60.02 для учета комиссий по эквайрингу (вместо традиционного 91.02), что обусловлено изменениями в методологии учета, вступающими в силу в ближайшие периоды. Однако при автоматической загрузке банковских выписок или даже при ручном создании документов «Поступление на расчетный счет» с видом операции «Поступление по платежным картам», программа часто игнорирует настройки и настойчиво подставляет счет 91.02.
Рассмотрим подробно причины этой проблемы, проанализируем технические нюансы программного кода и разберем по шагам, как можно добиться корректного заполнения данных.
В первую очередь разберем ситуацию с точки зрения разработчиков 1С. Существует официально зафиксированная Ошибка № 70140807. Суть ее заключается в том, что при загрузке документа «Поступление на расчетный счет» система принудительно устанавливает счет учета затрат 91.02, полностью игнорируя пользовательские настройки в справочнике «Виды оплат».
Проанализируем программный код типовой конфигурации. Даже в последних релизах (начиная с 3.0.195.xx и выше) эксперты отмечают наличие жесткой привязки (hardcode) к счету 91.02 в модулях, отвечающих за обработку банковских документов. Это означает, что при выполнении определенных условий алгоритм 1С считает операцию комиссией банка по умолчанию и перезаписывает значение счета, которое было подтянуто из настроек договора или вида оплаты.
Выясним, правильно ли заданы базовые настройки. Для того чтобы система понимала, какой счет использовать, необходимо убедиться в корректности заполнения справочника ВидыОплат. Рассмотрим по шагам:
Если после этих настроек при выборе вида оплаты в документе счет все равно меняется на 91.02, значит, срабатывает обработчик события ПриИзменении, который имеет более высокий приоритет, чем данные из справочника.
Проанализируем ситуацию с точки зрения глобальных настроек. Автоматическая подстановка счета 60.02 часто блокируется, если система не может верифицировать статью затрат. Рассмотрим, как это работает:
В последних патчах была внедрена зависимость от регистра «Счета учета номенклатуры» и настроек учетной политики. Если в организации установлен основной счет учета затрат (например, 26 или 44), 1С может пытаться сопоставить банковскую комиссию с этими счетами. Если сопоставление не удается, происходит сброс на предопределенный в коде счет 91.02.
Важный момент со статьей затрат: проверьте, какая статья выбрана для комиссии в виде оплаты. Если у статьи затрат вид расхода не соответствует «Прочим расходам» или «Услугам банков», или если в ней некорректно установлены флаги налогового учета, система может посчитать настройку ошибочной и вернуть значение по умолчанию.
Посмотрим на пример ручного заполнения документа. В 1С:Бухгалтерия порядок действий пользователя напрямую влияет на результат. Существует технический нюанс: алгоритм заполнения реквизитов счета затрат срабатывает в момент выбора Вида оплаты.
Если вы сначала вводите сумму документа, а затем выбираете вид оплаты — счет может подтянуться верно. Однако, если после этого вы измените сумму комиссии или статью затрат, сработает процедура пересчета, которая в типовых конфигурациях часто обращается к общему модулю ЗаполнениеБухгалтерскихСчетов. В этом модуле приоритет 91-го счета для операций эквайринга может быть прописан жестко.
Разберем еще одну возможную причину. В версиях программы 3.0.150 и старше был изменен механизм работы с комиссиями. Если у вас включен расширенный учет затрат в Настройках функциональности, программа ожидает более детальной аналитики.
Выясним, как проверить влияние этого механизма:
Если стандартные настройки не помогают, рассмотрим технические способы исправления ситуации:
1. Очистка кэша метаданных. Зафиксированы случаи, когда после установки исправляющих патчей 1С продолжает использовать старые алгоритмы из-за кэширования. Требуется очистка кэша на сервере или локальном компьютере пользователя.
2. Использование расширений. Поскольку проблема часто кроется в жестко прописанном счете в модуле МенеджерРасчетов или подобных, наиболее эффективным решением будет создание небольшого расширения, которое перехватывает процедуру заполнения счетов. Пример логики, которую следует реализовать в расширении:
&После("ЗаполнитьСчетаУчета")
Процедура Расш_ЗаполнитьСчетаУчета(ДанныеДокумента)
Если ДанныеДокумента.ВидОперации = ПредопределенноеЗначение("Перечисление.ВидыОперацийПоступлениеДенежныхСредств.ПоступлениеПоПлатежнымКартам") Тогда
Если ЗначениеЗаполнено(ДанныеДокумента.ВидОплаты) Тогда
ДанныеДокумента.СчетЗатрат = ДанныеДокумента.ВидОплаты.СчетЗатрат;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
3. Проверка настроек ДиректБанка. Если вы используете прямой обмен с банком, проверьте настройки маппинга полей в настройках обмена. Иногда значение 91.02 прописывается в самой схеме обмена как значение по умолчанию для поля «Комиссия», и оно перекрывает любые настройки внутри базы 1С.
Подводя итог, можно сказать, что проблема автоматической подстановки 91.02 вместо 60.02 носит комплексный характер. Она сочетает в себе как недоработки типового кода (подтвержденные номером ошибки 70140807), так и строгую зависимость от последовательности заполнения реквизитов и типов договоров. Для исправления ситуации рекомендуется сначала убедиться в использовании договора типа Прочее и корректной статьи затрат, а в случае неудачи — применить корректирующее расширение конфигурации, пока разработчики не выпустят финальное исправление в коде ядра системы. А если требуется скорректировать уже сформированные документы прошлых периодов, можно использовать обработку для массовой замены счёта и аналитики в банковских проводках.