Regarding Bob Goldberg's comment on 4/4/2017 12:02, we will ensure that we have the necessary database structure to support 6 lines x 60 characters for address. We are thinking using attribute to support it in the future. Therefore, we will expand the attribute reference field from 35 characters to 60 characters with V9. But we will not support this feature with the initial Elliott V9 release though.

I would like to see the 30 character Customer Address and Ship To fields expanded even more - perhaps up to 60 characters, with 6 lines of address available. Mercer has international customers that require that much detail on shipping labels and shipping documents.

Hmm. posted this before but never showed up.

Would like to ability to have Elliott intergrate with Salesforce. Not to knock the CRM in Elliott, but we need to use Salesforce for out CRM. We would like to have the ability for data be updated in both systems. Right now we are only able to extract data from Elliott to a spread sheet and then upload the data to Salesforce.
http://www.softwareadvice.com/resources/salesforce-erp-integration/

Add email address field to the order entry screen.

With the new additional fields being added, the Sales Desk Screen layout also needs to be expanded to have more than 12 custom fields displayed.

I suggest group permissions for attribute maintenance. Users in the same group need to have access to each others' attributes without having to setup a hierarchy for each person in the group.

Capabilities to support Prox payment terms in AR file

What about updating UOM field to 3 characters to accommodate case packs of 100+ ?

Regarding Aaron Keating's comment on 3/17/2017, yes, we can make this change. In addition, I suggest to add customer type to the order header as well. We can then optionally allow user to change customer type at the order header level base on Global Setup. This will allow different pricing for the customer base on the new customer type at the order.

As for the starting source of sales, it is already in the order line item audit trail table. We agree that it make sense to put in the order line item, and then carry over the invoice line item, as well as CPHSTTRX table.

While changing the table structures, I think it would beneficial add these 2 pieces of information for reporting purposes.

Customer Type should be recorded on the invoice header at the time of posting. This gives an accurate representation of what the customer's type was at the time of the sale. Joining the customer table to the invoice header only tells you what the customer's type is now, not what it was at the time of order.

The starting source of a sale should be recorded on individual line items. The source would be where the order originated from. Online, API, custom specified, etc... This would need to be on the order line item and then carried over to the invoice line item. Then, you could create very accurate historical reporting on order entry sources. Having this information on a note attached to the invoice header or line item is cumbersome and could be deleted. With this method, once the line item is added, the source is saved forever. This source field could also be carried over to the CPHSTTRX table. The actual source field only needs to be a few characters and each company can decide their own code formats.

Regarding Aaron Keating's comment on 2/16/2017, yes, you can continue to run Elliott V8.x in production, and V9 in a separate folder/database for testing purpose. Once testing is satisfactory, you can then do a final conversion and switch on V9. Unlike V7.5, you cannot run on V8 and V9 concurrently.

There will be changes to VIEWS due to the database structure had been changed. One example is APOPNFIL table used to have two type of records - vouchers and checks. In V9, they are separated into two different tables.

Is it safe to assume that Elliott v8.x can continue to run in production and V9 can be run concurrently from a separate database for testing?

I don't see anyone being able to switch over cold to v9, especially considering all of the breaking table changes and adjustments and testing that needs to happen to all reports, websites, etc...

Also, will there be new VIEWS made available to merge all of the data that is separating back together for easy querying?

Regarding Shyeryl Manz's comment on 2/10/17, just as a FYI, we currently a more finite level attribute security through "Supervisory Relationship". With that, you can consider a more restrictive approach with Global Security flags and Attribute Code Shareable for Read, Change and Delete flags. See knowledge base article: http://support.elliott.com/knowledgebase/articles/870954-feature-enhanced-security-for-attributes for more detail.

I noticed a lot of changes to attributes but I'm wondering if you could take it a step further.
Currently, you can set an attribute for shareable for read, change & delete, but that applies the same permissions to everyone (except the owner). If I give a user permission to change other users' attributes, they have access to change or delete ANY attributes.
I'd like to see better attribute permissions - possibly based on groups. For instance, people who have access to change item attributes don't need to be able to change customer attributes, and vice-versa.
Thank you

Regarding Avi Weissbard's comment on 1/31/2017:
5. We will support unit cost and unit price up to 6 decimals. Since not all users want that many decimals, so we will introduce the following flags in company setup:
Number of Decimals For Unit Price
Number of Decimals For Unit Cost
The default value are 4 which match Elliott V7/V8 design. The valid values can be from 2 - 6. We will introduce new AP to make the coding easier to support various number of decimals user choose to go with. At the database level, it is always 6 decimals. The flags here is only for the screen and report printing masking.

Regarding Avi Weissbard's comment on 1/31/2017:
1. Search by name - Elliott V9 will use case insensitive key, therefore, there's no need for the upper case search field and thus eliminated in V9.
2. We support up to 10 reference fields in customer, vendors, items...etc. In the past, they are searchable as user definable index (5 additional key). In V9, we will extend the user definable index to all 10 reference fields.
3. Noted and we will discuss internally.
4. We currently plan to support unit price at 9,999,999.9999 in Elliott V9.
5. Noted and we will discuss internally.
6. Yes, we will support Lot number up to 18 digits.
7. We will have better support for lot number in V9. In the initial Elliott V9 release, the lot number capability will not be as robust as serial number. We intend to make the V9 database capable supporting robust lot number feature like serial number. Those features may take time to develop like V9.1, V9.2...V10...etc. A good database schema is like a solid foundation. That is what we are trying to do with V9. We intend to build on this solid foundation for may robust features to come.

I like the changes. Few comments that Dan and I thought of:
1. Search by name (Customer, Vendor, Item). I assume that the upper case search field will be eliminated but we will be able to continue to search by name and will be case sensitive.
2. Replacing the Note fields by Attribute - will we be able to search by these attributes? Currently many of my customers are using the Notes' fields as a search for their customer's number. In some cases there are 2 or 3 cross reference numbers for the same customer (currently kept in a Note field) and I am not sure how the search can be done after the change.
3. I see the Order Number, Invoice number etc are going to 9 digits. I didn't see the PO number and would like to see the PO number being 9 digits (or 9 + 2 with the release number) as well. This is extremely helpful for the Petroleum industry.
4. Price at 9,999,999.9999. There are situations where the unit price is more than $1,000,000. I suggest to allow a unit price accordingly.
5. Cost with 5 decimals. In some situations the "M" unit of measure is not allowed and it is necessary to present the cost with 5 decimals. There are Tax Jurisdictions where translating the tax to a number will cause 5 decimals. These are usually Petroleum Tax.
6. I assume Lot number will be changed to 18 characters as well.
7. I like to see Lot functionality on the same or close to the Serial processing level. I see the improvement of preventing splitting a COP line to multiple lines because of the different lots (nice !!!) but would like to see a better functionality in areas such as Inventory Transfer.
Thank You

There are users suggest that Elliott V9 need to support plus work order with scheduling date at the routing level. Currently, Elliott plus work order support start and due date at the work order header level. But some users produce items that may take 2 weeks to produce. They need the scheduling at the routing level which SFC do. Then they need to print production scheduling report and material pick ticket for the date which is base on routing scheduling date. Without this feature, they can't covert to plus work order.