очистка InventSumLogTTS

[AK-76]

В связи со значительным ежедневным приростом записей в таблице InventSumLogTTS, возник вопрос о возможности её очистки для функционала Торговля-Логистика без сводного планирования.
Насколько я понимаю количество записей пропорционально количеству создаваемых складских проводок с учетом разбиения проводок в журнале комплектации.
Возникло два вопроса:
1. Существуют ли настройки в стандартном функционале, которые влияют на добавление количество записей в ээтой таблице .
2. Допускается ли очистка этой таблицы, допустим по истечении срока. (К примеру свзанный заказ полностью скомплектован и отфактурирован).

[Vadik]

"Множественные складские транзакции" отключать не хотите?

[AK-76]

да, неплохая идея.

[Андре]

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

[George Nordic]

А где в 3,0 такая галка? Что-то никак найти не могу

[Андре]

Администрирование -> Настройки -> Система -> Сист. множ. скл-х транзакций

[George Nordic]

Спасибо, Андре!

Выключены они у меня. Выключены. А таблица-то растет! Дико. 8 440 000 записей за пол-года. В последнее время более резво стала приростать. Есть подозрение, что данные проводки генеряться именно при планировании. В настройках "Сводное планирование - настройки - планы - сводные планы" галка "Складские проводка" включена. Может она влиять на заполнение имено InventSumLogTTS? Сейчас попробую убрать на тестовой базе. На рабочей базе попробуем почистить. AKIS говорит, что у него ничего страшного не произошло. Проверим у себя, постараемся описать. Но, ести кто сталкивался с подобным, откликнитесь, плиз, откуда такая беда (разрастание таблицы InventSumLogTTS при ВЫКЛЮЧЕНЫХ "множественных складских транзакциях") и чем чревата её очистка.

[Андре]

Цитата:

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

Именно. Зачем, честно говоря, не знаю.

[George Nordic]

Была ведь ветка - точно помню! К сожалению, при переносе куда-то потерялась... У AKISа была точно такая же беда... Насколько я помню, там шла речь о том, что это баг системы, ни на что эти данные не влияют, и что это поправили в SP2.

Вот что сказал Дмитрий (AKIS) по этому поводу:

Цитата:

...В двух словах - это баг, и Майкрософт (конечно же) знает об этом, но разумеется), не чешется чтоб исправить. .... Советуют запускать master planning once in a while - тогда, мол, табличка будет очищаться... Кстати, как выяснилось, чистить табличку мало. Нужно еще почаще запускать optimizations на всю базешку, а то у нее от
ввода-удаления миллионов строк за раз едет крыша..

Он решился на операцию по усекновению данной таблицы:

Цитата:

....InventSumLogTTS действительно почистил. Результат - ничего плохого, кроме хорошего (тьфу-тьфу-тьфу три раза). Поэтому сейчас стал этим заниматься регулярно, во всяком случае как только число записей в ней доходит до нескольких сотен тысяч, что случается раз в три-четыре дня. Правда, удаляю я только то, что имеет Commited=Yes - как мне и советовали. ...

Мы тоже решились на данную операцию. О результатах сообщу дополнительно.

С Уважением,
Георгий

[George Nordic]

Прибили. И очень хорошо себя чуствуем. Глюк-с это, точно. Теперь написан класс, который вызывается из пакета и удаляет все записи раз в неделю.