Алгоритм расчета хранения деталей

1. user1950534 10.06.24 16:18 Сейчас в теме
Всем привет.

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

Сейчас используется Регистр сведений, куда каждый день по каждой детали регламентом делается запись. Работает это всё, ну мягко говоря, долго. Есть мысль сгрузить функционал на регистр расчетов. Якобы туда можно записать только изменения, мол с 1 по 10 число - одна цена (раз запись), с 10 по 30 число другая цена (два запись). И потом неким образом сделать расчет за весь период.

Помогите плз кто знает, как составить структуру регистра расчетов? Материала в инете много, я читаю все эти вытесняющие периоды, понять ничего не могу)) Кажется просто, а оно непросто
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
2. Sashares 35 10.06.24 16:33 Сейчас в теме
(1) Я бы предложил сначала разобраться, что именно долго работает.
Сделать замер, посмотреть результаты.
Может у вас код просто не оптимальный, тогда не важно какой там будет регистр - сведений, накоплений или расчета.
22. Said-We 11.06.24 17:06 Сейчас в теме
(1)
Всем привет.
Требуется рассчитывать стоимость хранения каждой детали за период.
Но никто же не требует хранить расчеты за каждый день.
Сейчас используется Регистр сведений, куда каждый день по каждой детали регламентом делается запись. Работает это всё, ну мягко говоря, долго.
Может не нужно хранить за каждый день. Может расчет нужен при отгрузке детали, что бы знать, сколько она стала стоить. У каждой детали период может быть свой. Если у детали нет ИД, то FIFO или LIFO.
Есть мысль сгрузить функционал на регистр расчетов.
Можно вообще никуда не писать, а только по требованию рассчитывать.
Якобы туда можно записать только изменения, мол с 1 по 10 число - одна цена (раз запись), с 10 по 30 число другая цена (два запись). И потом неким образом сделать расчет за весь период.
Это регистр сведений для хранения изменения цены.
Помогите плз кто знает, как составить структуру регистра расчетов? Материала в инете много, я читаю все эти вытесняющие периоды, понять ничего не могу)) Кажется просто, а оно непросто
У вас вообще нет вытеснения. Нет конкурирующих записей. Условно, оклад есть, а отпусков, которые могли бы их вытеснять нету. :-)
23. vadim1011985 101 11.06.24 17:18 Сейчас в теме
(1)
по каждой детали регламентом делается запись

А откуда цены берутся ? Может действительно нет смысла хранить цены на каждый день, а просто по мере надобности
26. independ 1541 13.06.24 04:33 Сейчас в теме
(1) как сделано в любой типовой конфигурации, регистр сведений ЦеныНоменклатуры, СрезПоследних, СрезПервых
3. user1950534 10.06.24 17:16 Сейчас в теме
(2) а чего там разбираться? Такая архитектура, как я описал, будет приводить к ежедневной записи нескольких миллионов новых значений в регистр. Вот это и тормозит...
4. Sashares 35 10.06.24 17:40 Сейчас в теме
8. nomad_irk 76 11.06.24 08:10 Сейчас в теме
(3)так может не надо каждый день производить запись миллионов значений?
Если есть дата начала и дата окончания хранения, то будет достаточно выполнить расчет при выбытии детали со склада
5. starjevschik 10.06.24 20:55 Сейчас в теме
Возможно, логично в регистр записывать цену, а расчет делать отдельно когда он нужен. Расчет будет не очень простой, ну так что ж.
Еще возможно, что сначала надо полностью осознать задачу, потом уже решать. Что должно в результате получиться и какие данные есть на входе. Зачем каждый день что-то записывается куда-то, не очень понятно.
Насчет регистра расчетов я советы давать не возьмусь, но по-моему это какая-то катастрофа с самого начала их появления в 1с. С другой стороны, разберешься - можно будет подрабатывать в ЗУПе, это востребовано.
6. vadim1011985 101 10.06.24 22:17 Сейчас в теме
(1) Не легче ли сделать на регистре накопления ?
Sashares; +1 Ответить
7. novohatko 11.06.24 04:41 Сейчас в теме
Как-то все сложно. Есть документ прихода товара на склад, делаю запись в регистр с какой даты товар на складе. Когда товар был отгружен понимаем, что товар ушел и за него больше начислять нечего. Соответственно до того пока он не ушел мы можем не каждый день не делать запись, а просто понимать сколько дней товар храниться на складе.
9. user1950534 11.06.24 09:24 Сейчас в теме
(2)
(7) все так, но цена за хранение меняется с дискретностью 1 день. Может 100 дней висеть одна цена за хранение, а может каждый день меняться.

На выходе отчет, разумеется, что же еще. Стоимость хранения детали за период. С группировками и всеми делами
10. Zevzm 11.06.24 10:04 Сейчас в теме
(9) А стоимость дня хранения индивидуальна для каждой детали? Или устанавливается для групп например по размеру, весу и т.п.?
12. user1950534 11.06.24 12:01 Сейчас в теме
(10) индивидуально до позиции номенклатуры, то есть до детали
11. Sashares 35 11.06.24 10:52 Сейчас в теме
(9)Ну имхо, регистр накопления, который регламентно, ежедневно будет записывать сумму для детали за этот день.
В нем будут обороты, остатки и вот это вот все.
13. user1950534 11.06.24 12:03 Сейчас в теме
(11) так сейчас и сделано)) только не накоплений, а регистр сведений. И сумма в отчете считается через группировку по номенклатуре.

В итоге запись в регистр миллионов записей в день так серьезно грузит систему в общем-то
14. Sashares 35 11.06.24 12:37 Сейчас в теме
(13)Ну а как вы хотите?
Не хранить суммы для миллионов деталей, а рассчитывать их при формировании отчета? Вы серьезно считаете, что это будет быстрее работать в общем случае?

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

Ну и пишите регламентным заданием по ночам. Чтобы это не мешало работе пользователей.
16. user1950534 11.06.24 15:43 Сейчас в теме
(14) А я хочу как в ЗУП. ЗУП же не записывает каждого сотрудника каждый день с дневной ставкой, правда?

ЗУП берет базу оклад и рассчитывает с 1го по 30е число. А если оклад менялся в середине месяца, например, то ЗУП внесет одну запись с соответствующей датой. И потом всё рассчитает.

И ни у кого вроде не тормозит
17. nomad_irk 76 11.06.24 16:00 Сейчас в теме
(16)ну как сказать.....вы пробовали рассчитывать ЗП сотрудников так для >= 10к? :)
20. Sashares 35 11.06.24 16:26 Сейчас в теме
(16)У вас по вашим же словам миллионы деталей.
То есть в аналогии - ЗУП должен рассчитать оклад для миллионов сотрудников.
Я с зарплатными конфигурациями не работал, но есть сомнения в успешности такой процедуры.
Но может я не прав.
15. vadim1011985 101 11.06.24 13:06 Сейчас в теме
(13) Не совсем понятно что есть деталь ? Это конкретная позиция номенклатуры ? Например Мотор № 1 и Мотор № 2 - это 2 разных детали и сумма хранения у них отличается ? Или есть какой-то реквизит (например "Вид детали") от которого зависит цена хранения. Все таки для такой задачи нужен регистр накопления (информация по остаткам) + Регистр сведений (цены хранения на конкретный день) . И далее запросом получаем цены на каждый день хранения. Опять же в регистр сведений можно писать не по всем позициям а только по тем которые изменились
18. user1950534 11.06.24 16:00 Сейчас в теме
(15) деталь это Номенклатура. Вот представьте сотрудников предприятия. У них у каждого свой оклад, они не сгруппированы никак абсолютно. Оклад может измениться запросто в середине месяца, ну или года без разницы.

И механизм регистров расчета поддерживает все необходимые расчеты....
19. user1880116 11.06.24 16:18 Сейчас в теме
(18)
И механизм регистров расчета поддерживает все необходимые расчеты....
Пишет нам автор "я читаю все эти вытесняющие периоды, понять ничего не могу"
21. Sashares 35 11.06.24 16:27 Сейчас в теме
(19)Ну вытесняющие периоды вряд ли будут нужны, детали на больничный не уйдут.
27. WasiliyMay 8 13.06.24 08:46 Сейчас в теме
(18)Регистр расчета применительно к вашей задаче никаких преимуществ не даст. (он для других целей используется). Если нужен расчет по периодам изменения цен (вы привели аналогию с окладом), то делаете регистр накопления с периодом действия цены и месяцем регистрации. При этом период обязательно должен заканчиваться концом месяца и начинаться с первого числа, а внутри месяца разбиваться по датам изменения цены. Единственный минус таких данных, отчет по ним можно будет строить за период, кратный месяцу (как и с регистрами расчетов).
24. CheBurator 3126 13.06.24 01:05 Сейчас в теме
Зачем все это записывать/хранить на каждый день?
В большинстве случаев расчет за ХРАНЕНИЕ выполняется за период выставления сумм за хранение. 2-го числа пришла Деталь1, 10 ушла. 17 пришла снова (другой экземпляр этой детали)... на конец месяца считаем количество дней присутствия количества деталей на складе, пристыковываем цены, рассчитываем, формируем "акт сумм за хранение". Результатом расчета будет являться собственно документ "начисления за хранение", для фиксации цен/дней (чтобы избежать подправок цен задним числом после уже проведенного расчета и выставления клиенту) фиксируем в РС периоды-цены с привязкой к документу начисления. Как-то так я бы сделал.
25. CheBurator 3126 13.06.24 01:07 Сейчас в теме
Ну и при расчете кол-ва дней хранения надо учитывать ОСОБЕННОСТИ (см. условия договор хранения). Деталь пришла в 11:00 12.06.24, ушла в 17:00 12.06.24 - НачОст и КонОст по дате 12.06.24 = 0, но при этом количество дней хранения - есть, = 1
user2033930; +1 Ответить
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот