[Solved] Баг при смене Глоб. Измерения. - Страница 3 - NAV: Администрирование

apanko · 24.06.2009, 00:00

Цитата:

Сообщение от RedFox

У нас есть Товар 1 (пользовался у себя товар 80206 - Кронус), у которого устнавнолено Reserve=Always
Продали его, а теперь пытаемся вернуть. Для Этого создаем (но не заполняем) Возврат и просто пытаемся копировать документ (чтобы типа сохранить все условия отгрузки для корректировки).
И получаем ошибку, что поле "Shipment Date" не заполнено (см. вложение). Но в исходном документе оно заполнено!!!

Тоесть система не копирует значения???

P.S. Читаю, что написано в про галочку "Include Header" - Place a check mark in this field if you want the program to copy the information from the document header you are copying to the document you are creating. The document lines will be copied whether or not there is a check mark in this field.

Любопытная бага. Я помещу ее в Антибаг если ты не против.

Хочу отметить, что НАВ shipment date в заголовок документа получателя копирует, но затем затирает (если документ-получатель является возвратом). Однако проблема не в заголовке. Если формировать документ вручную, то можно заметить, что shipment date заполняется в строках при вводе товара, не смотря на то, что заголовок пуст. А вот при копировании документа, хотя shipment date и копируется из строк-документа источника, затем он затирается значением из заголовка документа-получателя (а как я уже говорил, для возвратов туда принудительно устанавливается значение 0D).

Т.е. на первый взгляд проблема кроется в CU 6620 Copy Document Mgt. в функции CopySalesLine - не в том месте стоит END

Код:

IF ExactCostRevMandatory AND
   (FromSalesLine.Type = FromSalesLine.Type::Item) AND
   (FromSalesLine."Appl.-from Item Entry" <> 0) AND
   NOT MoveNegLines
THEN BEGIN
  IF RecalculateAmount THEN BEGIN
	ToSalesLine.VALIDATE("Unit Price",FromSalesLine."Unit Price");
	ToSalesLine.VALIDATE(
	  "Line Discount Amount",
	  ROUND(FromSalesLine."Line Discount Amount",Currency."Amount Rounding Precision"));
	ToSalesLine.VALIDATE(
	  "Inv. Discount Amount",
	  ROUND(FromSalesLine."Inv. Discount Amount",Currency."Amount Rounding Precision"));
  END;
//Считаю, что здесь должен быть END
  IF NOT CreateToHeader THEN
	IF ToSalesLine."Shipment Date" = 0D THEN BEGIN
	  IF ToSalesHeader."Shipment Date" <> 0D THEN
		ToSalesLine."Shipment Date" := ToSalesHeader."Shipment Date"
	  ELSE
		ToSalesLine."Shipment Date" := WORKDATE;
	END;
END;  //А здесь его быть не должно

В подтверждение можно включить флажок Точный Возврат Себестоимости и убедиться, что ошибка исчезнет. На мой взгляд Точный Возврат Себестоимости ни коим образом не должен быть связан с датой отгрузки (тем более в возврате она не несет никакой информационной нагрузки).

RedFox · 24.06.2009, 00:37

Цитата:

Сообщение от apanko

Любопытная бага. Я помещу ее в Антибаг если ты не против.

Я же ранее давал согласие на все баги в этой ветке

Цитата:

Хочу отметить, что НАВ shipment date в заголовок документа получателя копирует, но затем затирает (если документ-получатель является возвратом). Однако проблема не в заголовке. Если формировать документ вручную, то можно заметить, что shipment date заполняется в строках при вводе товара, не смотря на то, что заголовок пуст. А вот при копировании документа, хотя shipment date и копируется из строк-документа источника, затем он затирается значением из заголовка документа-получателя (а как я уже говорил, для возвратов туда принудительно устанавливается значение 0D).

Т.е. на первый взгляд проблема кроется в CU 6620 Copy Document Mgt. в функции CopySalesLine - не в том месте стоит END

Ну для себя я сделал немного другое изменение - обнуление "shipment date" только при условии, что не копируется заголовок (NOT IncludeHeader), так как меня не устраивает пустое значение в Заголовке Возврата (тоесть для меня неприемлема фраза "а как я уже говорил, для возвратов туда принудительно устанавливается значение 0D").
А вот с END ты может быть прав, но у меня признак для ExactCostRevMandatory не стоял

Я исправил так:

Код:

	IF "Document Type" IN ["Document Type"::"Return Order","Document Type"::"Credit Memo"] THEN BEGIN
	 IF NOT IncludeHeader THEN //RedFox
		"Shipment Date" := 0D;

apanko · 24.06.2009, 00:53

Перенес, спасибо.

**Sancho** · 24.06.2009, 16:16

+1 то ли к багам, то-ли к неадекватной логике...

финансовый журнал
есть Клиент с кодом проекта ФОЛЬКСВАГЕН.
есть Банковский счет БЕЗ КОДА ПРОЕКТА

указываем клиента, он подставляет ФВ - ок, вопросов нет!
меняем код проекта на ТАЙОТУ- сохраняет, вопросов нет!

указываем банк - меняет код проекта на ФВ!!!!!!

парни, это кошмар какой-то... придется отгрызать, пользователи "такой логики" не понимают.
я, если честно, тоже.

RedFox · 03.07.2009, 12:57

Цитата:

Сообщение от RedFox

Вот интересная "фича" от создателей

Вот поставил FP3 for NAV 5.0 RU и поссмотрел код триггера PrintRecords(ShowRequestForm : Boolean) для таблиц 12451 Item Receipt Header и 12454 Item Shipment Header.
Разница в коде просто впечатляет:
Вопрос - неужели трудно было ReportSelection."Excel Export" сделать для списания? Или народ считает, что всегда можно доделать или он там не нужен?

RedFox · 06.07.2009, 10:15

Иногда интересно поссмотреть код от создателей в CodeUnit'ах.
Например в данном примере проверяется сначала на общее совпадение заполнения параметров, а потом поотдельности.
Вопрос - зачем так сложно?

RedFox · 08.07.2009, 13:48

Цитата:

Сообщение от RedFox

Иногда интересно поссмотреть код от создателей в CodeUnit'ах.

Ещё немного об албанской логике... в NAV
В данном случае про ЛОТ:
У нас есть товар 80216-T и на карточке товара устанавливаем ОБЯЗАТЕЛЬНО резервировать. Делаем 2 документа покупки с лотами ЛОТ1 и ЛОТ2, например по 5 и 10 шт.
В заказе продажи делаем строку для 2 шт и система резервирует товар из ЛОТ1. Но с помощью Трасинга устанавливаем привязку к ЛОТ 2.
И в итоге 2 шт. товара из ЛОТ1 блокируется (по крайней мере у меня на Кронусе - не последний) до учёта документа.

Вопрос - ЗАЧЕМ так делается или почему?
Например, если резервируется и есть ЛОТ Но., то не делать привязку трассировки сразу? И если меняется Трассировка, то не менять строки резервирования?

**Sancho** · 08.07.2009, 15:39

Цитата:

Сообщение от Sancho

+1 то ли к багам, то-ли к неадекватной логике...

финансовый журнал
есть Клиент с кодом проекта ФОЛЬКСВАГЕН.
есть Банковский счет БЕЗ КОДА ПРОЕКТА

указываем клиента, он подставляет ФВ - ок, вопросов нет!
меняем код проекта на ТАЙОТУ- сохраняет, вопросов нет!

указываем банк - меняет код проекта на ФВ!!!!!!

парни, это кошмар какой-то... придется отгрызать, пользователи "такой логики" не понимают.
я, если честно, тоже.

на всякий случай, если кому надо, побороли, есть таблетка.
SVG +1 к респектам!

RedFox · 08.07.2009, 16:26

Цитата:

Сообщение от Sancho

+1 то ли к багам, то-ли к неадекватной логике...

финансовый журнал
есть Клиент с кодом проекта ФОЛЬКСВАГЕН.
есть Банковский счет БЕЗ КОДА ПРОЕКТА

указываем клиента, он подставляет ФВ - ок, вопросов нет!
меняем код проекта на ТАЙОТУ- сохраняет, вопросов нет!

указываем банк - меняет код проекта на ФВ!!!!!

А не пробовали использовать форму 543 Default Dimension Priorities ? Рисунок не меняется?

**Sancho** · 08.07.2009, 19:15

это была первая мысль. но приоритеты измерений на то и Default, что работают только с Default Dimensions, а измерения, установленные в строке журнала, живут в Journal Line Dimensions, или как ее там, и не настраиваются стандартным образом.

RedFox · 09.07.2009, 12:52

Цитата:

Сообщение от Sancho

это была первая мысль. но приоритеты измерений на то и Default, что работают только с Default Dimensions, а измерения, установленные в строке журнала, живут в Journal Line Dimensions, или как ее там, и не настраиваются стандартным образом.

Извините, ну Вы пробовали их настривать?

**Sancho** · 09.07.2009, 21:02

Цитата:

Сообщение от RedFox

Извините, ну Вы пробовали их настривать?

а зачем настраивать, когда можно перепрограммировать?
конечно пробовал.
на картинке видно, что 81-й таблице НЕЛЬЗЯ дать высший приоритет, поскольку ее нет.

RedFox · 13.07.2009, 10:42

Цитата:

Сообщение от RedFox

Например, если резервируется и есть ЛОТ Но., то не делать привязку трассировки сразу? И если меняется Трассировка, то не менять строки резервирования?

Вот ещё немного про Трассировки.
На тестовой базе настраиваем трассировку Lot Info. Inbound Must Exist для товара 80216-T и получаем "счастье" в виде ошибки.

Вопрос - как пользователю прописать данные в таблице 6505 чтобы можно было сделать учёт без захода на форму 6505 Lot No. Information Card, которая вставляет запись в эту таблицу?

apanko · 13.07.2009, 11:25

Цитата:

Сообщение от RedFox

Вот ещё немного про Трассировки.
На тестовой базе настраиваем трассировку Lot Info. Inbound Must Exist для товара 80216-T и получаем "счастье" в виде ошибки.

Вопрос - как пользователю прописать данные в таблице 6505 чтобы можно было сделать учёт без захода на форму 6505 Lot No. Information Card, которая вставляет запись в эту таблицу?

Не понял проблемы:
Если включить Lot Info. Inbound Must Exist, значит пользователь должен вводить данную информацию через Lot No. Information Card.
Если не ввел - получи ошибку.

Чесно говоря запись уже должна была существовать, судя по скриншоту, система бы не дала оприходовать этот товар.

RedFox · 13.07.2009, 14:40

Цитата:

Сообщение от apanko

Не понял проблемы:
Если включить Lot Info. Inbound Must Exist, значит пользователь должен вводить данную информацию через Lot No. Information Card.
Если не ввел - получи ошибку.

Ну связь нужно тут додумать, а не напрямую следует из функционала.

В твоём случае где-то должно существовать меню ввода эти Номеров ЛОТ & Серий. Например Покупки\Серийные номера или Покупки\ЛОТ

Цитата:

Чесно говоря запись уже должна была существовать, судя по скриншоту, система бы не дала оприходовать этот товар.

*Видать не внеслось редактирование или удалилось.*
Проблема в том, что я нажал "Присвоить &Лот Но." и обычно людям достаточно, если всё настроено правильно. А вот если хочешь менять

RedFox · 20.07.2009, 10:46

Цитата:

Сообщение от RedFox

Ну связь нужно тут додумать, а не напрямую следует из функционала.

В твоём случае где-то должно существовать меню ввода эти Номеров ЛОТ & Серий. Например Покупки\Серийные номера или Покупки\ЛОТ

Вот очередной "перл от разработчиков - они считают, что Item Tracking это только Serial No.. По другому это "творчество" не назовёшь?!?!
Всё началось с кода в 22 CU: - SetupSplitJnlLine(VAR ItemJnlLine2 : Record "Item Journal Line";VAR PostItemJnlLine : Boolean)

Код:

	  IF Item."Costing Method" = Item."Costing Method"::Specific THEN BEGIN
		Item.TESTFIELD(Item."Item Tracking Code");
		ItemTrackingCode.TESTFIELD("SN Specific Tracking",TRUE);
	  END;

А если я использую LOT, мне что, проверять не нужно? Сначала я подумал, что просто ошибся..
НО потом просто прошёлся по коду и в первом же месте - 27 таблица нашёл похожее (см Item Tracking Setup).
Неужели трудно было сделать что-то типа такого (см. Item Tracking Setup (new))?

P.S. Исправления в 27 таблице заняли менее 1 минуты

RedFox · 21.07.2009, 17:46

Цитата:

Сообщение от RedFox

А если я использую LOT, мне что, проверять не нужно? Сначала я подумал, что просто ошибся..

Вот решил немного поиграться в нерадивого или злобного пользователя и в резервировании заменил номер лота с ЛОТ0004 на ЛОТ0005 в таблице резервирования для 37 таблицы (см. файл LOT-Error-Posting.jpg). После постинга у меня в 339 привязка расходной операции была к ЛОТ0004 (см. LOT-Error-Posting-Result.jpg).
Вот Вам и новая "фича" для отложенного связывания в Трассировках.

P.S. Sorry, забыл скрины добавить

RedFox · 24.08.2009, 22:45

Цитата:

Сообщение от RedFox

И вот очередная ошибка по складу, любезно указанная _enjoy_.
Проблема:
Товар А хранится на складе в единицах изм. "PCS" в ячейке Х.
Затем продаётся в единицах изм. "BOX".
1. Создается Заказ Продажи с Товаром А в ед.изм. "BOX"
2. Из Заказа создаю складскую Отгрузку с Товаром А в единицах изм. "BOX".
3. Из Отгрузки создаю Подбор: беру Товар А в ед.изм. "BOX" из ячейки Х и кладу Товар А в "BOX" в ту же ячейку Х. Регистрирую Подбор.
4. Отгрузка не учитыватеся у т.к. в ячейке Х Товар А по прежнему лежит в "PCS" а не "BOX"
В настройках склада настроены все операции, кроме Расширенный Подбор и Размещение=Нет

Анализ ошибки: .... И мы получили счастье!!!

Вот пришлось провести анализ ошибки:

Косметические исправления в 2 кодеюнитах:
- Для изменения Единиц Имерения.

Код:

//--RedFox
//  IF Location."Directed Put-away and Pick" THEN BEGIN
//++RedFox
	WhseJnlLine.Quantity := "Qty. to Handle";
	WhseJnlLine."Unit of Measure Code" := "Unit of Measure Code";
	WhseJnlLine."Qty. per Unit of Measure" := "Qty. per Unit of Measure";
	GetItemUnitOfMeasure2("Item No.","Unit of Measure Code");
	WhseJnlLine.Cubage :=
	  ABS(WhseJnlLine.Quantity) * ItemUnitOfMeasure.Cubage;
	WhseJnlLine.Weight :=
	  ABS(WhseJnlLine.Quantity) * ItemUnitOfMeasure.Weight;
//--RedFox
{
  END ELSE BEGIN
	WhseJnlLine.Quantity := "Qty. to Handle (Base)";
	WhseJnlLine."Unit of Measure Code" := WMSMgt.GetBaseUOM("Item No.");
	WhseJnlLine."Qty. per Unit of Measure" := 1;
  END;
}
//++RedFox

- для создания Внутрених перемещений по складу:

Код:

  IF NOT Location."Directed Put-away and Pick" THEN BEGIN
	TotalQtytoPick := ROUND(TotalQtytoPick * QtyPerUnitofMeasure,0.00001);
//--RedFox
	IF Location."Always Create Movement" THEN
	  IF (WhseSource = WhseSource::"Movement Worksheet") AND (FromBinCode <> '') THEN
		InsertTmpActLnFromMovWkshLine(LocationCode,ItemNo,VariantCode,FromBinCode,
									  QtyPerUnitofMeasure,TotalQtytoPick,TempWhseItemTrkgLine,TotalQtytoPickBase);
//++RedFox

P.S. Последнее попозже причешу, чтобы не нарушать "красоту"..

RedFox · 26.08.2009, 15:44

Цитата:

Сообщение от RedFox

Вот пришлось провести анализ ошибки:

Российские документы нужно причесать.. Опять же пока только в записную..

P.S. + внутренние Перемещения восстановить

RedFox · 05.11.2009, 15:27

Цитата:

Сообщение от RedFox

P.S. + внутренние Перемещения восстановить

Вот взял EXPRESS и немного повозился..

Проблема 1: У нас есть товар, который продается не в базовых единицах измерения, а например в паре или блоком-спайкой (например пиво). Мы используем резервирование (трассировку). Для списания или оприходования в такой Единице Измерения возникает ошибка в том, что резервируется на кол-во, привязанное к 32 (а там у нас базовые единицы). Функционал базовых значений в 337 до конца «не работает» (мое мнение так же – нет смысла в нем, но поля присутствуют).

Решение - Единица Измерения при Резервировании:
ReserveItemDocLine.TransferItemDocToItemJnlLine(ItemDocLine,ItemJnlLine,ItemDocLine.Quantity) нужно заменить на
ReserveItemDocLine.TransferItemDocToItemJnlLine(ItemDocLine,ItemJnlLine,ItemDocLine."Quantity (Base)");

Проблема 2: Нельзя вставить Value Entry Relation - лечится вставкой кодеюнита в соответствующий КЮ учета (по моему мнению его вообще нужно сделать одним по аналогии с 80-ым).

Проблема 3: - Почему в списаниях нельзя работать с ячейками? Неужели трудно в CU 12460, 12461 добавить перенос поля ячеек в Item Journal или сделать списание так же по складу?? Почему не блокируется Расширенный склад тогда? Функционал совсем не работает нормально со складом, хотя сделать это не совсем сложно (вместо того, чтобы плодить КЮ).
Я конечно доделал у себя, но общей идеи не понятно (почему нельзя списывать со склада?? Неужели склад должен быть даже без "ячеек")? Или это только списание документа для простых реализаций? Тогда есть документы типа Inventory PutAway&Pick (если надо, то могу проконсультировать.. просто хочется нормальный функционал в следующей версии).

Проблема 4: Неужели сложно сделать нормальный LookUp для формочек. Или это формы только для просмотра и без возможности выбора?? Пример решения подсмотреть можно на Заказах.