In Order Entry billing screen, if the freight amount is zero, then the order freight account is blank by default. In some situation, external application like Starship (a third pparty shipping manifest system) can write freight amount back to Elliott order header field. It has no logic to update the order freight account.

As a result, when you bring up order billing screen, you can see there's a freight amount, but there's no freight account associate with it which look odd. However, this is more an aesthetic issue because during COP Sales Journal for posting the invoice, system will see the freight account is blank, then system will find the proper freight account and use that for posting. So this is not an error condition.

So it is suggested that during order entry, even if the order freight amount is zero, Elliott will still populate the order freight account anyway to prevent the aesthetic issue when Starship perform freight back to Elliott order freight amount field.

If multiple users run sales order import at the same time as another user or a scheduled deferred processing job they will often lock up one another or the deferred processing job will lock and need to be reset.

There should be a way to avoid the lockups.

Straight from the man himself:

I think there’s a few areas we can look into:
(1) We need to have a mechanism for the defer processing not to lock up and just skip the job with printing something like “Sales Order Import Skipped Due to CPIMPHDR work file is in used by other users” on the report.

(2) We need to check when sales order import close the work files. We probably should close the work files in the beginning of the closing-procedure paragraph, before closing the printers. I said this because it seems USER is hugging this CPIMPHDR file for a long time. Probably he is just looking at the import result on the screen. If we close CPIMP*.BTR files before displaying the report on the screen, then this issue will less likely to happen.

We have never been able to remove a line item off of an order in Order Entry if there's a restricted attribute on that item. For instance, let's say there is an existing order and a restricted attribute has been added to a certain product line, etc. that prevents that customer from ordering it. The order will get thrown on hold at the time of a picking ticket. If we go into that order in Order Entry to delete it, it won't allow us into that line item. The only way to remove it is to take the restricted attribute off of the item or customer, remove the item(s), and then remember to put the attribute back on. It would be nice to be able to remove that line item without going through multiple steps.

It has been suggested that Elliott should support importing of shipment tracking number for sales order through CSV File. The CSV file should contain the following fields:
Order# String Sample 123456 (pad leading zero if numeric)
Package# String Sample 1
Tracking# String Sample 1Z92752E0300860395
Weight String Sample 1.00
Freight Amount String Sample 15.23
Ship Via String Sample UPS Ground
Ship Date/Time String Sample 8/23/2017 1:00:00PM
Reference String Sample 123456789

Not all fields need to be provided. Only the Order# and Tracking# is necessary. If the Package# is not provided, then it is assume 1. If the weight is not provided, then it won't be written to note, same for freight. If Ship Via is not provided, then we look up the ship via description of the order. If Ship Date/Time not provided, we use the current system date/time. Reference is to update Note Subject. It can be blank.

We need to prevent duplicate note. Therefore, if there are multiple records for the same sales order, then we may need to add 1 second to time until no duplicate value.

The import screen shall prompt for:
CSV File Pathy & Name:
Does Import File Has A Header Row?
Note Type: (Blank Allow)
The above value will be saved and used for the next session default.

When printing a PO with cancelled line or lines, the presentation is misleading and might cause an error on the vendor side. As we know Elliott print Cncl literal on cancelled lines but shows the quantity and the line total amount. The lines are not added to the total but I don't think its is enough, After cancelling the line, user cant even access field 19 and enter a comment. I think that the qty should be presented as 0 and the total line as zero. This is an old Macola behavior that we lived with and maybe it is time to change. If I am not correct the explanation was that we want to show the vendor what was originally on the line. The risk of the vendor sending a cancelled line, doesn't justify it.

When doing Order Import, Netcellent introduced new flags, 26 and 27 that handles the move of a file with errors to a different folder, this is a good feature. For good files. Elliott deletes the import file. My understanding from a conversation with Mark is that this logic of NOT archiving the import file is because of the assumption that the file already created in an EDI system and exists there. But if the import is NOT from EDI (maybe the partner created it in the required format), forcing the user to save it in 2 places is an extra step. I suggest to add 2 flags, "Move good files to a folder?" and the folder location. If user answer N to the first question continue to delete the file, but user will be able to save the import file. There is a point of the file name (in case the same file name is used), so adding a date-time stamp to the file name will prevent overriding previous files. Thanks.