Привет всем!

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

<материал> <остаток> <остаток:вид движ1> <остаток:вид движ2> <остаток:вид движ...> <остаток:вид движN> <остаток на конец дня>

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

Пугает только количество видов движений = 150 штук... + user-exit наименования этих столбцов = 150 штук + немного надо на вырост = 100 штук...

Может, как то можно малыми потерями обойтись?

В смысле он должен быть динамическим (типа автоматом выстраивать все виды движения)? Если можно статикой, то можно руками ограничить показатель и в коце добавить показатель, где вид движения not in (перечислить все вбитые ранее) - для контроля за появлением новых видов (в столбце значение появится). А вообще еще можно в строки кинуть "материал", а в столбцы кинуть вид движения и под него - "остаток", тогда его раскидает по видам,а в "итого" получим общий остаток. Непонятно только, что за "остаток на конец дня". А чем он отличается от "остаток"?

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

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

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

Имхо, для 3.5 и без программирования - либо все показатели разложены по видам, либо никакие. Либо вручную. Это в общем случае.

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

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


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

Но все равно это изврат.

Привет.
Если нет желания мутить WEB приложение то вариант один. Создать ещё один провайдер с такой же структурой, но без видов движения. Затем объединить их мультом, а в отчете по столбцам создаешь структуру в которой 3 "Выбора", в крайних показатель берешь из провайдера остатков, а в центральном из обычного, ну и ограничение на даты там-же наложить. Под структурой надо разместить признак вид движения. Загрузку в такой провайдер можно проводить из того-же источника. Если есть внедренный FI-AA то обрати внимание на 0FIA_MDS1, там как раз виды движения только для ОС, можно будет потренироваться.

Интересно. А в этом случае разве не каждый из выборов структуры будет развернут по всем видам движения (т.е. получим n*3 столбцов)?

Спасибо большое, Road Runner и EvgenySA!

Направление я понял.

Только вот засада - на экране выбора есть параметр - вид движения. Все показатели должны быть ограничены выбранными видами движения.

+ заказчик добавил еще 2 параметра в середину отчета - сумма прихода и расхода, их тоже не нужно бить по движениям...

Также заказчик стоит на своем - ему нужен отчет именно такого вида...

Нет, именно для этого и нужен провайдер остатков без видов движения. В отчёте будет выводится заголовок в две строки в первой надпись типа "Остаток на начало", а ниже вместо вида движения "Не присвоено", далее в первой строке "Остатки по видам движения", ниже пачка ячеек с видами движений, а вот остаток на конец надо тоже брать из провайдера остатков ибо сумма "Остаток на начало" и "Остатки по видам движения" как раз даст развёртку по видам движений. Я это на 0FIA_MDS1 проверял.

Ну ты попал, сочувствую.
Провайдер остатков тут не поможет. Можно попробовать сделать сервисный куб на тот провайдер, который есть сейчас, а в модуле АБАПом схлопывать записи, убирая вид движения.

Уговорил разделить на 2 отчета. Ура! Еще поживем!

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

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

Поздравляю, имхо это единственный неизвратный вариант (да и нечего этим данным вместе делать).

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

Наверно действительно из-за этого ! Полезный совет, спасибо!

З.Ы. "Ну, кроме чалмы еще, вот, сковорода нужна!" (с) Ералаш

Таки осилил создание сервисного куба, теперь можно свою обработку данных делать в АБАП