v7: Слишком долго открывается период оперативных итогов #598465

В конфигурации имеется регистр остатков имеющий 7 измерений и 8 ресурсов (еще есть 9 реквизитов). Такой вот монстр. Измерения регистра имеют неопределенный тип значения, сам тип значения определяется в момент записи движений в регистр. Однако в достаточно большом числе случаев половина измерений не заполняются при проведении (так и остаются неопределенного типа). Сам регистр к сожалению пока не закрывается (имеются только движения по приходу, но видимо придется делать движения и по расходу - регистр молодой, экспериментальный так сказать, живет первый месяц, но данных в нем очень много). Сегодня 1 марта и система предложила открыть период...открывается уже очень долго (5 часов прошло). Думаю дело в новеньком регистре. И есть вот такие вопросы: 1. Влияет ли на эффективность работы регистра наличие измерений с неопределенным типом значения? (измерения при проведении получают типы значений Справочник или Документ, примитивные типы не хранят, но имеется много записей где некоторые измерения не определяются) 2. Влияет ли на эффективность работы регистра такие параметры файлов (сам регистр 40247): RA40247.dbf 46 мб, RG40247.dbf 47 мб, а вот RA40247.cdx 26 мб, RG40247.cdx 378 мб. ? Получается, что размеры файлов dbf примерно равны, а вот файлы cdx различаются в разы.

Остатки не закрываются. Ты лучше не это пиши "RA40247" и т.д.... Пиши их название в конфигураторе, а то этот код генерится при создании БД, т.е. у каждого он свой :) + Что у вас за конфигурация? Типо ТиС, ПуБ или какой еще зверь... Если это свой "велосипед", то как правило он делается на какой либо базе. Мало героев, которые смогли нормально написать конфу с нуля, всегда выступают те или иные доработки типовых.

1. влияет ли на эффективность программиста-одноэса ГБ и руководятлы?

Регистр моего изготовления. Там просто отражаются движения в управленческом учете на основании данных бух.учет и прочих движений регистров. Соответственно 7 измерений это: СчетУпрУчет (Справочник.СчетаУпрУчет), Аналитика1УпрУчет и тд.до Аналитика6УпрУчет. Соответственно измерения аналитики определяются в момент записи движений, но не все аналитики заполняются в каждом случае. В реквизитах регистра указываются корреспондирующие счета упр.учета и аналитики. Доработка идет для конфигурации ПуБ

рассказывай что за задача, почему выбран именно регистр остатков и прочие подробности

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

цель свалки всей этой информации в регистр какова? Как используются результаты?

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

Цель такой свалки информации - собрать воедино необходимые данные из бух.учета и регистров. Информация собирается на ура и обрабатывается как нужно. Есть все данные, есть все отчеты для от ОДРа до ДДСа. Проблема как я понимаю только в незакрытом регистре. Накапливать данные в ресурсах ДтСумма и КтСумма в принципе удобно, так как можно получить развернутые остатки по дебету и кредиту. Но помня о том, что дебет и кредит появились только от непринятия средневековым итальянским мозгом понятия отрицательных чисел, остается сделать один ресурс а дебет и кредит квалифицировать через приход и расход.

А почему ты не использовал Регистр Оборотов? Наверняка ваша БД на SQL :)

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

Да, еще как вариант - использовать регистры оборотов

База обычная ДБФ

Уга, увидел :)

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

В измерениях точно только справочники и документы, но есть еще записи с пустыми значениями неопределенного типа. Например, для записи по движению денег мне нужно использовать только три измерения аналитики, тогда как три оставшихся так и остаются неопределенного типа. Может ли это влиять на эффективность?

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

реиндекс, дефрагментация ?

Покажи результат:

Вот такое счастье: Мой регистр это ПроводкиУУ. Монстры под названием ПотребностьВМатериалах и МатериалыКРаспределению это уже давняя доработка самого заказчика.

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

Ты про документы в измерении уверен? О_о... по сути это и есть геометрический прогресс роста итогов :)

Ахиллесова пята: ПотребностьВМатериалах: 55693 и

Да, точно уверен. Есть только один документ - План (или Производственный заказ). Документов не много, на данный момент в остатках 15 заказов

А что там с "Бирка 58357" ?

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

Глянул на регистр Бирка. Есть измерение Статус, приход по регистру идет при значении измерения НеОтгружена, а расход по Отгружена. Понятно дело регистр не закрывается. ПотребностьВМатериалах - только приход по регистру, движения по расходу не осуществляются. МатериалыКРаспределению - приход только по одному измерению Номенклатура, а расход уже и по всем остальным)))

Убери тогда измерение Статус

Это ты как-то жестко отборы для всех измерений впендюрил.

Да... Сейчас можно уже позлорадствовать. но не хочется - сам был в такой шкуре. Когда база была на ДБФ открытие периода было серъезным испытанием. Информация к размышлению: 1С77, скуль 2005, размер базы 110 гиг. Открытие периода от 8 до 10 минут.

Ну что же когда создавал этот регистр думаю понимал что это такое, да ещё с отборами и быстрыми движениями. Я тоже делал регистр специально для формирования некоторых МСФО отчетов но только оборотным, а остатки беру с типовых регистов и плана счетов если нужно. Дальше уже думай сам, чем удобней пожертвовать, скоростью или аналитикой.

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

Проблема решилась с переходом на оборотные регистры. Регистр остатков при использовании в измерениях неопределенного типа данных работает некорректно. Гугл по этой проблеме выдает только две ветки в форумах (может и еще где то есть, но мне удалось найти только две). Итог не утешительный - не используйте в измерениях регистра остатков неопределенный тип данных! Вполне возможно, что системой будут корректно обрабатываться одно два измерения с таким типом данных, но вот если их шесть, то это бесполезная затея. При открытии периода с таким регистром в мониторе ресурсов видно как 1С гоняет мой регистр но так в итоге ничего и не получается. Почему так происходит - загадка для меня

работает там все корректно, не свисти. Если регистр нормально закрывается, то пофик, какого типа там измерение.

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

Ага, конечно, когда на 7 измерений типа неопределнный еще и зафигачил отборы для каждого, и не закрываешь его. Там просто индексы скорее всего долго создаются.

Как описывал выше, в системе с которой работаю, есть еще несколько незакрытых регистров остатков. Остатков в них довольно много, но система их обрабатывает, а спотыкается на регистре с большим количеством измерений неопределенного типа, даже если он содержит существенно меньше остатков. При переходе на оборотный регистр проблема открытия периода исчезла. Период открылся за 5 минут. Да и мне удобнее накапливать обороты по ресурсам, остатки не так важны.

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

Для начала убрал все отборы по измерениям, индексный файл существенно похудел, но период так и не открывался в разумное время. Далее сделал расходные движения по регистру, количество остатков сократилось, но период так и не открывался. Оборотный регистр отработал как надо. Даже если дело не в типе значения измерения регистра, то в чем тогда? Ведь есть в системе, например регистр остатков Бирка, остатков более 50 тысяч, регистр не закрывается, так уж его спроектировали, но система все равно переносила остатки. Как только дело доходит до моего регистра (до расходных движений в нем было 20 тысяч остатков, после около 9 тысяч) - все, в разумное время остатки не переносятся.

Интересно, что вообще можно учитывать в 6-ти измерений неопределнного типа..

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

Так это навреное что-то типа бухитогов на одном регистре. Судя по .

ты в бухне регистры прикрутил, или что ?

У меня ПУБ конфигурация. Да, это некий аналог бухитогов, но как минимум необходимо было иметь шесть разрезов аналитики.

п.ц Если что, на обычных БИ можно сделать до 23 субконто.

И эммулировать это всё в регистре - не надо.

В восьмерке аналогичная штука имеется, там все проще - дополнительный регистр бухгалтерии. Задача стояла организовать подобное в семерке.

как можно вытянуть 6 субконто? Подскажите пожалуйста?

В семерке это еще один план счетов.

Согласен, как вариант можно использовать. Спасибо

чего как ? руками. Единственное, после 9 субконто могут не редактироваться, щас не помню уже. А так, держит легко 23 субконто, если больше - 1с-ина падает

Может у меня конечно руки не оттуда растут))) Но не получается в конфигураторе установить более 5 субконто. Если использовать реквизиты проводки, тогда можно еще что либо придумать

что-то не в ту степь, господа. индексы  какие в DD файле?

5 Субконто О_о... Кто это у вас так над Бух.Итогами извратился :) Последний раз, когда такое видел, все ровно бухи видели только 3 субконто.

Вот что об индексах для регистра: #==TABLE no 424    : Регистр ПроводкиУУ # Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable   T=RG40247 |Регистр ПроводкиУУ            |A          |RG40247    |1         #-----Fields------- # Name      |Descr               |Type|Length|Precision F=PERIOD    |Period Registr      |D   |8     |0         F=SP40223   |(P)СчетУУ           |C   |9     |0         F=SP40224   |(P)Аналитика1УУ     |C   |23    |0         F=TSP40224  |                    |C   |3     |0         F=SP40225   |(P)Аналитика2УУ     |C   |23    |0         F=TSP40225  |                    |C   |3     |0         F=SP40226   |(P)Аналитика3УУ     |C   |23    |0         F=TSP40226  |                    |C   |3     |0         F=SP40227   |(P)Аналитика4УУ     |C   |23    |0         F=TSP40227  |                    |C   |3     |0         F=SP40228   |(P)Аналитика5УУ     |C   |23    |0         F=TSP40228  |                    |C   |3     |0         F=SP40229   |(P)Аналитика6УУ     |C   |23    |0         F=TSP40229  |                    |C   |3     |0         F=SP40230   |(P)ДтКоличествоУУ   |N   |16    |3         F=SP40231   |(P)ДтСуммаУУ        |N   |16    |2         F=SP40232   |(P)ДтДопКоличествоУУ|N   |16    |3         F=SP40233   |(P)ДтДопСуммаУУ     |N   |16    |2         F=SP40234   |(P)КтКоличествоУУ   |N   |16    |3         F=SP40235   |(P)КтСуммаУУ        |N   |16    |2         F=SP40236   |(P)КтДопКоличествоУУ|N   |16    |3         F=SP40237   |(P)КтДопСуммаУУ     |N   |16    |2         #----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=PROP     |PERIOD+PROP   |0     |PERIOD,SP40223,SP40224,SP40225,SP40226,SP40227,SP40228,SP40229|PROP       # #=============================================================================== #==TABLE no 425    : Регистр (Дв.) ПроводкиУУ # Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable   T=RA40247 |Регистр (Дв.) ПроводкиУУ      |A          |RA40247    |1         #-----Fields------- # Name      |Descr               |Type|Length|Precision F=IDDOC     |ID Document's       |C   |9     |0         F=LINENO    |LineNo              |N   |4     |0         F=ACTNO     |Action No           |N   |6     |0         F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0         F=IDDOCDEF  |ID Def Document     |C   |4     |0         F=DATE      |date                |D   |8     |0         F=TIME      |Time                |C   |6     |0         F=SP40223   |(P)СчетУУ           |C   |9     |0         F=SP40224   |(P)Аналитика1УУ     |C   |23    |0         F=TSP40224  |                    |C   |3     |0         F=SP40225   |(P)Аналитика2УУ     |C   |23    |0         F=TSP40225  |                    |C   |3     |0         F=SP40226   |(P)Аналитика3УУ     |C   |23    |0         F=TSP40226  |                    |C   |3     |0         F=SP40227   |(P)Аналитика4УУ     |C   |23    |0         F=TSP40227  |                    |C   |3     |0         F=SP40228   |(P)Аналитика5УУ     |C   |23    |0         F=TSP40228  |                    |C   |3     |0         F=SP40229   |(P)Аналитика6УУ     |C   |23    |0         F=TSP40229  |                    |C   |3     |0         F=SP40230   |(P)ДтКоличествоУУ   |N   |16    |3         F=SP40231   |(P)ДтСуммаУУ        |N   |16    |2         F=SP40232   |(P)ДтДопКоличествоУУ|N   |16    |3         F=SP40233   |(P)ДтДопСуммаУУ     |N   |16    |2         F=SP40234   |(P)КтКоличествоУУ   |N   |16    |3         F=SP40235   |(P)КтСуммаУУ        |N   |16    |2         F=SP40236   |(P)КтДопКоличествоУУ|N   |16    |3         F=SP40237   |(P)КтДопСуммаУУ     |N   |16    |2         F=SP40238   |(P)КоррСчетУУ       |C   |9     |0         F=SP40239   |(P)КоррАналитика1УУ |C   |23    |0         F=TSP40239  |                    |C   |3     |0         F=SP40240   |(P)КоррАналитика2УУ |C   |23    |0         F=TSP40240  |                    |C   |3     |0         F=SP40241   |(P)КоррАналитика3УУ |C   |23    |0         F=TSP40241  |                    |C   |3     |0         F=SP40242   |(P)КоррАналитика4УУ |C   |23    |0         F=TSP40242  |                    |C   |3     |0         F=SP40243   |(P)КоррАналитика5УУ |C   |23    |0         F=TSP40243  |                    |C   |3     |0         F=SP40244   |(P)КоррАналитика6УУ |C   |23    |0         F=TSP40244  |                    |C   |3     |0         F=SP40245   |(P)РеквизитУУ       |C   |23    |0         F=TSP40245  |                    |C   |3     |0         F=SP40246   |(P)ПравилоУУ        |C   |9     |0         #----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO,ACTNO                                          |IDLINE     I=DATETIME |Date+Time+ID+L|0     |DATE,TIME,IDDOC,LINENO,ACTNO                                |DATETIME   I=VIA40223 |VIA40223      |0     |SP40223,DATE,TIME,IDDOC,LINENO,ACTNO                        |VIA40223   I=VIA40238 |VIA40238      |0     |SP40238,DATE,TIME,IDDOC,LINENO,ACTNO                        |VIA40238   # В общем ничего особенного. Интересно, когда измерение неопределенного типа, то в ДД файле описывается оно совершенно по другому. Для каждого измерения отводится два поля. Не не не! В системе 5 субконто нет, это просто я пытался увеличить их количество, но больше пяти не поставить. Хотя видел такую конфигурацию самописную.

Зачем ты так над базой извращался, почему решил их сделать без типа? Лучше бы сделал все через справочник, какой-нибудь

Да, тоже вариант, спасибо за совет! Можно даже было сделать и как в РАУЗе восьмерочном, через справочник ключей аналитики))) Посчитал, что раз уж разработчиками 1С предусмотрено использование неопределенного типа данных в измерениях регистра, то действительно это очень удобно и почему бы не использовать такую возможность? Сейчас допиливаю отчеты и некоторые обработки под оборотный регистр. Работает все быстро, существенно.

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

Согласен! :-)

Ну на тебе к примеру, 9 субконто

Забавно получается. Действительно более чем 5 субконто))) Думаю это делается явно не прямыми средствами 1С.