Setting up catalog parameters
The Catalog Setup card controls global rules, defaults and infrastructure that Pimics uses throughout the solution. Many of the values are just pointers to other records (number series, templates, checklists, etc.), but a few change behaviour dramatically when switched.
General tab
Fields in this tab are shown at the top of the card and are mostly single‑valued defaults:
Default Language Code – the language that is treated as the base language for all catalog content. Changing this value triggers a confirmation dialog, then updates the
Language Code Basefield on every record inPIMX Catalog TranslationandPIMX Description Text Transl.. The new code becomes the “source” language when the translation helpers and API helpers run. If you select a code that already exists on translations the old base entries will be overwritten.Group System Intern – a link to a
PIMX Group Systemrecord used for internal group calculations. The value is used by allocation logic and may be left blank if you do not have an internal group system.Unit ID Projects – points to a
PIMX Unitthat is used for project identifiers.Output Format Features – selects the default output format for feature lists when publishing (e.g. line‑separated, comma‑separated, …). It determines how feature values are rendered in document templates and exports.
Extended Desc. Class Texts – default description class for extended text records.
Campaign No. – default campaign code that will be filled in on new items. It is simply a
Campaigntable relation.Exchange Item Translations – controls whether item translations are kept in the Pimics catalog, transferred to the Business Central item table, or synchronised both ways. When the option is changed to Always you are prompted to copy all existing catalog translations into the BC Item Translation table (
PIMX Translation Management.AllCatTranslToBCItemTransl()).Substitution Blank‑Value Tab – two‑character code used by the import/export substitution routine for blank values.
Version Number / Subversion No. / Preparation Version No. – three numeric fields that can be used by external processes (API, publication, etc.) to stamp the “version” of the current catalogue data. The preparation version controls whether the version number or subversion number is shown first in generated identifiers.
Modification on Certified Item – when item data is changed while the item is in Certified or Partially Certified system status, Pimics can either switch the status back to Process (forcing re‑certification) or leave it untouched. The behaviour is controlled by the
PIMX Certified Item Switchenum:- Switch always to Process – any PIM field change (including channel, item group, inherited features, etc.) or changes to related tables listed in the picture below cause the status to revert to Process.
- Do nothing – updates are allowed without altering certification.
The same setting exists on Modification on Certified Category and works on category records.
Modification on Certified Category – same as above but for category records.
Descriptions to Channel Alloc – when enabled Pimics stores item/channel descriptions on the channel‑allocation records. Disabling it will clear any non‑manually‑created descriptions – you are warned before the switch is saved.
Label in Category Tree – determines which piece of information (e.g. code, description, number, or combination) is shown as the label of each node in the category tree on the website or in the tree views.
Sort Order in Category Tree – defines the default sort order (alphabetical, code, number, …) used when rendering the tree.
After Merge Class – used by the product‑feature merge report. Options are Keep original (leave the feature class on the surviving record), Keep failed (keep the class only on the record that failed to merge) or Delete (remove the class from both records).
History tab
Only visible when the PIMXBeta application area is enabled. Controls how many historic versions are retained:
- Keep Item Versions – determines whether old versions of items are kept after changes.
- Keep Category Versions – same for categories.
- Keep Digital Asset Versions – same for digital assets.
Values are taken from the PIMX History Keep Versions enum; removing history can save space but cannot be undone.
Allocations tab
This tab consists entirely of Code[20] fields pointing at checklist headers, number series and other master records that are used by the allocation engine:
- Publication Item, Item Group Publication Group, Publication Gr. Product Group, Publication Group Chapter, Catalog Gr. Publication Group, Publication Item Reference – defaults for the various publication‑allocation tables. When an item, group or chapter is allocated to a publication or catalog group the code in these fields is filled in automatically.
- Standard Description Class – default description class used when creating allocations.
- Master Data Company – company name used by the master‑data interface.
- Catalog Descriptions – checklist used for catalog descriptions.
- Multi Allocation Item Group / Product Group / Chapter / Publication Group / Catalog Group – allow more than one allocation of that type per object. For example, if Multi Allocation Item Group is on an item may belong to several item groups simultaneously.
- Master Data Link / Master Data Receiver – control behaviour of the real‑time sync with the master‑data service.
- Allow CAG Insertion Everywhere – if set items may be inserted into a catalog group at any level, not only under their normal parent.
- Sync. to Attributes – enabling this causes allocation changes to be written to the attribute tables; disabling stops that synchronisation.
- Delete Standard Allocation – when checked, removing the standard allocation from a parent record will also delete the corresponding allocations on all descendants.
Each field has a tooltip which is displayed on the page; the actual table relations enforce the lookup to the corresponding record types (checklists, templates, etc.).
Inheritance tab
Controls which data is passed down the category hierarchy when a child is created or updated:
- Delimiter Char for Inheritance – developer option (only visible in the
DEVbuild) specifying the separator used in the inherit‑path fields. - Inherit Duplicates – enum controlling what happens when a new entry from a parent already exists in the child (keep both, overwrite, error, …).
- Inherit Delete – defines what occurs when a parent entry is deleted: cascade delete, unlink only, etc.
- Inherit Short Descriptions / Inherit Descriptions / Inherit Classes / Inherit Features / Inherit Feature Values / Inherit Keywords / Inherit Pictures / Inherit Documents / Inherit Graphics / Inherit Media / Inherit CAD Drawings / Inherit References – boolean switches determining whether the corresponding piece of data (description text, classification, features, keywords, images, documents, graphics, media files, CAD drawings, cross‑references) is copied from the parent category when it is created or when the parent changes. When Inherit Classes is turned off the two dependant switches Inherit Features and Inherit Keywords become read‑only and are automatically reset to
falseby the OnValidate trigger; turning Inherit Classes on again validates the other two totrue.
Numbering tab
All fields on this page are links to No. Series codes used for automatically generating numbers for the corresponding types of records:
| Field | Usage |
|---|---|
| Cataloge Numbers Sales | catalog number on item card |
| Publication Numbers Sales | publication numbers |
| Group System Numbers | internal group system codes |
| Extended Text Numbers Sales/Purchase | extended text identifiers |
| Table Numbers / Table Template Numbers | miscellaneous tables |
| Request Numbers, Activity Type Numbers, Activity Numbers | workflow and activities |
| Item Group Numbers Sale, Product Group Numbers Sales, Chapter Numbers, Catalog Group Numbers Sales | groups and chapters |
| Publication Template Numbers, User Numbers, Role Numbers, Publication Groups Numbers | various templates and roles |
| Content Header Numbers | heading identifiers |
| Content Template Nos. | content template identifiers |
| Product Features Nos., Variant Nos., Class No. Series, Feature No. Series, Feature Group No. Series, Value No. Series, Unit No. Series, Pimics Rules No. Series | feature, variant, classification and unit numbering |
| Project Nos. (same as Project numbers) | project numbering |
A new record created by Pimics uses the selected series; make sure the series has Allow Gaps enabled if you will be generating numbers out of sequence. The preparation and update code in the table validates that Content Header Numbers series permits gaps, for example.
Checklists tab
This tab defines the default checklists and validation rules Pimics uses when processing items, groups, and other objects:
Empty object handling – specify what happens when an item, group, asset, or classification has no checklist attached:
- Checklist Empty Item / Checklist Empty Group / Checklist Empty DAM / Checklist Empty Classification – choose from Certify, Check, Warning, or Error.
Default checklists – select the checklist template to use for each object type:
- Items, item groups, product groups, chapters, catalog groups
- Extended text, group systems, templates
- Documents and digital assets (pictures, graphics)
- Purchase items, publication groups, tables
- Users and roles
Function number series – configure numbering for checklist-generated functions:
- Validate Function Numbers / Lookup Function Numbers / Version Function Numbers
Approval workflow – Default Pipeline sets the approval process for new requests.
Tip: Leave a lookup field empty to skip that checklist step.
Templates tab
The fields here specify which template should be used by default when creating new templates for the given object types (template header codes in PIMX Template):
- Standard Template
- Item Group Standard Template
- Product Group St. Template
- Chapter Standard Template
- Standard Catalog Gr. Template
- Publication Group St. Template
- Standard Picture Template
- Graphic Standard Template
- Standard CAD Drawing Template
- St. Extended Text Template
- New Page Standard Template
- Standard Page Template
- Table Header St. Template
These defaults are only applied when a new template record is inserted; changing an existing template does not retro‑actively affect documents already created.
Translations tab
- Confirm Activity Resolution – when enabled users are asked to confirm when they mark a translation activity as resolved.
- Translation API Type – selects which external translation provider to call (if any) when performing automated translation.
- Translation API Auth – credentials or key used by the chosen API.
- Language Variants – controls how Pimics treats language variants (e.g.
en‑GBvsen‑US) when looking up translations; options are Strict / Fallback / Ignore.
Database tab
Read‑only information pulled from codeunits and license service:
- Database Type – shows Development, Test or Production depending on the connection.
- State – current implementation state of the Pimics extension.
- License Valid To – expiry date of the Pimics license. Clicking the field displays the full license message.
- Is on‑premise – indicates whether BC is running on‑premises.
- Pimics Edition – indicates which edition was licensed (Standard/Enterprise/etc.).
- Pimics Version – version of the Pimics code. Drill‑down shows full major/minor/build/revision.
Developing & Debug options tab
Only to be used by Allium or developers:
- Data Change Log Enabled – if checked every change made by users is recorded in the data change log. Toggling this setting displays a reminder that users must log out and back in to take effect.
Languages in Pimics
This is a subpage where you can maintain the list of languages Pimics knows about. Each language is used on translations and extended texts.
Application Area
Another subpage; enable or disable broad functional areas of the Pimics extension. Turning areas off may hide pages and features for your users.
Note: the card also contains actions (Install, New License, Toggle Inheritance, Enable/Disable Pimics, etc.) used during setup.
This documentation is generated by inspection of the AL objects behind the card; tooltips shown in the code are reproduced here and behaviour confirmed by OnValidate triggers and related codeunits.