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

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

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

таблицы то проапдейтить напрямую не проблема но как дальше с этим жить :)

вобщем как бы так запросом получить группировку по видам регистров а ?

вот есть сейчас в отчетах выводы


а надо

авторне особо уловил разницу

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

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


автор, но на клюшках это будет через ж.пу как обычно...

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

leaf, это же 7ка :))... совсем корни забыли гля какие там объединения...

автора универсальный отчет два регистра за раз кушает?

они по переменным из регистра работают так что в этом плане

Товар = Регистр.Регистр1.Товар, Регистр.Регистр2.Товар;

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

не ну можно SQL прямой использовать но там чтоб построить универсальный (динамические группировки периода и фильтры) для 5-ти группировок разноплановых времени убить надо огого (плавали знаем :) - больше не хочу)

авторв чем дело то?

да можно и двумя запросами :) только вот вся универсальность теряется... одним надо

был когда то от абби црм с очень интересным движком отчетов... вот на этой базе скажем отчётец

http://slil.ru/28097762

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

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

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

вобщем таки решил ввести новые измерения где будет перечисление вида фонда учета товара (вчера весь день переписывал в коде методы СводныйОстаток и Остаток) а сейчас воюю с СКЛ чтоб таблицы итогов проапдейтить напрямую... дубли примари елки двадцать и это в итогах :(... производительность пока не мерял

мужики (и леди) пишу уже сюда раз начал

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

сам запрос


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


не выводит в "С" никаких цифер отличных от 1.. т.е. записи таки уникальны... апдейт идет конечно поля одного из ключей (измерение регистра)

где я что-то не учитываю ? (признак ключа на том поле что апдейтить пытаюсь скинул и не помогло)

leaf, реквизиты - обалденная штука только вот беда то в том что они только в RAxxx фигурируют :)

без остатков то никуда... к сожалению

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

ну вот нет такого


посему и

авторВидРегистра = Регистр.Регистр1.Вид,Регистр.Регистр2.Вид;

где Вид уже измерение (т.е. ключевое поле)

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