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

Идея такая - получить в суммовой таблице спецрегистра строки с суммами в разрезе ссылочного номера документа (в моем случае - документа MM). В ведении группы таблиц я добавил поле REFDOCNR типа REFBELNR на закладке суммовой таблицы. После всех настроек начал проводить документы MM. Документ спецрегистра у меня создается, но поле в суммовой таблице не заполняется.

Я поставил точку прерывания в инклюде FGIMV200, где отрабатывают правила переноса таблиц. В отладчике видно, что к этому времени в ACCHDR еще не появился номер FI-документа и номер ссылочного ММ-документа. При этом в таблице отдельных позиций регистра поле RZZREFDOCNR прекрасно заполняется!

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

Результаты расследования: номер документа FI и ссылочного документа переносится в таблицы спецрегистров в отдельном месте - в ФМ G_RWIN_UPDATE в строке PERFORM set_docnr, но эта самая подпрограмма set_docnr заполняет только фактическую и плановую таблицы отдельных позиций, но не суммовые таблицы.

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

А таблицу Объектов добавили поле? Ключ в _ИТОГОВОЙ_ таблице из чего собираться будет?

Ну да, добавил поле REFDOCNR в таблицу объектов и в итоговую. Беда в том, что в момент отработки логики переноса полей в итоговую таблицу номер бухгалтерского документа еще не известен.

Тогда ставите в настройке регистра "обновление задним числом", и переносите документы в спцрегистр постфактум тр. GCU4. Можно сделать фоновые задания, с нужной вам периодичностью.

Plank, спасибо за идею! При переносе задним числом проблем нет.

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

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

Получается, нужно создавать индекс по ACCTHD-CPUDT?

2 Лёдчик: Задача стоит такая. Имеется счет запасов 41-xxxx. Требуется получить перечень документов MM, которые сформировали обороты по этому счету за указанный период в разрезе
№документа-дата проводки-сумма оборота по счету 41-xxxx.

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

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

Посмотрите отчет J3RTAXJR - мне кажется для Вашей задачке он вполне подойдет.

В Вашем случае в таблицу итоговых записей совсем не нужно добавлять эти поля.
Вполне хватит того, что они будут в таблице отдельных позиций (-A).
К ней SAP Query запрос и грамотный индекс.

А так у Вас будут постоянно расти две таблицы, которые Вы не используете.

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

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

Я к чему это все? К тому, что использовать сущности, спроектированные не вами лучше так, как это задумывал разработчик. Иначе потом можно напороться на нелогичные и неразрешимые ограничения.

Посмотрите в сторону ИСЛ. Чем она вас не устраивает?

Ну, задача бизнеса решена. Отчет работает, хотя и медленнее, чем хотелось. Так как интресует именно расшифровка оборотов по бух. счету, то я и хотел пойти от бух документов, а не от документов материала. Отсюда и идея попробовать использовать спецрегистры, а не ИСЛ. Заодно и разобраться немного в том, что это такое и с чем едят. Не удалось - ничего страшного.