|
28.03.2007, 16:36 | #1 |
Участник
|
Добрый день.
NAV 4.0 SP3 SQL 2005 Кратко опишу проблему. Учет с\с товаров ведется по средней. При запуске задание коррекции с\с, на некоторых товарах оно напрочь отказывается завершаться и продолжает выполняться в течение длительного времени. Я останавливал задание по истечении 12 часов, так и не дождавшись результата Через профайлер видно, что запросы продолжают выполняться и выполняться и нет им конца. Подозрение на то, что при коррекции с\с конкретного товара задание просто зацикливается. Вот только понять смысл зацикливания я не могу. Методом вилки выцепил позиции, на которых происходит зацикливание. Их порядка 7 из более чем 200 товаров. Эти товары ничем не отличаются от других ни в плане настроек, ни в плане количества товарных операций. Прошу совета и жду предложений. Спасибо!
__________________
Вот такие, брат, дела! |
|
28.03.2007, 17:17 | #2 |
Участник
|
А товары не входят в кокой-нибудь комплект?
|
|
28.03.2007, 18:31 | #3 |
Участник
|
Я конечно понимаю, что предлагаю глупость, но может все-таки попробовать продебажить именно по одному из этих 7 товаров?
|
|
29.03.2007, 07:14 | #4 |
Участник
|
Нет, никаких комплектов нет. Общался со специалистами, оказывается такая проблема существует и в других системах в случае, если по товару много перемещений с одного склада на другой. Может возникнуть ситуация с округлением, когда одна копейка перекидывается то в одну сторону, то в другую до момента достижения максимального количества итераций. А в итоге может так получится, что товар ушел со склада с правильной с\с, а пришел на другой с с\с, уменьшенной на копейку
На лицо баг, связываюсь с МБС.
__________________
Вот такие, брат, дела! |
|
30.03.2007, 12:57 | #5 |
Участник
|
Интересно удалось ли что-нибудь выяснить по этому вопросу...
У одного из клиентов тоже проблема с этой функцией. Правда в моём случае появляется ошибка о том, что не хватает памяти для выполнения этой функции. Причём изменив код так, чтобы обрабатывался только один код товара (на котором и вылетает ошибка) ничего не изменилось. Таже ошибка. Что ещё можно предпринять? С этим товаром было довольно много продаж и возвратов (Credit Memos). Причём продажи в минус и только в конце (последняя операция) положительная, которая закрывает все записи. |
|
30.03.2007, 13:24 | #6 |
Участник
|
Хм... Ерунда какая-то... Сегодня явно не мой день.
Есть такой параметр в кодюнете 5895 (как-то не приходилось раньше так глубоко копать) MaxLevels = 100. По названию я решила, что чем эта константа больше, тем больше шансов завершить эту функцию. Оказалось наоборот. Уменьшив значение, функция сработала. Осталось выяснить правельно ли. А смысл параметра теперь мне не ясен. :-( |
|
30.03.2007, 16:57 | #7 |
Участник
|
Судя по коду - это глубина рекурсии.
|
|
30.03.2007, 18:11 | #8 |
Участник
|
|
|
03.04.2007, 14:54 | #9 |
Участник
|
Вновь обращаюсь к знатокам....
Проблема всё ещё не решена. Мой вариант уменьшения параметра не подходит, т.к. при этом в таблице Value Entry создаются записи типа округление с суммой >1, а этого не должно быть. Без изменений функция не выполняется и выдаёт сообщение о том, что нехватает памяти. [attachment=593:err.JPG] |
|
04.04.2007, 12:39 | #10 |
Участник
|
Добрый день. Проблему удалось решить, проблема таилась в некорректных данных, а именно в неверных датах переоценки в операциях стоимости. После ручной коррекции таких операций задание стало отрабатывать до конца.
Помощь пришла от Microsoft, Андрей Финогенов прислал мне утилиту для проверки целостности данных для пересчета себестоимости. Утилита мне очень помогла. Написана она изначально для 3.7 (в структуре данных по с\с между 4.0 и 3.7 есть существенные различия), однако она заработала и под 4.0. Утилита называется "Costing Error Detection and Data Correction White Paper". Я так понимаю, что файлы с титулом "White Paper" можно размещать на портале?! Уважаемый mazzy, если я прав, то отметьте это и я выложу утилиту сюда на форум. Marisha. Насчет длины рекурсии посмотрите поле "Amount Rounding Precision" в таблице "98 General Ledger Setup". Оно должно быть по умолчанию равно 0,01. Не меняли ли вы его?
__________________
Вот такие, брат, дела! |
|
04.04.2007, 17:05 | #11 |
Участник
|
Да, можно. Спасибо
|
|
04.04.2007, 18:04 | #12 |
Участник
|
И где это закинуто?
|
|
05.04.2007, 16:56 | #13 |
Участник
|
С Amount Rounding Precision всё в порядке... не меняли...
Проблему к сожалению вынуждена решать в ручную, меняя данные. Оказалось, что кое-что исправлено в SP3... но.... Bug стандарта был при регистрации продаж в минус... конкретнее Т339 заполнена не правилёно и никакие HotFix-ы не помогают, только ручками... Кроме того обнаружили довольно много ошибок, допущеных пользовотелем... (напр-р, делая возврат указывают не тот номер записи в Appl.-from Item Entry). И с этим стандарт не справился . И это в 4 SP3 неисправлено. Но всё из-за того, что разрешена возможность продовать в минус. Так что лучше что запретить. В чём и пытаюсь теперь убедить клиента. |
|
06.04.2007, 12:08 | #14 |
Участник
|
Запрещайте однозначно! Сам с этим в свое время накуролесился. В результате пришлось собирать 339 таблицу практически с нуля.
Выложил инструмент для проверки себестоимости Инструмент для анализа себестоимости
__________________
Вот такие, брат, дела! |
|