Неверное соотношение UOM и UOM в Pick Ticket

Question

Мы используем преобразования UOM на этом клиенте. Мы продаем в Eaches и продаем в чехлах. Проблема, с которой мы сталкиваемся с билетом Pick, заключается в том, что как количество, которое нужно выбрать, так и выбранное UOM являются единицей снабжения, а не единицей продажи. Например, клиент заказывает 73 короба (12 шт. за коробку). Пикетный билет печатает 876 каждый. Это требует от сотрудника склада поиска каждого товара, определения наличия UOM и соотношения продаж и последующего ручного преобразования 876 эша в 73 случая.

Очевидно, что билет выбора должен печатать 73 случая. Но я не могу найти способ сделать это. Предметы распределяются по лотам, и в случае из 73 случаев может быть 50 случаев для лота A и 23 случая для лота B. Это представлено в таблице SOShipLineSplit. Количества и единицы измерения в этой таблице основаны на единицах складирования.

В идеале, я мог бы присоединить таблицу INUnits к таблицам SOSHipLine и SOShipLineSPlit. См. Ниже.

Select  case when isnull(U.UnitRate,0) = 0 then S.Qty else S.Qty/U.Unitrate end as ShipQty
,case when isnull(U.UnitRate,0) = 0 then s.uom else U.FromUnit end as UOM
from SOShipLineSplit S 
inner join SOShipLine SL
ON S.CompanyID = SL.CompanyID and s.ShipmentNbr = SL.ShipmentNbr and  S.LineNbr = SL.LineNbr and S.InventoryID = SL.InventoryID
Left Outer Join INUnit U
On S.CompanyID = U.CompanyID and S.InventoryID = U.InventoryID and s.UOm = U.ToUnit and SL.UOM = U.FromUnit
where S.ShipmentNbr = '000161' and S.CompanyId = 4

Проблема в том, что программа составления отчетов Acumatica не поддерживает объединение с несколькими таблицами.

Left Outer Join INUnit U
On S.CompanyID = U.CompanyID and S.InventoryID = U.InventoryID and s.UOm = U.ToUnit and SL.UOM = U.FromUnit

Я полагаю, что я что-то упустил. Это не может быть единственный клиент, использующий Acumatica, который использует единицы измерения продаж. Могу ли я использовать другую таблицу, которая будет содержать количества и единицы измерения, уже преобразованные для этого заказа в Единицы продажи?

Или другое решение?

Заранее спасибо. погладить

Answer 1

РЕДАКТИРОВАТЬ:

Если целью является отображение точных количеств до / после преобразования, то INUnit DA C использовать нельзя. Он не хранит исторические данные, вы можете изменить значения INUnit после того, как заказ будет завершен, поэтому повторное использование его для вычисления количеств не даст точных результатов.

Для этого сценария вам потребуется использовать исторические данные поля с Base префиксами, такими как ShippedQuantity / BaseShippedQuantity. Если вам требуется хранить больше исторических данных, вам нужно добавить настраиваемое поле для хранения этих значений и обновить их при создании / изменении отгрузки.

---

Основной проблемой является логическая ошибка в требовании :

Проблема заключается в том, что таблицу INUnit необходимо соединить с ОБА таблицами SOShipLine и SOShipLineSplit.

INUnit DA C имеет одного родителя, а не 2, поэтому вам нужно изменить свое требование, чтобы отразить это ограничение.

Если значения SOShipLine и SOShipLineSplit различаются, вы никогда не получите никаких записей.

Если они идентичны, объединять оба эти параметра не нужно, поскольку они имеют одинаковое значение.

---

Я предлагаю добавить 2 соединения, одно для SOShipLine и другое для SOShipLineSplit. В отчете вы можете выбрать, какой из них отображать (1-й, 2-й или оба). Вы также можете добавить условия видимости или условие формулы IIF в отчет, если хотите обработать проверку ошибок нулевых значений для цели отображения.

Используйте свойство Child Alias ​​в построителе схемы, чтобы присоединиться к одной таблице 2 раза без конфликтов имен , В формулах отчета (для отображения поля или в условиях формулы) используйте также имя таблицы «Псевдоним ребенка».

Пример: