Add Stocking & Selling to Stock Ratio to Order and Invoice Line Item Database.

Currently, the line item qty match the line item UOM. On the other hand, the line item selling price is always in stocking UOM. Line item does not store selling to stocking ratio in line item and depend on the item master. If the item master selling UOM and ratio should change in the future, this can cause problem. See the following KB article: https://support.elliott.com/knowledgebase/articles/2011331-the-impact-of-changing-item-selling-unit-of-measur

It is suggested that we should store the selling ratio in the line if user should use selling UOM. This will prevent potential future problem.

In Elliott V9, we will incorporate all custom mod required database changes into the standard database. Custom mod data fields or tables will be visible in Elliott user interface through Global setup flag. It is important that we maintain one standard database with one setup of standard DDF without customization. We should speak with CyberMac to incorporate their database as well. This change is necessary if we should move toward to fully utilize relational database.

Need an index to quickly identify of a PO line item by item number with date so we can quickly see if this PO line item is the last PO for this particular item and hence allow to update item vendor "6. Last Purchase Cost" in the PO changed mode. We currently do not update "6. Last Purchase Cost" field even if the PO line item FOB cost is changed because we don't know if the PO line item is the latest PO for this item.

Note: This was requested in Version 8.x but there is not filler space available.

AP Transaction Processing - Add distribution level reference

Currently, AP Transaction Processing allows the entry of a Voucher Reference, which ultimately carries through to APDSTHST.APDSTHST_VOUCHER_REF for every distribution made against that voucher.

Propose adding a distribution level reference, allowing a unique reference to be added for each distribution made against a voucher.

Add APTRXDST.NEW_AP_DIST_REF
Add APDSTHST.APDSTHST_DIST_REF
Add both references to resultant APDISFIL record.

Expand AP Invoice Import Utility Detail Record Layout to include DIST_REF.

This is particularly useful when processing vouchers for credit card statements - which often contain a variety of charges which may require/benefit from a unique reference per distribution, as opposed to the single reference from the voucher entry itself.

The workstation ID field in PRINTWIN table should be expanded beyond current 10 digits. This is because sometime the workstation ID can be Loc+Workstation ID, or sometime it can be 2 Digits Form+Workstation ID. Both scenario make them 12 digits. So the Workstation ID is truncated after 8 digits. If you name the workstation in such a way so it may duplicate if using the first 8 digits, then this can cause printing problem.

Allow Misc. Charges on COP to be 6 digits and 2 decimals (currently maximum of 99999.99).

Elliott Price Code is very flexible. However, there are users suggested that Elliott should offer solution to make the pricing easier to maintain. So we are thinking of the following two solutions:

Solution 1 – Split Price Code Tables into Two
We will need to split the price codes into two tables:
(1) Price codes, which support price code 1 – 8. Pricing is not setup in price codes, instead price codes point to pricing policy table.
(2) Pricing policy. Setup pricing, including discount, price, markup, minimum price, and the quantity break pricing (if any).
You can have multiple price codes records per pricing policy.

Think of the idea this way, we can break up the top part of the price code file maintenance (customer type) into the “price code” table. We then break the pricing part (including item number, pricing, discount/marktup/price/min-price) into the pricing policy table. Then we link them to gether.

So when you are going to change pricing, you only need to change the pricing policy table, and no need to change price code table. If you want to add ore remove a customer type from a pricing policy, then change the price code table and no need to change pricing policy.

Solution 2 – Add More Price Fields into Item Master
The other solution is we can also add maybe 3 level pricing into the item master, so you can have the following price:
1. Item Price
2. Item Price 1
3. Item Price 2
4. Item Price 3
5. Item Minimum Price
Then when you setup the price code, you can indicate that your pricing is:
Discount (Base on Item Price)
Fixed Price
Markup (base on item cost)
Minimum Price
Item Price 1
Item Price 2
Item Price 3
If you don’t use Fixed Price, then when you change the price in the future, you just change the item’s price fields above. You only change the price codes if certain customers, or customer types need to be changed to apply to a different level of price.

Support 5 additional search keys of the attribute of customer, items, ship-to...etc.

Improve the lot number tracking capability per Avi. Create the database that will be capable of doing that first. Then gradual add the ability down the road.

SYZIPCDS table primary key is a 5 digits zip code. The maximum size is 5 digits. Canadian postal code is in the format is of “XXX XXX”. At this moment, Elliott can’t populate Canadian postal code to SYZIPCDS table due to the database incompatibility. I suggest to change the table in version 9 so Canadian zip codes will be supported.

We should probably consider adding volume information to the bin master level so we can determine how full a bin may be. The volume information including cubic feet, length, width, height? Also, a lot of time, the pallet size is important too. In many case, what's store at the bin is pallet, not the indivisual item. Not sure where to put that information.

Item packaging Length, Width and Height should be added to the item file as well. This could be used for future use in the WMS and other external applications

It will be nice to have more characters in the Job Number field but we would like to have the field to be alpha-numerical as well.

Material Cost Type should be expanded by at least 1 (potentially 2, consistent with Product Category expansion).

Add a FIPS County Code. With the increasing demand to pay sales tax for nation wide transactions (as far as I know now apply to CA, IL, OH and AL) and the need to report total sales by jurisdiction, and the assumption that we will NOT have all the possible jurisdictions in Elliott, we need to capture the FIPS code. This is available now using the zip code database but there is no logic to attach it to the order. Edward, I am using the Job field to capture it for the Amazon orders' import, but it will be nice to add a unique field. When running the Sales tax liability report, we can subtotal by juristriction which is required by the sales tax portals.

Increase COP Ship To to 6 characters. With more businesses selling nation wide through Amazon, Groupon etc. and with a need to trace these different ship to's we need a bigger field size. The current 4 characters field size allows 1,679,616 combinations if you use numbers and letters. Cybermac has the logic to create Ship to codes for these combinations. This looks as a big number but with a realistic 2000 orders per day it will not hold for very long time.

Someone suggested that the Freight Account should be removed from the Order Billing Screen and the invoice posting should always get the freight account from ship via code setup.

Currently, the freight account is determined at the time of entering the Order Billing Screen. It default to the freight account in the ship via code. One Elliott user choose to access billing screen during regular order entry. But they don't know the ship via code yet at the time of order entry, so they use a generic ship via code, and result the billing screen use the generic ship via code freight account. Later on, the ship via code is changed before the order is shipped. But the freight account in order header stay the same.

So it is suggested that Elliott should always determine the freight account base on Ship Via code on the order header upon invoice posting. If that is the case, then we should not even store freight account in order header file at all. We are evaluating whether we should remove freight account from order header file or not. Please comment and let us know your opinion.

Add item boxed height, width and length into item file for future use. The volume field does not give an accurate representation of the item to calculate DIM weights or determine packaging in any future enhancements.

Regarding Sheryl Manz's comment on 6/6/17 4:40AM, we do intend to introduce 12 months accumulator fields for customer, vendors and some other master table. This will be similar to the 12 months accumulator in IMLOCHST (I/M Location History).

I would like to see accumulators in addition to PTD and YTD - Monthly and QTD accumulators for customers, slm, vendors, items, etc. I also think there could be some Elliott reports for these new accumulator fields.