Добрый день.
Тема навеяна веткой
dynamicsmatters: Performance and InventDim
Один из выводов, после прочтения ветки:
Использование для учета ГТД стандартного механизма приводит к быстрому раздуванию размера таблицы InventDim и, соответственно, снижению производительности системы.
Возможные подходы по борьбе с этим
Паллиативный: настройка индексов и включение признака селективности на аналитике ГТД.
Промежуточный: дополнительно к этому дописывание специализированных запросов для использования аналитики ГТД, по примеру специализированных запросов для использования аналитики серийных номеров.
Радикальный: Разработка своего механизма учета ГТД.
Насколько я понял, свой механизм используют довольно многие. Как он выглядит?
Себе я его представляют так.
- Заводится таблица проводок по ГТД, для примера GTDTrans
- Таблица остатков по ГТД, для примера GTDSum
- В строках закупки заполняются ссылки на ГТД.
- При оприходовании закупки создаются проводки в GTDTrans, изменяются остатки в GTDSum
- Во внутрифирменных движениях ГТД не учитывается.
- При разноске накладной по заказу создаются расходные проводки в GTDTrans, изменяются остатки в GTDSum. Доступные ГТД подбираются по ФИФО. По строке накладной может быть создано несколько проводок.
- При формировании Счета-фактуры на каждую проводку в GTDTrans, связанную со строкой исходной накладной, создается строка счета-фактуры.
На самом деле этот же механизм может быть использован и при упрощенной схеме учета серийных номеров, когда серийный номер фиксируется только на этапе закупки и продажи конечному клиенту (мы на проекте в свое время обсуждали эту схему).
Первая проблема, которая видится при такой реализации – таблица остатков GTDSum в этой схеме потенциально будет являтся обьектом блокировок при многопользовательской работе. Возможно будет целесообразным вынести обработку ГТД из больших транзакций обработки накладных по закупке и заказу. Хотя при этом может возникнуть несогласованность данных.
Есть какие либо соображения, критика, очевидные пробелы в предлагаемой схеме?