The Category hierarchy is a crucial part of Advanced Search, not just for its tree (and related products) that form the base structure, but also as the location where the data to be included and the layout of the Search form/results is set up. The setup for Search on the Category hierarchy can therefore basically be divided in 2 main parts:
1) The data that gets uploaded to Azure (and thus becomes available for Search), is set up on the following tabs:
2) The functional setup to determine which information is displayed and how, is set up on the following tabs:
This distinction is good to keep in mind, as understanding it helps in realizing what order to set up (additions) in and where to start troubleshooting if there are issues.
The functional setup (part 2) can only be done if the fields exist in the Azure index (part 1). So when setup has been created/added to one of the tabs for the data upload, it is important to update the scheme of the index (or recreate it), so that the additions get added to the index, after which they can be selected for the layout etc.
It is also important to note that to create the Search related setup the Category hierarchy must always be opened via the search configuration. When opened via other paths, the Search related tabs do not show. So please make sure to always open up the hierarchy from within the Search configuration you want to create the setup for. (The same hierarchy can be used in multiple Search configurations; search setup made on the hierarchy is specific for the selected Search configuration.)
Note
When using multiple Category hierarchies for Product search, the same category node name cannot be used between hierarchies for the same level, as doing so will lead to incorrect counts and visibility of (released) products within Product search. We therefore recommend to not use the same category names at all across all Category hierarchies that are (also) used for Product search.
Note that this restriction does not apply to the 'friendly name' of the categories, so if required, it's possible to use the same category friendly names between multiple Hierarchies, even on the same node level. The category tree on the (Released) Product search form can display these friendly names instead of the 'true' category names by activating the 'Use friendly name' parameter on the Search configuration.
This tab displays information from the category. It cannot be edited, for that the Category hierarchy tree itself needs to opened (either via the shortcut button in the ribbon here or via the standard path).
This tab displays the products that are linked to the selected category. It is also possible to add or remove products from the selected category and to preview the search values that get generated for a selected product.
Making attributes available as a data source for Product search is done via the standard retail attribute framework. More information on attributes can be found here.
This tab is where attribute group(s) can be linked to a category, so that the attributes in the group apply to the products linked to this category.
Please note that for the Advanced Search functionality to work properly, it is highly advised for the attributes to be linked to the Category hierarchy via an Attribute group. Allthough linking attributes directly to a category is possible and supported, it more difficult to review and maintain, so please make sure to always use attribute groups if possible.
Please also note the 'Inherit from parent' option at the bottom of the fast tab, which enables the setting up of attribute groups on a higher level in the hierarchy tree and then letting it cascade down easily if applicable by activating this setting on the subcategory/subcategories. It also displays information to easily identify if the inherit function is activated on none, some or all underlying levels.
It's also possible to use category attributes as a data source for Search. Any category attributes must be added as part of an attribute group. Allthough linking attributes directly to a category is possible in the standard framework, this will not result in the desired search data for the Advanced Search functionality, so please make sure to always use attribute groups.
If a Category attribute group was added to a category, this tab displays the category attributes so that the value for the category attribute for this category can be set.
(Note that Category attributes always have the same value for all products linked to the category. Individual values for the attribute per product are obtained via the Product attributes.)
Almost any product related field in the system can be used as a data source for product search. To be able to access the data, queries are required. There are several default queries that come with the solution, but you can also create your own and/or edit the existing one. More information on this can be found in the Field search queries chapter here.
This tab is where the actually needed field(s) from the query are added so that the information is generated and uploaded to the index.
The fields that should be added to the index are added here by adding records with the + Add button. Removing records is done with the Remove button. Note that it is also possible to view and add translations (for the Azure fields) with the Language and Translations buttons.
Field | Description |
Translations complete | The icon displayed here indicates if all translations for this record are complete or not. |
Query | Select the Field search query to be used. |
Data source name | Select the relevant Data source (table) from the selected query. |
Field name | Select the Field from the data source that should be used (if applicable: if a method is used, leave this field empty). |
Method name | Select the Method from the data source that should be used (if applicable: if a field is used, leave this field empty). |
Azure search field |
Set the name of the field in the Azure search index. A name is proposed based on the used data source and field/method, but can be edited. Note that Azure only accepts lowercase letters for field names. |
Is composite | Indicates if the Azure field is a composite and therefore created as an array of fields. An array can contain more than one (1-to-many) value. |
Azure value type | Define if the Azure field can contain a single or multiple values. |
Category | Displays which Category this record has been set up against. Note that records can only be removed on the level that they were set up on. |
Please note the 'Inherit from parent' option at the bottom of the fast tab, which enables the setting up of Field search fields on a higher level in the hierarchy tree and then letting it cascade down easily if applicable by activating this setting on the subcategory/subcategories. It also displays information to easily identify if the inherit function is activated on none, some or all underlying levels.
Some product related information is difficult to gather via the Field search queries, due to a complicated relationship for example or maybe even because the information is from a different source than D365. With Custom search this information can still be included in Search. A couple of default options are built in to the solution (such as Customer and Vendor product ID's, Site On hand information and Trade agremeent base sales price) and they can be used as a guide to create your own additions.
This tab is used to define which Custom search sources are added to the index.
Field | Description |
Translations complete | The icon displayed here indicates if all translations for this record are complete or not. |
Custom search source | Select the Custom search source to be used. |
Description | Displays the Description given to the Custom search source |
Azure search field |
Set the name of the field in the Azure search index. A name is proposed (for the built in options), but can be edited. Note that Azure only accepts lowercase letters for field names. |
Category | Displays which Category this record has been set up against. Note that records can only be removed on the level that they were set up on. |
Please note the 'Inherit from parent' option at the bottom of the fast tab, which enables the setting up of Custom search fields on a higher level in the hierarchy tree and then letting it cascade down easily if applicable by activating this setting on the subcategory/subcategories. It also displays information to easily identify if the inherit function is activated on none, some or all underlying levels.
When performing a search with Azure Advanced Search the results are displayed as a sort of item cards. With the Azure search layout fields the layout for these cards is specified: it determines which data (coming from attributes, fields or custom search) is shown where on the card, with a few formatting options as well. This gives the flexibility to display and emphasize the data that is important to you and your company.
The fields and their position on the result card are defined by adding records with the + Add button. Removing records is done with the Remove button. Note that it is also possible to view and add translations for the used field labels with the Language and Translations buttons.
The 'Load defaults' button can be used to quickly load a default basic layout setup. This is both a good option for getting started with search as for quick test scenarios.
Field | Description |
Translations complete | The icon displayed here indicates if all translations for this record are complete or not. |
Field type | Select if this is an 'Azure field' type field (data available from the Azure index), a 'Calculated' type field or an 'Input' type field. Azure fields are for data that is being fetched from the Azure index. Calculated fields are for information that is taken (and calcuated) from the system itself. More information on the available calculated fields can be found here. Input fields are for records that allow for information to be put in. |
Index field |
Select the field to display (based on the name of the field in the Azure Search index) on the result card. Only applicable if the Field type is set to 'Azure field'. |
Collection | Select the calculated fields collection. This field is only applicable if the field type is set to 'Calculated'. |
Calculated field | Select the calculated field to display. This field is only applicable if the field type is set to 'Calculated'. |
Id | Select this option to specify that this is the default keyfield (identifier) for the retrieved record. |
Title | Select this option to specify that this field is the main title. The title will be displayed on the result card in a larger and bold font. |
Style | Select the display style for the field. |
Value range | If a value range should be applied to this field, select the desired value range here. |
Line number | Defines the line number of the record. This dictates the order in which the records are shown. Can be adjusted if required. |
Inherited from | Shows the category from which this record is inherited. If the record is set up against the current level, it shows the current level category name. Note that records can only be removed on the level that they were set up on. |
Please note the 'Inherit from parent' option at the bottom of the fast tab, which enables the setting up of layout fields on a higher level in the hierarchy tree and then letting it cascade down easily if applicable by activating this setting on the subcategory/subcategories. It also displays information to easily identify if the inherit function is activated on none, some or all underlying levels.
There are several collections of calculated fields available as-is in the solution. Below a short description of the fields found in the currently availble collections:
Variants
This collections holds variant-specific information. Note that for this to work, it needs to be used in a style that allows for the mapping of a key field (List with key) and the key field has to be mapped to the variant number.
System
This collection contains the main image for an item and can be used when the parameter 'use category layout for image setup' is activated on the Search configuration parameters.
Product search
This collection holds fields with information regarding products. Currently available are the total (company) on-hand quantity, location specific on-hand quantity, trade agremeent base price and/or customer price (if context is known) and the margin. Some more information regarding the on-hand quantity fields can be found here.
With the product pricing collection it is possible to show real time calculated price information (non-retail only) in the product search form based on the context of the sales order or sales quotation. When product search is opened from the sales order or sales quotation the prices will be shown in the context of the selected order. It will look for the prices setup for the order account of the order. The following values can be shown in the product search form:
Note
Be aware these fields are being calculated real time and can have a (severe) performance impact on loading of the product search form. If there is no need to see these prices directly, it's better to put them in the Extended view of the layout. This means the values are only calculated when you expand the item card of the selected product.
In case there is an error in the price calculation a '-' sign will be shown and the error message is be shown in the tooltip (=hoover).
For troubleshouting there is a form (mi=DYSPRCSalesPriceCalculator) which is not put into any menu but it can be used to verify whether the issue is related to Microsoft Dynamics 365 for Finance and Operations or to the react control (=Product Search) form. If the output is correct in the DYSPRCSalesPriceCalculator then the issue is related to the react control. If the mi=DYSPRCSalesPriceCalculator form does not show the expected prices and discounts it's related to the way this class is fetching the prices and discounts.
Remark: In the current version the following Price and Margin Management features have not been implemented in the calculated fields for Product Pricing:
Please also note that the following fields/functionality is currently not supported:
Setup here determines which Azure fields will also be displayed as filters in the filter section of the search form (left hand side, below the category tree).
The filters are defined by adding records with the + Add button. Removing records is done with the Remove button.
Field | Description |
Index field | Select the module this setup is relevant too. (Relevant only if Advanced Search is implemented for multiple modules, otherwise the value defaults with the only one available.) |
Filter type |
Select the field (/attribute) to use as a filter (based on the name of the field in the Azure Search index). |
Value range | Defines the label that is displayed on the filter for this field. It defaults to the label of the selected field and can be adjusted if required. |
Override setup | When activated, the default filters behaviour (as defined in the configuration parameters) is overridden and needs to be specified at filter level (in the following columns). |
Filtering mode | If the override setup has been activated, the desired filter mode can be selected here. Otherwise it shows the valid default setting from the configuration parameters. |
Values sorting | If the override setup has been activated, the desired value sorting option can be selected here. Otherwise it shows the valid default setting from the configuration parameters. |
More button | If the override setup has been activated, the more button threshold number can be set here. Otherwise it shows the valid default setting from the configuration parameters. |
Line number | Defines the line number of the record. This dictates the order in which the records are shown. Can be adjusted if required. |
Inherited from | Shows the category from which this record is inherited. If the record is set up against the current level, it shows the current level category name. |
Please note the 'Inherit from parent' option at the bottom of the fast tab, which enables the setting up of filter fields on a higher level in the hierarchy tree and then letting it cascade down easily if applicable by activating this setting on the subcategory/subcategories. It also displays information to easily identify if the inherit function is activated on none, some or all underlying levels.
Note that a filter will only show up on the left hand side of the Search form if it has been set up on the currently selected category level or a higher one. Filters set up on a lower level will show up once that level or a lower one is selected in the category tree.
Note
Search sorting allows for the creation of different sort orders for the Search results, for example alphabetically by product name.
Adding records is done with the + Add button. Removing records is done with the Remove button. Note that it is also possible to view and add translations for the used field labels with the Language and Translations buttons.
Field | Description |
Translations complete | The icon displayed here indicates if all translations for this record are complete or not. |
Index field | Select the field from the index that should be used for the sort order. For example, select entityName to sort the results based on the Product name. |
Sort order |
Select the sort order to be used. It can be either ascending or descending. |
Field label |
Set the label that should be used for this sorting method. If for example entityName was selected as the index field and the sort order is ascending, the label could be 'Name A-Z'. If the sort order was set as descending, the label would be 'Name Z-A'. |
Line number | Defines the line number of the record. This dictates the order in which the records are shown. Can be adjusted if required. |
Inherited from | Shows the category from which this record is inherited. If the record is set up against the current level, it shows the current level category name. |
Please note the 'Inherit from parent' option at the bottom of the fast tab, which enables the setting up of filter fields on a higher level in the hierarchy tree and then letting it cascade down easily if applicable by activating this setting on the subcategory/subcategories. It also displays information to easily identify if the inherit function is activated on none, some or all underlying levels.
There are several important functions for Search that can be accessed via the ribbon within a Search configuration.
Shortcut to open up the Category hierarchy, which allows for the tree and level information such as the friendly name to be edited.
This button publishes the definitions of the Search form. This job creates the layout, filter and sorting definitions that determine what the Search form displays.
Whenever any changes have been made to any of these parts (Search layout, Search filters, Search sorting), the definitions will need to be published (again) for the changes to come into effect. Note that this 'Publish definitions' option is completely silent. It happens in the background without any start or end notifications (which the button from the Search configuration will give you).
Also note that if no (layout) setup has been made and/or published, a (very) basic fall-back layout is used.
The 'Update inheritance' option that can be found on the Category section of the ribbon is a quick and easy way to activate or disable the 'Inherit from parent' setting on the current category level and all underlying ones.
Select the level in the tree from where you want to update the setting and then click the 'Update inheritance' item. A dialog opens where you determine if the setting should be disabled (by activating or disabling the setting) and selecting for which tabs this update should be performed. Then simply click 'OK' and the update will be executed on the current and all underlying levels. This process can be repeated at any time (for example after new categories have been added to the hierarchy).