Сравнение записей регистра сведений в запросе #744689

Подскажите плз. как организовать цикл в запросе, понимаю что через вложенный запрос, но дальше не знаю (

шта?

fetch в 1с не завозили

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

Наконец пятничная ветка!

в какая-то байда, похжая на нарастающий итог, но есть мнение что эту байду можно сделать в СКД

Интересно, в чем смысл функции? Она проходит по списку чего-то, и если первая запись больше или равна второй, то разницу между записями нужно вычесть из итога, иначе нужно добавить в итог вторую (большую) запись Моя фантазия мне даже не намекает на то, что бы это могло автоматизировать

Про ВЫБОР почитай.

чё так слабо - биллинг - СКУДЫ - скидки

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

Дешевле в цикле, перебором :) Формула какая то не полная, "Огласите весь список, пжалуста" (с)

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

Выбрать   Регистр.СуммаПриход Из РегистрНакопления.Регистр КАК Регистр

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

по этому СуммаПриход

дело имеем с регистром сведений (

сделайте на РН. а то если в РС хранится "накопленный итог" на каждый день - то это ЖП. проще всего добавить реквизит с изменением, и его просуммировать.

см. ну чё - съела ? биллинг в чистом виде сделанный конечно через ж.опу

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

ОК.. давайте с цифрами в регистре оборот по дням нарастающим итогом, так: 100 110 150 300 Запись1 - это первая видимо, Запись2 - вторая ... Что это?

балдой об стенку побейся тебе же русским языком ТС всё объяснил

Да, страшно представить, как и что он этой формулой считает. а так все норм

У ТС Запись2-Запись1 в , а у тебя наоборот. В итоге "Итог" будет 500 — а ИМХО это есть оборот за период выборки записей.

У нее как у ТС. Видимо, ТС слегка перепутал.

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

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

У меня как раз так, как у ТС. Он в условии определяет, что запись 1 >= Запись 2, а потом вычитает из меньшего большее

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

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

да, я так и пишу. только месяц в твоем примере один, а у автора - много, видимо

да тут регистр накопления просится, конечно.

точно, это я уже в пятницу читаю через слово :)

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