При подготовке к экзамену «1С:Специалист по внедрению прикладного решения 1С:Бухгалтерия предприятия 3.0» (в частности, при решении Билета №1) кандидаты часто сталкиваются с крайне неприятной «плавающей» ошибкой. При проведении стандартного документа Списание с расчетного счета программа неожиданно формирует проводки по налоговому учету (НУ). На первый взгляд, условия и параметры учета полностью совпадают, но в одной базе документ проводится корректно, а в другой — генерирует странные движения.
В этой статье мы подробно разберем, почему возникает этот дисбаланс, как он связан с методикой сдачи экзамена и багами интерфейса документа Операция, введенная вручную, а также выработаем четкий алгоритм, как избежать подобных ошибок на аттестации.
---
Для начала проанализируем методическую основу первого билета. В нем рассматривается классическая схема: «Договор займа в валюте через агента». В решении этой задачи активно задействуются следующие механизмы:
66.23 и 66.24.76.29 («Разные дебиторы и кредиторы в валюте»).Важная методическая тонкость экзамена: по условиям большинства задач переоценка валютных остатков должна выполняться строго в конце месяца специальной регламентной операцией. Однако типовая конфигурация 1С:Бухгалтерия 3.0 спроектирована так, что она переоценивает валютные активы и обязательства непосредственно в момент проведения повседневных документов (например, при оплате или списании валюты с расчетного счета).
Чтобы обойти это поведение на экзамене, применяется стандартный прием:
66.23, 66.24 и 76.29 добавляются в регистр сведений «Счета с особым порядком переоценки» с установленным признаком «Не переоценивать». Это блокирует расчет курсовых разниц при проведении оперативных документов (таких как Списание с расчетного счета).Закрытие месяца эти счета временно удаляются из регистра, чтобы регламентная операция успешно рассчитала курсовые разницы на конец периода.---
Рассмотрим ситуацию: вы отразили начисление задолженности перед агентом в валюте, используя документ Операция, введенная вручную (счет кредита — 76.29). Далее вы делаете выплату агенту документом Списание с расчетного счета (Дт 76.29 - Кт 52).
В проводках списания неожиданно появляются суммы по налоговому учету (НУ). Почему это происходит?
В платформе 1С:Предприятие на уровне регистра бухгалтерии всегда должно соблюдаться ключевое балансовое равенство:
БУ = НУ + ПР + ВР
(где БУ — бухгалтерский учет, НУ — налоговый учет, ПР — постоянные разницы, ВР — временные разницы)
Если в исходной ручной операции, которой фиксировалось обязательство по кредиту счета 76.29, вы указали сумму БУ (и валютную сумму), но по какой-то причине колонка «Сумма Кт НУ» осталась пустой (равной нулю) при отсутствии ПР и ВР, в системе возникает критический перекос:
76.29 числится валютный остаток и его рублевый эквивалент.Когда проводится последующий документ Списание с расчетного счета, его алгоритмы пытаются сопоставить остатки и закрыть (или частично погасить) задолженность. Видя, что по БУ рублевое покрытие есть, а по НУ оно отсутствует, система автоматически генерирует корректирующие движения по налоговому учету. Программа делает это принудительно, чтобы закрыть «зависшую» разницу и восстановить балансовое равенство на счете учета.
---
Выясним, почему же в исходном документе Операция, введенная вручную (ОперацияБух) колонка налогового учета может оказаться незаполненной. Это связано с особенностями проектирования управляемой формы документа в типовой конфигурации 1С:Бухгалтерия 3.0.
В форме ручной операции автоматический расчет сумм НУ, ПР и ВР привязан к обработчикам событий ПриИзменении на клиенте. Алгоритм работает следующим образом:
Однако если нарушить этот «естественный» порядок заполнения строки, автоматика дает сбой. Например, если вы сначала ввели сумму БУ, а затем выбрали или изменили счет кредита на субсчет, поддерживающий НУ (например, 76.29), то повторного вызова пересчета не происходит. Колонка «Сумма Кт НУ» остается пустой, хотя визуально строка кажется заполненной.
Для обхода этого бага на практике применяют следующее решение:
ПриИзменении, и программа корректно рассчитает показатели налогового учета.---
Чтобы гарантированно исключить подобные ошибки при сдаче экзамена «1С:Специалист по БП 3.0», рекомендуем придерживаться следующих правил:
После ввода абсолютно любой ручной операции обязательно сформируйте Оборотно-сальдовую ведомость по используемому счету (в нашем случае 76.29). Перед этим зайдите в настройки отчета на вкладку «Показатели» и включите отображение всех величин:
Если в колонке «Контроль» после проведения вашей ручной операции появилось любое значение, отличное от нуля — вы допустили ошибку при заполнении документа. Сразу же возвращайтесь в операцию и проверяйте показатели НУ.
При работе с документом Операция, введенная вручную всегда придерживайтесь правила: сначала аналитика, потом сумма. Заполняйте поля строки строго слева направо. Сначала выберите счета Дт/Кт, заполните все субконто, укажите валюту и валютную сумму, и только в самом конце вводите рублевую сумму БУ. Всегда контролируйте глазами появление значений в колонках НУ.
Помните, что на экзамене «1С:Специалист» за необоснованное использование ручных операций снимаются штрафные баллы. Попытка решить задачу «простыми проводками» там, где предусмотрен типовой документ (например, Корректировка долга, Поступление доп. расходов или ГТД по импорту), будет расценена экзаменатором как грубая ошибка.
Используйте документ Операция, введенная вручную исключительно в тех случаях, когда отразить операцию типовыми средствами физически невозможно (например, начисление сложных процентов по договору займа, не автоматизированное в БП 3.0).