Post your ideas, questions, or feedback.

Elliott V9 Changes Summary and Detail - Please Comment

Attached please find Elliott V9 Changes Summary and Detail documents. You can just read the summary document to get a good idea of what changes will take place in V9. Please comment if you can before we finalize Elliott V9 project. Thank you.

12 votes
Sign in
Signed in as (Sign out)

We’ll send you updates on this idea

AdminEdward M. Kwang - NETcellent System, Inc. (Admin, NETcellent Systems, Inc.) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

26 comments

Sign in
Signed in as (Sign out)
Submitting...
  • Avi Weissbard - Cybermac software LLC commented  ·   ·  Flag as inappropriate

    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.

  • Avi Weissbard - Cybermac software LLC commented  ·   ·  Flag as inappropriate

    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.

  • AdminEdward M. Kwang - NETcellent System, Inc. (Admin, NETcellent Systems, Inc.) commented  ·   ·  Flag as inappropriate

    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.

  • Aaron Keating - Lipsey's, LLC commented  ·   ·  Flag as inappropriate

    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.

  • Sheryl Manz - Davidson's, Inc. commented  ·   ·  Flag as inappropriate

    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.

  • AdminEdward M. Kwang - NETcellent System, Inc. (Admin, NETcellent Systems, Inc.) commented  ·   ·  Flag as inappropriate

    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.

  • Bob Goldberg - Diversified Micro Systems Inc. commented  ·   ·  Flag as inappropriate

    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.

  • Brian Koomen - CEM Corporation commented  ·   ·  Flag as inappropriate

    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/

  • Sheryl Manz - Davidson's, Inc. commented  ·   ·  Flag as inappropriate

    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.

  • AdminEdward M. Kwang - NETcellent System, Inc. (Admin, NETcellent Systems, Inc.) commented  ·   ·  Flag as inappropriate

    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.

  • Aaron Keating - Lipsey's, LLC commented  ·   ·  Flag as inappropriate

    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.

  • AdminEdward M. Kwang - NETcellent System, Inc. (Admin, NETcellent Systems, Inc.) commented  ·   ·  Flag as inappropriate

    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.

  • Aaron Keating - Lipsey's, LLC commented  ·   ·  Flag as inappropriate

    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?

← Previous 1

Feedback and Knowledge Base