Custom Fields

Purpose

Use the Custom fields page to create and maintain additional client-specific fields for key ERP entities. This page lets the client extend standard forms without changing the core system structure.

Roles involved

• System administrator
• Business analyst
• Implementation / support team

Preconditions

• You need permission to edit Client profile.
• You should know which entity needs an extra field and what business purpose the field will serve.
• Before adding fields, confirm that the same information is not already captured in the standard ERP fields.

Navigation path

Client profile → Custom fields

Step-by-step procedure

1. Open Client profile → Custom fields.
2. Review the field groups shown on the page. The page is divided into separate sections for:
   • Products
   • Customers
   • Vendors
   • Sales orders
   • Purchase orders
3. In the required section, click Add new field. This opens the custom field form in a modal window.
4. Complete the field setup in the modal. The page structure shows that each saved field stores:
   • Code
   • Name
   • Type
5. Save the new field in the modal window.
6. After saving, verify that the new field appears in the correct section list.
7. To change an existing field, click Edit on that row.
8. To remove an existing field, click Delete and confirm the deletion.
9. Repeat the process for each section where extra fields are needed.

Required fields

• Field code
• Field name
• Field type
• Target section (Products, Customers, Vendors, Sales orders or Purchase orders)

Validation rules

• Each custom field should have a unique code within its section.
• The name should clearly describe the business meaning of the field.
• The type must be selected from the field types supported by the custom field modal.
• Custom fields should only be created when there is a clear business need and an agreed data entry process.

Exceptions

• Custom fields are maintained separately for each section. A field created for Products does not automatically exist for Customers or other entities.
• The exact list of supported field types is defined in the modal dialog and not fully visible from the page list itself.
• Deleting a custom field can affect historical records, reporting or exports if that field was already used.

Common errors

• Creating fields with unclear names causes confusion for users later.
• Adding duplicate or overlapping fields for the same business purpose results in inconsistent data entry.
• Deleting a field without impact review can remove access to business data already entered in existing records.
• Creating too many custom fields makes cards and documents harder for users to maintain.

Troubleshooting

• If a field does not appear where expected, confirm that it was created in the correct section.
• If users are unsure how to fill the field, rename it to a clearer business term before rollout.
• After adding a new field, test it on one real product, customer, vendor or document before announcing it to all users.
• If the field list is empty in a section, use Add new field to create the first one for that entity.

Questions / Gaps

• The page shows that each field has a type, but the exact end-user list of available field types should be confirmed from the modal dialog in live use.
• It should be confirmed whether custom fields can be made mandatory, searchable or exportable in all implementations.
• The exact behavior of editing or deleting fields that are already used in historical data should be verified before production changes.