|
24.07.2008, 16:54 | #1 |
Участник
|
Дока по произ-ву просто убила. Мало того, что примеры не интуитивные, так еще и пропуски в шагах есть (хотя номерация нормальная) + некорректные ссылки.
Чего стоит пример? Попобуйте найти на форме это: |
|
25.07.2008, 11:24 | #2 |
Участник
|
Цитата:
предлагаю перенести найденные Вами баги на треккер багов NAV дабы они не сгинули в бездне тем... |
|
25.07.2008, 12:11 | #3 |
Участник
|
Цитата:
Сообщение от Fordewind
RedFox
предлагаю перенести найденные Вами баги на треккер багов NAV дабы они не сгинули в бездне тем... Разве Mazzy собирается закрывать ресурс? Я потихонечку, когда что-то нахожу или непонятно - выкладываю сюда. Да и движок MANTIS'овский мне не очень нравится + "дублирование". |
|
25.07.2008, 14:04 | #4 |
Участник
|
Надеюсь, что нет.
И получается такая куча полезностей, в которой трудно что-либо найти А какой движок по Вашему подошел бы? |
|
21.08.2008, 13:26 | #5 |
Участник
|
Почти контрольный - как можно было перепутать ПРИНЦИПИАЛЬНЫЕ названия!!
Или все-таки это недоделанный функционал? Тогда где, например, обещанная в доке Карточка Простоя? В любом случае, как обычно, 2 скрин-шотика: P.S. Вот сижу и думаю, когда закончил с докой, сдавать такой экзамен или нет... |
|
30.09.2008, 13:31 | #6 |
Участник
|
Вот нашлось пару минут заскочить на сайт и запостить хотя бы 1 сообщение. Выбор пал на проблему в поле "Comparison Period Formula" в таблице "The Analysis Column"
Комментировать нечего - все на скрин-шоте. P.S. Добавлю, что код ПРОСТО убил, особенно в области разборки символов (не цифр)! |
|
05.12.2008, 15:51 | #7 |
Участник
|
В журнале передвижений для товара (Movement Worksheet), который имеет серийный номер (просто проверял товар 80001 из доки WM) ручками ввел строку (а не использовал функционал Get Bin Content). А потом хотел назначить конкретные серийные номера для подборки.
Но мои старания не увенчались успехов - LookUp не работал P.S. Решил добавить ещё данные про серийные номера и складской журнал. |
|
08.12.2008, 11:00 | #8 |
Участник
|
Коррекция: Все операции Warehouse производились на NAV 2009.
Иду дальше по доке и натываюсь на очередное в Item Tracking. В подборе захотелось отфильтровать по ячейке (кстати, было создано системой), а потом назначить конкреный Серийный номер (Пункт 6, Сценарий 16, Дока - Склад) и вижу - при открытии формы для выбора серийных номеров при заполненном поле Ячейка Код по серийнфым номерам нет фильтрации! Далее ещё веселее - такую "несуществующую комбинацию" товар+серийник+ячейка система вполне даёт вставить на форме. Вот как это можно назвать... ??? |
|
08.12.2008, 11:30 | #9 |
Участник
|
Цитата:
Сообщение от RedFox
Иду дальше по доке и натываюсь на очередное в Item Tracking.
В подборе захотелось отфильтровать по ячейке (кстати, было создано системой), а потом назначить конкреный Серийный номер (Пункт 6, Сценарий 16, Дока - Склад) и вижу - при открытии формы для выбора серийных номеров при заполненном поле Ячейка Код по серийнфым номерам нет фильтрации! Далее ещё веселее - такую "несуществующую комбинацию" товар+серийник+ячейка система вполне даёт вставить на форме. Вот как это можно назвать... ??? Выполняю обычные операции по складу согласно документа (тоесть в дополнение к 16 отгрузенным ранее товарам с серийниками SN00009..SN00024 нужно отгрузить срочно ещё 4 шт). Всё как положено, через журнал подбора создаю ещё 4 в 1 документе и вдруг решил зайти в Item Tracking Lines и вижу... в списке отгруженные серийники (это ещё как бы понятно - Заказ то общий), но ПОЧЕМУ без каких-то признаков или статусов то?? P.S. После создания подбора та же ситуация, что и в предыдущем посте! Вобщем как ни крути, а даже по складу для МС работы ещё много осталось. И чтобы они не писали про оптимизацию процессов, но "Писателей" нужно профильных брать!!! |
|
08.12.2008, 11:36 | #10 |
Участник
|
Коррекция: Все операции Warehouse производились на NAV 2009.
А это вобоще НЕ ПОНЯЛ ВЗАГАЛИ!!! |
|
19.12.2008, 11:35 | #11 |
Участник
|
Недавно перенося функционал встретил ОЧЕНь интересную "фичу" НАВ - получается, что при импорте текстового файла и фоба (импорт/экспорт) система не проверяет то, что указано в свойствах. Покажу на примере переноса функционала с версии 5.0 на 3.70:
1. Берём любую таблицу в 5.0, у которой установлено свойство первичного ключа Clustered=Yes 2. Делаем экспорт данной таблицы в Фоб и текстовый файл. 3. Берём НАВ версии 3.70 и импортируем фоб, а потом его экспортируем. Всё проходит без проблем. 3. Берём НАВ версии 3.70 и импортируем текстовик. При компиляции всё проходит на ура! Но при попытке выгрузить в текст получаем ошибку (в моем случае упоминалась ошибка 4994). В моес случае я методом научного втыка просто удалил в текстовике запись Clustered=Yes и всё начало работать. но это лишь часный случай. P.S. Если кто имеет перечень расшифровок ошибок, то плиз, поделитесь! |
|
19.12.2008, 13:07 | #12 |
Участник
|
Следующий баг касается "Expiration Date", а точнее не возможности "совпадения" товара с ЛОТ или СН, но одинаковыми значениями в данном поле.
Чтобы долго не описывать ситуацию скажу, что на Демо-БД было оприходовано 2 товара с разными ЛОТ+СН (ItemData-1). Потом создаем Заказ Продажи, делаем Inventory Pick (ItemData-2, ItemData-3) и пытаемся отгрузить. В итоге получаем ошибку. Проблема в функции ExistingExpirationDate(ItemNo : Code[20];Variant : Code[20];LotNo : Code[20];SerialNo : Code[20];TestMultiple : Boolean;VAR EntriesExis. Она высылается из SetupSplitJnlLine(ItemJnlLine2,PostItemJnlLine) (КЮ 22) Ошибка пользователя - НЕ ПРАВИЛЬНОЕ назначение СН + "манипуляции" с "Reclass. Journal". НО (!!) почему система дала сделать это? Ведь мы знаем, что серийные номера уникальны для одного товара! Тоесть любой человек может с помощью этого журнала на складе вертеть как хочешь? При этом данные в Warehouse Entry не отобразились, а прошли только по ILE. Наверное разработчики решили положиться на код в триггере GetLotSNDataSet, но неучли вышеописан. А ещё более непонятно сообщение: Text007="There are multiple expiration dates registered for lot %1", когда проверяются серийные номер?? И что заставлет систему думать, что есть ещё записи - я так и не понял. Но мне не нравится этот код: IF NOT ItemLedgEntry.ISEMPTY THEN ERROR(Text007,LotNo); |
|
22.01.2009, 13:42 | #13 |
Участник
|
Цитата:
Проблема: Товар А хранится на складе в единицах изм. "PCS" в ячейке Х. Затем продаётся в единицах изм. "BOX". 1. Создается Заказ Продажи с Товаром А в ед.изм. "BOX" 2. Из Заказа создаю складскую Отгрузку с Товаром А в единицах изм. "BOX". 3. Из Отгрузки создаю Подбор: беру Товар А в ед.изм. "BOX" из ячейки Х и кладу Товар А в "BOX" в ту же ячейку Х. Регистрирую Подбор. 4. Отгрузка не учитыватеся у т.к. в ячейке Х Товар А по прежнему лежит в "PCS" а не "BOX" В настройках склада настроены все операции, кроме Расширенный Подбор и Размещение=Нет Анализ ошибки: - Всё хорошо работает, пока мы не регистрируем Подбор. После регистрации подбора в таблице 7312 Warehouse Entry создаются строки, но (!!!) в единицах измерения "PCS". Чтобы далее сценарий начал работать, нужно исправить заполнение значениями полей в этой таблице "Quantity", "Unit of Measure Code", "Qty. per Unit of Measure" и "Qty. (Base)". И (забегая немного наперед - см. ошибку), создать запись в таблице 7302 "Bin Content" для нашей единицы измерения "BOX". Далее, чтобы учесть Отгрузку, нам нужно присутствие условия: - записи в таблице 7302 "Bin Content" (указано и сделано ранее) - поставить ячейку в поле "Adjustment Bin Code" для склада (правда непонятно что лучше - доделать код в функции DeleteFromBinContent или RegisterRoundResidual или донастроить). И мы получили счастье!!! |
|
10.06.2009, 19:48 | #14 |
Участник
|
|
|
11.06.2009, 10:36 | #15 |
MCTS
|
Работы ведутся.
В NAV2009 SP1 второй строки нет. |
|