Про проверку журнала

[YVAS]

Вопрос такой: создаем журнал в ГК и импортируем туда 3000 записей. Проверка данного журнала длится 172 часа, если верить счетчику времени при проверке. Естетсвенно, такое не годится.
Можно ли решить данную проблему настройками? Или нужно перепрораммировать алгоритм проверки. Тогда не возникнут ли какие-нибудь побочные эффекты.
И еще вопрос: вообще какие операции выполняются при проверке, что с чем сверяется итд. Спасибо за ответ.....................

[waitingforsharan]

Проверяет целостность ссылок (настроек и т. д.) "сверху вниз" для каждой записи.

[Anais]

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

2 All:
это проблемы частной функциональности. Не заморачивайтесь.

[YVAS]

Цитата:

это проблемы частной функциональности. Не заморачивайтесь.

Ты хочешь сказать, что ни у кого не может возникнуть такая же проблема?

[Anais]

Я тебе письмом подробности описала.

Может, конечно, если навернут ту же фичу, что и мы (кстати, вероятность отнюдь не равна нулю). Но в стандратной версии - нет, не может.

[mazzy]

журнал ГК - скорее всего у вас модификации.
вот если бы был складской журнал...

рекомендация одна - делать небольшие журналы по 100-500 записей в каждом.

[Anais]

Цитата:

Изначально опубликовано mazzy
журнал ГК - скорее всего у вас модификации.

Я натравливала Профайлер кода на проверку этого журнала.
На классе LedgerJournalTransUpdate у нас модификация: стоит проверка на уникальность поля Voucher.
Но все равно спасибо.

[mazzy]

О! хм...
1. а зачем?
2. у вас корреспонденция включена?
3. проверка делается одним запросом?
4. проверка делается внутри метода updateNow или внутри таблицы LedgerJournalTrans.Validatewrite?

Похоже, что в любом случае вам нужно разбираться с теми, кто модифицировал.

Журналы ГК в станартной версии обрабатываются достаточно быстро... В отличие от складских журналов.

[Anais]

Цитата:

Изначально опубликовано mazzy
1. а зачем?

Во избежание создания строк с одинаковым voucher'ом (многострочных проводок). "Дабы не нарушать отчетности" - в смысле, чтобы отчеты нормально строились, а не множили бы суммы. В стандартной версии, извернувшись, можно создать -дцать строк журнала ГК на один voucher.

2. у вас корреспонденция включена?
А что это? И зачем это нужно?

3. проверка делается одним запросом?
Двумя. Сверху стоит получение журнала по номеру. А под ним проверяется уникальность номера документа ГК (одним запросом, в котором join'ятся два ledgerJournalTrans'а)

4. проверка делается внутри метода updateNow или внутри таблицы LedgerJournalTrans.Validatewrite?
Проверка стоит в классе LedgerJournalTransUpdate, в методе check.

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

[mazzy]

э-э-м... подробнее чуть попозже.

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

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

Подробнее чуть позже.

[Anais]

Ок. Буду ждать с нетерпением.

[mazzy]

ну и день сегодня. Извините.

Цитата:

Изначально опубликовано Anais
Во избежание создания строк с одинаковым voucher'ом (многострочных проводок). "Дабы не нарушать отчетности" - в смысле, чтобы отчеты нормально строились, а не множили бы суммы. В стандартной версии, извернувшись, можно создать -дцать строк журнала ГК на один voucher.

И это правильная функциональность. Это многострочная проводка. На этом построена практически вся Аксапта. Мало того, в многострочных проводках правильно (в пределах возможного) работает корреспонденция. Только многострочной проводкой можно сделать перенос суммы с аналитики на аналитику в пределах одного счета. Именно многострочными проводками вводятся ОС в международной функциональности.

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

Проблема решается без долгих поисков по базе.

Цитата:

Изначально опубликовано Anais
2. у вас корреспонденция включена?
А что это? И зачем это нужно?

Возвращаемся к международной функиональности.
Дело в том, что международная Аксапта "сворачивает" бух.проводки по счету и финансовой аналитике. Фактически, например, на каждую накладну будет генерится столько строк в бух.проводках, сколько различных счетов с различной аналитикой присутствует.

Естественно, получается многострочная проводка. НО: таблица бух.проводок LedgerTrans получается очень компактной.

Разработчикам корреспонденции пришлось выключить "свертку". В результате, генерится столько строчек в таблице бух.проводок сколько строк в накладной * коэффициент (коэффициент обычно = 8-10). В результате, таблица LedgerTrans раздувается до немыслимых размеров (50-60% от всего размера базы занимает именно эта таблица). И! Самое главное, все операции с LedgerTrans становятся медленными по сравнению с международной версией. В том числе операции поиска ваучера.

Цитата:

Изначально опубликовано Anais
3. проверка делается одним запросом?
Двумя. Сверху стоит получение журнала по номеру. А под ним проверяется уникальность номера документа ГК (одним запросом, в котором join'ятся два ledgerJournalTrans'а)

Вот-вот. Это то я и имел в виду. Выполняются операции с LedgerTrans, а размер LedgerTrans наверняка несколько гиг. К тому же в стандартной версии в LedgerTrans нет индекса по номеру журнала. Не удивлюсь, если у вас делается table scan на LedgerTrans в этом запросе. Вы мониторинг запросов делали?

Цитата:

Изначально опубликовано Anais
4. проверка делается внутри метода updateNow или внутри таблицы LedgerJournalTrans.Validatewrite?
Проверка стоит в классе LedgerJournalTransUpdate, в методе check.

Хорошо. Пусть будет так.

Цитата:

Изначально опубликовано Anais
Похоже, что в любом случае вам нужно разбираться с теми, кто модифицировал.
Дык субподряд. Ну, не будем тыкать пальцем, пожалуй... Все равно разбираться мне.

А кому ж еще? Задавайте вопросы тем, кто модифицировал.

[Anais]

Прежде всего, огромное спасибо за столь содержательный ответ.

Можно еще уточнить на счет 2. у вас корреспонденция включена?
Я все поняла на счет международной функциональности, но
что из всего изложенного имелось в виду под словами "корреспонденция включена"?

Так же не понимаю вот чего:
Разработчикам корреспонденции пришлось выключить "свертку".
Но если у меня в одной закупке есть строчки на номенклатуру Н1 и номенклатуру Н2, и обе эти номенклатуры должны уйти на один счет С1, то в LedgerTrans ложится одна проводка на С1 на общую сумму. (Это я проверяла). Так в чем же выключение свертки, которая должна быть в Российской функциональности?

Вот-вот. Это то я и имел в виду. Выполняются операции с LedgerTrans, а размер LedgerTrans наверняка несколько гиг.
Не с LedgerTrans, а с LedgerJournalTrans. Впрочем, все равно получается очень долго.

А кому ж еще? Задавайте вопросы тем, кто модифицировал.
В общем, получается что мы и модифицировали. Это идея нашего консультанта. Субподрядчик (программист) просто запрограммировал то, что ему велели. (Rem по этому пункту: изначально тема поднята не мной )

[mazzy]

Цитата:

Изначально опубликовано Anais
Можно еще уточнить на счет 2. у вас корреспонденция включена?
Я все поняла на счет международной функциональности, но
что из всего изложенного имелось в виду под словами "корреспонденция включена"?

Есть такая галочка в параметрах главной книги.

Цитата:

Изначально опубликовано Anais
Так же не понимаю вот чего:
Разработчикам корреспонденции пришлось выключить "свертку".
Но если у меня в одной закупке есть строчки на номенклатуру Н1 и номенклатуру Н2, и обе эти номенклатуры должны уйти на один счет С1, то в LedgerTrans ложится одна проводка на С1 на общую сумму. (Это я проверяла). Так в чем же выключение свертки, которая должна быть в Российской функциональности?

Скорее всего, я чего-то не понимаю.
Так у вас установлена корреспонденция?
Главное меню \ Настройки \ Параметры \ Закладка Главная книга \ Использовать механизм корреспонденции счетов

Цитата:

Изначально опубликовано Anais
Вот-вот. Это то я и имел в виду. Выполняются операции с LedgerTrans, а размер LedgerTrans наверняка несколько гиг.
Не с LedgerTrans, а с LedgerJournalTrans. Впрочем, все равно получается очень долго.

А вот тут я промахнулся. Там индекс конечно есть.
Но искать ваучеры в LedgerJOURNALtrans принципиально неверно, поскольку журналы после разноски могут (и должны) удаляться. И уникальность ваучеров вы там не проверите. В стандартной версии.

[Anais]

Цитата:

Изначально опубликовано mazzy

Скорее всего, я чего-то не понимаю.
Так у вас установлена корреспонденция?
Главное меню \ Настройки \ Параметры \ Закладка Главная книга \ Использовать механизм корреспонденции счетов

Установлена.
При этом если в закупке создать строку на номенклатуру Н1 на сумму S1 и строку на номенклатуру Н2 на сумму S2, и обе эти номенклатуры разносятся на один счет СН, то создается одна проводка СН - СПоставщика на сумму (S1 + S2) и одна проводка СП - СПоставщика на сумму -(S1 + S2). Ну, еще налоги разносятся (тоже единой суммой).
А что, что-то не так??

Цитата:

Изначально опубликовано mazzy

А вот тут я промахнулся. Там индекс конечно есть.
Но искать ваучеры в LedgerJOURNALtrans принципиально неверно, поскольку журналы после разноски могут (и должны) удаляться. И уникальность ваучеров вы там не проверите. В стандартной версии.

Ну, если учесть что мне нужно проверить многострочные проводки (т.е. уникальность ваучера в пределах одного, еще не разнесенного журнала), то все нормально.
Но с другой стороны, объявить обязательность корр. счета кажется мне более простым и "дешевым" вариантом.
Вот при\дет консультант, который все это придумал, и обсудим
Большое спасибо за совет.

[mazzy]

Цитата:

Изначально опубликовано Anais
Установлена.
При этом если в закупке создать строку на номенклатуру Н1 на сумму S1 и строку на номенклатуру Н2 на сумму S2, и обе эти номенклатуры разносятся на один счет СН, то создается одна проводка СН - СПоставщика на сумму (S1 + S2) и одна проводка СП - СПоставщика на сумму -(S1 + S2). Ну, еще налоги разносятся (тоже единой суммой).
А что, что-то не так??

На всякий случай спасибо. Проверю ближе к вечеру.
Вдруг у меня сведения устарели.

Цитата:

Изначально опубликовано Anais
Ну, если учесть что мне нужно проверить многострочные проводки (т.е. уникальность ваучера в пределах одного, еще не разнесенного журнала), то все нормально.

Хм... Теперь въехал. Извините.

[mazzy]

Цитата:

Изначально опубликовано Anais
При этом если в закупке создать строку на номенклатуру Н1 на сумму S1 и строку на номенклатуру Н2 на сумму S2, и обе эти номенклатуры разносятся на один счет СН, то создается одна проводка СН - СПоставщика на сумму (S1 + S2) и одна проводка СП - СПоставщика на сумму -(S1 + S2). Ну, еще налоги разносятся (тоже единой суммой).
А что, что-то не так??

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

А вот в 2.5 в СП5 сильно улучшили ситуацию по сравнению со старыми СП, но себестоимость все равно отдельными проводками списывается. И это тоже хорошо. Хотя могло бы быть и лучше.

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