Home

⌘K
  2. Home
  4. Docs
  6. Home
  8. Client Profile
  10. Custom Fields

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 a field, confirm whether the information should be stored only as an additional custom attribute or mapped to an existing standard Resico field using the Base field option.

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 -Unique system identifier for the custom field. Use a short, meaningful value without special characters (for example: customer_region, supplier_code). This value is used internally by the system.
    • Name – The display name shown to users in forms, lists, and other screens (for example: Customer Region).
    • Type – Defines what kind of data can be entered. Select the appropriate field type from the dropdown list.
    • Max length -Maximum number of characters allowed in the field. Applicable primarily to text fields. Leave empty if no limit is required.
    • Synchronize with external data field – Defines the external field or metadata key that should be synchronized with this custom field. For example, a WooCommerce customer metadata field such as meta.billing_wooccm13.
    • Synchronization mode – Defines whether the value is read from the external system, written to it, or synchronized in both directions, depending on the integration configuration.
    • Base field – Optionally links the custom field to a standard Resico field. When a base field is selected, the synchronized value is stored in the corresponding standard Resico record field instead of being available only as an additional custom attribute.
  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.

Field Type Descriptions

  • Text – Stores plain text values. Suitable for names, descriptions, codes, comments, or other alphanumeric information. The Max length setting can be used to restrict the number of characters.
  • Number – Stores numeric values only. Used for quantities, measurements, percentages, or other numerical data.
  • Boolean – Stores a Yes/No or True/False value. Typically displayed as a checkbox or toggle.
  • Date – Stores a calendar date without a time component.
  • DateTime – Stores both a date and a time.
  • List – Allows users to select a value from a predefined list of options. This helps standardize data entry and prevents variations in spelling or formatting.
  • Images – Allows one or more image files to be uploaded and associated with the record.
  • File – Allows users to upload and store documents or other file types.

Native field mapping

Custom fields can also be mapped to standard Resico fields, referred to in the configuration as Base fields.

This allows data received from an external system to be stored directly in the corresponding standard Resico field instead of only as an additional custom attribute.

For example, a WooCommerce customer metadata field can be configured as follows:

  • External field: meta.billing_wooccm13
  • Custom field: Registration ID
  • Base field: Registration ID (RegistrationID)

In this case, the value received from WooCommerce is stored in the customer’s standard Registration ID field in Resico.

The same approach can be used for other supported standard fields. For example, customer data such as:

  • Registration number
  • VAT registration number

can be mapped from external metadata directly to the corresponding Resico customer fields.

Fields that are not mapped to a Base field continue to work as regular custom fields and are stored as additional attributes.

The available base fields depend on the entity and the standard fields supported by Resico.

Synchronization direction

The actual synchronization direction also depends on the permissions configured for the integration.

For WooCommerce integrations:

  • Read – data is synchronized from WooCommerce to Resico.
  • Read/Write – data can be synchronized in both directions where the mapped field and integration support it.

Changing a custom field to use a Base field does not by itself change the integration permissions.

Example

A customer may have the following WooCommerce metadata:

meta.billing_wooccm11 → Legal entity
meta.billing_wooccm12 → Legal address
meta.billing_wooccm13 → Registration number
meta.billing_wooccm14 → VAT registration number

The fields can be configured so that some remain regular custom attributes while others are mapped directly to standard Resico customer fields.

For example:

meta.billing_wooccm13
→ Registration number
→ Base field: Registration ID (RegistrationID)

and

meta.billing_wooccm14
→ VAT registration number
→ corresponding Resico VAT registration field

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.
  • A custom field mapped to a Base field acts as a bridge between external data and an existing standard Resico field. It does not create a second standard field.

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.