Allow custom field type on sales invoice lines

Understand from guides that sales invoice line is a custom field. To get the most out of it can I expect to have the type option similar to other custom fields please @lubos ? This will be a great for many users, trust me.

Can you be more specific on our request - it isn’t clear what you re looking for

Sales Invoice Line is a line on a Sales Invoice form not a custom field

According to the guide customs fields can be added for individual line items. Currently the line field supports text only which confines the benefits in my point of view. I wanted the option to choose the type field as text, dropdown, date, number - similar to other custom fields. Adding the option will help us to utilise the line field in many more ways.

1 Like

The difficulty with your request, @raj, is that line-item custom fields are displayed as part of a line. The coding for them must fit the extra information into an existing structure. So they work for such things as adding a serial number to a sales invoice for a computer. Or, for the Indian tax scheme, the HSN. But you cannot fit paragraphs and images into that scheme.

Regular custom fields offer more flexibility because they are displayed elsewhere on the form, without the restrictions of fitting into the table structure that builds the displayed columns.

A post was split to a new topic: New updates

The feature is a work in progress at the moment. For now, just enter text in the field. It will be completed in the near future.

All these years and still waiting for this feature, hope it works soon because I really need the dropdown list in a line custom field

@lubos THE DEVELOPER Has Not Decided to Implement it in Manager till now.
This is in #ideas Category because it is useful for many users.
Decision of implementation Will be taken by @lubos only.

1 Like

This has been added to the latest version (22.8.16).

You can now have date, number or dropdown custom fields on individual lines.


This is part of new custom fields implementation I’m working on. When you go to Custom Fields under Settings. You will notice there are now 4 sub-items.

Classic Custom Fields is the old implementation. You should not be creating new custom fields under Classic Custom Fields section anymore.

Instead new custom fields should be created as either:

  • Date Custom Field
  • Number Custom Field
  • or Text Custom Field

This is new implementation that has quite a few (future) advantages over the old one but new implementation is not yet complete. When new implementation is complete, existing custom fields under Classic Custom Fields will be automatically converted to new implementation and Classic Custom Fields will disappear.

So we kind of have 2 implementations running side-by-side in the program temporarily.


@lubos, the addition of subcategories seems unnecessary. It forces users to guess what type of field they are dealing with, possibly drilling down on multiple subcategories until they find the field they are looking for. Couldn’t the same thing be accomplished in a single list by adding a column listing the subcategory?

The subcategories may seem obvious, but what happens when a user enters numerals in a text-type field? Or you decide to edit an existing field with a new placement, but the field names don’t make the subcategory obvious and the particular example you are looking at has no content in the field? The separate subcategory pages just seem like an extra step in implementation with no benefit.

I really appreciate the new features, especially the tabular presentation of the new custom fields section but I have a few remarks:

  1. @Tut has a point, the implementation is fine but viewing all in a single table could potentially save users of creating a mess with duplicate names, multiple placements, etc.

  2. How do custom fields work when they are placed in both Document-level and line-level at the same time?

  3. Can we still convert from one type to another? Say I created a field as a number but later decided that a drop-down is enough, will we be able to convert it?

  1. The current implementation is consistent with almost all screens in Manager. You could make the same argument about why inventory, non-inventory and inventory kits are not seen all in one screen. They are all items after all.
  2. You can do it. It’s supported.
  3. No. This is why all three types are in their separate screens now. It’s not possible to move custom fields from one screen to another. If you really want to do that, then you will need to create new custom field in desired screen. Then generic find & recode (which hasn’t been implemented yet) could assist you to move data from one custom field to another in bulk.
1 Like

Hope this will be implemented soon, the current custom fields that I expect at one point to become obsolete can then be allocated to the new ones.

It is excellent to distinguish better between numeric, date and text fields as it would open up opportunities with for example numeric fields to have custom formula fields.

Unfortunately the approach seems unnecessarily complicated to separate them into three different categories while the only distinction is type of field. Many of us are familiar with “format cells” functions in spreadsheets where content can be anything or with dominant form creating applications such as gravity forms that also allow to select between different types.

Maybe the underlying reason/justification is the way Manager commits form data to the database where it can not allocate to different types?

Imo adding custom fields of type date or number is an excellent idea as that will enable appropriate sorting and range searching.

Settings page layout is less critical to me. Having a custom field with type specified within the custom field page would also allow field type definition and may better support field layout setting.

The field type could be made not editable if it contained any content (or after creation) to prevent corruption of data by changing type should that be a possibility. With find and recode or batch update used to move data between fields of different types.

I support the new implementation 100%

1 Like

When the new Text Custom Fields are used for Business details they do not appear on printed documents like the Classic Custom Fields do. That is, below Business name in the top right corner of documents.

Will something replace this before Classic Custom Fields are removed?