Расширенные регистры

04.01.23

Задачи пользователя - Адаптация типовых решений

Продолжаем разговор о возможности функционального подхода при создании конфигураций.

Скачать файлы

Наименование Файл Версия Размер
Расширенные регистры:
.dt 123,51Kb
14
.dt 123,51Kb 14 Скачать бесплатно

В предыдущей статье //infostart.ru/public/1721980/ был предложен т.н. функциональный подход при создании конфигураций. Суть его заключается в том, что результат проведения документа зависит только от самого документа, но не от окружения. Было показано, что простое расширение регистра накопления позволяет решать частную задачу резервирования в функциональном стиле. Еще одно расширение регистров накопления, которое я хочу предложить здесь, дает возможность решать в функциональном стиле уже очень широкий круг задач. Возможно, что вообще все или почти все.

Для начала вспомним, как устроен регистр накопления. Мы делаем записи в регистр. Записи могут быть двух видов: "приход" или "расход". На основании этих записей система предоставляет в наше распоряжение виртуальную таблицу остатков. Остатки вычисляются с помощью очевидных арифметических операций: "приход" это "+", "расход" это "-". При этом, нас совершенно не заботит порядок внесения записей в регистр. Если что-то вносится "задним числом", виртуальная таблица все равно выдаст нам верный остаток.

Самый важный момент заключается в том, что "внутри" регистра накопления может "лежать" что-то более сложное, чем элементарная арифметика. Набор операций "приход-расход" пришел к нам из докомпьютерной эпохи. И в настоящее время мы не обязаны ограничивать себя им.

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

Есть два документа поступления товаров

 

 

 

Обработка проведения для документов поступления выглядит так:

	Движения.Себестоимость.Записывать=истина;
	для каждого стр из Товары цикл
		дв=Движения.Себестоимость.Добавить();
		дв.ВидДвиженияРасширенный=Перечисления.ВидДвижения.Накопить;
		дв.Период=Дата;
		дв.Товар=стр.Товар;
		дв.Партия=ссылка;
		дв.Количество=стр.Количество;
		дв.Сумма=стр.СуммаСНДС;
	конеццикла;

Результат проведения этих двух документов

 

 

Есть один документ отгрузки

 

 

В обработке проведения

	Движения.Себестоимость.Записывать=истина;
	для каждого стр из Товары цикл
		дв=Движения.Себестоимость.Добавить();
		дв.ВидДвиженияРасширенный=Перечисления.ВидДвижения.Распределить;
		дв.Период=Дата;
		дв.Товар=стр.Товар;
		дв.Количество=стр.Количество;
	конеццикла;

Результат проведения

 

 

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

Я воспользовался подпиской на событие и сэмулировал работу такого регистра (см. приложение). В результате я получил вот такую "виртуальную" таблицу оборотов

 

    

 

На основе этих данных можно построить так любимый многими отчет типа такого

 

 

Реализацию эмуляции можно найти в приложении. Но здесь она не так уж и важна. Гораздо интереснее то, что нам удается применить функциональный принцип. А это в свою очередь дает нам простоту в модулях объектов. Например, обработка проведения документа "Отгрузка" у меня сейчас выглядит так:

Процедура ОбработкаПроведения(Отказ, РежимПроведения)
	
	если не Основание.Пустая() тогда
		Движения.Резервирование.Записывать=истина;
		для каждого стр из Товары цикл
			дв=Движения.Резервирование.Добавить();
			дв.ВидДвижения=ВидДвиженияНакопления.Расход;
			дв.Период=Дата;
			дв.Заказ=Основание;
			дв.Товар=стр.Товар;
			дв.Количество=стр.Количество;
		конеццикла;
	конецесли;
	
	Движения.Себестоимость.Записывать=истина;
	для каждого стр из Товары цикл
		дв=Движения.Себестоимость.Добавить();
		дв.ВидДвиженияРасширенный=Перечисления.ВидДвижения.Распределить;
		дв.Период=Дата;
		дв.Товар=стр.Товар;
		дв.Количество=стр.Количество;
	конеццикла;

	Движения.ОстаткиТоваров.Записывать=истина;
	для каждого стр из Товары цикл
		дв=Движения.ОстаткиТоваров.Добавить();
		дв.ВидДвижения=ВидДвиженияНакопления.Расход;
		дв.Период=Дата;
		дв.Товар=стр.Товар;
		дв.Количество=стр.Количество;
	конеццикла;

	Движения.Продажи.Записывать=истина;
	для каждого стр из Товары цикл
		дв=Движения.Продажи.Добавить();
		дв.Период=Дата;
		дв.Товар=стр.Товар;
		дв.Количество=стр.Количество;
		дв.Сумма=стр.СуммаСНДС;
	конеццикла;
	
КонецПроцедуры

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

В приложении демонстрационная выгрузка базы. Пример тестировался на версии платформы 8.3.19.1467.

расширение регистров накопления

См. также

Табличная часть в доп. реквизитах и формирование таблиц в шаблоне docx для 1С:ДО 3.0

Адаптация типовых решений Платформа 1С v8.3 1С:Документооборот Россия Платные (руб)

Расширение конфигурации для «1С:Документооборот КОРП», редакция 3.0. позволяет: 1.использовать произвольные табличные части в качестве дополнительных реквизитов к документу; 2 использовать произвольные табличные части в шаблонах в формате docx для автоматического заполнения таблиц.

29400 руб.

29.06.2023    4454    9    4    

18

Расширение для 1С:УНФ. Автоматическое снятие резервов в Заказах покупателей

Логистика, склад и ТМЦ Адаптация типовых решений Платформа 1С v8.3 1С:Управление нашей фирмой 1.6 1С:Управление нашей фирмой 3.0 Россия Управленческий учет Платные (руб)

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

7200 руб.

02.08.2023    2957    4    0    

19

Создать на основании - своя кнопка (БСП). Проблема двух подменю Создать на основании

БСП (Библиотека стандартных подсистем) Адаптация типовых решений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Понадобилось в подменю "Создать на основании" добавить свою команду, которая открывает обработку. В процессе доработок появилась проблема двух подменю "Создать на основании". В статье о том, как решились проблемы.

01.03.2024    1302    dimanich70    6    

13

Доработка отчета "Связанные документы" (структура подчиненности) для вывода объектов из любого расширения

Адаптация типовых решений Платформа 1С v8.3 1С:Управление торговлей 11 Россия Абонемент ($m)

Доработка типового отчета "Связанные документы" позволяет просто и быстро расширять состав объектов для построения структуры подчиненности документов, используя объекты основной конфигурации и любых расширений.

1 стартмани

27.10.2023    1998    13    avmartynov    10    

43

Печать непроведенных документов для УТ, КА, ERP. Настройка печати по пользователям, документам и печатным формам

Пакетная печать Печатные формы Адаптация типовых решений Универсальные функции Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Абонемент ($m)

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

2 стартмани

22.08.2023    2078    21    progmaster    7    

3
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. RustIG 1382 26.09.22 07:52 Сейчас в теме
Представим, что наш расширенный регистр умеет обрабатывать операцию "распределить". Тогда, при обращении к виртуальной таблице оборотов, мы могли бы получать правильное распределение, в соответствии с тем или иным методом. Метод распределения можно было бы указывать в параметрах регистра.


Распределение должно быть прошито в платформе? Оно зависит не только от "метода", но и от аргументов-параметров - организации, складов, отдельно по каждой номенклатуре - одна так, другая по-другому методу, подразделение, характеристика, серия - в некоторых методах решается СЛАУ.

Но допустим, что можно самим прописать "распределение" - в какой момент времени это будет считаться и себестоимость Сумма (руб) будет проставляться в регистр "Себестоимость" ? Вот здесь :
Движения.Себестоимость.Записывать=истина;
	для каждого стр из Товары цикл
		дв=Движения.Себестоимость.Добавить();
		дв.ВидДвиженияРасширенный=Перечисления.ВидДвижения.Распределить;
		дв.Период=Дата;
		дв.Товар=стр.Товар;
		дв.Количество=стр.Количество;
	конеццикла;
2. mkalimulin 1153 26.09.22 08:45 Сейчас в теме
(1) Да, в идеале мы должны иметь платформенную реализацию расширенного регистра. Детали реализации могут быть различными. Можно сделать регистр, у которого метод распределения будет задан как параметр регистра в целом. Можно сделать регистр, в котором метод распределения будет указываться, как параметр записи движения. Лично я на данный момент считаю, что первый вариант лучше. Алгоритмы методов распределения могут быть предопределенными, а могут быть описаны пользователем.
Но в любом случае, себестоимость не "проставляется" в регистр. Себестоимость считается в момент обращения к виртуальной таблице. В регистр "проставляются" промежуточные остатки для ускорения расчета себестоимости. Но так же, как и сейчас в регистре накопления, эти промежуточные остатки не видимы напрямую. Это служебные таблицы.
9. RustIG 1382 26.09.22 11:06 Сейчас в теме
(2)
Но в любом случае, себестоимость не "проставляется" в регистр. Себестоимость считается в момент обращения к виртуальной таблице. В регистр "проставляются" промежуточные остатки для ускорения расчета себестоимости. Но так же, как и сейчас в регистре накопления, эти промежуточные остатки не видимы напрямую. Это служебные таблицы.


Похожим образом можно все задачи мира засунуть в платформу - для создания платформой вирт. таблиц - то есть разработчики Си-шарп теперь начнут программировать предметные области.
10. mkalimulin 1153 26.09.22 11:27 Сейчас в теме
(9) Все не надо. Достаточно только задачи распределения
14. RustIG 1382 26.09.22 12:58 Сейчас в теме
(10)
Все не надо. Достаточно только задачи распределения

Почему не надо все? Я не понял тогда вашу концепцию.
Почему только распределение?
В управленческом учете много задач распределения: распределение бонусов (баллов) при списании по товарам, распределение последней 1ой копейки при расчете НДС или других управленческих процентов, распределение материалов по заказам на производство и т.д.
О каких задачах вы говорите?
Есть еще задачи оптимизации - похожи на задачи распределения, только надо выбрать наилучшее распределение по определенному критерию.
3. user1466751 16 26.09.22 10:07 Сейчас в теме
А как посчитать оборачиваемость неделя к неделе за пару лет при таком подходе?
5. mkalimulin 1153 26.09.22 10:22 Сейчас в теме
(3) Запросом к виртуальной таблице оборотов
8. user1466751 16 26.09.22 10:52 Сейчас в теме
(5)
Так нет движения по с/с в регистре в вашей реализации с "распределить". Что вернут обороты?
11. mkalimulin 1153 26.09.22 11:29 Сейчас в теме
(8) В регистре нет, а в виртуальной таблице есть. Вот, например, в обычном регистре накопления нет остатков на 12:31:23 на 17/03/2022, а виртуальной таблице остатков они есть
13. user1466751 16 26.09.22 11:57 Сейчас в теме
(11)
Что, простите? Что вы понимаете под виртуальной таблицей остатков?
15. mkalimulin 1153 26.09.22 13:21 Сейчас в теме
(13) Виртуальная таблица - это таблица, которая не хранится явно в БД, а формируется по запросу
17. user1466751 16 26.09.22 13:43 Сейчас в теме
(15)
Что делать, когда запрос упадет по превышению памяти серверного вызова? А если с течением времени один и тот же алгоритм изменится, до 1 сентября была одна логика, с 1 сентября другая? Все в запросе учитывать?
19. mkalimulin 1153 26.09.22 14:26 Сейчас в теме
(17) Регистры накопления работают же, не падают. Если логика меняется, переходишь с одного регистра на другой
20. user1466751 16 26.09.22 14:30 Сейчас в теме
(19)
Регистры не рассчитывают суммы, они по ресурсу собирают агрегатную функцию. В вашем варианте в ресурсе нет суммы - ее для каждого документа нужно рассчитать.
В смысле перейти с одного регистра на другой? У меня до 1 января с/с списывалась по средней, а с 1 января по ФИФО - новый регистр городить?
22. mkalimulin 1153 26.09.22 15:11 Сейчас в теме
(20) В контексте данного обсуждения, не вижу принципиальной разницы между агрегатной функцией и произвольной функцией. Какая разница - что считать?
Ну да, переходить на другой регистр. А сейчас разве есть более простые способы?
23. user1466751 16 26.09.22 15:26 Сейчас в теме
(22)
СуммаНачальныйОстаток (из таблицы итогов) + СУММА(СуммаОборот) (из самого регистра за месяц) - с одной стороны

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

Точно нет разницы, как считать?

Ну да, переходить на другой регистр. А сейчас разве есть более простые способы?


Эм. Использовать регистры накопления остатков так, как задумывалось 1С? А сумму списания определять или при проведении документа, или отложенно, тут уж зависит от предпочтений, объемов данных и прочего.
24. mkalimulin 1153 26.09.22 15:29 Сейчас в теме
(23) Зачем за все время? Промежуточные итоги никто не отменял. Расширенный регистр работает точно так же, как обычный регистр накопления, только "внутри" у него не +/- а что-то более содержательное
25. user1466751 16 26.09.22 16:03 Сейчас в теме
(24)
Еще и итоги поддерживать в актуальном состоянии самостоятельно средствами 1С?
26. mkalimulin 1153 26.09.22 16:41 Сейчас в теме
(25) Я не вполне понимаю ваши вопросы. Регистры накопления поддерживают итоги в актуальном состоянии. В чем вы видите проблему?
27. user1466751 16 26.09.22 18:35 Сейчас в теме
(26)
Я сдаюсь. Извините за беспокойство.
4. user1559729 26.09.22 10:14 Сейчас в теме
(0) правильно я понял суть предложения - перенести обработку проведения из модуля документа в ?куда - регистр? общий модуль?
6. mkalimulin 1153 26.09.22 10:24 Сейчас в теме
(4) Перенести в регистр. В идеале, в платформенную реализацию. В отсутствии платформенной реализации можно сделать эмуляцию через подписки на события
7. user1559729 26.09.22 10:52 Сейчас в теме
(6) В таком случае унификации не будет, т.к. распределение в различных документах может отличаться?
12. mkalimulin 1153 26.09.22 11:31 Сейчас в теме
(7) Что вы имеете ввиду? Методы распределения могут отличаться? Тогда для разных методов можно использовать разные регистры, а метод распределения задавать как параметр регистра
16. mkalimulin 1153 26.09.22 13:24 Сейчас в теме
(14) Потому что распределение закрывает почти все задачи, встречающиеся в учете. Кроме резервирования, но резервирование можно решить регистром с неотрицательными остатками
18. RustIG 1382 26.09.22 14:20 Сейчас в теме
(16)В управленческом учете много задач распределения, и все решаются по разному, но с применением различных таблиц - иначе где хранить входную информацию? не понятно почему именно регистры накопления, и как решить все задачи сразу?
21. mkalimulin 1153 26.09.22 15:08 Сейчас в теме
(18) И все эти задачи очень схожи друг с другом. Что дает возможность перейти к рациональному обобщению
28. mixsture 04.10.22 01:20 Сейчас в теме
Убийственный для производительности подход. По сути вы предлагаете каждое чтение виртуальной таблицы заново рассчитывать распределение. Чтений в базе существенно больше записи, а еще для чтений обычно более жесткие требования по времени выполнения - поэтому вы в любом случае сильно проигрываете в нагрузке. Чем вы это покроете? Десятикратным удорожанием серверных мощностей?
Имхо, загнется эта штука при переходе от тестового стенда к реальным массивам данных.
29. mkalimulin 1153 04.10.22 09:03 Сейчас в теме
(28) Сейчас, в обычном регистре накопления, при каждом чтении виртуальной таблицы остатков происходит их вычисление и ничего страшного.
30. mixsture 04.10.22 16:23 Сейчас в теме
(29) вычисление остатков != вычислению распределения. Это задачи различающиеся по сложности на порядки. И даже без различий в сложности между этими задач по смыслу - вычисление остатков происходит целиком на sql, а вы примеры пишете уже на ЯП. Даже если сделать сверхбыстрый компилируемый строго типизированный ЯП из 1с или заложить эти механизмы внутрь платформы, что будет С++, насколько я помню, это все равно проиграет по скорости вычисления на стороне СУБД.
AllexSoft; +1 Ответить
31. mkalimulin 1153 04.10.22 18:36 Сейчас в теме
(30) Что мешает делать вычисление распределения "целиком на sql"?
32. mixsture 04.10.22 21:25 Сейчас в теме
33. mkalimulin 1153 04.10.22 21:32 Сейчас в теме
(32) Примеры для примера ))) В идеале это реализуется в платформе. В тех же случаях, когда объемы данных позволяют, можно пользоваться и эмуляцией платформенного решения. Пример такой эмуляции я и привел. Могу добавить, что это будет нормально работать где-то в 90% случаев
34. mixsture 04.10.22 21:55 Сейчас в теме
(33) в платформе - это расплывчатое понятие. Там внутри куча кода на C++, принцип хранения данных регистров накопления, трансляция запроса к виртуальной таблице в реальный запрос к таблице итогов и движений. Как это у вас будет работать? В sql или в ЯП распределение считается? какие таблицы будут? в комментах вы упоминаете про промежуточные результаты - что это и где хранится? когда пересчитывается?
35. mkalimulin 1153 04.10.22 22:30 Сейчас в теме
(34) Промежуточные результаты - те же самые, что и сейчас в регистрах накопления
Оставьте свое сообщение