Ситуация, когда в отчете Карточка счета по счету 62.01 (Расчеты с покупателями и заказчиками) внезапно появляется отрицательное сальдо («краснота») в момент проведения реализации, часто вызывает беспокойство у бухгалтеров. На первый взгляд это кажется ошибкой: товар только что отгружен, задолженность должна быть положительной, а программа показывает минус. Рассмотрим подробно, почему это происходит в 1С:Бухгалтерия 3.0, проанализируем внутреннюю логику программы и выясним, нужно ли с этим бороться.
Для начала проанализируем, как именно документ Реализация (акт, накладная) взаимодействует с регистрами бухгалтерии при наличии аванса от клиента. В системе заложен строгий алгоритм, который определяет последовательность формирования записей. Когда мы проводим документ реализации, программа выполняет следующие действия в рамках одной транзакции:
62.02 (Расчеты по авансам полученным) по конкретному контрагенту и договору. Если аванс найден, система формирует проводку Дебет 62.02 Кредит 62.01. Эта запись «перебрасывает» деньги с авансового счета на счет расчетов.В чем же кроется причина «минуса»? Проанализируем ситуацию: в момент формирования первой проводки (зачет аванса) сумма попадает в Кредит счета 62.01. Если до этого момента на счете 62.01 не было дебиторской задолженности, то по правилам бухгалтерского учета остаток по счету становится отрицательным. Спустя микросекунду (в рамках того же документа) формируется вторая проводка, где сумма попадает в Дебет счета 62.01, и сальдо выравнивается до нуля или до суммы остатка долга.
Выясним причину, по которой мы видим этот технический минус в отчетах. Отчет Карточка счета — это максимально детализированный отчет, который выводит информацию в хронологическом порядке вплоть до каждой отдельной проводки (строки) внутри документа. По умолчанию 1С:Бухгалтерия сортирует записи внутри одного регистратора следующим образом:
Поскольку алгоритм программы сначала делает зачет аванса, а потом начисляет выручку, в карточке счета мы видим их именно в такой последовательности. Первая строка создает искусственный минус, вторая его закрывает. Если бы программа формировала проводки в обратном порядке (сначала выручка, потом зачет аванса), минуса бы не возникло, но логика 1С построена на приоритете определения источника покрытия задолженности.
Чтобы убедиться, что данные в базе верны и «краснота» носит лишь визуальный характер, выполним следующие действия:
62.01 с детализацией по субконто (Контрагенты, Договоры, Документы расчетов). В этом отчете данные группируются по результатам работы всего документа. Если итоговое сальдо после проведения реализации не является отрицательным, значит, учет ведется корректно.62.01 и 62.02). Если развернутое сальдо (по дебету одного и кредиту другого) отсутствует, то зачет аванса прошел успешно.Поступление на расчетный счет и Реализация имеют одинаковое время, но реализация по какой-то причине оказалась в списке раньше. В этом случае достаточно изменить время реализации на несколько секунд позже или воспользоваться обработкой Групповое перепроведение документов.Рассмотрим способы решения проблемы, если бухгалтерия настаивает на эстетичном виде отчетов без отрицательных значений внутри документа:
1. Объяснение методологии (Рекомендуемый способ). Важно донести до пользователей, что возникновение временного отрицательного остатка в рамках одной секунды внутри одного документа-регистратора не является нарушением правил бухгалтерского учета. Нормативные акты (ПБУ) регулируют итоговую достоверность отчетности, а не последовательность технологических записей в базе данных. Поскольку итоговое сальдо в ОСВ верное, налоговые и финансовые риски отсутствуют.
2. Изменение сортировки в отчете.
К сожалению, в типовой конфигурации 1С:Бухгалтерия 3.0 отчет Карточка счета имеет жесткую структуру. Однако можно попробовать настроить Универсальный отчет по регистру бухгалтерии, где задать собственную сортировку. Но на практике это редко удовлетворяет требования бухгалтера к стандартному виду карточки.
3. Использование сторонних расширений.
Программист может написать небольшое расширение, которое будет принудительно менять порядок следования проводок (поле НомерСтроки) в документе реализации. Например, чтобы проводка Дт 62.01 Кт 90.01.1 всегда шла под номером 1, а зачет аванса Дт 62.02 Кт 62.01 — под номером 2. Рассмотрим пример того, как это выглядит логически на уровне кода (метакод):
// В процедуре обработки проведения реализации
// После формирования всех проводок
Проводки = ЭтотОбъект.Движения.Хозрасчетный;
Для Каждого Запись Из Проводки Цикл
Если Запись.СчетДт = ПланыСчетов.Хозрасчетный.РасчетыСПокупателями Тогда
Запись.НомерСтроки = 1; // Условно ставим реализацию первой
ИначеЕсли Запись.СчетКт = ПланыСчетов.Хозрасчетный.РасчетыСПокупателями Тогда
Запись.НомерСтроки = 2; // Зачет аванса вторым
КонецЕсли;
КонецЦикла;
Важное замечание: Мы не рекомендуем менять типовые алгоритмы проведения без острой необходимости, так как это может повлиять на логику работы других механизмов (например, расчет НДС или работу партионного учета).
Проанализировав ситуацию, мы выяснили: появление «красного» сальдо в карточке счета 62.01 — это штатное поведение программы 1С:Бухгалтерия 3.0. Оно обусловлено архитектурой системы, где зачет аванса предшествует начислению выручки в коде проведения документа.
Главные выводы нашего разбора:
Оборотно-сальдовой ведомости итоговое сальдо за день корректное — ошибки нет.Карточке счета из-за детализации до каждой строки проводки.Помните, что современные ERP-системы оптимизированы для корректного итогового результата, и микро-колебания внутри одного документа являются допустимой технической особенностью.