|
29.03.2006, 13:57 | #1 |
Участник
|
Где изменяется статус заказа?
Подскажите пож-та где именно происходит изменение статуса Заказа. при его обработке. Пол дня ищу, но что то не успешно
|
|
29.03.2006, 14:04 | #2 |
Модератор
|
?? Не понял.
Тебя интересует, где непосредственно происходит update? В SalesFormLetter есть чудесный метод postUpdate X++: if (salesTable)
{
salesTable.updateDocumentStatus(this.documentStatus());
salesTable.updateBackStatus();
this.updateSalesType();
this.createBackorderLines();
salesTable.updateDeadline(salesParmUpdate.respiteDate);
} С Уважением, Георгий |
|
29.03.2006, 14:05 | #3 |
Модератор
|
Пол-дня... Друг, поставил бы брекпоинт на update в salesTable да и посмотрел бы
С Уважением, Георгий |
|
26.05.2006, 14:27 | #4 |
Участник
|
Цитата:
Сообщение от George Nordic
Пол-дня... Друг, поставил бы брекпоинт на update в salesTable да и посмотрел бы
С Уважением, Георгий |
|
26.05.2006, 14:50 | #5 |
Модератор
|
Цитата:
Сообщение от simply2double
какой такой брекпоинт... ты точно скажи.. скока вешать...
Я ж говорю: Класс SalesFormLetter, метод postUpdate. Вызывает метод updateDocumentStatus(новый статус) таблицы SalesTable |
|
26.05.2006, 15:07 | #6 |
Участник
|
Цитата:
Сообщение от George Nordic
200 граммов |
|
29.03.2006, 15:09 | #7 |
Участник
|
Спасибо.
|
|
13.01.2011, 11:37 | #8 |
Участник
|
Добрый день!
Очень интересует зачем менять статус заказа при обработке каждой строки заказа? Почему нельзя это сделать в конце один раз? |
|
13.01.2011, 12:02 | #9 |
северный Будда
|
А если заказ отгружается несколькими накладными? Как определить этот самый момент в конце?
__________________
С уважением, Вячеслав |
|
|
За это сообщение автора поблагодарили: AvrDen (1). |
13.01.2011, 12:05 | #10 |
Мрачный тип
|
Потому что:
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
|
За это сообщение автора поблагодарили: AvrDen (1). |
13.01.2011, 12:32 | #11 |
Участник
|
Спасибо!
Я тоже так подумал что это сделано из-за частичной обработке заказа, просто у нас на предприятии все заказы обрабатываются всегда целиком и содержат по 2-5 тыс. строк и разноска занимает очень продожетельное время. Вот и приходиться искать пути оптимизации |
|
13.01.2011, 12:39 | #12 |
северный Будда
|
В вашем случае как раз и подошёл бы способ, предложенный Tasmanian Devil. Напишите метод, который по завершении обработки строк накладной проверяет, можно ли изменить статус заказа.
__________________
С уважением, Вячеслав |
|
13.01.2011, 12:45 | #13 |
Участник
|
|
|
13.01.2011, 12:54 | #14 |
Участник
|
простое убирание обновления статуса в разноске из цикла в конец отработки всех строк, скорее всего мало повлияет на скороть обработки:
1. это не самая тяжелая операция 2. updateStatus вызывается еще при обновлении строк заказа |
|
13.01.2011, 13:34 | #15 |
Участник
|
При анализе нашли, что больше тормоза происходят в методе salesLine.lowestSalesStatus, который вызываеться из salesTable.updateBackStatus. Скорее всего из-за того что нет индекса по SalesId,SalesStatus в таблице salesLine. В итоге получается что при обработке заказа больше 1000 строк на обработку одной строки уходит порядка 10 сек.
|
|
13.01.2011, 15:01 | #16 |
северный Будда
|
У вас какие-нибудь отчёты строятся по строкам заказов? Если да, то какие?
__________________
С уважением, Вячеслав |
|
14.01.2011, 06:01 | #17 |
Участник
|
Нет, отчетов по строкам заказов нет. Но пользователи изначально работают с формой Заказы, она содержит много модификаций для удобства восприятия информации. И если предложить работать с формой накладных, то у них возникнет дискомфорт в работе. Пользователи сильно противяться этому.
|
|
14.01.2011, 11:09 | #18 |
Участник
|
Изменили код Classes\SalesFormLetter\postUpdate
X++: protected void postUpdate() { SalesParmTable localSalesParmTable; ParmId parmIdPrev; SalesId salesIdPrev; ; ttsbegin; localSalesParmTable = this.setForUpdateSalesParmTable(); localSalesParmTable.StartDateTime = startDateTimeTable; localSalesParmTable.EndDateTime = DateTimeUtil::newDateTime(systemdateget(),timenow(),DateTimeUtil::getUserPreferredTimeZone()); localSalesParmTable.updateParmJobStatusExecuted(); salesParmLine.clear(); // Sales totals are nulled in order to force a recalculation of the sales totals // which are then stored in the SalesTable.estimate field for utilization during credit limit check salesTotals = null; recordListSalesParmLine.first(salesParmLine); while (salesParmLine) { if (salesParmLine.OrigSalesId != salesIdPrev || salesParmLine.ParmId != parmIdPrev) { //counting number of SalesOrders we deal with if (salesParmLine.OrigSalesId != salesIdPrev) { ++numberOfRecords; } // 13.01.2011 AVRDV --> /* salesTable = salesParmLine.salesTable(true); if (salesTable) { salesTable.updateDocumentStatus(this.documentStatus()); salesTable.updateBackStatus(); this.updateSalesType(); this.createBackorderLines(); salesTable.updateDeadline(salesParmUpdate.RespiteDate); if (salesTable.SalesId != salesParmTable.SalesId) { // If this is not the primary sales order in the summary order, // void the credit card preauthorization that may exist as it is no longer valid this.voidCreditCardPreauthorize(); } } */ // 13.01.2011 AVRDV <-- localSalesParmTable = salesParmLine.salesParmTable(true); if (localSalesParmTable) { localSalesParmTable.updateParmJobStatusExecuted(); } } salesIdPrev = salesParmLine.OrigSalesId; parmIdPrev = salesParmLine.ParmId; if (!recordListSalesParmLine.next(salesParmLine)) break; } // 13.01.2011 AVRDV --> salesTable = SalesTable::find(salesIdPrev,true); if (salesTable) { salesTable.updateDocumentStatus(this.documentStatus()); salesTable.updateBackStatus(); this.updateSalesType(); this.createBackorderLines(); salesTable.updateDeadline(salesParmUpdate.RespiteDate); if (salesTable.SalesId != salesParmTable.SalesId) { // If this is not the primary sales order in the summary order, // void the credit card preauthorization that may exist as it is no longer valid this.voidCreditCardPreauthorize(); } } // 13.01.2011 AVRDV <-- ttscommit; } |
|
14.01.2011, 12:25 | #19 |
Участник
|
а если процессы изменятся?
|
|
14.01.2011, 13:11 | #20 |
Участник
|
А почему в случае изменения процессов Вас беспокоит только эта модификация, а не 10 тысяч других, сделанных ранее?
Ясно же, что если меняются процессы, то много чего нужно пересматривать и проверять будет. Заложиться заранее на то, что именно и как изменится - невозможно. А конкретная проблема есть уже сейчас, и решать её нужно, и весьма эффективное решение найдено. Искренне поддерживаю автора. |
|
|
За это сообщение автора поблагодарили: AvrDen (1). |