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

Задача - обойтись без вычисляемых полей в СКД для вычислении разницы между датами. Мне пришлось создавать отчеты, в которых вычисляется разницы между датами в днях с учетом производственного календаря. Как вы знаете, в типовых есть регистр сведений производственного календаря и функция Но вот в чём проблема. Использовать эту функцию в отчетах, сделанных с использованием СКД тяжело, поскольку запрос этой функции нельзя соединить с другими запросами изза грёбанной строчки А число дней то для каждой строчки запроса может быть разное! А нам необходима возможность рассчитывать даты с учетом производственного календаря прямо в запросе! для того, чтобы это работало быстро, нужно создать ещё один регистр сведений в котором будут все возможные комбинации дат и в качестве ресурса будет количество дней между ними, просчитанное заранее. Что скажете про этот подход или есть более умный метод?

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

и чем не подходит РазностьДат

надо выходные исключить видимо и праздники

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

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

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

вот она как раз с учетом дает, а за вычетом нет

проще уже из РазностиДат исключать праздники и выходные

- в РегистрСведений.РегламентированныйПроизводственныйКалендарь - уже все есть (там еще по-моему есть и продолжительность дня) - остается только связать с входным набором периодов

Как вариант - взять сумму календарных дней по условию ДатаКалендаря МЕЖДУ ДругаяТаблица.ДатаНачала И ДругаяТаблица.ДатаОкончания Только не факт что будет быстрее вычисляемых полей. А если отчет попробуют за 10 лет сформировать, что тогда?

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

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

а если за 10 лет? долго. отчет не должен работать долго.

я вот щас создам и заполню регистр и скажу на сколько гигово увеличилась база )

и количество записей не забудь

- цитата ".. будут все возможные комбинации дат и в качестве ресурса будет количество дней между ними, просчитанное заранее. " -  вы представляете себе количество комбинаций скажем хотя бы за месяц? А за год? Не забудьте между 1-м и 5-м, 2-м и 5-м и т.д. Дурное дело конечно не хитрое ... :)

+ - насколько помню навскидку - это будет для года 365! (!- это фактериал)

Понимимаешь, тут надо будет сразу на все будущее время сформировать все возможные сочетания дат. Иначе потом будешь постоянно сражаться с нулями дней в отчете. Думаешь, копаться среди 13 с лишним млн. записей будет быстрее?

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

дни просрочки вообще ни о чем, вот если расчет пеней тогда другое дело

+ а дни просрочки интересны только в интервалах, т.е. свыше 30, 60 и более дней

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

пеня не может начисляться на небанковский день

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

ну я имею ввиду что менеджерам зарплату считаем так.

Вот вам примерно готовый запрос с получением выборки (без СКД) - дальше модифицируйте как угодно:    ИЗ

а писал не ты, так?

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

я под пени подразумевал штрафы которые влияют на заработок.

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

не спорю. можно и в отчете. просто время. просто в не доконца понял что имелось ввиду и по умолчанию подумал что та же идея.

а что он делает в данном случае?

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

- получаете массив: требуемые исходные строки (началопериода, конецПериода еще какие-то реквизиты вам нужные, например мне нужен был заказ и т.п.) - и в моем случае количество секунд каждый день в интервале с учетом выходных, предпраздничных и т.п. (можете сделать просто 1 для рабочего, 0 - для выходно, в зависимости от потребности) - все - просчитайте итоги продолжительности по ключевым полям - и вся задача

+ - в частности сумма рабочих дней за интервал и будет разность дат

Время будет только при первом формировании отчета, когда такой регистр массово будет заполняться. Тут минус в одном - придется писать код вне СКД. Да и то смотреть надо, сколько времени в реале выйдет. Может и не стоит сохранять - и достаточно просто во временную таблицу поместить, тогда можно и одним запросом обойтись.

+ если последний подзапрос переписать в виде:        И График.ДатаОкончания >= Календарь.ДатаКалендаря) КАК Т СГРУППИРОВАТЬ ПО Т.ДатаНачала,Т.ДатаОкончания То получаете вам нужные данные, в предположении что "Смена" - формировали 1 - для рабочего дня и 0 - для выходного. Усе!!

ну не дело это... долго работают вычисляемые поля и это уже не запрос. а запрос переносим на другие отчеты... а как вычисляемое поле перенесёшь куда-нибудь помимо СКД?

понял)

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

Кстати вот что сделал