Тормозит ли у вас выбор накладных при создании фактуры?

[CDR]

Да, наличие ненужных фильтров и отсутствие индекса по фильтруемым полям именно к full table scan и приводило. Соответственно на больших объемах данных обработка фактур практически не жизнеспособна. Так же, как и не жизнеспособна дальнейшая обработка входящего НДС и формирование книги покупок/продаж (но это отдельная песня).

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

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

Мы пошли немного другим путем. Поскольку 99% фактур обрабатывается по одной накладной, была сделана кнопулина обработки фактуры по текущей накладной. В простеньком диалоге (RunBase) вводится номер фактуры и дата, далее класс сам "проставляет" нужные галочки по активной накладной и запускает формирование фактуры. В итоге производительность бухов выросла в разы. Им не приходится ждать открытия формы обработки фактуры, а за тем в открывшейся форме заново искать накладную, что б поставить галочку.