Галактика в вопросах и ответах

Добрый день. Не можем победить ошибку.
Имеется бюджет. При его загрузке вываливаться ошибка и свал.

Delphi internal error 1 (Не удалось выделить динамическую память) in atlantis.rtl at 00002714

Слева внизу при этом этап на котором происходит свал: "Инициализация: Построение оси StV"

Подскажите что может быть? Как победить ошибку.

Вероятно кубик данных большой тянете в форму. Об этом писалось уже здесь.
Слегка может помочь опция "Ускоренная загрузка аналитик" в настройке типовой бюджетной формы.
А вообще нужно умерить свои аппетиты: оптимизировать бюджетную форму (сократить число аналитик), а также чистить каталог аналитик бюджетирования.
Также не мешает периодически удалять dsk и tmp.

Даже при выставленном флаге у ТФ "ускоренная загрузка аналитик" ?

для DEN:
да флаг выставлен.

для Sim:

Аналитик то собственно не много. Всего 6
в двух - по 2 значения
в третей - 6
в четвертой - 10
в пятой системной организации 20.
В шестой еще штук 5.
Одна системная аналитика (организации), остальные пять пользоватлеьские.
Нет даже ни одной двухуровневой аналитики.
Для такого уровня системы детализация не большая.
куда еще урезать?

По всем перечисленным аналитикам посмотрите в Аналитике бюджетирования - сколько там значений? Перемножьте все взятые оттуда числа, затем еще умножьте на количество подпериодов, выводимых в форму (месяцев, или дней - что у вас там). Если полученное значение будет превышать 10 млн. - значит все-таки перебор, будет работать нестабильно.

dsk и tmp чистим.

Итоговое значение посчитаем. и сообщим

Подсчитали итоговое значение получилось 311 040 вариаций аналитик
ЧИсло подпериодов 31
Поэтому итоговое значение получается 9,62 млн.
Вроде как не перевалили за 10 млн.
Неужели эту ошибку нельзя подтравить никак? Можно как то разработчику написать?

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

на сервере тоже валится
причем точно также

Вобще достаточно странно, я бы что попробовал сделать - разбить используемую типовую форму предположим на две части (две отдельные типовые формы, для примера - доходная и расходная части БДДС).
Попробовать загружать эти две формы. Если проходит, то дело все же в размере кубика данных, sim правильно говорит, только писать в техподдержку в этом случае бессмысленно.
Выходы следующие.
1. Чистить аналитику и продолжать использовать данную типовую форму, но я бы не советовал, в будущем всеравно черевато вылетами.
2. Упрощать типовую форму бюджета сокращая аналитику, необходимые отчеты получать через анализ бюджетов, там вылетов не будет и скорость получения отчетов выше.
3. Бить типовую форму на несколько частей.

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

Все верно говорит Serg7907, упрощение типовых форм через минимизацию выводимых аналитик - это наиболее эффективное решение. Это как говорится "по-молодости", когда только начинают работать с бюджетами, многие почему-то стараются впихнуть в формы максимум информации (аналитик, периодов). От этого одни проблемы - валится, медленно работает, крайне неудобно работать с этими "портянками", что на экране, что на бумаге. Вообще, по-хорошему (если посмотреть в литературе советы бывалых, да и вообще рекомендации специалистов) - бюджет должен умещаться на ОДНОЙ странице формата А4.
А для анализа бюджетной информации, кроме непосредственно галактических бюджетных типовых форм, есть другие инструменты (в который раз уже повторяемся): реестр финопераций, Анализ бюджетов, кнопка раскрытия агрегатов по данным (сверление бюджетной статьи) и пр.
И еще один явный перекос, на который RavageR-у здесь уже указывали - это тип периода. Ну не делает никто бюджеты с детализацией до дня - неудобно это, да и непрофессионально. На то есть платежный календарь. В крайнем случае в бюджетах можно тот же реестр финопераций использовать, там до дня спуститься - без проблем, при том что горизонт планирования в бюджетах будет месяц.
А в вашем случае RavageR - применение форм бюджетов с ежедневной разбивкой является еще одним гвоздем в крышку так сказать. Т.е. еще больше повышается нестабильность работы.
Так что перестраивайтесь потихоньку, и чем раньше тем лучше.

Уважаемые господа учавствовавшие в обсуждении.
Во-первых все большое СПАСИБО за идеи, опыт и предложения и варианты.
Многочисленные тесты, корректировки, на базе ваших идей дали бесценный опыт и соственно результат.
В кратце о полученном опыте о свалах. Есть определенный порог в бюджете когда он сначала начинает жукто тормозить при загрузке, если его при этом еще чуть нагрузить тогда начинает наглухо валиться. Порог этот достигается количеством аналитик. Причем если заменить по возможности некоторые аналитики статьями (подстатьями), тогда бюджет будет жить. Порог этот начинается резко. Буквально пара новых значений аналитик бюджета и из 5 секундной загрузки он преврящается в 1 минуту времени ожидание, еще пара значение и время загрузки увеличивается до 3 -4 минут. Еще пара значение и он больше не загрузиться.
Причем если разбить БДДС мертвый, незагружающийся на 2 части (например расходная и доходная), то по отдельным кускам он загрузиться ОЧЕНЬ быстро и без проблем. Но этот не выход. Она из функций БДДС по плановым данным видеть остаток на конец периода. Дабы не ушли мы в минус на определенном этапе.
Часть аналитик получилось заменить подстатьями, т.о. удалось сохранитть всю требуюемую согласно постановке бюджета структуру. Т.о. на мой взгляд, программисты Галактики имееют очень узкое место в данной подсистеме, по сути я бы его расценивал как ошибка в программирование. Да можно обходиться другими средствами. Был упомянут "платежный календарь". Согласен. Но после покупке модуля Бюджетирвоание, заказчик с удивлением воспринял информацию, о том что часть возможностей предлагается сделать вдругом модуле. Давайте его тоже купим. И у него возникает реззоный вопрос: Зачем мы Бюджетирование покупали. Если одну задачу нужно решать в разных местах.
Еще раз повторюсь тот БДДС который мы реализовали, он не портянка. Данных детализации там не много. Документов в системе не много. Да он по дням, но что теперь. Поэтом убежден что тут косячное програмирование имело место быть.
Еще раз спасибо всем за ответы и опыт.
Дальше будем делать БДР и прогнозный баланс. Затем надеюсь займемся второстепенными бюджетами (Бюджетами з/п, комерческих расходов, бюджетом продаж и прочими)

Не согласен с выводами по большинству пунктов.

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

Можно конечно заменить подстатьями, это один из вариантов.
Есть и другие варианты:
Вариант 2. Оставить все как было (имеется в виду тот же набор аналитик), но не тащить аналитики в форму. Именно об этом вам и говорили - уменьшить количество ВЫВОДИМЫХ в форму аналитик. А данные по невыведенным аналитикам можно просматривать путем "сверления" статей. О варианте 3 - ниже.

RavageR писал(а): Причем если разбить БДДС мертвый, незагружающийся на 2 части (например расходная и доходная), то по отдельным кускам он загрузиться ОЧЕНЬ быстро и без проблем. Но этот не выход.

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

RavageR писал(а): Одна из функций БДДС по плановым данным видеть остаток на конец периода. Дабы не ушли мы в минус на определенном этапе.

Видеть остатки можно уже с помощью "верхнего" БДДС, в форме которого можно вывести буквально четыре статьи - Остаток на начало, Поступления, Выплаты, Остаток на конец. Грузится такой бюджет - в секунды.

RavageR писал(а): Т.о. на мой взгляд, программисты Галактики имееют очень узкое место в данной подсистеме, по сути я бы его расценивал как ошибка в программирование. Да можно обходиться другими средствами. Был упомянут "платежный календарь". Согласен. Но после покупке модуля Бюджетирвоание, заказчик с удивлением воспринял информацию, о том что часть возможностей предлагается сделать вдругом модуле. Давайте его тоже купим. И у него возникает реззоный вопрос: Зачем мы Бюджетирование покупали. Если одну задачу нужно решать в разных местах.

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

RavageR писал(а): Поэтом убежден что тут косячное програмирование имело место быть.

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

Для SIM
Покупали как раз машину, а оказался мопед.
Причем нигде не написано, что работает с сильно ограниченым количеством аналитик.
Обходные варианты это конечно хорошо. Зайди посмотри там. Тут вывернись вот так. А здесь надо еще модуль купить.
Такими темпами Топ-менеджеру такими темпами целую инструкцию нужно будет писать. Система ориентируется для пользователя, и чем он меньше кликов сделает для получения нужной ему информации тем лучше. Это основопологающий принцип дружелюбности и эргономичности системы должен быть.
Просто в какой-то ERP системе будет модуль, который решает, цитата "задачи среднесрочного и долгосрочного планирования" с жестким ограничением числа аналитик и свалом в случае их превышения, даже на небольших объемах данных, а в какой-то ERP системе будет полноценный, в полном смысле этого слова, модуль.
Современем люди будут делать выводы.