Ideas for Acumatica

Feedback processing: We do not reply to all messages, but we do read them, analyze them, and work to improve Acumatica based on the feedback we receive. Ideas and comments may not appear immediately. Some legitimate ideas are flagged as spam and will be added when we review the spam folders.
Content: This portal is for product ideas and feedback only. If you need customer service assistance, contact your Acumatica Support Partner, submit a support case, or get assistance from community resources: LinkedIn Group or StackOverflow
No Reliance: Information is maintained on a best-efforts basis and may be changed without notice. Acumatica cannot guarantee the accuracy of the information provided or guarantee completion of features/ideas described on this portal.

Restructure Contact ID logic

Currently the ContactID field on the contact form is generated using the LastName, FirstName + Title. 

In the database the ContactID is an integer.

This setup makes importing contact/lead information using import scenarios highly problematic.  The Contact form should remain consistent with the rest of the ERP's main master data records like Business Accounts, etc.  A segmented key with numbering sequence.


  • Colin MacMillan
  • Dec 22 2014
  • Gathering Feedback
  • Attach files
  • Wileyska Sandoval commented
    22 Jun 21:08

    I agree to this idea, users are very visual and they are used to seeing the Customer ID and Vendor ID to something they come up with and relate to, same should go for Contacts.

  • Bob Voorheis commented
    September 19, 2019 20:50

    Completely agreed.  This makes import scenarios a huge, unnecessary pain.  Why not simply have an application-level unique ID? Every other DAC that is visible in the UI aligns to the same structure.  It shouldn't be difficult to have a separate application-level ID that's visible in the UI.

  • Jean Slusher commented
    August 01, 2018 15:34

    Acumatica assigns a unique ID to the contact behind the scenes because it needs to have a unique key and the last name, first name may not be a unique key as there are a lot of Smith, John's out there.  Since you are doing it automatically we just cannot see it unless we specifically add that field to be displayed in the inquiry screen why not make it consistent with the business accounts, customers, vendors, employees where we can set up a segment for it to use and auto number it.

  • Gabriel Michaud commented
    December 22, 2014 18:26

    I'm not sure it makes sense for users to have to deal with IDs for something like a contact. We instead need to improve import capabilities to ensure it's easy to work with this information and map to external IDs if needed.