В современной практике бухгалтерского учета метод LIFO (Last-In, First-Out — «последним пришел, первым ушел») запрещен для целей регламентированного учета (ПБУ 5/01, а затем и ФСБУ 5/2019). Однако в управленческом учете руководители и финансовые службы часто запрашивают информацию о себестоимости реализации именно в разрезе последних поступлений, чтобы понимать текущую маржинальность бизнеса в условиях инфляции. Рассмотрим ситуацию, когда в конфигурации 1С:Бухгалтерия 3.0 (БП 3.0) установлен метод оценки «По средней», но стоит задача оперативно получать данные по конкретным партиям (поступлениям) методом LIFO.
Когда в настройках учетной политики 1С выбран метод «По средней», система списывает товары по средней стоимости, накопленной на остатках счета 41 (Товары) на момент проведения документа. При этом в проводках отсутствует информация о том, из какого конкретно ДокументаПоступления пришел товар. Бухгалтеру приходится вручную анализировать КарточкуСчета 41, сопоставляя реализации с последними приходами. Разберем, как автоматизировать этот процесс программными средствами и настройками типовой конфигурации.
Проанализируем техническую возможность платформы БП 3.0. Несмотря на выбранный метод «По средней», мы можем заставить систему фиксировать партии. Для этого выполним следующие действия:
Важный нюанс: Установка этого флага не изменит расчет себестоимости в бухгалтерских проводках (она останется «по средней»), но добавит на счете 41 третье субконто — Партии. После перепроведения документов в регистре бухгалтерии появится информация о конкретных поступлениях, из которых сформировался остаток. Это позволит нам строить отчеты на базе стандартного регистра бухгалтерии без сложных вычислений «на лету».
Если мы не хотим менять настройки учета или перепроводить исторические данные, нам потребуется разработать отчет, который будет виртуально восстанавливать цепочку списания. Проанализируем алгоритм построения такой таблицы:
Шаг 1: Формирование таблицы приходов и расходов.
Нам необходимо собрать все обороты по конкретной номенклатуре за период. Напишем запрос к регистру Хозрасчетный, выбирая данные по счету 41. Нам важны: период, документ (регистратор), количество прихода и количество расхода.
Шаг 2: Реализация логики стека (LIFO).
В отличие от FIFO, где мы берем первые записи, для LIFO нам нужно сортировать таблицу приходов в обратном хронологическом порядке. Рассмотрим пример кода для формирования выборки партий:
// Пример формирования запроса для получения последних поступлений
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ХозрасчетныйОбороты.Регистратор КАК ДокументПоступления,
| ХозрасчетныйОбороты.КоличествоОборотДт КАК КоличествоПриход,
| ХозрасчетныйОбороты.СуммаОборотДт КАК СуммаПриход,
| ХозрасчетныйОбороты.Период КАК Период
|ИЗ
| РегистрБухгалтерии.Хозрасчетный.Обороты(&НачалоПериода, &КонецПериода, Регистратор, Счет = &Счет41, , Номенклатура = &Номенклатура, , ) КАК ХозрасчетныйОбороты
|ГДЕ
| ХозрасчетныйОбороты.КоличествоОборотДт > 0
|УПОРЯДОЧИТЬ ПО
| Период УБЫВ"; // Ключевой момент: обратная сортировка для LIFO
Шаг 3: Расчет себестоимости конкретной реализации.
Выясним причину сложности: при расчете реализации за июнь нам нужно знать, какие остатки «дожили» до этого момента после всех предыдущих продаж. Процесс должен быть итерационным:
Период УБЫВ).Проанализируем ситуацию с возвратами товаров от покупателя (как в Сообщении 7 обсуждения). В логике LIFO возврат — это «новое» поступление товара, которое должно встать на самый верх стека. То есть, при следующей реализации этот возвращенный товар должен списаться первым, так как он физически (или логически) является самым «свежим» на складе.
В программном коде это реализуется добавлением документов ВозвратТоваровОтПокупателя в общую таблицу партий-приходов с положительным знаком и текущей датой возврата.
Разберем предупреждение из Сообщения 10 форума. Если мы пытаемся построить отчет за большой период для всей номенклатуры сразу, система может столкнуться с проблемой производительности. Поскольку расчет каждой последующей реализации зависит от результатов предыдущей, классический SQL-запрос может стать слишком громоздким.
Рекомендация: Для оптимизации лучше использовать временные таблицы (МенеджерВременныхТаблиц) и производить расчеты в коде 1С (через обход выборки), фиксируя промежуточные остатки партий в таблице значений. Это позволит избежать рекурсивных запросов к базе данных.
Подведем итог: автоматизация списания по LIFO в БП 3.0 возможна двумя путями. Первый — включение штатного субконто Партии, что является наиболее стабильным вариантом. Второй — разработка внешнего отчета на СКД с использованием запросов с обратной сортировкой по периоду. Проанализировав ситуацию, мы видим, что даже при официальном учете «по средней», механизмы 1С позволяют гибко извлекать данные для нужд управленческого анализа, избавляя бухгалтера от ручного перебора карточек счетов.