Скользящая FIFO. Партионный учет в любой момент

Прежде чем говорить о моем методе, напомню азы партионного учета и различные подходы к FIFO.

Изначально был классический метод – это УТ 10, сейчас это «Бухгалтерия 3.0». Там тоже есть партионка – последовательное проведение, которое занимает очень много времени.

Потом шло развитие. В УТ 11 партии уже начали проводить в конце месяца. ERP пошла дальше – партионный учет версий 2.1, 2.2. Разницы сейчас нет, но суть такая: во-первых, у нас нет актуальных данных, потому что закрываем все в конце месяца. ERP закрывает партионку очень быстро, но кроме плюса во времени здесь есть и минусы.

Есть различные методы оценки по партиям. Самая простая – средняя за месяц. Это вообще не FIFO, поэтому ее рассматривать не будем.

Есть взвешенная оценка. Это подход современных ERP. У нас есть конечный остаток на конец месяца и последние поступления партий. Мы считаем, что последние поступления составляют остаток, все остальное, что приходило раньше, уже продали, и просто распределяем стоимость поступлений на расходы.

Когда мы распределяем стоимость поровну, получается взвешенная оценка: стоимость везде одинаковая, и для многих этого достаточно.

Либо мы делаем скользящую оценку, когда первые поступившие партии распределяются на начальные документы, затем идет середина, а последние партии – на конечные документы. Это уже скользящая оценка, которая в ERP делается по итогам закрытия месяца.

Здесь возникает большой вопрос: как система закрывает перемещения, комплектации и другие внутренние движения внутри периода. Когда появляется потребность расшифровать, как именно все произошло, начинаются проблемы. Мы должны согласиться с тем, как ERP все рассчитала, а часто сказать, как именно получился результат, не можем.

На иллюстрации скользящей FIFO цены партий постепенно растут – от 10 до 25 рублей. Но представим ситуацию: года три назад часть товара отгрузили на другой склад, там этот товар сгнил, протух, а затем его вернули обратно. Сейчас он составляет наш остаток и числится по 14 рублей.

Как при взвешенном подходе ERP учтет это при закрытии месяца, мы, по сути, не знаем. В зависимости от настроек система может это учитывать, а может не учитывать.

Вернемся к классическому расчету FIFO, когда расчет делается по каждому документу.

Слева направо у нас есть три партии. Первый документ забирает первые две партии. Второй документ смотрит на остаток и на результаты первого документа, забирает остаток второй и третью партию. Конечный остаток – третья партия.

Это основная разница между современным и классическим FIFO.

То же самое можно показать на привычном примере 1С.

У нас есть два регистра, которые работают согласованно: регистр товаров на складах и регистр партий товаров на складах. Соответственно, есть два отчета: ведомость по товарам и ведомость по партиям.

Согласованность заключается в том, что в здоровой системе начальный остаток, приход, расход и конечный остаток должны совпадать. Когда все хорошо, регистры согласованы.

А что происходит в реальности?

Те, кто пробовал считать партионку, знают эту ситуацию. У нас одна штука лежит на складе, при этом по партиям может быть +100, ?100, +1000, ?1000.

Почему так происходит? Потому что за несколько лет мы накопили огромное количество ошибок. Мы их не исправили и часто уже никак не можем исправить: прошлые периоды закрыты, а рассчитывать партии нужно сейчас.

Мы приходим к ситуации, когда на нас давят старые накопленные ошибки и мы ничего не можем с ними сделать.

Кто-то пытается преобразовать минусы в плюсы: из плюсов вычесть все минусы, что-то оставить, пересортировать. Но никто не гарантирует, что таким образом мы найдем правильную партию.

Если этого не делать и просто списывать плюс, мы можем списать очень давнюю партию – самую первую, которая пришла лет десять назад. Это тоже неправильный результат.

Мой авторский подход к FIFO

Теперь перейдем к моему подходу.

Я хочу здесь и сейчас, в любой момент, взять и провести любой документ. Если я знаю, что ничто другое на него не повлияет, я хочу сразу получить его себестоимость, то есть провести его по партиям.

Моя методика работает следующим образом. Расчет не зависит от порядка проведения документов. Он не зависит от того, какой бардак находится в регистре партий. При этом он учитывает все внутренние перемещения: комплектации, списания, оприходования и другие внутренние документы.

Базовая идея очень простая: не читаем остатки и движения партий.

В партиях у нас может находиться полная ерунда – я этот регистр не читаю, мне неинтересно, что там находится. Я читаю только остатки и движения товаров. То есть ориентируюсь на товары, их остатки и движения.

ERP при закрытии месяца подбирает поступления под остаток. Я делаю примерно то же самое, но в разрезе каждого документа.

Поступления и перемещения я дублирую в отдельный регистр поступлений, причем это регистр сведений. Это нужно и для оптимизации, и для быстрой выборки.

Есть регистр партий товаров, который мы должны восстановить. В него я только пишу, ничего оттуда не читая. Если включить разделение итогов, это приветствуется.

Подход может применяться не только в УТ. Это может быть и Бухгалтерия, потому что в бухгалтерии партионка, по сути, присутствует на 41-м счете, на 45-м, на 60-м, 62-м. Если поставить задачу внедрить такой механизм в Бухгалтерию, те же преимущества можно получить и там.

Пример расходной операции

Рассмотрим пример расходной операции, когда нужно подобрать поступления партий товаров.

У нас есть несколько партий по 50 штук с ценой примерно от 12 до 25 рублей. В нашем примере нужно списать 90 штук, а конечный остаток составит 70 штук.

Изображение нужно читать справа налево. Почему именно так? Потому что подбор мы всегда ведем назад – от текущего времени в прошлое.

70 штук, которые останутся после нашего проведения, – это остаток. Самые правые три партии дают эти 70 штук, поэтому мы их пропускаем. Следующие 90 штук – это то, что нам необходимо списать. Их и подбираем, получая таблицу партий.

Идея на самом деле очень простая. Но из нее следует много выводов, дополнительных возможностей и вариантов оптимизации.

Оптимизация

Зачем нужны отдельный регистр поступлений партий товаров и дополнительный регистр расходов партий товаров?

Поступлений у нас в десятки, а иногда в сотни раз меньше, чем расходных документов и вообще всех документов. Поэтому количество записей в регистре существенно меньше. Это важно, когда я постоянно обращаюсь к этому регистру и беру оттуда обороты по поступлениям. У меня это вообще регистр сведений.

Регистр расходов партий товара нужен потому, что внутренние товародвижения – например, комплектация или перемещение – имеют две стороны: откуда товар ушел и куда пришел.

То, откуда он ушел, я записываю в регистр расхода. Например, мы взяли такой-то товар с такого-то склада. Партий там нет, идут только измерения товароучета. А информацию о том, куда товар пришел, записываю в поступление.

Возникает вопрос: нужно ли каждый раз уменьшать поступления после того, как мы их использовали? Нет, не нужно. Это вообще регистр сведений. Мы используем его практически как справочник: добавляем туда новые партии – и все.

Как следующий документ учтет предыдущее списание? Нам это тоже не нужно.

Ключевая цифра – конечный остаток товара, который останется после проведения нашего документа. Если подряд идет несколько документов, у каждого будет свой конечный остаток. Поэтому для каждого документа мы по-разному сдвинемся по оси времени, когда будем подбирать партии. И таким образом каждому документу обязательно подберем свою партию по правилам FIFO.

Следующий вопрос – за какой период выбирать движения?

Когда мы выбираем остатки, такого вопроса нет. А движения я выбираю несколькими итерациями. Сначала выбираю движения от начала текущего месяца и начинаю подбирать поступления партий из этого периода. Если их не хватает, выбираю еще, например, предыдущие три месяца. Если и этого недостаточно, третья выборка идет за год, а четвертая – с начала времен.

Чтобы дойти до четвертой выборки, в учете должен быть уже полный бардак, потому что в бизнесе обычно такого не происходит.

Можно заранее собрать статистику и определить, какая выборка наиболее оптимальна: для всех товаров сразу либо отдельно по каким-то группам. Это настраиваемый механизм.

Что делать, когда встречается перемещение, комплектация? Какая у них себестоимость? Здесь мы переходим к следующей теме – итерационная выборка данных.

Итерационная выборка данных

По сути, сам выбор периода несколькими шагами – уже итерационный подход. Но особенно интересный момент начинается, когда встречаются комплектации и перемещения.

В своей системе я делю все поступления партий товаров на абсолютные и виртуальные.

Абсолютное поступление – это ситуация, когда мы купили товар и знаем его цену без дополнительных расходов. Дополнительные расходы потом можно довинтить сюда без проблем, как в обычной партионке.

Главное, что мы купили конкретное количество товара за конкретную цену и знаем его себестоимость.

Это может быть выпуск продукции по фиксированной стоимости, покупка, прием на комиссию и так далее. Все это абсолютные поступления.

Виртуальные поступления – это как раз перемещения, комплектации, списания и оприходования, например при пересорте.

Позиция, появившаяся в результате пересорта, наследует себестоимость той позиции, которая оказалась лишней. По сути, это тот же принцип, что и при комплектации.

Информация о партиях хранится в регистре сведений. В нем находятся все измерения товарного учета плюс партия. Там же хранится признак: абсолютное это поступление или виртуальное, а также уникальный идентификатор для связи с расходным регистром. Например, комплектация имеет две части – приход и расход. Я сопоставляю их через ID.

Изображение снова читаем от обратного: снизу вверх, справа налево.

На складе 1 мы подбираем партии и встречаем партию, которая пришла перемещением. Это красная виртуальная партия.

Напрямую списать ее мы не можем. Поэтому идем в расходный регистр и смотрим, откуда пришел этот товар.

Допустим, он пришел со склада 2. Тогда мы переходим на склад 2 и рекурсивно вызываем ту же процедуру, подбирая партии уже там. Если там снова встречается виртуальная партия, опять рекурсивно идем дальше.

В результате виртуальная партия разворачивается в реальные партии.

При этом нужно не забывать, что из виртуальной партии мы можем брать только ее часть. Поэтому среди всех составляющих ее партий по оси времени нужно взять именно необходимый кусок.

Например, у нас есть расход 100 штук и приход 100 штук – перемещение. Мы переместили 100 штук.

В регистр поступлений записываем виртуальную партию на 100 штук, а в расходной части расписываем эти 100 штук по конкретным партиям, из которых они состоят.

То же самое можно показать на примере 1С.

Допустим, у нас есть синий табурет, одна штука, и это виртуальная партия. В регистре поступления партий товаров по ID мы переходим в регистр расходов партий товаров и смотрим, из чего этот табурет был создан.

Здесь может быть не только перемещение, но и комплектация. Например, табурет сделан из гвоздей, досок, клея и лака. Это уже другие единицы измерения, другие товары, возможно, другие склады.

Дальше снова переходим к поступлениям партий товаров. Если попадаем на абсолютную партию, уже видим ее себестоимость.

Таким образом, синий табурет разворачивается в массив конкретных партий. Неважно, какие там единицы измерения и товары: в итоге у нас появляется себестоимость.

Каждая итерация вызывает новый выбор партий. Получается, каждый раз, когда у нас новый запрос к движениям, возникает «запрос в цикле».

Да, это действительно так, это особенность данной методики. Но само по себе несколько выборок в течение одной процедуры подбора по партиям не является проблемой. Есть несколько важных моментов:

Во-первых, запрос к поступлениям партий товаров намного легче запроса к остаткам по регистру партий товаров на складах.

Когда мы обращаемся непосредственно к регистру партий, там много итогов, они могут быть не закрыты – все это тормозит.

Поэтому моя методика, если сравнивать ее с классическим проведением по партиям, даже немного быстрее. Детальных замеров я не делал, поэтому точную разницу назвать не могу, но как минимум она не медленнее.

Запрос к остаткам также часто можно делать на границе рассчитанных итогов.

Хотя здесь нужно уточнить: остаток мы все-таки смотрим текущий – тот, который получится на конец документа. Иногда можно взять остаток на конец рассчитанных итогов и скорректировать его. Выигрыш небольшой, но такой вариант тоже можно использовать.

Отрицательные остатки товаров

Следующая тема – что делать, когда остаток отрицательный. Это больная тема для всех: именно из-за отрицательных остатков учет часто сбивается.

Как и в ERP в последних версиях партионного учета, требование здесь одно: остаток должен быть положительным только на конец периода.

Когда остаток положительный, все работает так, как было описано раньше: мы идем назад по оси времени и ищем нужные поступления партий.

Если конечный остаток отрицательный, делаем то же самое, но уже идем вправо – в будущие партии.

Например, сегодня мы списываем товар, завтра снова списываем, а поступление товара – виртуальное или реальное, неважно – произойдет только послезавтра.

Это нормальная ситуация. Поступление может вообще случиться в конце месяца. Особенно часто подобное происходит на крупных предприятиях.

Допустим, у вас многопередельное производство: товар движется из цеха в цех, со склада на склад. Выстроить все эти движения строго по оси времени бывает практически невозможно.

Для этого механизма это и неважно.

Допустим, со склада нужно списать 10 штук, а остаток составляет пять. Первые пять штук мы списываем назад, в прошлые партии. Оставшиеся пять отрицательных штук ищем вправо – в будущих партиях.

Обязательный критерий здесь – неотрицательный остаток на конец периода. Иначе мы просто не сможем подобрать нужную партию: ни в прошлом, ни в будущем.

Там, где остаток положительный, мы идем назад и сопоставляем его с партией из прошлого. Там, где остаток отрицательный, идем вперед и ищем первую партию, которая поступит позже, чтобы списание пришлось на нее.

Сюрпризы: Циклическая петля

При отрицательных остатках возможны интересные сюрпризы. Но они появляются только тогда, когда в учете уже полный бардак.

У меня был реальный пример с мебельной фабрики. Стиральная машина около двух лет перемещалась между выставочными залами.

Интерес заключался в том, что изначально на складе ее вообще не было. Откуда она взялась, никто не знает. Она прошла через несколько выставочных залов и в итоге вернулась на склад.

После того как машина вернулась, о ней никто не вспомнил, потому что изначально ее не существовало. Начальный остаток – ноль, конечный остаток – ноль.

Почему возникает проблема?

Допустим, в первом перемещении указано снять одну стиральную машину с первого склада, при этом остаток на этом складе отрицательный. Мы начинаем искать вправо, в будущее, и попадаем на это же самое перемещение – фактически на него самого.

Но эта ситуация не патовая, потому что продаж здесь нет. У нас просто нереальная цепочка перемещений. Мы ничего не продали, поэтому себестоимость отсутствующей позиции практически никого не интересует.

Конечно, бухгалтер может спросить, как все это получилось, и тогда придется объяснять.

Если же стиральная машина действительно вернулась и должна находиться на складе, достаточно, чтобы появился положительный остаток. Как только будет начальный остаток в одну штуку, неважно до или после этих перемещений, циклическая петля исчезнет сама.

Групповая обработка документов

Групповая обработка документов – это необязательно закрытие периода или месяца.

Основная идея в том, что я хочу здесь и сейчас, в любой момент восстановить партионку.

Например, приходит поставщик и просит посмотреть, что из его товара продалось.

Мы берем один товар, строим отчет, накладываем необходимые отборы и используем согласованность регистров товаров и партий.

В здоровой системе итоги по товарам и по партиям должны совпадать.

Допустим, у нас есть отчет по товарам, а мы хотим посмотреть тот же отчет по партиям. В отчет по товарам можно добавить кнопку. Она берет все регистраторы и проводит их по партиям в любом порядке.

После этого ведомость по партиям товаров на складах в тех же измерениях будет показывать правильные данные. Начальный остаток, приход, расход и конечный остаток будут совпадать с данными по товарам. При этом ведомость по партиям покажет, что именно этот конкретный кусок учета мы сейчас рассчитали и он правильный.

Почему это возможно? Потому что наш расчет не зависит от других участков. Мы не портим другой такой же отчет по другому товару. Посчитали свой кусочек – и все. Другой кусочек можно посчитать в другое время, и он не испортит уже сделанный расчет.

При групповой обработке появляются дополнительные преимущества.

Документы находятся рядом друг с другом по времени, а мне нужно выбирать движения по товару. Поэтому я могу один раз выбрать движения, закэшировать их и больше к базе данных не обращаться.

Если нужно провести 10 документов, получается ускорение уже примерно в три раза. Если нужно провести 100 документов, ускорение может составлять пять-семь раз.

То есть групповая обработка идет значительно быстрее, чем проведение одного отдельного документа.

Поэтому, когда мы закрываем месяц целиком – например, нужно провести все в Бухгалтерии, УТ, КА или любой другой базе, – проведение, хотя и остается по своей сути классическим, выполняется значительно быстрее.

Кроме того, на границе рассчитанных итогов иногда можно получать остатки и за счет этого дополнительно оптимизировать работу.

А когда внутри подбора мы попадаем на виртуальные партии, результат их разворачивания тоже можно закэшировать. Следующий документ, который попадет на ту же виртуальную партию, получит уже готовый результат.

Многопоточное проведение

Значимый плюс этого подхода связан с многопоточным проведением.

В 2024 году я проделал большую работу в Бухгалтерии по многопоточному проведению документов. Проведение занимало 24 часа, и мне удалось ускорить его примерно в 3,5 раза.

Главная проблема была именно в FIFO, в партионке. Там, где выбирались остатки и существовала зависимость от предыдущего документа, документы нельзя было проводить параллельно в разных потоках.

У меня была статья «Семафоры потоков» //infostart.ru/1c/articles/2251982/. В середине проведения одного документа, прямо перед запросом по партиям, я фактически останавливал поток, как на красном сигнале семафора, и ждал, пока другой документ восстановит регистр. После этого регистр можно было читать.

Почему тогда я не вспомнил про свою партионку – не знаю. Потому что этот механизм фактически перечеркивает всю ту сложную работу: теперь можно распараллелить документы, которые раньше принципиально нельзя было проводить параллельно.

Товары на складах – мы только читаем. Значит, можно читать без блокировок, без ответственного чтения.

В партии товаров – мы только пишем результат. Блокировок и ожиданий нет. Получается чистая многопоточность. Порядок проведения может быть любым. Допустимы и отрицательные остатки.

Поэтому все, что раньше требовало сложной работы для доказательства того, можно ли проводить документы в разных потоках параллельно, здесь становится ненужным. Можно просто запускать документы параллельно.

Партионкой может быть не только регистр партий товаров. Если применить этот подход к Бухгалтерии, это может быть 41-й счет, 45-й счет, 60-й, 62-й. Там везде есть партионный учет.

Для этого в Бухгалтерии для каждого такого разреза учета, для каждого счета, который мы хотим закрывать, нужно продублировать информацию в мои регистры: поступления партий и расходы партий.

Можно сделать дубль самого счета на регистрах, а результат записывать уже непосредственно, например, в регистр 41-го счета вместо регистра партий. После этого Бухгалтерию тоже можно закрывать параллельно. В целом за последние несколько лет у меня было несколько разных внедрений в трех компаниях.

Эта идея появилась не сейчас. Первый раз я придумал ее еще в 2006 году, двадцать лет назад. Потом несколько раз к ней возвращался.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.