Удаление InventSettlemens

[Andrux]

Вопрос глупый, но все же
если отменить все пересчеты себестоимости, удалить проводки по этип операциям (в ГК), и удалить все записи в InventSettlements, а затем пересчитать себестоимость, что будет?

[glibs]

Записи в InventSettlement относятся не только к закрытию склада и корректировкам. Например, к корректировке себестоимости, разноске накладных расходов.

В общем, плохо будет.

Посмотрите функцию суммирования сопоставлений. Или она очисткой сопоставлений называется.

[Wamr]

Удалить можно те, что с Canceled = 1

[Raven Melancholic]

е

Цитата:

сли отменить все пересчеты себестоимости

нет проблем, это штатный механизм Аксапты.

Цитата:

удалить все записи в InventSettlements

Если пересчеты и закрытия себестоимости отменены, то записи в InventSettlements никак не влияют на баланс главной книги (с точки зрения российских ПБУ возможны проблемы из-за разницы сторно и реверса операций).

Цитата:

удалить проводки по этип операциям (в ГК)

Абсолютно лишняя операция. Отмена закрытия (пересчета) и так скорректирует операции по ГК. Опять же, если забыть про корреспонденцию счетов, то операция совершенно законная. Если добавить российские правила, то есть небольшие проблемы

Цитата:

удалить все записи в InventSettlements

Не нужно. Отмена пересчетов или закрытий отмечает записи в InventSettlements как не активные. Эти неактивные записи можно удалить стандартной периодической операцией.
PS: в общем, если вы не скрыли какие-то неочевидные особенности, то задачу вполне можно решить стандартными средствами. (если же сказали не все, то нужно думать, как решить задачу)

[Zabr]

Цитата:

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

Удалить можно те, что с Canceled = 1

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

[fed]

Цитата:

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

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

В таком случае, непонятно наличие оператора

delete_from inventSettlement
        index hint ItemDateIdx
        where inventSettlement.ItemId       == _inventTable.ItemId              &&
              inventSettlement.Cancelled    == NoYes::Yes                       &&
              inventSettlement.SettleModel  != InventSettleModel::PhysicalValue &&
              inventSettlement.TransDate    <  transDateDel;

в методе inventCostCleanup.updateDelSettlement(). На что же нам намекают его авторы ?

А если говорить по делу, то та функциональность которая нужна топикстартеру присутствует в этом самом классе inventCostCleanup. Разница только в том, что он проводки по ГК не удаляет, а сторнирует. (О чем уже было сказано Raven Melancholic).
Если написать свой класс, который удаляет отмененные записи в inventSettlement, проводки по ГК (с аккуратным пересчетом балансов в ledgerBalanceDim / LedgerBalanceDimTrans) и сопутствующую запись в inventClosing, то можно добиться полного удаления следов закрытия/пересчета склада. Я конечно знаю, что это методологически неверно, но во время запуска системы мне приходилось для устранения последствий собственных ошибок такие классы писать.

[mazzy]

Цитата:

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

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

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

[Zabr]

Цитата:

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

А по-моему, "отсутствие в индексах" - просто ошибка.

Да, конечно, про намёки я ж просто пошутил. У меня например inventsettlement - 53 млн. записей на 28 Гб (данные+индексы),.

[Vadik]

Цитата:

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

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

Ну это как посмотреть. Если регулярно проводить ТО системы, включающее удаление отмененных сопоставлений в прошлых периодах, то селективность и соответственно польза от такого индекса радостно стремится к нулю. Так что если вы N-цать лет экспериментировали с закрытием склада и не чистили InventSettlement, то соотношение "хороших" и "плохих" сопоставлений и количество данных будут такие, что оптимизатору будет дешевле запустить один table scan чем миллионы раз метаться от записей в индексе к страницам с данными. В этом случае очистка частями по дате сопоставления (TransDate) вам в помощь, благо поле проиндексировано неоднократно

[Zabr]

Цитата:

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

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

Это да, но меня на самом деле интересовала скорость чистки, сколько времени моя база будет шуршать по 53 миллионам записей без индекса по нужному полю.

[Vadik]

Цитата:

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

Это да, но меня на самом деле интересовала скорость чистки, сколько времени моя база будет шуршать по 53 миллионам записей без индекса по нужному полю.

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

[sukhanchik]

Цитата:

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

Это да, но меня на самом деле интересовала скорость чистки, сколько времени моя база будет шуршать по 53 миллионам записей без индекса по нужному полю.

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

Только надо учесть, что имена индексов уникальны в БД (MS SQL Server) и полную копию таблицы с индексами создать не получится, если не переименовать помимо таблицы еще и индексы.
Я создавал копию таблицы без индексов - туда все переливал, после чего синхронизировал табличку (после удаления исходной таблицы)

[Zabr]

Цитата:

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

Если отмененных сопоставлений много (миллионы)

Всего 53,7 млн, из них отмененных 3,7 млн. Вообще, имеет смысл чистить при таком раскладе, что посоветуете?

[Vadik]

Цитата:

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

Всего 53,7 млн, из них отмененных 3,7 млн. Вообще, имеет смысл чистить при таком раскладе, что посоветуете?

Я бы почистил, профилактики ради и экономии места для - производительности особой это не прибавит. Если планируете запускать такую очистку регулярно и используете SQL Server 2008, можете создать filtered index (WHERE CANCELLED = 1) - получится симпатично, эффективно и не громоздко

[Zabr]

Почистил. Заняло 7 часов. Удалилось 10,1 млн сопоставлений, добавилось 6,5 млн, итого уменьшение на 3,6 млн. записей. Посмотрел на таблицу в Sql management studio .. и очень сильно удивился занимаемому объему в базе: ОН ВЫРОС! Число записей - да, сократилось. Но занимаемое место в базе: было 14 Гб данные + 14 Гб индексы, стало 13 Гб данные + 20 Гб индексы. Почему вдруг настолько сильно (на 50%) выросло место занимаемое индексами, если число записей сократилось?
Vadik, есть версии ?

[Vadik]

Цитата:

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

Почистил. Заняло 7 часов. Удалилось 10,1 млн сопоставлений, добавилось 6,5 млн
..
Почему вдруг настолько сильно (на 50%) выросло место занимаемое индексами, если число записей сократилось?

Если не углубляться в технические подробности - это пройдет после перестройки индексов