.png)
Name your own fields across nine AIMS360 modules in three types, then sort, filter, export and report on them. Plus System Fields, which set default values and mandatory fields on new customers, orders and invoices.
Every brand tracks something the software did not ship with. A sustainability claim, a buying group, a container number, the wash house that did the job. In AIMS360 you add those as real fields, custom fields or user defined fields depending on which ERP you came from, on styles, customers, orders, purchase orders, cut tickets and more, then sort, filter and report on them like anything else. No developer, no side spreadsheet.
Yes. Custom fields, user defined fields, UDFs: same thing, different vendor vocabulary. In AIMS360 they are built in Field Customization, a module under the Setup menu, and it adds your own named fields to nine parts of the system: styles, style color size, customers, customer orders, vendor purchase orders, cut tickets, garment dye, pick tickets and materials. You name the field, pick one of three types, and it appears in that module for every user. Nothing is quoted, scoped or scheduled.
It started as styles only and grew module by module as brands asked, which is why the list looks like the places apparel and consumer brands actually keep their own private taxonomy.
What brands actually put in them, by module.
| Module | What brands use it for |
|---|---|
| Styles | Season detail, fabric family, factory, sustainability claim, licensing, whatever your merchandising team sorts by. Up to ten dropdown categories here. |
| Style color size | The same categories one level deeper, so a single colorway or a single SKU can carry its own code. Rows can be batch updated from that screen. |
| Customers | Buying group, territory, retail vs wholesale flag, compliance program, onboarding stage. The fields your sales team wishes the customer list had. |
| Customer orders | Program name, promotion, event, internal approval reference. Anything that tells you later why an order exists. |
| Vendor purchase orders | Container, booking reference, freight forwarder, inspection date. The detail that lives in email today. |
| Cut tickets | Contractor, wash house, production line, quality check. Domestic cut and sew tracking that is specific to how you run. |
| Garment dye | Dye house, formula reference, lot notes against the dye job. |
| Pick tickets | Routing program, appointment number, staging lane, anything the warehouse needs on the paperwork. |
| Materials | Mill, content, certification, country of origin on the material record rather than in a spreadsheet. |
If the record you want to extend is not on that list, say so during your evaluation. The list has grown over time, and knowing which module a brand needs is how it grows.
A code of up to twenty characters with a description of up to fifty. Use this for anything you will group, count or filter by, because everyone picks from the same list instead of typing their own version.
Free form, up to 255 characters. Right for a reference number or a short description that is genuinely different every time. Wrong for anything you plan to report on.
A single date. It is labeled date and time, but only the date is stored. Type it or pick it from the calendar; enter a month and day and it assumes this year.
| Where | Custom fields |
|---|---|
| On the record | Yes. They appear in the module you added them to, on their own tab or alongside the standard fields, ready to fill in. |
| Saved views | Yes. Add them as columns to a view, then sort and filter on them like any built in field. They can go on the customer orders by line and invoice by line views too. |
| Excel export | Yes, through the export on that view. This is the route most brands use for a printed or shared report that includes custom data. |
| Business intelligence | Yes. Custom fields are available in the BI module, so a category you invented can be a dimension in a report you build. |
| Standard printed reportsNo | The reports that ship with AIMS360 do not include custom fields. If a custom field has to appear on a document, build a view and export it, or build it in BI. |
The practical workflow is: name the field, add it to a view, filter there, export or report from that. See grids and the report editor and the built in BI tool for the two ends of that.
The System Fields tab does something different from custom fields: it sets the behavior of the standard fields. You can give a new customer a set of defaults so it opens half filled in, and you can mark fields required so a record cannot be saved without them.
Preferred warehouse, division, terms, price tier, order status, ship via, sales rep and the invoice email options can all carry a default, so a new account starts from your house standard rather than blank.
Header fields on manually entered customer orders can be made mandatory. Orders arriving from an integration or the API are not affected, which is usually right and always worth knowing.
Tracking number can be made mandatory on invoices. Brands do this so nothing ships unreferenced. The trade is real: without a tracking number the invoice process fails rather than continuing.
Customers created through import data pick up your defaults wherever the template leaves a field blank, so a bulk load lands on the same house standard as a keyed one.
A required field cannot be bypassed. Not in the interface, not when editing an existing record, and not through the API. Require only what your team can always supply.
Do not default currency if you run multi currency. Currency cannot be changed once the customer is saved and orders exist against it, so a default that was wrong for that account becomes a support request rather than a quick edit.
If you default the automatic invoice email options, make sure an email address is saved too. Otherwise the system tries to send and fails on a customer that has nowhere to send to.
A few fields sit outside the customer import template and will not be set by a default on import: the invoice email To, CC and BCC options, carrier account numbers, additional freight charges, preferred payment method, default packing rule, and the shipping, packing and VAS notes. See customer contacts for how the email roles work.
It is under the Setup menu. Every available field is listed by entity, so sort by entity name to see just the ones for customers, or vendor purchase orders, or styles.
Double click an available slot and give it a meaningful name. Avoid any name that already exists in the style master: a custom field called Season will break style imports later. Style Season or Season Detail is safe.
Each value is a code of up to twenty characters plus a description of up to fifty. Add them all now rather than letting people request them one at a time, and keep the codes short enough to read in a column.
Go to the module and the named field is there. On styles it sits on the additional details tab, and categories can be set per color rather than only per style. Nothing is mandatory unless you make it so.
This is the step people skip. Add the field as a column to a saved view so the data is sortable, filterable and exportable. A field nobody can see in a list is a field nobody fills in.
Styles are the one record type in AIMS360 that can be updated in bulk from an Excel import, which makes backfilling a new category practical rather than theoretical. Name your fields first, then download the style template and your custom names are already sitting there as column headers.
The template is generated from your configuration, so anything you have not named yet still shows its default label. Finish the naming, then download.
Download the style template from the import data screen, then export your style master separately. Sizes are not needed for this.
Copy style, color, size scale, season, division and type into the template, then fill in the codes for your new categories. Keep the Field Customization screen open to check codes as you go.
On import, map the required fields and your named categories and leave everything else blank so nothing else on the style is touched. Validate, then import.
At style color size level there is a batch update directly on the screen, so a set of SKUs can be selected and given the same category, text or date value without going near Excel.
Worth saying twice because it catches people. The printed reports that ship with AIMS360 do not include custom fields. Views, exports and BI do. Plan the workflow around that rather than discovering it the week you need the report.
The style master takes up to ten. Most brands settle at four or five that everyone actually maintains, but if your taxonomy needs fifteen this is the wrong shape for it and we should talk about the data model instead.
Once a field is mandatory, nothing gets saved without it, through any route including the API. That is the point, and it is also the risk. Make a field required when the business genuinely cannot proceed without it, not when you would prefer people filled it in.
A text field will hold anything, which is exactly why it will not group. If the answer is a set of known options, make it a dropdown even when that feels like more work up front.
Yes, and they are the same thing: what most ERP vendors call user defined fields (UDFs), AIMS360 calls custom fields, and the module that builds them is Field Customization. It sits under the Setup menu, and it lets you add your own fields to styles, style color size, customers, customer orders, vendor purchase orders, cut tickets, garment dye, pick tickets and materials. You name the field, choose its type, and it appears in that module for everyone. No developer, no change request, no separate database.
AIMS360 does, across nine modules and three field types, plus a separate System Fields layer that sets defaults and mandatory fields on customers, orders and invoices. The practical test when you are comparing vendors is not whether custom fields exist but where they reach: whether you can filter and sort a list by them, export them, and use them in reporting. In AIMS360 they reach saved views, Excel exports and business intelligence, and they do not reach the standard printed reports.
Three. A dropdown, which holds a code of up to twenty characters with a description of up to fifty, so the data stays consistent instead of being typed differently by four people. A text field, free form, up to 255 characters. And a date field, which despite being labeled date and time only stores the date.
The style master takes up to ten custom dropdown categories. That ceiling is rarely the constraint in practice, but it is worth knowing before you plan a taxonomy that needs fifteen. Other modules have their own set of available fields, including text and date types.
No, and this is the most important thing to know before you build a workflow around them. The standard printed reports in AIMS360 do not include custom fields. What they do reach is saved views inside the module, the Excel export from those views, and the business intelligence tools. So the pattern that works is to build a view with your custom fields as columns, filter it there, and export or report from that.
Yes. Once a field is named it can be added as a column to a view in that module, and then sorted and filtered like any other column. Custom field columns can also be added to the customer orders by line and invoice by line views, which is where most of the useful cross referencing happens.
Yes. Custom fields are available in the AIMS360 business intelligence module, so a field you invented can be a dimension in a report you build yourself. See the built in BI tool and the grids and report editor for what that looks like.
Yes, and getting it wrong costs you an afternoon. Do not give a custom field a name identical to a field that already exists in the style master. If you want a season field that carries the year, you cannot call it Season, because that name already exists and it will break style imports later. Call it Style Season or Season Detail instead.
Yes, through the System Fields tab. On the customer master you can pre-set the values a new customer starts with, so preferred warehouse, division, terms, price tier, order status, ship via and sales rep are already filled in and only get changed when they need to be. Every default can still be overridden on the individual record.
Yes, on customers, on manually entered customer orders and on invoices. Use it deliberately, because a field marked required cannot be bypassed: not in the interface, not by an editor changing an existing record, and not through the API. If you require something your team cannot always supply, you have blocked the work rather than improved the data.
No. Order mandatory fields apply to customer orders entered by hand in AIMS360. Orders arriving from an outside integration or through the API are not affected. That is usually what you want, since an EDI or ecommerce order cannot answer a question your own team invented, but it does mean the rule is not universal.
Yes, and a lot of brands do. Be aware of the consequence: once tracking is mandatory, the invoice process fails if no tracking number is present. On a batch invoice run that means the batch stops rather than quietly producing invoices you cannot ship against. Do not set a default value on that field, because a default would defeat the point.
Yes, defaults are applied to customers created through the import data feature when the template leaves that field blank. A handful of fields sit outside the customer import template and will not be set that way, including the invoice email To, CC and BCC options, carrier account numbers, additional freight charges, preferred payment method, default packing rule, and shipping, packing and VAS notes.
Only if you sell in one currency. If you run multi currency, leave it unset. Currency cannot be changed on a customer once the record is saved and orders have been placed against it, so a default that was wrong for that account becomes a support ticket rather than an edit.
Yes. Styles are the one record type in AIMS360 that can be updated in bulk through an Excel import. Download the style template after you have named your fields and the custom names appear as column headers, paste in your style, color, size scale, season and division data, add the codes, and import. At style color size level there is also a batch update directly on that screen.
Field Customization sits under the Setup menu, so access follows your permissions. In most brands this is an administrator or a systems owner rather than every user, which is the right call: a field list that three people can add to on a whim stops being a taxonomy and becomes a mess.
Nothing. A field that has never been named still shows its default label, which is how you tell at a glance which ones are in use. Fields are not mandatory to fill in either, so a style with nothing in a category is simply blank rather than incomplete.
If you want to filter, sort, group or count by it, it should be a field, and a dropdown rather than text so the values stay consistent. If it is a sentence explaining a situation to a colleague, it should be a note. The mistake to avoid is a free text field holding data you intended to report on, because free text cannot be grouped reliably once four people have typed four versions of the same thing.
The one next to the ERP that holds the three things it does not track. Show us the columns and we will tell you which become custom fields, which become dropdowns, and which were never fields at all.
