|
20.05.2008, 17:01 | #1 |
Участник
|
Следующая фича только под Native (на SQL видать сортировака по другому) - при попытке открыть форму Shipment на Native (на SQL все ОК) на 5.0 (+4.0 SP2 RU) выдается сообщение. Повторилось на нескольких базах, вплоть до 5.0 SP1:
|
|
21.05.2008, 12:43 | #2 |
Участник
|
Как и обещал - продолжаю про Серийные Номера и ЛОТы (и уже включая 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 | #3 |
Участник
|
Цитата:
Далее идем все по тому же стандартному документу и когда назначаешь свои номера (а в новой версии добавлены поля о доступности) - непонятна работа ни Серийных номеров, ни ЛОТов (см. рис "Serial No. Information 4"). Например, зачем мне показывать запись, которую я назначил предыдущей? Чтобы я еще раз выбрал случайно? Или чтобы акцентировать внимание на Доступном Кол-ве -1? Далее, я всет-аки решил подтвердить, что у меня праильно выбраны серийные номера и начинаю подтвердать (я не уже не акцентирую внимание на окне Serial No. List, хотя там такой же "беспорядок") и получаю, что Quantity (Base) обнуляется. Возникает вопрос - ЗАЧЕМ!?!? P.S. Например, нигде не указано, что операции типа "Серийный номер + ЛОТ" нужно начинать с серийного номера (я понимаю. что серийных номеров обычно гораздо больше, чем лотов, но вопрос остался открытым). P.P.S. Чтобы не постить новое сообщение - пишу тут: при использовании "Item Reclass. Journal" на окне "Serial No. List" точно такой же "беспорядок". Хотя бы фильтра на положительное значение наложили бы ... |
|
30.05.2008, 15:50 | #4 |
Участник
|
Item Charge Granule:
Просто решил удалить строку с издержками, которая на "пол-пути" заполнения стала просто не нужна и получил ошибку. Ошибка ОЧЕНЬ простая, но удивила последовательность операци: OnDelete() вызывает - VALIDATE(Quantity,0), а затем цепочка: VALIDATE("Line Discount %"), UpdateAmounts; UpdateItemChargeAssgnt и далее производится расчет ItemChargeAssgntSales."Unit Cost". Вопрос - ЗАЧЕМ это мне все нужно делать при удалении, например, перерасчитывать сумму? |
|
30.05.2008, 19:05 | #5 |
Участник
|
Не знаю, баг или нет, но поле НЕ меняется в соответствии с Hepl'ом после изменения значений в заголовке.
|
|
04.06.2008, 12:50 | #6 |
Участник
|
Вот залез в Replenishment часть и обраружил инетерсую штуку - все расчеты ведутся по SKU и как только для товара без SKU нужно сделать расчет по складам, система автоматом преходит в режим LOT-TO-LOT (Reordering Policy = Lot-for-Lot) (Кстати, все это, оказывается написано в help, раздел - Planning for Locations without Using SKU).
У меня вопрос - ЗАЧЕМ?? городить кучу параметров, которые в итоге можно просто забыть?? И тем более в доках писать то, что НЕ работает корректно!!! Правка не сильно объемная, но все же... P.S. для примера см последовательно рис. Task, Description и что есть в системе - Real value. |
|
05.06.2008, 11:58 | #7 |
Участник
|
Просто решил проверить доку перед поездкой и получилось весело:
- строки в таблице внесены некорректно, тоесть нет промежуточного заголовка для заполнения полей; - может мне кто-нибудь сможеть объяснить такую сложную формулу (см. двойную красную обводку). P.S. Глянул для версии 4.0 и 5.0 - результат одинаковый |
|
09.10.2008, 19:31 | #8 |
MCTS
|
Цитата:
Сообщение от RedFox
Вот залез в Replenishment часть и обраружил инетерсую штуку - все расчеты ведутся по SKU и как только для товара без SKU нужно сделать расчет по складам, система автоматом преходит в режим LOT-TO-LOT (Reordering Policy = Lot-for-Lot) (Кстати, все это, оказывается написано в help, раздел - Planning for Locations without Using SKU).
У меня вопрос - ЗАЧЕМ?? городить кучу параметров, которые в итоге можно просто забыть?? И тем более в доках писать то, что НЕ работает корректно!!! Правка не сильно объемная, но все же... P.S. для примера см последовательно рис. Task, Description и что есть в системе - Real value. 1. чтобы для этого товара не существовало единиц складского учета (по крайней мере они не должны попадать в фильтр планирования) 2. надо снять флаг Склад Обязателен в Товары Настройка. 3. в поле Компоненты по складам в Производство Настройка, должно быть пусто. Полное несоответствие с WhitePaper'ами подтверждаю. (Так и не смог добится, чтобы система проигнорировала строку для пустого склада и не создавала действий) Цитата:
Demand at Blank Location
Even if the Location Mandatory field is selected, the program will allow demand lines to be created without a location code, also referred to as blank location. This is a deviation for the system because it has various setup values tuned to dealing with locations (see above) and as a result, the planning engine will not create a planning line for such a demand line. Смог. В карточке товара политика дозаказа должны быть пустой. |
|
21.05.2008, 14:21 | #9 |
Участник
|
Цитата:
Вот, например, нумерация бухгалтерских документов, счетов-фактур идет по такому же принципу. И заметьте, за нарушение нумерации можно и штраф поиметь. |
|
21.05.2008, 14:26 | #10 |
Участник
|
Цитата:
Вот, например, нумерация бухгалтерских документов, счетов-фактур идет по такому же принципу. И заметьте, за нарушение нумерации можно и штраф поиметь. |
|