Documentation
Item Custom Attributes (UDA)
Item Custom Attributes (UDA) lets an Organization define additional governed Item characteristics when the standard Item master does not contain the business-specific field that is needed. A definition controls what the attribute means, where it applies and how its value is entered; each applicable Item then stores its own value.
What is a User Defined Attribute (UDA)?
UDA means User Defined Attribute. It is a governed way to add a business-specific characteristic to the Item master without turning every possible industry requirement into a permanent standard Item field.
AkshaERP already provides standard Item fields for identity, classification, UOM, tax, tracking, dimensions, weight, purchasing, sales, logistics and other common controls. UDA is for characteristics that are genuinely specific to a product family, industry or implementation.
A UDA has two parts: the definition and the Item value. The definition says what the characteristic means and how it should behave. The Item value records the answer for one particular Item.
Definition versus Item value
Create the definition once and reuse it across all applicable Items in the owning Organization. Do not create a new definition for every Item.
| Concept | Example | Meaning |
|---|---|---|
| UDA definition | PAPER_GSM | Defines a reusable Item characteristic called Paper GSM, its data type, unit and applicability. |
| Item value | Class 10 Mathematics → 70 GSM | The value of PAPER_GSM for one specific Item. |
| Another Item value | Premium Atlas → 100 GSM | The same definition can hold a different value for another applicable Item. |
Standard Item field or UDA? Use this decision first
Before creating a custom attribute, check whether AkshaERP already has a standard field or dedicated function for that information. Recreating standard controls as UDAs creates duplicate sources of truth and makes reporting and operations harder.
| Business information | Use | Why |
|---|---|---|
| SKU / Item Code | Standard Item field | This is core Item identity. |
| Item Category | Item Categories + Item master | Classification already has a governed hierarchy. |
| Default UOM | Standard Item field | Operational quantity control already exists. |
| Weight / Length / Width / Height | Standard Item Attributes / Logistics | Common physical dimensions already have dedicated fields. |
| HSN / SAC | Standard tax fields | Tax classification has dedicated controls. |
| Supplier | Purchasing setup | Supplier relationships belong to the Purchasing part of the Item master. |
| Barcode | Barcodes function | Multiple and Primary barcode control already exists. |
| Paper GSM for books | UDA | Industry-specific characteristic not required by every Item. |
| Steel Grade | UDA | Material-specific characteristic. |
| Motor IP Rating | UDA | Product-family characteristic. |
| Fabric Composition | UDA | Industry-specific descriptive/controlled characteristic. |
Quick Reference
| Task | What to do | Key control |
|---|---|---|
| Create a definition | Inventory → Item Custom Attributes (UDA) → Create. | The active Organization owns the definition. |
| Create a stable identity | Enter Attribute Code and Attribute Name. | Both are permanent after creation; change Label for display wording. |
| Choose value behavior | Select TEXT, NUMBER, DATE or BOOLEAN. | Data Type determines the Item entry control and stored value type. |
| Control text entry | For TEXT choose Free Entry, Static List or Value Set. | Static List and Value Set prevent arbitrary answers. |
| Add a unit | For NUMBER optionally select an active UOM. | Use when the number has a unit such as MM, V or KG. |
| Make it mandatory | Enable Required when applicable. | Only Items to which the UDA applies must provide a value. |
| Limit where it appears | Configure Item Type and/or Category applicability. | Use All Items only when the attribute genuinely belongs everywhere. |
| Retire | Change Status to Inactive. | Use for definitions that have been used historically. |
| Delete | Delete only an unused mistaken definition. | Used or operationally referenced definitions are protected from deletion. |
A practical mental model
| Question | UDA control |
|---|---|
| What characteristic are we asking about? | Attribute Code / Attribute Name / Label |
| What kind of answer is valid? | Data Type |
| Can users type anything or choose from a list? | Entry Mode |
| Which answers are allowed? | Possible Values or Value Set |
| Does the number have a unit? | UOM |
| Must every applicable Item answer it? | Required |
| Which Items should see it? | Applicability |
| Should users still use it for new Item maintenance? | Status |
| In what order should attributes appear? | Sort Order |
Organization ownership
A UDA definition belongs to the Organization active when it is created. Users do not choose a different Organization inside the definition screen.
The list, create, edit and delete operations work within the active Organization context. This keeps one Organization from unintentionally imposing its custom metadata model on another Organization.
Item Custom Attributes list
The list is the administrator view for finding, opening, creating, retiring and safely deleting UDA definitions.
| Column | Meaning | Why it matters |
|---|---|---|
| Attribute Code | Stable governed code such as PAPER_GSM. | Best reference for integrations, documents and other configured rules. |
| Attribute Name | Canonical business name. | Permanent business identity alongside the Code. |
| Label | User-facing wording. | Can be changed when the display wording should improve without changing identity. |
| Data Type | TEXT, NUMBER, DATE or BOOLEAN. | Controls the kind of value the Item can hold. |
| Entry Mode | How TEXT values are entered. | Shows whether the value is free, static-list controlled or Value Set controlled. |
| UOM | Optional unit for NUMBER. | Provides meaning to numeric attributes. |
| Required | Whether applicable Items must provide a value. | Required is evaluated only where the attribute applies. |
| Applies To | Summary of applicability. | Helps administrators see the intended Item population without opening the definition. |
| Status | Active or Inactive. | Controls whether the definition participates in current Item entry. |
| Sort | Display sequence. | Keeps related attributes in a useful order. |
Create / Edit – field reference
| Field | Requirement | What to enter | Business effect |
|---|---|---|---|
| Attribute Code | Required | Stable uppercase-style code such as PAPER_GSM or RATED_VOLTAGE. | Permanent reference identity after creation. |
| Attribute Name | Required | Canonical business name such as Paper GSM. | Permanent canonical name after creation. |
| Label | Optional | Wording users should see, for example Paper Grammage (GSM). | Can evolve without changing Code or canonical Name. |
| Description | Recommended | Explain what the characteristic means and how it should be entered. | Reduces inconsistent master-data interpretation. |
| Data Type | Required | TEXT, NUMBER, DATE or BOOLEAN. | Determines valid Item value behavior. |
| Required when applicable | Optional | Yes when every applicable Item must have a value. | Blocks an applicable Item from being saved without a valid answer. |
| Entry Mode | TEXT only | Free Entry, Static List or Value Set. | Controls how text answers are governed. |
| Possible Values | Static List only | Maintained list such as MATTE, GLOSS, LAMINATED. | Restricts Items to one of the configured choices. |
| Value Set | Value Set mode only | Select a maintained Application Management Value Set. | Reuses centrally maintained controlled codes. |
| Validation Regex | Optional TEXT rule | A validation pattern when format must be controlled. | Rejects text that does not match the configured format. |
| Unit / UOM | Optional NUMBER rule | Select an active UOM when the number has a unit. | Displays the expected unit and preserves numeric meaning. |
| Status | Lifecycle | Active or Inactive. | Inactive definitions are retired from current applicable entry. |
| Sort Order | Optional | Number controlling display sequence. | Organizes the Attributes section for users. |
| Applicability | Recommended | All Items, Item Types, Categories or a combination. | Determines which Items should use the definition. |
Attribute Code, Attribute Name and Label are different
The three fields deliberately serve different purposes. Separating identity from display wording prevents a cosmetic wording change from changing the reference used by reports, documents or other configured rules.
| Field | Example | Can it change later? | Use it for |
|---|---|---|---|
| Attribute Code | PAPER_GSM | No | Stable configured/integration identity. |
| Attribute Name | Paper GSM | No | Canonical business name and compatibility identity. |
| Label | Paper Grammage (GSM) | Yes | The wording shown to users. |
Data Types – choose the meaning before users enter values
| Data Type | Item control | Good examples | Avoid |
|---|---|---|---|
| TEXT | Text field or controlled dropdown depending on Entry Mode. | Steel Grade, Cover Finish, IP Rating, Fabric Composition. | Numbers that must participate as numeric values. |
| NUMBER | Numeric entry, optionally with UOM. | Paper GSM, Thickness, Voltage, RPM, Capacity. | Values such as “about ten” or mixed text/unit strings. |
| DATE | Date entry. | Model Release Date, Certification Date when it is an Item characteristic. | Date/time events that belong to a transaction or audit history. |
| BOOLEAN | Yes / No checkbox. | Waterproof, Food Grade, RoHS Applicable. | Multi-state choices that require more than Yes/No. |
TEXT Entry Mode – Free Entry, Static List or Value Set
| Entry Mode | Use when | Example | Control level |
|---|---|---|---|
| FREE_ENTRY | Valid answers cannot reasonably be predefined. | Manufacturer colour description or a technical free-text designation. | Flexible; optional Regex can control format. |
| STATIC_LIST | Choices belong specifically to this one UDA and change rarely. | Cover Finish = MATTE, GLOSS, UV, LAMINATED. | Controlled directly in the UDA definition. |
| VALUE_SET | The same governed code list should be centrally maintained/reused. | A company-wide product characteristic list maintained in Application Management. | Controlled through the selected Value Set. |
Static List versus Value Set – how to choose
| Situation | Recommended choice | Reason |
|---|---|---|
| Four choices used only by one attribute | Static List | Keeps a small local list simple. |
| A code list reused across functions or maintained centrally | Value Set | One maintained source can serve multiple controlled contexts. |
| Answers are open-ended | Free Entry | A list would create unnecessary administration. |
| Format is open but structured | Free Entry + Validation Regex | Users can type a value but must follow the required format. |
Validation Regex – use it for format, not business meaning
Validation Regex is an optional TEXT control for values that must follow a predictable format. It should not be used where a controlled list or Value Set better represents the business rule.
| Requirement | Example pattern idea | Better control? |
|---|---|---|
| Two letters, hyphen, four digits | For a controlled technical designation format. | Regex can be appropriate. |
| Only MATTE, GLOSS or UV | Do not solve this with Regex. | Use Static List. |
| Yes or No | Do not solve this with Regex. | Use BOOLEAN. |
| A numeric thickness | Do not solve this with Regex. | Use NUMBER with the correct UOM. |
NUMBER attributes and UOM
NUMBER should be used when the value is mathematically numeric. A UOM can be attached when the number represents a measurable quantity.
| Attribute | Data Type | UOM | Example Item value |
|---|---|---|---|
| PAPER_GSM | NUMBER | GSM | 70 |
| THICKNESS | NUMBER | MM | 4.500 |
| RATED_VOLTAGE | NUMBER | V | 230 |
| RATED_POWER | NUMBER | KW | 7.5 |
| RPM | NUMBER | None | 1440 |
| PURITY_PERCENT | NUMBER | Optional business UOM if maintained | 99.950000 |
Required means required when applicable
Required does not make the attribute mandatory for every Item in the Organization. It makes the value mandatory only for Items that match the UDA applicability rules.
| Definition | Item | Result |
|---|---|---|
| PAPER_GSM required; applies to BOOKS and TEXTBOOKS | Class 10 Mathematics (BOOKS) | Paper GSM must be entered. |
| Same definition | Electric Motor (unrelated Item Type) | Paper GSM is not required and should not be presented as an applicable attribute. |
| STEEL_GRADE required; applies to Steel Category + descendants | Steel Plate under Steel | Steel Grade must be entered. |
| Same definition | Aluminium Sheet outside Steel hierarchy | Steel Grade is not required. |
Applicability – the key to keeping the Item screen useful
Applicability determines which Items should use a UDA. Without applicability, an active definition applies to all Items in the Organization.
Use applicability aggressively for industry-specific characteristics. A Book should not ask for Motor Voltage; a Motor should not ask for Paper GSM.
Applicability by Item Type
Use Item Type when the characteristic belongs broadly to one or more Item Types.
| Attribute | Applicable Item Types | Example |
|---|---|---|
| PAPER_GSM | BOOKS, TEXTBOOKS | Publishing Items need a paper grammage characteristic. |
| SERVICE_DELIVERY_MODE | SERVICES | A service-specific characteristic should not appear on stocked goods. |
Applicability by Item Category and descendants
Use Category applicability when the characteristic belongs to a product/material family. You can apply it only to the selected Category or include descendant Categories.
| Category structure | Rule | Result |
|---|---|---|
| Metals → Steel → Steel Sheet / Steel Rod | STEEL_GRADE applies to Steel; Include descendants = Yes | Steel, Steel Sheet and Steel Rod Items receive STEEL_GRADE. |
| Same hierarchy | Include descendants = No | Only Items directly classified in Steel receive the UDA. |
| Metals → Aluminium | Steel rule | Aluminium Items do not receive STEEL_GRADE. |
Combining Item Type and Category applicability
A definition can contain several Item Type rules and several Category rules. Within one group, matching any configured value is sufficient. When both Item Type and Category groups are configured, the Item must satisfy a configured Item Type and a configured Category rule.
| Configured rules | Meaning |
|---|---|
| Item Types = BOOKS or TEXTBOOKS | Either Item Type can match. |
| Categories = School Books or Academic Books | Either Category rule can match. |
| Both groups configured | The Item must match one configured Item Type and one configured Category rule. |
How Custom Attributes appear on the Item
Custom UDA values are maintained in the Item → Attributes area alongside the standard Item attributes. Standard fields such as dimensions and weight remain separate from the UDA definitions.
For a saved Item, AkshaERP shows the active UDA definitions applicable to that Item. The control follows the definition: text entry, dropdown, number, date or checkbox.
| Definition | Item control |
|---|---|
| TEXT + FREE_ENTRY | Text entry field |
| TEXT + STATIC_LIST | Dropdown from the configured choices |
| TEXT + VALUE_SET | Dropdown from active values in the selected Value Set |
| NUMBER | Numeric field, with UOM shown when configured |
| DATE | Date field |
| BOOLEAN | Yes / No checkbox |
New Item – what happens before the first Save / Apply
A new Item does not yet have a persisted Item identity. During initial creation, the Attributes area can show the active Organization UDA definitions while the Item Type and Category are being finalized.
When the Item is saved, AkshaERP evaluates the submitted Item Type and Category. Applicable Required and validation rules are enforced. Values entered for definitions that do not apply to the final new Item classification are not treated as Item UDA values.
After Save / Apply and reopen, the Attributes area shows the active definitions applicable to that saved Item.
Changing Item Type or Category on an existing Item
Changing classification can change which UDAs apply. AkshaERP protects populated metadata from silently becoming irrelevant.
If an existing UDA has a value but would no longer apply after the classification change, clear or migrate that value before changing the Item Type or Category. If the new classification introduces a Required UDA, provide the newly required value before the Item can be saved.
Status – Active versus Inactive
| Status | Use it when | Effect |
|---|---|---|
| Active | The attribute should participate in current Item maintenance. | Applicable Items can use the definition. |
| Inactive | The attribute is no longer used for new/current maintenance but has history. | The definition remains preserved but is retired from current applicable entry. |
What can and cannot be changed later
| Change | Allowed? | Reason |
|---|---|---|
| Change Label | Yes | Display wording can improve without changing identity. |
| Change Description | Yes | Administrator guidance can be improved. |
| Change Sort Order | Yes | Display order is operational presentation. |
| Change Status | Yes, subject to dependencies | Supports controlled lifecycle. |
| Change Attribute Code | No | Code is permanent stable identity. |
| Change Attribute Name | No | Canonical name remains stable for compatibility and meaning. |
| Change Data Type after Item values exist | No | Existing values already have a defined meaning/type. |
| Change NUMBER UOM after Item values exist | No | That would change the meaning of stored numeric values. |
| Tighten validation so existing values become invalid | No until values are corrected | Existing Item data must remain valid. |
| Narrow applicability so populated Items fall outside it | No until values are cleared/migrated | Existing metadata is not silently orphaned. |
Delete versus Inactive
Delete is intended for an unused definition created by mistake. Inactive is the normal retirement path for a definition that has already become part of Item history or another configured business rule.
| Situation | Recommended action |
|---|---|
| Definition created accidentally and never used | Delete |
| Definition has Item values | Set Inactive when it should be retired |
| Definition participates in another active configured rule | Remove or replace that dependency first, then retire as appropriate |
| Several unused mistakes selected together | Bulk Delete can remove them together |
| Bulk selection contains one used definition | The selected delete is rejected rather than partially deleting the rest |
How UDA can be used downstream
A governed UDA can be more useful than a display-only custom field because its stable definition can be consumed by supported documents, reports, integrations and configured Item-attribute-aware rules.
Where a UOM Conversion rule is configured to use an Item UDA, use the stable Attribute Code for new configurations. Existing compatible references remain supported, but Attribute Code is the preferred business identity going forward.
Publishing example – Books and Textbooks
For a Class 10 Mathematics title, the Item master still owns ISBN, publisher/author references, dimensions, weight, UOM and other standard fields. UDA adds only the publishing characteristics that are not already standard Item controls.
| Attribute Code | Type / control | Applicability | Example value |
|---|---|---|---|
| PAPER_GSM | NUMBER + GSM | BOOKS, TEXTBOOKS | 70 |
| COVER_FINISH | TEXT + Static List | BOOKS, TEXTBOOKS | MATTE |
| PAPER_TYPE | TEXT + controlled list | BOOKS, TEXTBOOKS | MAPLITHO |
| COLOR_PAGES | NUMBER | Relevant book Categories | 16 |
Steel example – Category hierarchy
Assume the Item Category hierarchy is Metals → Steel → Steel Sheet / Steel Rod. Define Steel-specific attributes at the Steel Category and enable descendant inclusion.
| Attribute Code | Type / control | Example |
|---|---|---|
| STEEL_GRADE | TEXT + Static List | IS2062_E250 |
| THICKNESS | NUMBER + MM | 4.500 |
| HARDNESS | NUMBER | 180 |
Fabric example
These characteristics can be scoped to a Fabric Category and its descendants so unrelated Inventory Items never see them.
| Attribute Code | Type / control | Example value |
|---|---|---|
| FABRIC_GSM | NUMBER + GSM | 180 |
| COMPOSITION | TEXT | 100% COTTON |
| WEAVE_TYPE | TEXT + Static List | TWILL |
| COLOR_FAMILY | TEXT + controlled list | NAVY |
Electrical motor example
A Motor Category rule keeps these technical questions away from Books, Services and other unrelated Items.
| Attribute Code | Type / control | Example value |
|---|---|---|
| RATED_VOLTAGE | NUMBER + V | 415 |
| PHASE | TEXT + Static List | THREE |
| RATED_POWER | NUMBER + KW | 7.5 |
| IP_RATING | TEXT + Static List | IP55 |
| RPM | NUMBER | 1440 |
Electronics example
| Attribute Code | Type / control | Example value |
|---|---|---|
| PROCESSOR_GENERATION | TEXT + controlled list | 14TH_GEN |
| RAM_TYPE | TEXT + Static List | DDR5 |
| SCREEN_TECHNOLOGY | TEXT + Static List | OLED |
| TOUCH_ENABLED | BOOLEAN | Yes |
Pharmaceutical / regulated-product example
| Attribute Code | Type / control | Example value |
|---|---|---|
| DOSAGE_FORM | TEXT + controlled list | TABLET |
| STRENGTH_MG | NUMBER | 500 |
| STORAGE_TEMP | NUMBER + appropriate maintained UOM | 25 |
| COLD_CHAIN_REQUIRED | BOOLEAN | No |
A complete example – design COVER_FINISH
When a Book Item is maintained, Cover Finish appears as a controlled dropdown and must be completed. A Motor Item does not need the field because the UDA does not apply to that Item Type.
| Step | Configuration |
|---|---|
| 1 | Attribute Code = COVER_FINISH |
| 2 | Attribute Name = Cover Finish |
| 3 | Label = Cover Finish |
| 4 | Data Type = TEXT |
| 5 | Entry Mode = STATIC_LIST |
| 6 | Possible Values = MATTE, GLOSS, UV, LAMINATED |
| 7 | Required = Yes |
| 8 | Applicability = BOOKS and TEXTBOOKS |
| 9 | Status = Active |
| 10 | Set a useful Sort Order near other publishing attributes |
A complete example – design THICKNESS
A Steel Plate Item can then store a numeric value such as 4.500 with MM displayed as the expected unit. The value remains numeric instead of being stored as the text “4.5 mm”.
| Step | Configuration |
|---|---|
| 1 | Attribute Code = THICKNESS |
| 2 | Attribute Name = Thickness |
| 3 | Data Type = NUMBER |
| 4 | UOM = MM |
| 5 | Required = Yes |
| 6 | Applicability = Steel Category with descendants |
| 7 | Status = Active |
Designing a clean attribute catalogue
- Start from real business decisions, reports, documents or operational rules—not from a desire to capture every possible fact.
- Use a clear stable Attribute Code such as PAPER_GSM instead of vague codes such as ATTR1.
- Keep one business meaning per attribute.
- Use Label for friendly wording and Description for administrator guidance.
- Scope the definition to the smallest correct Item population.
- Prefer NUMBER for numeric facts, BOOLEAN for true Yes/No facts and controlled lists for finite choices.
- Attach a UOM when a numeric value has a unit.
- Use Sort Order to group related characteristics logically.
- Retire obsolete definitions instead of creating renamed duplicates.
Common mistakes and better alternatives
| Mistake | Why it causes trouble | Better approach |
|---|---|---|
| Create CUSTOM_WEIGHT | Duplicates an existing standard Item/logistics control. | Use the standard Weight field. |
| Make PAPER_GSM apply to All Items | Unrelated Items receive irrelevant questions. | Scope to Book/Textbook Item Types or appropriate Categories. |
| Store “4.5 mm” as TEXT | The number cannot be reliably treated as numeric. | Use NUMBER + MM. |
| Use free text for a four-value choice | Users can enter spelling variants and invalid values. | Use Static List or Value Set. |
| Change business meaning by reusing an old Code | Downstream references still point to the old identity. | Create a new definition when the meaning genuinely changes. |
| Delete a historically used definition | Destroys the intended lifecycle of business metadata. | Set it Inactive. |
| Create separate UDAs for every Item | Creates an unmanageable catalogue. | Create one reusable definition with applicability. |
Recommended setup workflow
| Stage | Action |
|---|---|
| 1. Inventory model | Confirm standard Item fields and Item Categories first. |
| 2. Gap list | List business characteristics that are genuinely missing from the standard model. |
| 3. Classify | For each characteristic choose Data Type, unit and whether answers should be controlled. |
| 4. Scope | Choose All Items, Item Type and/or Category applicability. |
| 5. Govern | Create stable Code/Name, Label, Description, Required rule, Status and Sort Order. |
| 6. Pilot | Test on a small representative set of Items. |
| 7. Downstream test | Verify documents, reports or conversion rules that will consume the attribute. |
| 8. Roll out | Populate the applicable Item masters. |
| 9. Retire carefully | Use Inactive when the attribute is no longer used. |
Troubleshooting
| Problem | What to check |
|---|---|
| Attribute does not appear on a saved Item | Confirm the definition is Active, belongs to the Item owning Organization and that Item Type/Category matches applicability. |
| Attribute appears on too many Items | Review whether it was left as Applies to All Items or whether Category descendants are broader than intended. |
| Item cannot save because an attribute is required | Complete the required applicable value, or correct the definition applicability if the Item should not require it. |
| Dropdown is empty | For Static List confirm Possible Values; for Value Set confirm the selected Value Set and its active values. |
| Text value is rejected | Check Static List/Value Set choices and any configured Validation Regex. |
| Cannot change Data Type | Existing Item values already use the definition. Create a new definition or perform a controlled migration instead of changing meaning in place. |
| Cannot change UOM | Existing numeric values already use that unit meaning. Create a new definition or migrate data deliberately. |
| Cannot change Item Type or Category | A populated UDA may become non-applicable, or the new classification may introduce a missing Required attribute. Review Item → Attributes. |
| Delete is rejected | The definition is already used by Items or another active configured dependency. Use Inactive or remove the dependency first. |
| New Item initially shows more UDAs than expected | Complete Item Type/Category and Save / Apply. The saved Item view filters current UDAs by applicability. |
| Control | Operational rule |
|---|---|
| Ownership | Definition belongs to the active Organization. |
| Stable identity | Attribute Code and Attribute Name are permanent after creation. |
| Display wording | Label can be maintained without changing identity. |
| Supported Data Types | TEXT, NUMBER, DATE, BOOLEAN. |
| TEXT Entry Modes | FREE_ENTRY, STATIC_LIST, VALUE_SET. |
| NUMBER unit | Optional active Inventory UOM. |
| Required | Required only when applicable to the Item. |
| No applicability rules | Applies to all Items in the owning Organization. |
| Item Type rules | Any configured Item Type in the group may match. |
| Category rules | Any configured Category rule may match; descendants can be included. |
| Item Type + Category groups | The Item must satisfy both configured groups. |
| Lifecycle | Active for current use; Inactive for retirement. |
| Delete | For unused mistaken definitions; used definitions are protected. |
| Bulk Delete | Rejected as one selected operation if a selected definition is blocked. |
| Preferred downstream reference | Attribute Code. |
Related pages
Frequently asked questions
What does UDA mean in AkshaERP?
UDA means User Defined Attribute. It is a governed additional Item characteristic defined by an Organization when the standard AkshaERP Item master does not already contain the required business-specific field.
Is UDA the same as adding a custom database column?
No from a user perspective. Administrators define the characteristic through Item Custom Attributes and then maintain values on applicable Items without treating every new characteristic as a new standard Item field.
When should I not create a UDA?
Do not create one when AkshaERP already has a standard field or dedicated function for the same meaning, such as SKU, Item Category, UOM, HSN/SAC, dimensions, weight, supplier setup or barcodes.
What is the difference between Attribute Code, Attribute Name and Label?
Attribute Code is the stable configured identity, Attribute Name is the permanent canonical business name, and Label is the user-facing wording that can be improved later without changing the identity.
Can I rename an Attribute Code later?
No. Attribute Code is permanent after creation. Use Label when the display wording needs to change.
What Data Types are supported?
TEXT, NUMBER, DATE and BOOLEAN. The Item entry control follows the Data Type and, for TEXT, the configured Entry Mode.
When should I use a Static List instead of a Value Set?
Use a Static List for a small choice list that belongs only to that UDA. Use a Value Set when the controlled codes should be centrally maintained or reused.
Can a numeric UDA have a unit?
Yes. NUMBER definitions can optionally use an active Inventory UOM so users understand whether the value represents MM, V, KG or another maintained unit.
What does Required mean?
Required means required when the UDA applies to the Item. An unrelated Item that does not match the applicability rules does not need that value.
How do I apply an attribute to a whole Category family?
Add a Category applicability rule and enable descendant inclusion. Items in that Category and its descendants can then use the UDA, subject to any Item Type rules also configured.
What happens if I configure both Item Type and Category rules?
The Item must match at least one configured Item Type and at least one configured Category rule. Within each group, any configured value can match.
Why can a new unsaved Item initially show more custom attributes?
Before the Item has its saved identity, the Attributes area can show active Organization definitions while classification is being finalized. Save or Apply the Item; the saved Item view then shows the current definitions applicable to its Item Type and Category.
Why is changing Item Type or Category sometimes blocked?
The change may make an existing populated UDA non-applicable, or it may introduce a newly Required UDA. Review and correct the Item custom-attribute values before completing the classification change.
Can I change a UDA from TEXT to NUMBER after Items already use it?
No. Once Item values exist, changing Data Type would change the meaning of stored business data. Create a new definition or use a controlled conversion process instead.
Should I Delete or make a UDA Inactive?
Delete only an unused mistaken definition. Use Inactive to retire a definition that has Item history or has become part of the business configuration.
Can UDA values be used outside the Item screen?
Yes where supported. Governed Item attributes can be consumed by documents, reports, integrations and configured Item-attribute-aware rules. New configured references should prefer the stable Attribute Code.
Can another Organization edit UDA values on a shared Item?
Sharing does not transfer Item ownership. The owning Organization remains responsible for maintaining the Item master and its custom-attribute values.