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

My feedback

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

    We’ll send you updates on this idea

    Also, when user in the cursor of "Enter Beginning Balance Date:", currently, it default the value to today days. It need to be changed to "blank". If users hit enter, then it means "System Date". This is necessary for defer processing purpose. The defer report should be relatively simple which shows the item#, description, location and beginning balance quantity. The legend show the "Beginning Balance Date".

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

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

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

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

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

    We’ll send you updates on this idea

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

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

    We’ll send you updates on this idea

    started  ·  0 comments  ·  Elliott Forum  ·  Admin →
  11. 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?

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

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

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

    We’ll send you updates on this idea

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

    We’ll send you updates on this idea

  18. 5 votes
    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

    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.

  20. 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?"

← Previous 1

Feedback and Knowledge Base