Приветствую всех!

Встала задача (мозг, тем временем, лег) - необходимо создать логику вычисления стоимости хранения продукции на складах ответ.хранения. Т.е. есть множество контрагентов, которые постоянно привозят/увозят товары, а надо рассчитывать стоимость хранения посуточно в зависимости от наполненности/тарифа.

Но вопрос заключается в том, что стоит ли создавать запись в оборотном регистре на каждый день по каждому контрагенту и складу или лучше каждый раз рассчитывать результат?
Сразу оговорюсь, что около 100-150 контров, 10 складов и период около 20 лет. Конфа самописная. УФ.

С удовольствием воспользуюсь Вашими доводами)

(0) Что здесь думать-то?
Нужны агрегаты — используй регистр
Не нужны — не используй

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

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

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

(0) Какое время считается что контрагент хранил у вас сутки?

6:00 12:00 15:00 18:00 ... 24:00?
А что если утром было полный склад а в 10:25 вывезли весь товар?

На нефтебазах просто считают. Завёз, за месяц заплати с каждой тонны. И на остаток на конец месяца начисляют хранение вперёд. Сократи период до суток, и вперёд.

Зы
Я лично не люблю хранить данные лучше подсчитать их.
Но все должно быть в пределах разумного.
Остаки на каждый день известны нужно каждый день ночью запускать регламент на расчет за прошедший день.
И записывать в РС
Потомо по ним отчеты строить

(7) а потом задним числом изменят алгоритм расчета...

(5) (7)  Это не столь принципиально, но считается что факт поступления товара в календарную дату - есть факт хранения товара в эти сутки. Так же и убытие. Т.е. если утром был полный, а в 10:25 вывезли все - оплата за эти сутки требуется. Формула выглядит как (Расход + КонечныйОстаток) * Тариф

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

Может, регистр расчета?

(9) Не расход, а приход. Читай внимательно (6)

(10) Читаю. Но именно Расход

(10) Документы как выставляете? Раз в месяц или каждый день?

(9) не надо приплетать расчеты туда где они не нужны.

(11) Ещё раз читай, и думай. Расход ни причём, за поступление должна плата браться и за остаток на конец расчетного периода.

(12) Раз в месяц обычно. Но бывает и за 10 дней, и за 13. Иногда надо аналитику строить. И за месяц, и за год. И за N дней. Для регистров - идеальная ситуация

(9)

Автор -- хочу регистр расчета!
Все -- нахрен он тебе не нужен!
Автор -- но я все-равно хочу! Я художник, я так вижу.

Автор, если ты хочешь делать на регистрах расчета -- делай.
Как получится, не забудь зайти, поделиться, рассказать как все классно работает и какие все отцы старперы и {еще нехорошее слово}

(15) Вот и считай приход за месяц + остаток на конец каждого дня расчетного периода. Это для документов. Или делай начисление каждый день, а в конце просто сумму всех документов используй (но это косячный метод).

(14) приход уже сидит в остатке. Чтобы получить условно максимальный остаток за период берут (Расход + КонечныйОстаток) как они написал, выглядит логично

(14) Ок, подумай. Ты взял 10 тонн на месяц. В конце месяца у тебя осталось 5 тонн. Ты считаешь "за поступление должна плата браться и за остаток на конец расчетного периода". А если к поступлению в этот период пришло еще 7 тонн и ушло 7 тонн? Вот поэтому Расход + КонечныйОстаток отражает эту картину целиком и полностью!

(18) Во, опередил)

(18), (19) всё крайне логично. 10+7 — поступление и за остаток на каждый день возьму, и пофиг когда и сколько ты вывозил. Я вам из жизни пример привёл, когда в одной бочке хранится товар целого десятка поклажедателей.

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

(0) Используй Регистр Сведений и не ипи ничего

(21) К сожалению, твой пример не подходит для данной ситуации

(22) Обороты здесь не прокатят, в формуле расчета фигурирует остаток, да ещё на каждый интервал из расчетного периода.
Учтите ещё момент, когда поклажедатель положил товар на полгода, и расхода не будет. Вот потому нормальные люди и берут денежку вперёд, по приходу.

(24) То есть пример с нефтебазой, когда произвольно по времени поступает произвольное количество продукта (в рамках квоты) и также произвольно по времени и количеству вывозится не подходит? Странно даже.

(25) Обороты для стоимости хранения. Они никогда не уйдут в ноль и двигаются только вперед.
Остатки для количества хранимого товара.
Ну а тариф - сведения. Непериодические.

(27) Тариф это справочник + периодический РС где кому, где, какой тариф

(28) периодический РС где Контрагент, Склад, Тариф

(27) Имхается какая-то каша у вас в бестолковке, или задача не озвучена корректно. Стоимость хранения считать по регистру остатков товара не логично. Логично считать по документам, исходя из условий договора. И делить все деньги на всё количество.

(29)+ Еще один РС (непериодический и даже независимый можно) куда уже пишутся результаты расчетов
И можно в реквизит засунуть в ХранилищеЗначения документ в виде ТабДок с детальными расчетами

Короче "наймите программиста"©

(31) Да там много чего ещё можно придумать. Разная стоимость хранения в первый и последующие дни, стоимость погрузки/разгрузки с тонны.
И ещё один недостаток схемы, когда считают по расходу: возможность банального кидка. Когда товар вывезли и за последний месяц не заплатили. У хранителя в этом случае ни товара ни денег захранение.

(30) Причем тут каша? Я бы рад решить стандартную задачу "договор на месяц -> счет на оплату", но задача именно такая: считать стоимость хранения за период времени. И документами это не считается, потому что документы являются регистраторами прихода/расхода, а никак не времени пребывания товара на складе.

(33) а это хороший довод.

(33) И причем здесь "нерентабельность коммерческой схемы" и "возможность кидка"? Мы с Вами не бизнес-модели обсуждаем)

Арифметика: Ост_нач + Приход - Расход = Ост_кон
Или
Ост_нач + Приход = Ост_кон + Расход

(34) Если "документы являются регистраторами прихода и расхода", то в чем проблем построить по ним остатки на любой произвольный момент времени? Если есть остатки на любой момент времени, то в чем проблема построить "время пребывания определенного количества"?
(9) а если утром был пустой, перед обедом завезли товар, а после обеда вывезли, и склад снова пустой?

(27) [Обороты для стоимости хранения. Они никогда не уйдут в ноль и двигаются только вперед.]
превращение ОХ в систему биллинга влечёт паранойю
Стоимость хранения фиксируется документом выбытия, расчет храниться в его ТЧ

(38) а если утром был пустой, перед обедом завезли товар, а после обеда вывезли, и склад снова пустой?
Взимается оплата за один день. Работает формула Расход + КонечныйОстаток

(39) Не совсем понял про биллинг?
В том и проблема, что нет четких документов выбытия. Есть поступивший товар - например, фура хагиваги в 10 номенклатурах. Это один документ прихода. А потом начинается расход - например, 27 документов расхода по 250 килограмм красных, синих или зеленых. В разные дни. И увязывать хранение документами в этом случае - тяжело. Ну или я пока не вижу как.

Вывод: регистр не нужен.
1. Берётся контрагент
2. С даты договора по сегодня включительно все приходы (Приходище) и все расходы (Расходище)
Имеем:
Ост_кон = Приходище - Расходище
3. С даты последнего выставления предыдущего счёта за хранение по сегодня  берётся Расход
4. Сумма текущего счёта = (Приходище - Расходище + Расход) * Тариф

(0) Не забудь указать реквизиты организации, чтобы не столкнуться потом с этим поделием.

(42) регистром в этом случае проще. Но он не обязателен.

(41) не нужен поклажедателю биллинг, т.е. возможность в любой момент получить счёт для оплаты

(41) если у вас  "поступление - фура", а "расход - килограммы", то вы никогда не посчитаете. Наймите программиста.

(44) Лишнее. Хранение ориентируется только на объёмы, хоть хлопок, хоть золото.
Машины завозят и увозят объёмы, которые уже учтены в накладных(?).

(47) ну тогда и отчеты по складу можно по документам делать... там же "всё учтено", "регистры - лишняя сущность"

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

(49) Да ну, какие там партии. Есть, к примеру, у меня гараж пустой и я за плату храню там сезонные шины. Кто-то привозит/увозит, платит за время и объём, ну какие партии?

(48) Хорошо, пусть будет регистр. Машу каслом не испортить.

оборотный регистр, запрос к которому нужно делать так, чтобы разбить на интервалы по датам изменения объемов хранения (тета соединение в запросе 1С)

(46) Все уже давно работает хорошо. Но есть "НО!" - работает на вычислениях. То есть вычисляет все необходимое для любых контров, или групп контров, складов, да хоть для всех с разбивкой по каждому. На любой период.

И в этом кроется та "хотелка", за подсказкой о которой я обратился ко всем Вам. Если понадобится рассчитать по 1000 контров за 10 лет - это какие-никакие затраты ресурсов и времени на выполнение. Хранить миллион строк "ежедневных начислений", дабы получить агрегаты - быстро считает, но смущают "лишние" сотни тысяч строк (и не очевиден механизм реализации этого добра)

(53) чтобы не было разночтений:
получаю таблицу остатков на каждый день по контру за период
получаю таблицу тарифов на те же дни по контру за период
перемножаю
итоговая сумма = стоимость хранения за период

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

Истина как всегда посередине. РС по ежемесячным остаткам + уже налаженный расчёт внутри месяца.

(53) >Хранить миллион строк "ежедневных начислений", дабы получить агрегаты - быстро считает, но смущают "лишние" сотни тысяч строк
1. Миллион строк это сколько в кб?

>(и не очевиден механизм реализации этого добра)    
2. Механизм очевиден и описан в (32)

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

(4) это называется - OLAP

(59) который реализуется другими средствами. для клюшек это была QryConsole, например. Для снеговика таких средств нет. Да и OWC ушел из доступности.