gifts2017

Всегда актуальный партионный учет в 1С8

Опубликовал Осипов Сергей (fixin) в раздел Программирование - Практика программирования

Один из вариантов реализации партионного учета, не требующего перепроведения по партиям.

Всегда актуальный партионный учет

У физиков есть вечный двигатель, у алхимиков – философский камень, у архитекторов 1С – всегда актуальный партионный учет. Это такая реализация алгоритма распределения по партиям, когда не нужно восстанавливать границу последовательности и распределение по партиям остается актуальным при любом изменении документов задним числом.

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

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

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

Идею позволили реализовать только новые механизмы, которые появились в 1с8. Это регистры сведений и работа с ними через наборы записей в базе данных.

Используемые регистры

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

Классический регистр накопления для партионного учета в УТ

Предлагаемый регистр сведений для партионного учета

   

Демонстрационный пример

Рассмотрим некий демонстрационный пример, из которого будет понятен принцип нового партионного учета. Рассмотрим некоторую историю движения по товару:

1.06 поступило 100 штук по накладной ПНК1

2.06 продано 20 штук по накладной РНК1

20 штук списано с ПНК1, остаток по ПНК1 80 штук

3.06 поступило 30 штук по накладной ПНК2

4.06 продано 20 штук по накладной РНК2

20 штук списано с ПНК1, остаток по ПНК1 60 штук.

4.06 продано 70 штук по накладной РНК3

60 штук списано с ПНК1, остаток по ПНК1 0 штук.

10 штук списано с ПНК2, остаток по ПНК2 20 штук.

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

Отражение демонстрационного примера в регистре

Вот как будут выглядеть записи регистра сведений в предлагаемом подходе:

Дата

Дата по

Документ

Документ оприходования

Количество

Остаток

1.06

2.06

ПНК1

ПНК1

100

100

2.06

4.06

РНК1

ПНК1

-20

80

3.06

ПНК2

ПНК2

30

30

4.06

4.06

РНК2

ПНК1

-20

60

4.06

4.06

РНК3

ПНК1

-60

0

4.06

РНК3

ПНК2

-10

20

Поля Номенклатура, Склад, Стоимость не рассматриваются для простоты изложения.

Документ оприходования – это документ партии.

Документ – это документ, по которому происходит движение.

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

Остаток – это остаток в партии после движения.

Дата – дата и время движения.

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

Интерпретация данных регистра

Чтобы получить остатки по регистру на некоторую дату/время Д, нужно построить запрос, которые извлечет все записи регистра сведений Р по условию:

Р.Дата> = Д И Д

Возможно, нужно более аккуратно обдумать условия отбора, с учетом того, что в 1С на одну дату может быть несколько документов.

Соответственно, мы получим набор записей регистра, которые отражают остатки по партиям на указанную дату/время.

Выполнение алгоритма

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

То же самое происходит и при отмене проведения документа.

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

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

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

Считать записи регистра лучше всего запросом, т.к.:

  1. Запрос позволяет выполнять сортировку и группировку. Особенно это актуально, если мы выполняем один запрос по нескольким товарам.
  2. Обход запроса можно осуществлять с помощью выборки, которая не грузит все данные в память, соответственно можно обрабатывать сколь угодно большие наборы движений.

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

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

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

Заключение

Прошу коллег высказать свое мнение об алгоритме. По-моему вполне действенный алгоритм.

 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей Рудаков (fishca) 06.12.11 16:23
Записи регистра сведений можно считывать и записывать одной операцией чтения.

Можно подробнее, это как?
2. Сергей (ildarovich) 06.12.11 16:29
В статье Еще один взгляд на проблему "жизнь без последовательностей" предлагался алгоритм, основанный на той же структуре данных. В продолжении статьи Еще один взгляд на проблему «жизнь без последовательностей». Часть вторая (практическая) приведена каркасная конфигурация, реализующая метод на основе той-же структуры данных. Конечно, есть небольшие отличия в деталях. Там приведены и тесты быстродействия метода. Получились весьма обнадеживающие результаты. Правда, в тех статьях акцент сделан не на структуре данных (она достаточно очевидна), а на алгоритме расчета новой схемы списания - ставилась задача найти быстрый и математически обоснованный алгоритм.
Кстати, могли бы привести ссылку на Вашу статью на mista, где Вы уже довольно давно кратко высказывали подобную идею.
3. Осипов Сергей (fixin) 06.12.11 16:44
(1) НЗ = РегистрыСведений.*.СоздатьНаборЗаписей(); НЗ.Отбор = ... ; НЗ.Прочитать(); НЗ.Записать();
(2) такую идею я на мисте не мог высказывать, т.к. она возникла уже после моего пожизненного бана на мисте. Можно поискать обсуждение на дубовом, но оно малоконструктивно.
Статью почитал, но там общие математические выкладки и конкретный алгоритм не прописан. Тут же описан вполне конкретный алгоритм - бери и пользуйся. Хотя может не осилил вашу статью, допускаю.
4. Сергей Рудаков (fishca) 06.12.11 16:54
(3) не увидел, если честно, одной операции чтения
1) НЗ.Прочитать() - первая операция - чтение
2) НЗ.Записать() - вторая операция - запись
5. Александр Зубцов (iov) 06.12.11 16:54
(3) Пожизенный бан на мисте?
Чтоб из дурдома выгоняли? Нонсенс... (С)
Хаяли царя?
6. Осипов Сергей (fixin) 06.12.11 17:03
(4) правильно нужно читать как "Записи регистра сведений можно считывать и записывать одной операцией", думаю по контексту понятно, но потом поправлю в статье.
7. Сергей (ildarovich) 06.12.11 17:09
(3) Во второй части статьи Еще один взгляд на проблему «жизнь без последовательностей». приведен и алгоритм и целая конфигурация с открытым кодом, где алгоритм на основе описанной здесь структуры данных (регистра сведений) уже реализован целыми двумя разными способами. Конфигурацию можно скачать, провести тестирование. Там, кстати, реализовано и заполнение тестовым набором документов на основе статистических показателей документов из УТ - для опытов конфигурация заполнялась миллионом документов.
Ну а ссылку я найду ... там речь шла об ускорении перепроведения ...
8. Игорь Steelvan (Steelvan) 07.12.11 13:00
Надо будет потестировать :)
9. Александр Иванов (dkprim) 07.12.11 18:20
идея очень заинтересовала меня. буду читать статьи :)
10. Mir-mup (Mir-mup) 08.12.11 10:00
11. aim (aim) 12.12.11 09:26
Опять привязывать партии к документу прихода? Фи! Вчерашний день.
Сам я когда-то пробывал заводить партии автоматически создавая справочник "Партии"... Но сегодня 1С вводит "ключи аналитики" -- это по-моему ближе к истине. (И к моему ностальгическому справочнику "партии"). Это более стабильно при перепроведениях/копированиях/добавлениях новых приходов и более соответствует реляционности баз данных.
Сейчас 1С (в новейшем течении, именуемом "РАУЗ") пробует трактовать партии как "день прихода"... Говорят, что в СССР партии трактовались как "цена прихода". -- Все гайки d=20 по 5 руб. - это была одна партия, независимо от способа и даты прихода, а гайки d=20 по 6 руб. 10 коп. - это была другая партия.
Итого. Если каждый приход номенклатуры снабдить ключом аналитики "Характеристика" (тапочки, белые, 50-й размер, Китай) и ключом аналитики "Диапазон цен" (цена от 100, шаг по 40 рублей) то думаю мы и получим удобную партционность. ["диапазон цен" - необходимый реверанс в сторону учета себестоимости]
12. Сергей (Sergoninfostarru) 12.12.11 11:56
Идея хороша тем, что не надо всех выгонять из 1С и организовывать восстановление последовательности. Однако, продолжим численный пример. Если вставить документ прихода между существующими, что часто бывает в жизни, то прийдется записать тут же дополнительные данные по расходу регистра накопления с последующих расходных накладных и сторнировать расходы по следующему приходному документу.

Приход 1
Расход 1 Документ оприх-ния - Приход 1
Приход 2- вставленный приход
Приход 3
Расход 2 - старые значения Док.оприх. 1 + Док оприх. 3 ,
новые значения Док.оприх. 1 + Док оприх 2 - Док оприх. 3

Количество сторнирующих записей будет сильно раздувать базу данных и запутывать учет !!!
13. Виктор Клевцов (taiba) 11.04.13 17:24
(11) aim, а как при таком подходе определять FIFO, например?
14. Осипов Сергей (fixin) 11.04.13 17:26
(12) не придется. пересчитывается все сразу вперед.
15. Осипов Сергей (fixin) 11.04.13 17:27
16. aim (aim) 12.04.13 09:29
(13) taiba,
1) Ну, в РАУЗе, 1С как-то считает FIFO, хотя периодически его стараются уличить в неправильных цифрах.

2) По-советски, тоже, наверное, можно считать. Тут главное разобраться - что МинФин РФ (а не 1С) понимает под понятием "FIFO" и "партия". Вряд ли в МинФин-овском определении есть понятие "документ прихода" или "день прихода". Там наверняка что-то типа "однородное по характеристикам количество" и т.д. Так что особых противоречий нет: первая партия - партия с наименьшей ценой.

3) С точки зрения FIFO-LIFO. В 90-х была галлопирующая инфляция. Выгодно было более дорогой товар сразу включать в цену потребителям (а не обесценивать дорогой товар на складе) - т.е. LIFO. От обратного - FIFO (как я себе на пальцах понимаю) - сначала списываем ВСЕ партии с минимальной ценой, потом следуюшие по цене.

4) Самый главный вопрос - а часто ли мы сталкиваемся с реальным партионным учетом? Чтоб столкнуться с реальной мешаниной партий - нужно а) каждый день покупать маленькую партию гвоздей. б) каждый день гвозди должны хаотично менять цену.
Часто ли такое происходит?
Например, цемент, - зимой он 40 руб, а летом (в сезон) - 60 руб. Но зато у бизнесмена есть есть склад - куда он 1 раз затарится и работает.
Например, завхоз купил шариковые ручки по разным ценам. Но ведь бухгалтерия спишет ВСЕ ручки в тот же месяц не разбираясь - партия-не партия.
17. aim (aim) 12.04.13 09:41
Вчера пиво стоило 40 руб. А сегодня 40.99 руб. Что - в магазине новая партия пришла? НЕТ! - они ценники поменяли! А что нам мешает привести на складе инвентаризацию и остаток старой партии до-оценить по цене новой партии? Да - будет прибыль и с неё налог. Но зато на складе единственная партия. (А инвентаризацию всё-равно проводить надо.)
18. Ak A (frc) 12.04.13 09:53
(16) aim,
1С как-то считает LIFO

вы явно отстали от учета.
ЛИФо уже отменен, а учет ведется - по ФИФО. И это не одно и то же.
РАУЗ же вообще по своему понимает ФИФО и учет как таковой.
ФИФО-ЛИФО - это партионный учет, в РАУЗ он есть только складской, по затратам - никаких ФИФО.
19. aim (aim) 12.04.13 09:57
(18) frc,
LIFO Это описка (ведь в №13 вопрос про FIFO задавали).
20. Ak A (frc) 12.04.13 10:00
(16) aim,
Самый главный вопрос - а часто ли мы сталкиваемся с реальным партионным учетом?

везде и всюду кроем торгово-развлекательных сетевых компаний.
21. aim (aim) 12.04.13 10:09
(20) frc,
Я ПРИВЕЛ пример с цементом и шариковыми ручками, можно с арендой, платой за эненргию. Стабильность цен все-таки есть.
Где цены на "гвозди" меняются 2-3 раза в месяц? В каком бизнесе нужно закупать "гвозди" закупать 2-3 раза в месяц?
22. Евгений Палагин (Jon2011) 12.04.13 19:37
(21) aim, от разных производителей на один и тот же товар цены могут скакать очень сильно. За несколько дней цены скачут на 5-10%. Никто не хочет чтобы деньги лежали в товаре, поэтому все время ценовая политика меняется в зависимости от задач. В торговле основной инструмент извлечение прибыли -ЦЕНА.
23. aim (aim) 13.04.13 12:58
(22) Jon2011,
Проблема в том, что нет аналитических и статистических работ по право-применительной практике использования партий. Теоретически кажется, что они должны быть. А на практике инфляция в стране 7% годовых или 7/12 = 0.6% в месяц. Можно сказать, что в пределах отчетного месяца цены не меняются.

Вот аптека. Приходит "аспирин" от 4 компаний. Вопрос ... Ответ: я видел, что в аптеке были заведены 4 номенклатурных позиции "аспиринов" на каждого поставщика. Итого - (на практике) цены не пляшут, партии не нужны.
Вот пиво от 4-х поставшиков, но марки-то разные и ни когда не смешаются.
Вот конфетки "Мишка на севере" от 4-х поставщиков. Уверен, что они как и "аспирин" будут в 4-х номенклатурных копиях (на каждого поставщика, как минимум для удобства инвентаризации).
Вот хлеб от 4-х поставщиков. Но хлеб - цены регулируются, там скорее всего 1 партия и 1 номенклатура и 1 цена.

Вобщем 1-вопрос "нужны ли партии?". 2-вопрос "если нужны, то какие? (упрощенные для учета или супер-точные или ...)"
Я бы и сам хотел разобраться.
24. Евгений Палагин (Jon2011) 14.04.13 08:58
(23) aim,
упрощенные для учета или супер-точные
Аспирин, пиво, конфеты, хлеб,- поставщики этого товара - монополисты. Цены предсказуемы и за месяц действительно мало поменяются. Кроме того, срок хранения такого товара ограничен и вероятнее всего вся партия будет либо продана, либо списана. Получается партии не нужны, больше подходят серии.
Но возьмем магазины с канцелярией, сувенирные, строительные, - поставщиков море, цен еще больше.
Пример: товарная единица "Матрешка". Различия описываются только в характеристиках.
Задача: товар от одного поставщика и закупали такой товар за последние 2 года несколько раз и по разной цене. А продали в этом месяце только 2 матрешки. Чему ровна прибыль от проданного товара?
Надо иметь ввиду, что такой товар может лежать в магазине очень долго. У него нет срока годности и мода на него не меняется.
Причем, метод ФИФО - не катит потому как цена закупки в прошлом году отличаться от нынешний в десятки процентов.
На серии и в этом случае нельзя опираться, так как алгоритм для серий в 1С заточен под срок годности товара.
Как в таком случае определить закупочную цену?
25. aim (aim) 14.04.13 17:46
(24) Jon2011,
Согласен. Есть два нюанса.
1) Обычно, те кто торгуют матрешками - им полный учет не нужен - они ИП-шники или упрошенщики. Они отправляют в налоговую 30-40 страниц страниц "книг учета доходов и расходов".
2) Такая "долгая" матрешка (одна) вряд ли сдвинет себестоимость предприятия на существенную сумму. Проще по-средней считатьи на 1С-обновлениях экономить.
26. Евгений Палагин (Jon2011) 14.04.13 18:57
(25) aim, а вот как раз все на оборот. ИП-шник каждую копейку считает и поставщики у него тоже не богатые ребята.Какая конкретно вещь продана за ту и расчет идет. Это сетевой магазин может на десятки тысяч списывать товара без разбора, они на объемах свое берут. Они мыслят среднеарифметическими статистическими цифрами.
Я как раз программы дорабатываю для таких у которых оборотный запас товара умещаются на три полки в магазине.И цена за штуку крутится в районе 100 рублей. Для них просто не реально по усредненным ценам торговать и рассчитываться с поставщиками.
27. Alexandr Климчук (undo) 20.04.13 00:31
(21) aim, Есть такой бизнес называется оптовая продажа сахарного песка, цена может меняться в течении дня. В моем опыте было, что цена менялась за день 3 раза. И при этом росла. Клиент приехал в 8 утра купил по 26.80 5 тонн, и забронировал ещё 10, приехал через 2 часа с деньгами, а цена уже 27, а за последней партией приехал и купил по 27,50. И это не сказка а реальная торговля, а приезжал он продавая купленный товар.
28. aim (aim) 20.04.13 16:12
(27) undo,
При всём уважении к Вашему мнению и к мнению Jon2011 ...
Похоже, в данном случае речь идет о торговых (40-х) счетах. На которых (насколько я помню) партии не предусмотрены. А себестоимость считается бесхитростно, без всяких партий.{По-этому, насколько я понимаю, Jon2011 и дорабатывает конфигурацию для партионного учета.}
Ну, а в обычном смысле (о чем и велась речь основное время) сложный учет партий и сложной себестоимости ведется на 20-х счетах. Вряд ли производственник позволит закупочным ценам так скакать (склады, опты, долгосрочные контракты). {Если только может и готовую продукцию в том же темпе поднимать} Но это моё "вряд ли" нуждается в практическом и статистическом обосновании (о чем и речь).
29. aim (aim) 20.04.13 16:29
Есть
1) Монстр-"КАМАЗ" который скорее всего считает на чем-то самописном или зарубежной программе.
2) Мелкий торговец пряниками (у которого цены могут скакать) но он считает в экселе.
3) Средний бизнесмен. Его задача - показать минимальную налогооблагаемую прибыль. Ему выгоднее считать по ЛИФО (отменено) или на крайняк по-средней.
4) Есть ушлый производственник. Ему важно знать - сколько в себестоимости его табуретки доля энергии, труда, материальных затрат. И вот мы ему говорим. Если посчитаем по ФИФО - материальные зартраты будут 40%, а если по-средней - 45%. Так ли ему вашны эти доли процента?
30. aim (aim) 20.04.13 16:36
По моему поверхностону мнению. Если у точно считать себестоимость... Нужно стоимость товаров на складе связывать с процентом на заемные средства, с инфляцией и т.д. и т.п.
31. Alexandr Климчук (undo) 20.04.13 16:46
Как точно не считать, но себестоимость это всё же стоимость приобретения плюс стоимость затрат по доставке до места реализации или складирования, а вот уже всё остальное (инфляция, аренда, зарплата, кредиты и т.д. и т.п.) это расходы по реализации данной продукции. И чем хуже идут продажи тем больше расходы и меньше прибыль.
32. Евгений Палагин (Jon2011) 20.04.13 16:59
(29) aim,
Если посчитаем по ФИФО - материальные зартраты будут 40%, а если по-средней - 45%. Так ли ему вашны эти доли процента?
Ну не фига себе! Разница в пять процентов. Может у меня расчетная прибыль всего 3%. А вы мне говорите +- 5%. Может мне на фиг этот бизнес нужен, а я просто кого кормлю себе в убыток?
33. aim (aim) 20.04.13 18:40
(32) Jon2011,
Нет, табуретка как 100 рублей стоила так и стоит (себестоимость). Просто львиную долю в её себестоимости занимает освещение. Вывод замени лампочки на энергосберегающие. Я так понимаю.
34. aim (aim) 20.04.13 18:57
Ладно, допустим партии нужны.
Как их считать?
Первое, что бросается в глаза - как точно партии в течении месяца ни считай, всё равно "закрытие месяца" начнет всё пересчитывать. Ещё и копейку-другую доначислит. Может и в проведённый документ зайти и там сумму поменять. Сам документ тоже может провестись с количеством, но без суммы (и об ошибке не сообщит). То есть бухгалтер в течении месяца может "живую цифру" и не увидеть.

Не проще ли считать в течении месяца по учетным ценами (как в СССР, - с 15 и 16 счетами)? Берешь среднюю цену, округляешь до рублей (или до сотен рублей) и спокойно в течении месяца списываешь. А уж в "закрытии месяца" можешь организовать любой партионный учет.

И бухгалтер будет видеть в течении месяца достаточно "живую", понятную цифру. И считаться документ проще будет. И можешь задним числом зайти и внести изменения. При этом надо будет пересчитать только документы "закрытие месяца", а не всё подряд. Вот такие мысли.
35. Евгений Палагин (Jon2011) 20.04.13 21:13
(34) aim,
При этом надо будет пересчитать только документы "закрытие месяца", а не всё подряд.
Это хорошая мысль, и с точки зрения бухучета удобная вещь. Потому как отчет бух составляет только раз в месяц. И самое главное, не надо перепроводить все документы.
Но с точки зрения реальной торговли опять возникает, как в квантовой физике, принцип неопределенности.
Предположим, у меня есть договор с поставщиком комиссионного товара и с периодом расчета - 10 дней.
Как такому товарищу точно сосчитать сумму его проданного товара, если у меня есть точная цифра только в документе "Закрытие месяца" за прошлый месяц? Я же не могу ему сказать: на тебе стольник и отвяжись от меня. Типа, приходи в конце месяца, там разберемся кто кому должен. И что это будет за бизнес?
Мы сейчас, в этой дискуссии пытаемся, и фирма 1С к стати тоже, найти единый алгоритм учета для "ООО КАМАЗ" и "ООО Табуретка". Но физики не зря же придумали квантовую физику,а математики - теорию больших чисел. Поэтому в одном случае нужны партии, а в другом РАУЗ - просто панецея.
Речь в статье идет не о том нужны партии или нет, а о том как сделать так чтобы не перепроводить эти чертовы движения регистров.
А вот по изложенной идее у меня большие сомнения, и ее надо для начала хотя бы воплотить в опытной конфигурации.
36. aim (aim) 21.04.13 13:38
А можно ли сделать гибрид грузовика и автомобиля представительского класса? 1С может поставлять только бухгалтерское микро-ядро и интерфейс связи с внешними данными. А весь наворот выполнять в подкючаемых модулях (внешних данных). В "Комплексной Автоматизации 8" - помню, если не перешёл на РАУЗ, то закрытие месяца(исчисление себестоимости) в партионном учете тебе ни кто не посчитает - сам пиши.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа