Где изменяется статус заказа?

[Zick-Zibn]

Подскажите пож-та где именно происходит изменение статуса Заказа. при его обработке. Пол дня ищу, но что то не успешно

[George Nordic]

?? Не понял.
Тебя интересует, где непосредственно происходит update?

В SalesFormLetter есть чудесный метод postUpdate

            if (salesTable)
            {
                salesTable.updateDocumentStatus(this.documentStatus());
                salesTable.updateBackStatus();
                this.updateSalesType();
                this.createBackorderLines();
                salesTable.updateDeadline(salesParmUpdate.respiteDate);
            }

Обрати внимание на updateDocumentStatus.

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

[George Nordic]

Пол-дня... Друг, поставил бы брекпоинт на update в salesTable да и посмотрел бы

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

[Zick-Zibn]

Спасибо.

[simply2double]

Цитата:

Сообщение от George Nordic

Пол-дня... Друг, поставил бы брекпоинт на update в salesTable да и посмотрел бы

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

какой такой брекпоинт... ты точно скажи.. скока вешать...

[George Nordic]

Цитата:

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

какой такой брекпоинт... ты точно скажи.. скока вешать...

200 граммов

Я ж говорю: Класс SalesFormLetter, метод postUpdate. Вызывает метод updateDocumentStatus(новый статус) таблицы SalesTable

[simply2double]

Цитата:

Сообщение от George Nordic

200 граммов

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

[AvrDen]

Добрый день!
Очень интересует зачем менять статус заказа при обработке каждой строки заказа? Почему нельзя это сделать в конце один раз?

[pitersky]

Цитата:

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

Добрый день!
Очень интересует зачем менять статус заказа при обработке каждой строки заказа? Почему нельзя это сделать в конце один раз?

А если заказ отгружается несколькими накладными? Как определить этот самый момент в конце?

[TasmanianDevil]

Потому что:

• заказ может обрабатываться частично
• каждая строка заказа может обрабатываться частично

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

[AvrDen]

Спасибо!
Я тоже так подумал что это сделано из-за частичной обработке заказа, просто у нас на предприятии все заказы обрабатываются всегда целиком и содержат по 2-5 тыс. строк и разноска занимает очень продожетельное время. Вот и приходиться искать пути оптимизации

[pitersky]

Цитата:

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

Спасибо!
Я тоже так подумал что это сделано из-за частичной обработке заказа, просто у нас на предприятии все заказы обрабатываются всегда целиком и содержат по 2-5 тыс. строк и разноска занимает очень продожетельное время. Вот и приходиться искать пути оптимизации

В вашем случае как раз и подошёл бы способ, предложенный Tasmanian Devil. Напишите метод, который по завершении обработки строк накладной проверяет, можно ли изменить статус заказа.

[AvrDen]

Цитата:

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

В вашем случае как раз и подошёл бы способ, предложенный Tasmanian Devil. Напишите метод, который по завершении обработки строк накладной проверяет, можно ли изменить статус заказа.

Да я так и попробую. Посмотрим как это повлияет.

[ice]

Цитата:

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

Да я так и попробую. Посмотрим как это повлияет.

простое убирание обновления статуса в разноске из цикла в конец отработки всех строк, скорее всего мало повлияет на скороть обработки:
1. это не самая тяжелая операция
2. updateStatus вызывается еще при обновлении строк заказа

[AvrDen]

Цитата:

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

простое убирание обновления статуса в разноске из цикла в конец отработки всех строк, скорее всего мало повлияет на скороть обработки:
1. это не самая тяжелая операция
2. updateStatus вызывается еще при обновлении строк заказа

При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.

[ice]

Цитата:

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

При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.

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

[mazzy]

Цитата:

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

раз так, то добавьте нужный индекс

угу.
а еще лучше - удаляйте старые уже обработанные заказы

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

если обработанные заказы удаляются, то на логическом уровне получается красивая картина:
УЖЕ сделанное находится в фактических документах
ОЖИДАЕМОЕ в ближайшем будущем находится в заказах

[pitersky]

Цитата:

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

угу.
а еще лучше - удаляйте старые уже обработанные заказы

При всём уважении к этому подходу - ни разу не видел на внедрениях, чтобы он применялся. Думаю, что бухгалтерия встанет на дыбы, но такого не допустит.

[AvrDen]

Цитата:

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

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

Да в трассировке и нашли что тормозит

    select minof(SalesStatus) from salesLine
        where   salesLine.SalesId       == salesId              &&
                salesLine.SalesStatus   >  SalesStatus::None;

[AvrDen]

Цитата:

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

угу.
а еще лучше - удаляйте старые уже обработанные заказы

У нас это требование руководства - хранить "историю"....