AdminEdward M. Kwang - NETcellent System, Inc. (Admin, NETcellent Systems, Inc.)

My feedback

  1. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  2. 2 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    We will be adding the Product Category and the Material Cost Type to the Item Audit Trail file in V9.0.

  3. 11 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    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.

    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).

    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.

    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.

    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.

    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.

    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.

    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.

  4. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    planned  ·  0 comments  ·  Elliott Forum  ·  Admin →
  5. 3 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    The main reason PDF PostOffice dos not allow to run in defer processing has to do with the requirement to check the select the printer tab. The printer tab is used when there's no eContact for a particular PDF PostOffice document, in that case, a hard copy is printed on the printer instead.

    Defer Processing, by design, does not allow printing to printer, and therefore is not compatible with the current PDF PostOffice design.

    An idea had been mentioned that we may print to the disk, instead of printer, when eContact is not found. We are evaluating if this is a viable method to move forward with future enhancement.

  6. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    We have no plan to support item cost at the warehouse level. We suggest you to use a different item.

  7. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    planned  ·  0 comments  ·  Elliott Forum  ·  Admin →
  8. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    started  ·  0 comments  ·  Elliott Forum  ·  Admin →
  9. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  10. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    We do not support PSQL 13 at this moment.

  11. 2 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    planned  ·  0 comments  ·  Elliott Forum  ·  Admin →
  12. 3 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    We are not aware of the 2nd operator to replace the first operator scenario. We will do a test to check if that’s the case. In the mean time, we think it is a good idea to offer the 2nd operator the option to login the work center automatically when the 1st operator is already on that job. This way, the 2nd operator time become the share labor. When the 2nd operator leave that job by working on other job, the share labor time automatically stop. Is this something you image how it should work?

  13. 3 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  14. 4 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  15. 2 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  16. 2 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  17. 2 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    We are aware of this might happen. But we are not sure how frequent this issue happen or under exact what condition this will happen. At this moment, we are not aware of a better solution than the current method to delete the orphan user session from PSQL engine.

  18. 1 vote
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  19. 2 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

  20. 5 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

← Previous 1

Feedback and Knowledge Base