В практике работы с программой «1С:Бухгалтерия государственного учреждения 8» (редакция 2.0) бухгалтеры часто сталкиваются с ситуацией, когда документ Поступление услуг, работ или Поступление МЗ производит зачет аванса некорректно. Одной из наиболее неприятных ошибок является зачет суммы, превышающей фактический остаток выданного аванса, из-за чего по счету 206.00 (например, 206.23) образуется отрицательное («красное») сальдо. Рассмотрим подробно, почему это происходит и как привести учет в порядок.
Когда мы видим «красноту» по дебету счета 206.00 после проведения поступления, это сигнализирует о том, что алгоритм автоматического зачета «увидел» аванс там, где его либо нет, либо он числится по другой аналитике. Давайте разберем по шагам, какие факторы влияют на этот процесс.
Для корректного автоматического зачета аванса в 1С:БГУ 2.0 требуется абсолютное совпадение всей цепочки аналитических разрезов на счетах расчетов. Если система «видит» остаток на одном КПС, а документ поступления оформлен по другому, автоматика может сработать непредсказуемо или проигнорировать остаток. Проанализируем следующие параметры:
Договоры с одинаковыми названиями. Программа воспринимает их как разные объекты учета.Для детальной проверки сформируем отчет Оборотно-сальдовая ведомость по счету (например, 206.23) с максимальной детализацией по всем субконто, включая Документы расчетов. Если мы видим суммы в разных строках при одинаковых названиях — значит, есть расхождение в скрытых реквизитах или типах данных.
Важно понимать, что 1С:БГУ 2.0 при выполнении автоматических операций опирается не только на проводки по счетам (бухгалтерский регистр), но и на специализированные регистры накопления. Основным регистром для расчетов является Расчеты с контрагентами.
Рассмотрим ситуацию: по счету 206.23 остаток верный, а в регистре накопления из-за программного сбоя или некорректного ручного исправления проводок данные искажены. В этом случае документ Поступление услуг, работ, ориентируясь на регистр, может зачесть сумму, которой фактически нет на счете.
Для диагностики выполним следующие действия:
Проанализируем время проведения документов в пределах одного дня. Если оплата (аванс) и поступление услуг зафиксированы одной датой, критически важно, чтобы документ оплаты (Заявка на кассовый расход или Кассовое выбытие) был проведен раньше документа поступления.
Если Поступление услуг, работ проведено, например, в 09:00, а оплата прошла в 14:00, то на момент проведения поступления система не увидит аванса и не зачтет его автоматически. Если же ситуация обратная, и система зачитывает «лишнее», возможно, в этот же день были другие документы, которые уже использовали этот аванс, но последовательность проведения была нарушена.
Совет: Попробуем выполнить групповое перепроведение документов за месяц. Это часто решает проблемы с неверными остатками, возникшими из-за «перепутанного» времени документов.
В документе Поступление услуг, работ на вкладке Основные или в шапке документа (в зависимости от версии интерфейса) есть реквизит Зачет аванса. Рассмотрим доступные варианты:
Если автоматический режим работает некорректно, попробуем переключить способ на «По документу» и выбрать конкретную заявку на кассовый расход. Это позволит принудительно ограничить сумму зачета.
Как показывает практика, если автоматический документ продолжает ошибаться, можно воспользоваться механизмом Типовой операции. В документе поступления можно выбрать операцию, которая не предполагает автоматического зачета, а саму процедуру закрытия аванса выполнить отдельным документом Бухгалтерская операция или специализированным регламентным документом в конце месяца.
Разберем пример настройки в случае использования облачного сервиса или при подозрении на программную ошибку релиза:
Если мы работаем в 1С:Фреш или аналогичном облаке, иногда помогает принудительное обновление итогов. Перейдем в Администрирование — Обслуживание — Управление итогами и агрегатами. Выберем Установить основной период итогов на актуальную дату. Это заставит систему пересчитать остатки, на которые она опирается при проведении документов.
Если вышеперечисленные методы не помогли и «красный» остаток сохраняется, проанализируем ситуацию с технической точки зрения. Выполним Тестирование и исправление информационной базы (предварительно создав архивную копию!):
Конфигуратор.Администрирование — Тестирование и исправление.Проверка логической целостности и Пересчет итогов.Это восстановит внутренние связи в базе данных, что часто является ключом к решению проблем с «фантомными» авансами.
Подводя итог, отметим: для исправления ситуации с некорректным зачетом аванса в БГУ 2.0 необходимо последовательно проверить аналитику субконто, актуальность регистров накопления и временную последовательность документов. В большинстве случаев проблема кроется в разнице КПС или времени проведения оплаты и поступления.