В процессе работы с программным продуктом 1С:Бухгалтерия предприятия 3.0 пользователи нередко сталкиваются с ситуацией, когда автоматизация начинает работать против них. Одной из таких проблем является некорректное заполнение реквизита БанковскийСчет в документе Поступление на расчетный счет при импорте данных из клиент-банка. Рассмотрим ситуацию: у организации открыто несколько счетов (например, в ВТБ и Альфа-Банке). Покупателю выписан Счет на оплату покупателю, в котором указаны реквизиты ВТБ. Однако покупатель по разным причинам (ошибся, скопировал старую платежку или ему так удобнее) перечисляет деньги на счет в Альфа-Банке. При загрузке выписки по Альфа-Банку система распознает оплату, находит счет-основание и... самопроизвольно меняет расчетный счет организации в документе на ВТБ, игнорируя тот факт, что выписка загружается по совершенно другому банку.
В данной статье мы подробно разберем, почему так происходит, проанализируем техническую сторону вопроса и выясним, как окончательно устранить эту проблему.
Проанализируем ситуацию с точки зрения программной логики. Система 1С при загрузке текстового файла выписки (или через прямой обмен DirectBank) выполняет последовательный алгоритм заполнения данных. На первом этапе программа корректно определяет, по какому счету организации пришла оплата, считывая номер расчетного счета из файла выписки. Однако далее вступает в силу механизм автоматического поиска документов-оснований.
Процедура поиска ищет подходящий Счет на оплату покупателю по следующим критериям:
Как только подходящий Счет на оплату покупателю найден, программа инициирует процедуру ЗаполнитьПоСчетуНаОплату. До возникновения ошибки №60002491 в коде типовой конфигурации приоритет данных из найденного счета-основания был выше, чем приоритет данных, полученных непосредственно из банковского файла. В результате программа принудительно перезаписывала поле БанковскийСчет в созданном документе Поступление на расчетный счет значениями из счета на оплату. Это приводило к серьезным искажениям в бухгалтерском учете: деньги фактически лежат на одном счету, а по программе "числятся" на другом, что делает невозможным корректную сверку с банком (формирование 51 счета). Для исправления уже возникших расхождений в учете подойдёт обработка для массовой замены счёта и аналитики в банковских проводках.
Выясним статус данной проблемы. Разработчики фирмы 1С признали наличие ошибки под кодом 60002491 (ранее фиксировалась как 60002005). Ошибка была официально исправлена. Рассмотрим, какие версии конфигурации содержат исправление:
Для полного устранения бага необходимо обновить конфигурацию 1С:Бухгалтерия предприятия 3.0 до версии 3.0.121.25 или выше. В актуальных релизах веток 3.0.122, 3.0.125 и далее этот механизм работает корректно: при заполнении документа на основании счета приоритет остается за расчетным счетом, по которому фактически загружается выписка. При наличии нескольких информационных баз для автоматизации этой операции можно настроить обновление конфигураций 1С по расписанию без участия пользователя.
Чтобы проверить текущую версию программы, выполним следующие шаги:
Если по каким-то причинам вы не можете выполнить полноценное обновление конфигурации прямо сейчас (например, база сильно доработана или закрывается период), воспользуемся механизмом расширений (патчей). Разработчики выпустили специальный патч под названием EF_60002491.
Разберем процесс установки патча по шагам:
EF_60002491 и нажмем "Далее" для установки.После установки патча и перезапуска сеанса 1С алгоритм сопоставления изменится, и расчетный счет организации перестанет "прыгать" при подцеплении счета на оплату.
Если вы хотите временно избежать возникновения ошибки без установки обновлений, мы можем изменить настройки автоматического заполнения. Это заставит программу меньше полагаться на автоматический поиск счетов, что минимизирует риск подмены данных.
Проанализируем настройки в интерфейсе:
БанковскийСчет.Даже после исправления ошибки, рекомендуем проверять корректность реквизита Договор. Часто случается сопутствующая проблема: если в счете на оплату указан один договор, а в выписке — другой, система может отдать приоритет договору из счета. Чтобы избежать путаницы в аналитике по 62 счету, после загрузки выписок целесообразно воспользоваться отчетом Анализ субконто по контрагентам, чтобы убедиться, что оплаты не "зависли" на неверных договорах или счетах организации. Для автоматической корректировки соответствия договоров можно использовать расширение для подстановки договоров при загрузке банковских выписок в 1С:Бухгалтерии.
Важный момент: если вы используете обработку "Клиент-банк" сторонних разработчиков, убедитесь, что в них не зашит аналогичный ошибочный алгоритм. В типовом механизме 1С проблема решается строго обновлением до 3.0.121.25.
Рассмотрим краткий пример кода, который описывает логику исправления в модулях системы (условно):
// Было (упрощенно):
Если НайденСчетНаОплату Тогда
Объект.БанковскийСчет = НайденСчетНаОплату.БанковскийСчет; // ОШИБКА: перезапись счета из выписки
КонецЕсли;
// Стало после исправления:
Если НайденСчетНаОплату Тогда
// Заполняем аналитику, но сохраняем счет организации из выписки
СчетОрганизацииИзВыписки = Объект.БанковскийСчет;
ЗаполнитьПоСчетуНаОплату(Объект, НайденСчетНаОплату);
Объект.БанковскийСчет = СчетОрганизацииИзВыписки; // ВОЗВРАТ верного счета
КонецЕсли;
Таким образом, мы выяснили, что корень проблемы лежал в приоритетах заполнения объектов. Следуя приведенным инструкциям по обновлению или патчингу системы, вы сможете восстановить корректную работу обмена с банками и избежать ошибок в учете денежных средств.