NOTE: The primary key for this table is ItemCode, SupplierCode, WarehouseCode, ShipFromCode
ISSUE 1: (CB ticket 595692)
After importing item/supplier records, if the ShipFromCode is not under the SupplerCode, the CB client will CRASH. The import Manager should validate the imported data to the degree the data will be valid after the import. The defect is the import manager does not validate that the ShipFromCode is under the SupplierCode.
ISSUE 2:
(a) The "Priority" value must be 0 for all item/supplier rows per supplier except for one, the primary supplier. This import allows you to create multiple suppliers flagged as "Priority" which will CRASH the CB client
(b) The "Priority" supplier must be loaded first because the import automatically flags the first supplier
as the primary, then if you flag a subsequent supplier as the primary, then you will have two, as the import does not clear
the first one. This is the defect.
WORDAROUND: Create the input file so the primary supplier is first to import
(c) The "Priority" column is not on the InventorySupplier table as you would expect, it is on table InventorySupplierPricingLevel
column IsPriority (and if you have multiple pricing rows for the primary supplier, all of those rows
as flagged as primary)
(d) After loading, you can check to confirm if you have an issue, this query should return zero rows (only works if you have one UOM per item, if you have multiple UOM per item that will return rows for valid conditions)
select count(a.IsPriority) AS ISPriority, a.ItemCode, b.ItemName
from InventorySupplierPricingLevel a
left join InventoryItem b on a.itemcode = b.ItemCode
where ispriority = 1
group by a.ItemCode, b.ItemName
having count(a.IsPriority)>1
order by ISPriority desc
ISSUE 3:
This import also creates default InventorySupplierPricingLevel rows.
It populates these rows with "DateFrom" and "DateTo" seemingly incorrectly.
These values do not show up on the screen, not sure if they are considered.
When entering data in the UI, those dates are always NULL
Set all of these dates to NULL after import
ISSUE 4:
Performance of the validate is terrible over when a large number of rows are involved. I assume an index is missing on one of the tables (or temp tables) causing the validate time to explode.
9,000 input rows takes a few minutes to validate
10,000 input rows takes 15 minutes to validate
20,000 input rows takes 1 hour to validate
ISSUE 5:
It is required that you join in the CB database in order to get the data needed to build the file. This is because it requires the CB ship from code, ship from name, and ship from address. It does not accept legacy codes. Therefore, it is impossible for the legacy system consultant to produce this file on their own using legacy codes for the mapping.
ISSUE 6:
The ship from name is required in this file, which should not be the case. Here are some factors:
(a) The table contains a duplicate copy of the ship from name and address (from older design?), so this seems to be one reason, I assume these are not longer used by the CB client.
(b) The import does not create a new ship from.
(c) The import does match to an existing ship from using ship from name, which is problematic as a field for matching.
(d) When the user updates the ship from in the CB client, this copy of the ship from name and address is not updated
(e) The ShipFrom Legacy Code should be used for matching and validation
NOTE: The primary key for this table is ItemCode, SupplierCode, WarehouseCode, ShipFromCode
ISSUE 1: (CB ticket 595692) After importing item/supplier records, if the ShipFromCode is not under the SupplerCode, the CB client will CRASH. The import Manager should validate the imported data to the degree the data will be valid after the import. The defect is the import manager does not validate that the ShipFromCode is under the SupplierCode.
ISSUE 2: (a) The "Priority" value must be 0 for all item/supplier rows per supplier except for one, the primary supplier. This import allows you to create multiple suppliers flagged as "Priority" which will CRASH the CB client (b) The "Priority" supplier must be loaded first because the import automatically flags the first supplier as the primary, then if you flag a subsequent supplier as the primary, then you will have two, as the import does not clear the first one. This is the defect. WORDAROUND: Create the input file so the primary supplier is first to import (c) The "Priority" column is not on the InventorySupplier table as you would expect, it is on table InventorySupplierPricingLevel column IsPriority (and if you have multiple pricing rows for the primary supplier, all of those rows as flagged as primary) (d) After loading, you can check to confirm if you have an issue, this query should return zero rows (only works if you have one UOM per item, if you have multiple UOM per item that will return rows for valid conditions) select count(a.IsPriority) AS ISPriority, a.ItemCode, b.ItemName from InventorySupplierPricingLevel a left join InventoryItem b on a.itemcode = b.ItemCode where ispriority = 1 group by a.ItemCode, b.ItemName having count(a.IsPriority)>1 order by ISPriority desc
ISSUE 3: This import also creates default InventorySupplierPricingLevel rows. It populates these rows with "DateFrom" and "DateTo" seemingly incorrectly. These values do not show up on the screen, not sure if they are considered. When entering data in the UI, those dates are always NULL Set all of these dates to NULL after import
ISSUE 4: Performance of the validate is terrible over when a large number of rows are involved. I assume an index is missing on one of the tables (or temp tables) causing the validate time to explode.
9,000 input rows takes a few minutes to validate 10,000 input rows takes 15 minutes to validate 20,000 input rows takes 1 hour to validate
ISSUE 5: It is required that you join in the CB database in order to get the data needed to build the file. This is because it requires the CB ship from code, ship from name, and ship from address. It does not accept legacy codes. Therefore, it is impossible for the legacy system consultant to produce this file on their own using legacy codes for the mapping.
ISSUE 6: The ship from name is required in this file, which should not be the case. Here are some factors: (a) The table contains a duplicate copy of the ship from name and address (from older design?), so this seems to be one reason, I assume these are not longer used by the CB client. (b) The import does not create a new ship from.
(c) The import does match to an existing ship from using ship from name, which is problematic as a field for matching. (d) When the user updates the ship from in the CB client, this copy of the ship from name and address is not updated (e) The ShipFrom Legacy Code should be used for matching and validation