Now that we implemented multi-bin with I/M Inventory Transfer Processing. We like to know if we can have information displayed of the order in COP Order Inquiry screen. Currently, it only show me if the order is picked (after picking ticket printed), billed or invoiced. I like to know if the order is:
* actually in picking (the transfer ticket was generated);
* they have moved from the bin locations to the "ship" bin location;
For example, if the transfer ticket is printed, we can show one "*" beside the Date Picked field. If the transfer batch is completed or posted, then we show two "*" beside the Date Picked field. See attached sample screen.

If a customer has an EDI Partner profile setup, general speaking, they would (1) need a valid PO number; (2) need the PO number be less than 22 digits because that's standard EDI limit.

For (1), we should setup a flag in EDI trading partner profile to indicate whether PO number is required or not. For (2), it is safe to assume that if the EDI trading partner profile is setup for the customer, then the PO length should not exceed 22 digits. Currently, Elliott allow 25 digits PO number.

The implementation should apply to the following areas: (a) COP Order Entry; (b) COP Copy/Consolidate Order; (c) COP Sales Desk. We probably do not need to apply to Sales Order Import or web services because we can assume the original data should not have this issue.

We can look at the existing coding and implement changes by following CHECK-DUP-PO paragraph.

Currently, when print packing list, the total weight is always printed at the the bottom of the packing list like:
TTL WEIGHT - 999,999.999
It has been suggested by some users that the total weight in Elliott is not necessary correct due to various reasons. Therefore, it would be desirable if the packing list does not print total weight. We could potentially introduce a global setup flag for this purpose. If we should make this change, this flag should apply to both regular packing list, as well as packing list by box.

Please let us know how do you feel about this change.

Currently, most of the locking conflicts in Elliott come from user going to item or customer file maintenance change mode. User keep the change record on the screen without releasing it. This can happen when the user is interrupt with a phone call, or has to take a break. This however, causing extensive locking for other users who need to update the item or customer record and wait have to wait in the locking loop until this record is released.

It is suggested that we should consider implementing phantom locking on Item and Customer in the change mode to avoid locking conflict. Just as an example, the phantom locking for item table work as following:
(1) User bring up item A in item file maintenance change mode. Traditionally, the item A will be locked at this moment. With phantom locking, there's no lock on item A. However, we will keep a copy of the record A as the original value.
(2) User 1 change the item A and save it. However, before saving it, system will read item A with lock, then compare if the record is different with the original value.
(3) If the record value is the same, then system will proceed with the change and save the record, and release the lock.
(4) If the record value is not the same, then system will warn user that the record had been changed by someone else while trying to change the record and retry it again, and release the lock without making changes.
(5) Since the time it takes from (2) to (3) or (4) is only a split of a second (because there's no users interface), the locking burden is minimal which will greatly reduce the potential locking conflict.

In theory, all master file maintenance can create a locking conflict stated above. But, base on our experience, so far the areas that more likely to cause the conflict is customer and item file maintenance. Therefore, we suggest to address these two areas first. Let us know if you are interested for us to support something like this.