Ошибка оборотно-сальдовой ведомости ГК

[Serge_DD]

Аксапта 4.0 SP2 на "большом" плане счетов при построении ОСВ по ГК выдается следующая ошибка: "Ошибка времени выполнения: Выполняемая операция генерирует оператор SQL, содержащий большое количество вложенных операторов. Разбейте данную операцию не несколько частей и повторите попытку.

Трассировка стека

(C)\Classes\QueryRun\next
(C)\Classes\FormDataSource\executeQuery
(C)\Forms\RLedgerSheetTurnoverBalance\Data Sources\LedgerTable\Methods\executeQuery
(C)\Classes\FormDataSource\research
(C)\Forms\RLedgerSheetTurnoverBalance\Methods\init
(C)\Classes\SysSetupFormRun\init - line 3

"
Установкой фильтра на меньший диапазон счетов ГК эта проблема решается.
Подскажите возможные пути решения проблемы.

[TasmanianDevil]

В
\Forms\RLedgerSheetTurnoverBalance\Data Sources\LedgerTable\Methods\executeQuery
вставьте перед вызовом super()

info(this.query().datasourceno(1).toString());

Что он там выдает ?
Так же интересует - какова глубина вложенности плана счетов ?

Всю структуру запроса там делает класс RLedgerSheetEngine_TurnoverBalance по настройке структуры плана счетов.

Копайте в нем, вполне возможно что заданный диапазон счетов имеет в плане счетов такую структуру, что формируемый этим классом запрос просто выходит за рамки возможностей системы.

[ena_ax]

Аналогичная проблема.
5000 строк в таблице LedgerTable.
При формировании отчета указываю условие запроса "!9*".

Генирируется честный запрос
SELECT * FROM LedgerTable WHERE ((AccountNum = N'00' OR AccountNum = N'10000000' OR AccountNum = N'10009990' OR AccountNum = N'10100000' OR AccountNum = N'10110000' OR AccountNum = N'10111010' OR AccountNum = N'10112000' OR AccountNum = N'10112010' OR AccountNum = N'10112028' OR AccountNum = N'10113000' OR AccountNum = N'10113010' OR AccountNum = N'10113028' OR AccountNum = N'10114000' OR AccountNum = N'10114010' OR
.......
и так далее перечисление по всем счетам, т.е. более 3000 счетов.

Как результат имеем ошибку: "Ошибка времени выполнения: Выполняемая операция генерирует оператор SQL, содержащий большое количество вложенных операторов. Разбейте данную операцию не несколько частей и повторите попытку.


Получается системная ошибка при использовании стандартных запросов.
Есть ли рецепты по решению этой проблемы?
Спасибо.

[Raven Melancholic]

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

[Михаил Андреев]

Цитата:

Сообщение от Raven Melancholic

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

Хм. Примерно так же в 3.0 сделан российский генератор финансовых отчётов. Мягко говоря, очень долго работает. Уверен, что в данном случае работает намного быстрее
А можно просто запрос переписать, чтобы "!9*" превращалась именно в NOT LIKE "9%" без расшифрования на отдельные счета.

[ena_ax]

Цитата:

Сообщение от Raven Melancholic

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

Идея понятна, буду признателен за уже реализованный код.

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

[Михаил Андреев]

Цитата:

Сообщение от ena_ax

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

Увы. Российская и прочая локализации накладывают гораздо большее количество ограничений, например: обязательные корреспонденция, флаг "фиксированная корреспонденция", невозможность использования одновременно польской функциональности (а если у меня филиал в Польше?), учёт только "по отгрузке" и много других.
О части из них, кстати, честно говорится в соответствующих мануалах и тренингах.

[TasmanianDevil]

Цитата:

Сообщение от ena_ax

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

5000 счетов, это, простите, Ваша собственная придумка на проекте или это консалтер от внедренца предложил таким способом пару разрезов аналитических в учете завести ( т.е. в LedgerTable запихать) ?

[ena_ax]

проект по трансформации бухгалтерской отчетности в управленческую.

5000 счетов это план счетов МСФО. Не вижу в этом ничего плохого.
Аналитика тоже испоьзуется.

[Михаил Андреев]

Вопросы ко всем:
1. В каком виде и для каких целей используется данный отчёт?
2. Если в нём вам не нужно проводок, может, проще настроить свой финансовый отчёт? Будет работать на порядок быстрее.

[pitersky]

Цитата:

Сообщение от ena_ax

проект по трансформации бухгалтерской отчетности в управленческую.

5000 счетов это план счетов МСФО. Не вижу в этом ничего плохого.
Аналитика тоже испоьзуется.

Если не секрет - кто всё-таки разрабатывал ваш план счетов по МСФО? Вы сами, внедренец, контора управленческого консалтинга или кто-то ещё?
Мне кажется, что план счетов из 5000 строк (даже если 1000 из них - это уровни иерархии) в принципе малоуправляем и трудноанализируем с точки зрения управленческого учёта. наличие такой детализации ИМХО автоматически должно привести к тому, что обозреватся будут 2-3 сотни итоговых счетов, а остальные будут содержать редко востребованную детализацию. Что само по себе наводит в итоге на мысль о 2-3 сотнях счетов и переводе остальной детализации в финаналитику.
Поправьте меня, если ошибаюсь. Проект с участием МСФО у меня был только один

[ena_ax]

Цитата:

Сообщение от pitersky

Если не секрет - кто всё-таки разрабатывал ваш план счетов по МСФО? Вы сами, внедренец, контора управленческого консалтинга или кто-то ещё?
Мне кажется, что план счетов из 5000 строк (даже если 1000 из них - это уровни иерархии) в принципе малоуправляем и трудноанализируем с точки зрения управленческого учёта. наличие такой детализации ИМХО автоматически должно привести к тому, что обозреватся будут 2-3 сотни итоговых счетов, а остальные будут содержать редко востребованную детализацию. Что само по себе наводит в итоге на мысль о 2-3 сотнях счетов и переводе остальной детализации в финаналитику.
Поправьте меня, если ошибаюсь. Проект с участием МСФО у меня был только один

Вся методика по МСФО уже существовала в компании. И каким образом она появилась мне не известно. Вопрос "Почему такой план счетов?" не обсуждался, приняли как данность.

[ena_ax]

1. Использование отчета стандартное - распечатка обротов и сальдо по счетам для целей проверки, просмотра. контроля и тд.
2. Финансовыми отчетами пользуемся.

К стандартному отчету ОСВ првавыкли пользователи. Опять же используя финансовые отчеты, нужно постоянно поддерживать структуры этих отчетов в актуальном состоянии плана счетов и аналитик.

[Михаил Андреев]

Цитата:

Сообщение от ena_ax

К стандартному отчету ОСВ првавыкли пользователи.

Именно такой ответ я и ожидал. И сколько страниц содержит такой отчёт с 5000 счетов и проводками? По опыту, данные такого отчёта используются максимум на долю процентов, не более. Если нужно выверить что-то конкретное, то так и делают, фильтруя не более десятка счетов для выверки.

Цитата:

Сообщение от ena_ax

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

Извините, но в 4.0 это можно один раз настроить, чтобы структура поддерживалась. Бывают какие-то баги, не без этого, конечно.

[ena_ax]

Вопрос был не в том как использовать отчет, а понять причину ошибки и устранить ее.
Теперь все ясно, Ошибка системная, исправляется программированием.
Для меня это было совсем не очевидно.

[Raven Melancholic]

Увы, с примером кода я поторопился. Поиски привели к осознанию того, что выполнял эту модификацию на прошлой работе. Естественно, что того приложения у меня нет.

[vallys]

Обсуждение, конечно, давнее, но есть еще один "стремный" способ обойти эту пробему. Стемный - потому что для специфических случаев может не прокатить
Можно сгруппировать счета:
Пусть некоторые счета удовлетворяют одной конкретной маске (отберем все счета для этой маски). Если в плане счетов нет ни одного счета, который подходит под указанную маску и не используется для отчета, то исходные счета можно заменить маской.
Например, счета 1000000, 2000000, 3000000 можно заменить маской ?000000. Маски ?000000, ?100000, ?200000 можно заменить маской ??00000. И т.д.
Подмена на маску осуществляется только если все счета, которые удовлетворяют маске, используются в отчете. И не забыть про спец. символы.
В принципе - работает, но лучше все-таки через таблицу, как посоветовал Raven Melancholic, хотя и там есть свои "прелести".

[pitersky]

понятно. ИМХО это ошибка учётной политики. Мне даже интересно, как можно проанализировать операции по 5000 счетов за адекватное время.

По теме топика - у меня на одной задаче тоже возникла необходимость наложения ограничения виде "!АА*". Но никакого перечисления в итоговой строке запроса я не получил. На сиквел ушло (NOT(Field1 LIKE "AA*")). Правда, я это на 3.0 делал