Currently, Elliott decide PO's Default FOB Cost base on the following priority sequence:
(1) If Vendor Item record exist and set to use "Price Table", then Price Table will be used;
(2) If PO Setup "20. Default FOB Std Cost On PO's" is set to "Y", then default to Item Std Cost;
(3) If Vendor Item Record Exist, use the Vendor Item Last Purchase Cost;
(4) Use Item's Last Cost.

It had been suggested that we should modify the flag "20. Default FOB Std Cost On PO's ?" to "20. Default PO FOB Cost Method ?" and the possible value can be:
Y=Std Cost; L=Last Cost; N=Vendor Item Last PO Cost before Last Cost

Y or N value follow the priority sequence (1) - (4) above. If user choose "L", then it will affect the priority sequence for (2) - (4).

In addition, we should change the logic that we use to update item vendor last cost field. Currently, the logic is update it when a PO is added, or the line item is added. But we don't update it if the PO or line item changed. This is to prevent an PO changed, canceled from updating the item vendor last cost field. But it some case, we could update the PO line item expected cost and like new cost be reflected in PO item vendor file. So it is suggested that we should add a new field ITEM-VEND-LAST-COST-FROM-PO which is an 8 bytes field to store the PO# that cause the update of ITEM-VEND-LAST-PUR-COST. Then during PO printing for change PO (& line items), we will compare the vendor item file ITEM-VEND-LAST-COST-FROM-PO if match with the current printing PO. If yes, then proceed with the update if ITEM-VEND-LAST-PUR-COST, otherwise skip it.

AP Transaction Processing - Add distribution level reference

Currently, AP Transaction Processing allows the entry of a Voucher Reference, which ultimately carries through to APDSTHST.APDSTHSTVOUCHERREF 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.NEWAPDISTREF
Add APDSTHST.APDSTHSTDIST_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.

Currently, user is allowed to defined a note type with literal. In the example provided below, we have a note type "S" with literal. When we create a note with note type S, the literal is really not part of the note even though the literal is displayed. What I really like is the ability to define a note type with literal with the option "28. Put Literal in Note Body" The default is "N". But if user set this flag as "Y", then when a note is created, the literal is part of the note body. The main benefit of doing it this way is that (1) We can then use free flow text in note which support copy and paste. In many case, I need to copy an email content to the note for documentation purpose so other people can see it too; (2) The printing of note will not skip note because a line with literal is blank.

Currently, Elliott allow defining sales and COGS account by location and product category. We are facing with the following complaints:
(1) User only want to define sales account by product category, not by location. Because of the fix structure, user will have to define all combination of locations and product categories which is a burden.
(2) Sometime user may miss a combination, as a result the sales and COGS go to the default account causing reconciliation problem. System should make it easier to find potential missing setup problem.
(3) Some users want to define sales and COGS account by customer (customer type) instead of product category.

Therefore, we are proposing the following changes in Elliott V9 to make it easier and flexible for the user to define sales & COGS account in Elliott. Our thinking is we can come up with a replacement for Product Category/Location account file (CPPRDACT.) The new file CPSLSCOG will support all combinations of the following 3 variables:
Location
Product Category
Customer Type
We will have the following combinations:
1 = Location/Product Category/Customer Type
2 = Location/Product Category
3 = Location/Customer Type
4 = Product Category/Customer Type
5 = Location
6 = Product Category
7 = Customer Type
In the Global Setup, we will ask the default combination code to determine Sales and Cost of Good Sold. If it is not setup, it is considered “2 = Location / Product Category” which is like the current feature. We will need to handle the conversion from 7-8 database to 9.0 accordingly. The new database CPSLSCOG (COP Sales & Cost of Good Account File) will replace CPPRDACT file and will have the following fields as primary key:
Product Category Primary Key
Location Primary Key
Customer Type Primary key
User can only choose one code in global setup. For example, if user choose “7 = Customer Type”. Then the data entry for “Sales & Cost of Goods Account File” will only prompt for “Customer Type”. The value for Location and Product Category will always be blank.

User is allowed to change their sales and cost of goods account combination code from one to the other. For example, if they wish to change from code 7 to code 3. Then when they go to the user interface, system will prompt for Location and Customer Type. But system is not going to delete the old code 7 record automatically just in case user may want to change it back, or maybe still want to reference the old setup. The old codes is now become invalid, but will not cause problem staying in the database.

The printing of the edit list will allow the following parameters:
1. Starting Location
2. Ending Location
3. Starting Product Category
4. Ending Product Category
5. Starting Customer Type
6. Ending Customer Type
7. Print Invalid Setup Codes? (Default “N”)
8. Print Missing Sales & COG Setup? (Default “N”)
We allow “7. Print Invalid Setup Codes?” so users can print out the old setup for reference. At this moment, we are not providing an utility to purge them since purging is not necessary since they are harmless. If user really want to purge, we can purge for them in PSQL control center.

We allow “8. Print Missing Sales & COG Setup?” because it is often user forget to add the corresponding Sales & COGS setup when a new customer type, location or product category is added. This may be intentionally so system will default it, or a mistake of oversight. We give this flag 8 so user can verify if they have any combination of setup that they may miss. For example, if user choose “7 = Customer Type” in global setup, then we will loop through the customer type file and find out if any customer type have a corresponding record in CPSLSCOG file. If user choose “3 = Location/Customer Type”, then we look through every combination of location and customer type to see if the corresponding record is missing. We will print the missing records like a regular record, but in the sales and cogs area show “*** Missing ***”. We will finalize the layout before implementing.

Also, we should print in the grand total areas:
999,999 Records Printed
999,999 Invalid Records Printed (if flag 7 is setup to “Y” and invalid account codes > 0)
999,999 Records Missing Setup (if flag 8 is set to “Y” and records missing setup > 0)

We will also add a Global (Management) Event that support the following variables:
Record Number (Value always = 1)
Default Sales Account (From ARCTLFIL)
Default COGS Account (From CPCTLFIL)
All Locations Chosen Base on screen parameters and have value “Y”, “N” or blank if not applicable per global setup
All Category Chosen Base on screen parameters and have value “Y”, “N” or blank if not applicable per global setup
All Customer Type Chosen Base on screen parameters and have value “Y”, “N” or blank if not applicable per global setup
Total Records Printed

Total Invalid Records Printed If flag 7 is set to “Y”, otherwise 0
Total Records Missing Setup If flag 8 is set to “Y”, otherwise 0
The purpose is so that admin can subscribe to this event by filtering when “Total Records Missing Setup” > 0. Then admin can use defer processing to run this on the daily basis. If user miss the setup, then an email will be sent to warn the admin.

We will also modify CP0305.CBL to reflect the new logic.

Elliott allows to use a variable on the Attach... field when sending a Post Office email. For example the variable InvNo will automatically attach a document with the invoice number as the file name. This is NICE. I suggest to allow multiple path in case the documents are in different folders and to allow wildcard. So instead of $InvNo$.pdf I can define $InvNo$.. For example if the invoice number is 123456, Elliott will attach 123456.DOC, 123456A.PDF etc. In addition user should be able to define different path so it can be something like M:\ELLIOTT8\DOC1\$InvNo$., M:\ELLIOTT8\DOC2\$InvNo$.,M:\ELLIOTT8\DOC3\$InvNo$.. In this example, Elliott will attache any document that has the invoice number as the first characters in the file name. If the multiple path is complicated, I think that one path is acceptable.

Resolve Cost Adjustment Issues Across Multiple Asset Accounts

Currently, if you post a Cost Adjustment to an item that has QOH in multiple locations, with a different assigned GL Asset Account per location (via material cost type/location account control), the system defaults to writing the entire adjustment (qty summed across all locations) to the asset account indicated by the transaction location. If posted, this creates immediate discrepancy between effected GL Asset Account balances and the Stock Status by GL Report. Would like to see the system pre-fill distributions to accommodate this scenario, allowing user to choose final distribution account(s) to offset the re-valuation. Example screenshot attached.