ну и день сегодня. Извините.
Цитата:
Изначально опубликовано 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
Похоже, что в любом случае вам нужно разбираться с теми, кто модифицировал.
Дык субподряд. Ну, не будем тыкать пальцем, пожалуй... Все равно разбираться мне.
А кому ж еще? Задавайте вопросы тем, кто модифицировал.