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

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

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

    We’ll send you updates on this idea

  6. 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?

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

    We’ll send you updates on this idea

  8. 3 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.

  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 had reviewed this issue in depth and we can't address this issue in any reasonable manner. Any changes will cause bigger problem in other area. At this moment, we are not going to address this issue. Instead, we are asking you to consider a few things in your procedure: (1) We suggest you not to perform GL interfacing while the posting is taking place. A lot of our users use defer processing at night to perform posting. That would certainly address this issue; (2) When interfacing with G/L , please interface distribution in the past, not the current date; (3) The chances of the out of balance increase because the distribution file is not purged and cause the interface take forever to complete which increase the chances of conflict. Therefore, we recommend you to purge your old distribution records to speed up your interface.

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

    We’ll send you updates on this idea

    Expanding of the AP invoice number came up many times before. In our next major version, we plan to expand the AP invoice number from 8 digits to 12 digits. We do understand that there are certain vendors (especially, trucking companies) will send you invoices over 12 digits. On the other hand, if we expand the maximum invoice number field to something like 25 digits, then it will cause difficult with displaying it on the screen because there are only so much real estate space. The common strategy to deal with this type of long invoice number problem is to use AP Voucher Reference. Enter the long invoice number on AP Voucher Reference. Then you should also go to Global Setup -> Acct -> AP Global Control. Turn on the following flag: "1. Print Voucher Reference On A/P Check?"

  12. 10 votes
    Sign in
    Signed in as (Sign out)

    We’ll send you updates on this idea

    When we evaluate this project, one thing that concerns us is the security issue. We are concerned that once we implement AP ACH feature, if there's no proper check and balance built into the system, then embezzlement can take place. That's the reason why some of users only allow ACH in (AR ACH), not ACH out (AP ACH or AR ACH credit).

    We like to hear from you on how you think the proper security, check and balance, should be built into the system to prevent potential fraud.

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

    We’ll send you updates on this idea

    Dan, in the original modules design, IM (Inventory Management) is a lower layer module than PO (Purchase Order). That is, you could have IM module, without PO module. But not vice versa.

    Even though most of the user perform Landed Cost calculation through PO module, but user could perform do that base on the receiving transaction in IM Inventory Transaction Processing as well. Therefore, placing the report under the IM module making more sense than PO module. Just FYI

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

    We’ll send you updates on this idea

    Dan, I like your idea. This is probably something we should look at in Elliott V9.

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

    We’ll send you updates on this idea

    There are two concerns with implementing this feature: (1) This particular feature is complicated. Especially the logic to ensure good performance now we are printing against the invoice history database; (2) The coding with DYO is difficult to maintain.

    We are considering moving away from DYO. We can't be sure if we are going to create something new to replace DYO in Elliott V9 or continue to support it. If you can implement your invoice form with standard Elliott form, we would encourage you to do so.

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

Feedback and Knowledge Base