Проблема «зависания» копеек на счетах учета затрат (особенно на счете 20.02 «Производство полуфабрикатов») — одна из самых распространенных при закрытии месяца в конфигурации 1С:УПП 1.3. Ситуация, когда по одной номенклатурной позиции сумма по дебету не сходится с суммой по кредиту, может быть вызвана как техническими ошибками ввода данных, так и спецификой работы алгоритмов РАУЗ (Расширенной аналитики учета затрат). Проанализируем основные причины и пошагово разберем методы решения этой проблемы.
Первым делом проанализируем ситуацию через стандартные отчеты. Часто бухгалтеры замечают расхождения в Оборотно-сальдовой ведомости (ОСВ), но для поиска корня проблемы этого недостаточно. В системе УПП 1.3 при включенном режиме РАУЗ данные хранятся параллельно в бухгалтерском регистре и в регистре накопления УчетЗатратРег.
Если мы видим, что в ОСВ по счету 20.02 висит остаток, а количество закрыто в ноль, разберем следующие шаги:
Одной из самых частых причин, как показал разбор реальных ситуаций, является человеческий фактор. Рассмотрим ситуацию, когда в документе ПередачаТоваров (или ТребованиеНакладная) бухгалтер ошибочно указывает счет учета, не соответствующий настройкам номенклатуры или смыслу операции. Например, вместо счета 20.02 указывается счет 21.
В этом случае система РАУЗ может корректно отразить движение в своих регистрах по аналитике «Затраты», но бухгалтерская проводка уйдет на «чужой» счет. При расчете себестоимости документ РасчетСебестоимостиВыпуска будет пытаться закрыть затраты согласно данным регистров, что приведет к копеечным (или более крупным) остаткам в ОСВ из-за нестыковки корреспонденций.
Проанализируем влияние документа Операция (бухгалтерский и налоговый учет). Важно понимать, что в 1С:УПП 1.3 при использовании РАУЗ обычные бухгалтерские справки не делают движений по регистрам затрат. Рассмотрим последствия:
20.02 вручную.РасчетСебестоимостиВыпуска не «видит» этой правки, так как он работает с регистром Учет затрат (бухгалтерский и налоговый учет).Для исправления таких ситуаций необходимо использовать документ КорректировкаЗаписейРегистров, чтобы синхронизировать данные бухгалтерии и РАУЗ.
Если ошибки в документах исключены, а копейки все равно остаются, разберем техническую сторону РАУЗ. Расчет себестоимости в УПП выполняется методом решения Системы Линейных Алгебраических Уравнений (СЛАУ). Посмотрим, почему возникают погрешности:
СпособыРаспределенияЗатратНаВыпуск. Если база распределения слишком сложная или содержит ошибки в фильтрах, суммы могут распределяться «в никуда».Если визуальный анализ отчетов не помогает, попробуем выявить расхождения программно. Рассмотрим логику запроса, который сопоставляет данные регистра бухгалтерии и регистра накопления РАУЗ:
ВЫБРАТЬ
ХозрасчетныйОстатки.Счет,
ХозрасчетныйОстатки.Субконто1 КАК Номенклатура,
ХозрасчетныйОстатки.СуммаОстаток КАК СуммаБух,
УчетЗатратОстатки.СтоимостьОстаток КАК СуммаРАУЗ
ИЗ
РегистрБухгалтерии.Хозрасчетный.Остатки(&Период, Счет = ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.Полуфабрикаты), , ) КАК ХозрасчетныйОстатки
ПОЛНОЕ СОЕДИНЕНИЕ РегистрНакопления.УчетЗатрат.Остатки(&Период, , , ) КАК УчетЗатратОстатки
ПО ХозрасчетныйОстатки.Субконто1 = УчетЗатратОстатки.АналитикаВидаУчета.Номенклатура
ГДЕ
ЕСТЬNULL(ХозрасчетныйОстатки.СуммаОстаток, 0) <> ЕСТЬNULL(УчетЗатратОстатки.СтоимостьОстаток, 0)
Такой анализ позволит быстро выявить номенклатуру, по которой «разъехались» данные, и сузить область поиска до конкретного месяца.
Для окончательного устранения проблемы выполним следующие действия:
ВстречныйВыпускПродукцииУслуг, чтобы задать системе четкий алгоритм исключения встречных затрат.ПоступлениеДопРасходов. Если сумма доп. расхода не распределена по позициям вручную, РАУЗ распределит ее программно, что иногда вызывает копеечные расхождения с ОСВ из-за разных механизмов округления в документе и в итоговом расчете себестоимости.Таким образом, копейки на счете 20.02 — это почти всегда следствие либо нарушения аналитики (разные счета, разные номенклатурные группы), либо технологических особенностей СЛАУ при сложных схемах выпуска. Регулярная сверка Ведомости МПЗ и ОСВ позволит купировать эти ошибки на ранних этапах закрытия периода.