|
15.05.2008, 13:17 | #1 |
Участник
|
Наткнулся на мерзкий момент.
Если сменить Глобальное Измерение, то Navision начинает ругаться на рядового пользователя, что тот не имеет прав доступа к некоторому числу таблиц (на пользователя с правами Super не ругается). Причем эти таблицы в работе компании никак не используются и не имеют ни единой записи, они могут даже в лицензию не входить. Так же замечено, что в Table Information при этом возникают строки с таблицами, которые так же показывают количество записей равное нулю. Единственным полноценным решением стал старый способ создания/восстановление бэкапа с глючной базы. Кстати, наткнувшись на этот баг сразу решил найти ответ на форуме, но так и не нашел. Возможно стоит завести отдельный раздел с багами? P.S. NAV4sp3 БД Nativе |
|
15.05.2008, 18:11 | #2 |
Участник
|
Цитата:
Вот еще один из произ-ва (NAV 5 PS1 W1) Add: + А если еще поссмотреть использование в КЮ 99000773 и 99000809, то вообще получим, что потом затирается старое значение "Prod. Order Routing Line" |
|
20.05.2008, 12:04 | #3 |
Участник
|
Далее есть стандратная дока (кто читал - сразу ее опознает).
Так вот просто читаю то, что написано и делаю. И в итоге ошибка (или я не понял что там хотели написать...), которая не позволяет обычному пользователю выполнить то, что написано, заметте, в стандартной доке, которую продает (не распространяет бесплатно, а продает) МС. Я не проверял, но помоему, ВОЗМОЖНО, такой же "баг" есть в книге (ставлю памятку в файл, чтобы поссмотреть) P.S. База 5.0 W1 (not SP1). The NAV 5.0 SP1 has similar LOT (Item tracking - usability) error (see next time). |
|
20.05.2008, 17:01 | #4 |
Участник
|
Следующая фича только под Native (на SQL видать сортировака по другому) - при попытке открыть форму Shipment на Native (на SQL все ОК) на 5.0 (+4.0 SP2 RU) выдается сообщение. Повторилось на нескольких базах, вплоть до 5.0 SP1:
|
|
21.05.2008, 12:43 | #5 |
Участник
|
Как и обещал - продолжаю про Серийные Номера и ЛОТы (и уже включая 5.0 PS1):
Вроде все обновлено, но баги стались (Серийные Номера = ЛОТы ): При назначении Серийные Номера (для ЛОТа тоже самое) можно поссмотреть информацию (см рис. "Serial No. Information"). А теперь, как "любознательный пользователь" просто меняем, возможно, ошибочный номер, присвоенный в поле "Serial No." (см. рис "Serial No. Information 2") Все вернулось на круги своя после изменения, но ... смотрим таблицу "Serial No. Information" и видим новую запись (см. ис. "Serial No. Information 3"). Так вот вроде бы пустяк и на работу никак не влияет, но мне, например, не хотелось ыбы иметь мусорные сзписис в системе... P.S. Да, кстати, как по мне - проблема (а точнее функционал) с назначением новых Серийных Номеров или ЛОТов присутствует. Простой пример - назначте новые номера, а потом просто удалите строки в форме. А затем назначте заново. И вот мы получили "дырку" в серийных номерах или лотах. Реальная партионность ТАКОГО не прощает!!! |
|
21.05.2008, 13:05 | #6 |
Участник
|
Цитата:
Далее идем все по тому же стандартному документу и когда назначаешь свои номера (а в новой версии добавлены поля о доступности) - непонятна работа ни Серийных номеров, ни ЛОТов (см. рис "Serial No. Information 4"). Например, зачем мне показывать запись, которую я назначил предыдущей? Чтобы я еще раз выбрал случайно? Или чтобы акцентировать внимание на Доступном Кол-ве -1? Далее, я всет-аки решил подтвердить, что у меня праильно выбраны серийные номера и начинаю подтвердать (я не уже не акцентирую внимание на окне Serial No. List, хотя там такой же "беспорядок") и получаю, что Quantity (Base) обнуляется. Возникает вопрос - ЗАЧЕМ!?!? P.S. Например, нигде не указано, что операции типа "Серийный номер + ЛОТ" нужно начинать с серийного номера (я понимаю. что серийных номеров обычно гораздо больше, чем лотов, но вопрос остался открытым). P.P.S. Чтобы не постить новое сообщение - пишу тут: при использовании "Item Reclass. Journal" на окне "Serial No. List" точно такой же "беспорядок". Хотя бы фильтра на положительное значение наложили бы ... |
|
21.05.2008, 14:21 | #7 |
Участник
|
Цитата:
Вот, например, нумерация бухгалтерских документов, счетов-фактур идет по такому же принципу. И заметьте, за нарушение нумерации можно и штраф поиметь. |
|
21.05.2008, 14:26 | #8 |
Участник
|
Цитата:
Вот, например, нумерация бухгалтерских документов, счетов-фактур идет по такому же принципу. И заметьте, за нарушение нумерации можно и штраф поиметь. |
|
15.05.2008, 20:32 | #9 |
Участник
|
To Redfox
Чтобы использовать в маршрутах специальную себестоимость еденицы нужно в карточке ресурса проставить флаг Специальная себестоимость (specific unit cost). Тогда в каждом маршруте можно сипользовать свою стоимость. Честно говоря не понял в чем описанный тобой баг.
__________________
Want to believe... |
|
16.05.2008, 10:44 | #10 |
Участник
|
Цитата:
Вот именно, что тут идет речь не про Специальную Стоимость, а про стандартную, которая должна переносится с карточки Центра. Иначе это поле теряет всякую логическую нагрузку. P.S. Хотя этот "конструктор" рулит и от него много можно ожидать |
|
09.10.2008, 20:31 | #11 |
MCTS
|
Я код и посмотрел. Одним глазком. Прослезился.
Для спроса по пустому складу система делает запрос: а не существует ли SKU. И находит SKU для Красного склада! Лично мне кодить ничего не надо. Я хочу чтоб этот раздел стал адекватен. |
|
24.06.2009, 16:16 | #12 |
Administrator
|
+1 то ли к багам, то-ли к неадекватной логике...
финансовый журнал есть Клиент с кодом проекта ФОЛЬКСВАГЕН. есть Банковский счет БЕЗ КОДА ПРОЕКТА указываем клиента, он подставляет ФВ - ок, вопросов нет! меняем код проекта на ТАЙОТУ- сохраняет, вопросов нет! указываем банк - меняет код проекта на ФВ!!!!!! парни, это кошмар какой-то... придется отгрызать, пользователи "такой логики" не понимают. я, если честно, тоже. |
|
08.07.2009, 15:39 | #13 |
Administrator
|
Цитата:
Сообщение от Sancho
+1 то ли к багам, то-ли к неадекватной логике...
финансовый журнал есть Клиент с кодом проекта ФОЛЬКСВАГЕН. есть Банковский счет БЕЗ КОДА ПРОЕКТА указываем клиента, он подставляет ФВ - ок, вопросов нет! меняем код проекта на ТАЙОТУ- сохраняет, вопросов нет! указываем банк - меняет код проекта на ФВ!!!!!! парни, это кошмар какой-то... придется отгрызать, пользователи "такой логики" не понимают. я, если честно, тоже. SVG +1 к респектам! |
|
08.07.2009, 16:26 | #14 |
Участник
|
Цитата:
Сообщение от Sancho
+1 то ли к багам, то-ли к неадекватной логике...
финансовый журнал есть Клиент с кодом проекта ФОЛЬКСВАГЕН. есть Банковский счет БЕЗ КОДА ПРОЕКТА указываем клиента, он подставляет ФВ - ок, вопросов нет! меняем код проекта на ТАЙОТУ- сохраняет, вопросов нет! указываем банк - меняет код проекта на ФВ!!!!! |
|
08.07.2009, 19:15 | #15 |
Administrator
|
это была первая мысль. но приоритеты измерений на то и Default, что работают только с Default Dimensions, а измерения, установленные в строке журнала, живут в Journal Line Dimensions, или как ее там, и не настраиваются стандартным образом.
|
|
09.07.2009, 12:52 | #16 |
Участник
|
Извините, ну Вы пробовали их настривать?
|
|
09.07.2009, 21:02 | #17 |
Administrator
|
а зачем настраивать, когда можно перепрограммировать?
конечно пробовал. на картинке видно, что 81-й таблице НЕЛЬЗЯ дать высший приоритет, поскольку ее нет. |
|