Использование ГТД и производительность

[vc]

Добрый день.
Тема навеяна веткой
dynamicsmatters: Performance and InventDim
Один из выводов, после прочтения ветки:
Использование для учета ГТД стандартного механизма приводит к быстрому раздуванию размера таблицы InventDim и, соответственно, снижению производительности системы.

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

Насколько я понял, свой механизм используют довольно многие. Как он выглядит?

Себе я его представляют так.

1. Заводится таблица проводок по ГТД, для примера GTDTrans
2. Таблица остатков по ГТД, для примера GTDSum
3. В строках закупки заполняются ссылки на ГТД.
4. При оприходовании закупки создаются проводки в GTDTrans, изменяются остатки в GTDSum
5. Во внутрифирменных движениях ГТД не учитывается.
6. При разноске накладной по заказу создаются расходные проводки в GTDTrans, изменяются остатки в GTDSum. Доступные ГТД подбираются по ФИФО. По строке накладной может быть создано несколько проводок.
7. При формировании Счета-фактуры на каждую проводку в GTDTrans, связанную со строкой исходной накладной, создается строка счета-фактуры.

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



Первая проблема, которая видится при такой реализации – таблица остатков GTDSum в этой схеме потенциально будет являтся обьектом блокировок при многопользовательской работе. Возможно будет целесообразным вынести обработку ГТД из больших транзакций обработки накладных по закупке и заказу. Хотя при этом может возникнуть несогласованность данных.


Есть какие либо соображения, критика, очевидные пробелы в предлагаемой схеме?

[Logger]

Ощущение словно велосипед изобрели...

Я бы для начала попробовал пользоваться стандартной аналитикой ГТД и где надо расшивать узкие места. (Способы вы сами и перечислили)
Готов поспорить, что вы даже не попробовали на тестовых данных. А зря.

[vc]

Цитата:

Сообщение от Logger

Ощущение словно велосипед изобрели...

Велосипед.
Да.
Извините.
Меня, собственно и интересует, насколько это решение является велосипедом. В смысле это широко известный и широко применяемый подход? Или подход широко известен но не применяется, в силу своей порочности?

Цитата:

Сообщение от Logger

Я бы для начала попробовал пользоваться стандартной аналитикой ГТД и где надо расшивать узкие места.

Да в общем то мы пробуем, в смысле стандартным функционалом пользуемся. И узкие места расшиваем.

Но в общем ситуация беспокоит, (может быть и зря, конечно). Постоянно, и быстро, растущая таблица InventDim, это же аналог ситуации с ростом числа открытых проводок если не закрывать склад. То есть деградация производительности с течением времени нам гарантирована.

[Logger]

Цитата:

То есть деградация производительности с течением времени нам гарантирована.

Это точно.

Слишком уж большой перечень кастомизаций получился у вас. Это смущает. Я сам не пробовал отдельный учет ГТД писать. Знаю людей которые писали. Работает вроде.

[vc]

Цитата:

Сообщение от Logger

Слишком уж большой перечень кастомизаций получился у вас. Это смущает.

Вы имеете виду те семь пунктов, которые я привел в начальном посте?
У меня меньше не получается никак.
Да и там не оговорены возвраты по заказам (нужно сторнировать расходные ГТД проводки из исходной накладной), приход по инвентаризации (тут вообще непонятно что
делать),

[mazzy]

Цитата:

Сообщение от vc

У меня меньше не получается никак.
Да и там не оговорены возвраты по заказам (нужно сторнировать расходные ГТД проводки из исходной накладной), приход по инвентаризации (тут вообще непонятно что
делать),

Точно! Возвраты! Я и забыл.

Меньше конечно же получается. Первое о чем стоит подумать в таких случаях - неужели у этих проклятых буржуинов нет таможни? А если есть, то как они фикируют таможенные дела в системе Аксапта?

Ищите. Думайте.

[mazzy]

Цитата:

Сообщение от vc

Таблица остатков по ГТД, для примера GTDSum

Спорно.

Цитата:

Сообщение от vc

В строках закупки заполняются ссылки на ГТД.

Принципиально неверно.
Как правило, информации о ГТД нет во время формирования закупок.
Зачастую, информации о ГТД нет во время формирования документов физического прихода (неотфактурованная поставка).
Нередко бывает и так, что информации о ГТД нет во время продаж/списаний неотфактурованных поставок.
Не по законодательсту, но бывает и так, что информации о ГТД нет во время формирования финансовых документов.


Ну и стопудово бывает так, что одна закупка идет разными партиями/контейнерами. Поэтому в одной строчке закупки может появиться несколько разных ГТД.

Думайте дальше. Ищите дальше.

Даю маячок - документ ГТД не является уникальным для нашей страны.
Другие страны тоже оформляют подобные документы, причем делают это примерно так же. Для европейских стран в Аксапте предусмотрен функционал Интрастат (это не полный аналог ГТД, но чертовски похож, на мой взгляд).

Цитата:

При оприходовании закупки создаются проводки в GTDTrans, изменяются остатки в GTDSum

Вы бы для начала просто диаграму состояний нарисовали, до того, как за таблицы браться

Цитата:

Во внутрифирменных движениях ГТД не учитывается.

С какой это стати? Принципиально неверное предположение.

Цитата:

При разноске накладной по заказу создаются расходные проводки в GTDTrans, изменяются остатки в GTDSum. Доступные ГТД подбираются по ФИФО.

Во-первых, почему расходные проводки у вас создаются только в "накладной по заказу"? А производство? А списание? А инвентаризация?

Цитата:

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

Нет, конечно

Вы не подумали о том, что в результате инвентаризации кладовщики могут найти излишек товара, для которого обязательно ГТД. Какое ГТД надо поставить в этом случае?

Серийные номера фиксируются НЕ только на этупе закупки или продажи. Но и в результате инвентаризации, производства, переноса из со склада на склад или из ячейки в ячейку.

Цитата:

Первая проблема...

Это не единственная проблема.
Думайте дальше.

[vc]

Цитата:

Сообщение от mazzy

Серийные номера фиксируются НЕ только на этупе закупки или продажи. Но и в результате инвентаризации, производства, переноса из со склада на склад или из ячейки в ячейку.

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

[mazzy]

Цитата:

Сообщение от vc

В таком случае логичнее всего было бы использовать стандартную складскую аналитику.

Для серийных номеров - наверное.
А для ГТД - нет, не логичнее. Я же говорил, что ГТД могут появляться после физического прихода, изредка после того, как товар уже продали, а иногда даже после финансового прихода. Складскую аналитику же можно менять только до физического прихода. После уже нельзя.

Цитата:

Сообщение от vc

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

Ну, раз так, то делайте как считаете нужным.
У вас получится очередное частное решение с ограничениями для очередного заказчика.

Цитата:

Сообщение от vc

Сплошной учет серийных номеров по всей логистической цепочке для нас на данном этапе неприемлем - слишком дорого.

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

Цитата:

Сообщение от vc

(вне системы)

[vc]

Цитата:

Сообщение от mazzy

У вас получится очередное частное решение с ограничениями для очередного заказчика.

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

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

Учет только на входе, используется нами для ГТД, далее они подбираются автоматически.

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

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

[MironovI]

Цитата:

Сообщение от vc

Насколько я понял, свой механизм используют довольно многие. Как он выглядит?

Себе я его представляют так.

1. Заводится таблица проводок по ГТД, для примера GTDTrans
2. Таблица остатков по ГТД, для примера GTDSum
3. В строках закупки заполняются ссылки на ГТД.
4. При оприходовании закупки создаются проводки в GTDTrans, изменяются остатки в GTDSum
5. Во внутрифирменных движениях ГТД не учитывается.
6. При разноске накладной по заказу создаются расходные проводки в GTDTrans, изменяются остатки в GTDSum. Доступные ГТД подбираются по ФИФО. По строке накладной может быть создано несколько проводок.
7. При формировании Счета-фактуры на каждую проводку в GTDTrans, связанную со строкой исходной накладной, создается строка счета-фактуры.

Делали не так давно один в один - так. Что сказать - полет нормальный

[vc]

Цитата:

Сообщение от MironovI

Делали не так давно один в один - так. Что сказать - полет нормальный

Спасибо за ответ.

[MironovI]

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

[glibs]

Цитата:

Сообщение от MironovI

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

Не факт. Лучше ручное добавление ГТД в пул сделать.

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

[vc]

Цитата:

Сообщение от MironovI

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

Согласен, расходовать ГТД надо будет на все расходные операции, приходовать на все приходные. Исключая межскладские перемещения

Цитата:

Сообщение от glibs

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

Об этом не думал, действительно лучше. Спасибо