Product documentation
Important
The required setup in standard Microsoft Dynamics 365 for Finance and Operations tables is limited to enabling warehouses and the coverage group of the item.
Optionally units can be assigned to specific packaging levels and specific EOQ units
Optionally specific customers (e.g. IC) can be excluded.
Warehouse management > Setup > Masterplaning parameters
Advice is to use a specific master plan for the Slim4 Integration planned orders.
Important
Warehouse management > Setup > Warehouse > Warehouses
| Field | Description | Remark |
| Slim4 active | Active for Slim4 | If switched on, this warehouse is used in export to Slim4 |
Important
Master planning > Setup > Coverage > Coverage groups > tab: General
| Field | Description | Remark |
| Review time |
Frequency of reviewing planned orders (in days). The review time is defined on the coverage group. If not filled, the review time defined on the vendor is used |
Expensive, irregular-demand, large or perishable items need to be reviewed more often |
|
Planning |
Leading application for planning the items in this coverage group |
For Slim4 Integration choose between stock item and non-stock item. This is exported in the Logistics file export. This setting does not relate to the Stocked product setting on the item model group. |
Note
Note that the default setting for planning is Microsoft Dynamics 365 for Finance and Operations , so the released products will not be planned in Slim4 yet.
If the majority of released products should be planned in Slim4, go to the master planning parameters, General coverage group. In that coverage set Planning to Slim4 stock item (or non-stock item).
Setting a coverage group to Planned by Microsoft Dynamics 365 for Finance and Operations impacts all export files (as items linked to that coverage group are not included in the exports).
Organization administration > Setup > Units > Units
| Field | Description | Remark |
| Unit conversion Slim4 services |
Default value is zero: no conversion needed if D365FO inventory unit is m and Slim4 calculates in cm: set 100. |
Legacy customers only |
|
EOQ logistics unit |
Logistics: conversion factor from inventory unit to this unit can be mapped to field EOQ logistics unit 1..6 |
If Euro pallets and block pallets are different units, both can be mapped to the same EOQ unit in Slim4. If the same product has different conversion factors to Euro pallet and block pallet, the first found is exported. |
|
Unit level |
Defines whether this unit represents Piece, Inner box, Outer box, Pallet layer Pallet, Container, Truck load. Based on this Unit level the Share in pallet, share in pallet layer etc. can be mapped. E.g. If 1 pallet = 20 pieces, then share in pallet = 0.05 |
If Euro pallets and block pallets are different units, both can be mapped to the same Unit level. If the same product has different conversion factors to Euro pallet and block pallet, the first found is exported as Share in pallet to Slim4. |
Accounts receivable > Customers > All customers > Fast tab: miscellaneous details
| Field | Description | Remark |
| Exclude from Slim4 Integration | Exclude orders and transactions during export to Slim4 Integration |
Warehouse management > Setup > Inventory > Inventory statusses
| Field | Description | Remark |
| Exclude from Slim4 Integration | Inventory with this inventory status will be excluded from the Stock details export | Note that Slim4 Integration does not have the concept of inventory status. Therefor in the export, the inventory is aggregated over all statusses that are not excluded from Slim4 Integration |
Slim4 Integration integration > Setup > Slim4 Integration integration parameters
| Field | Description | Remark |
| Export data management group | Export data management group, i.e. export project that contains the Slim4 export entities that push data to the database |
|
Exclude negative sales lines |
Exclude negative sales lines from Confirmed demand |
Sales return orders (RMAs) are never exported |
|
Transaction export number of days |
Export of transactions in the past n days |
E.g. 7 days. Around company holidays, change to e.g. 28 days temporarily. NB: for the initial PO history upload which should cover typically 730 days, use the Initial export. |
|
PO history export number of days |
Export of purchase order history in the past n days |
E.g. 7 days. Around company holidays, change to e.g. 28 days temporarily. NB: for the initial PO history upload which should cover typically 730 days, use the Initial export. |
|
Export GDPR data |
For customers with type Organisation, export the name and the address on the Transactions and Confirmed demand |
For customers with type = Person (natural person), the name and street will never be exported. Only city and country are exported. |
|
Max records per task |
Maximum number of records each task will process, if 0 then the system will default to a 1000 records |
|
Import processing mode |
Batch processing or direct processing |
The data is always staged in the Planned order import table, and can be converted to planned orders immediately or through the batch process Create planned orders |
|
Plan |
Master plan in which the Slim4 planned orders are imported |
|
Status |
Status of the imported planned order |
Unprocessed, completed or approved |
|
Apply rounding |
Apply the Microsoft Dynamics 365 for Finance and Operations rounding rules on the Slim4 planned orders |
|
Buyer group |
If specified in the parameter, this buyer group will be filled on planned orders. Else use buyer group from released product |
|
Webservice - URL |
The webservice that posts planned orders must validate the validity of additional import data fields |
|
|
Tenant |
||
|
Client ID |
||
|
Scope |
||
|
Client ID secret |
||
|
Function key |
Slim4 Integration integration > Setup > Export > Export interface setup
Note
This form contains the main setup of the different interfaces. It is possible to switch off elements in the interface, and select price methods.
Slim4 Integration integration > Setup > Warehouse groups Slim4
Note
With multiple warehouses and many items, the number of theoretical item warehouse combinations is large. E.g. frozen peas and peanut butter should both be planned by Slim4 Integration, but frozen peas are only relevant in the freezer warehouse, and peanut butter only in the grocery warehouse.
To reduce the amount of data that is exported to Slim4 Integration, the relevant combinations of items and warehouses can be maintained in an efficient way through warehouse groups. E.g. a warehouse group Frozen, DCs only, DCs + large stores, etc.
The warehouse group specifies the valid combinations of items within a group and warehouses. Within the warehouse group, for each warehouse a coverage group can be set. The coverage group can have a planning type Slim4 Stocked, Slim4 Non-stocked or Finance and operations.
On the Released product, fast tab Plan, a warehouse group can be selected. If no warehouse group is selected, there is a fall-back to the default warehouse group parameter in the Export interface setup - Article filter.
Slim4 Integration integration > Setup > Warehouse groups Slim4 - Exceptions
This form specifies the exceptions to the warehouse group, e.g.
Exceptions can also be used without warehouse groups.
Slim4 Integration integration > Setup > Export > Field mapping
This form displays the key fields and the user mappable fields per data set. When a new release is installed, press Update field mapping. This will retrieve new configuration options and will not modify existing field mapping setup.
For the article code master it is possible to setup automatic mapping of existing fields from the item table to UDF fields, Criterium fields and Analysis codes and other fields that are indicated as User mappable.
Field mapper
In the lower grid, column Name, select Field mapper, and through the button Parameters, specify a table (Items, Item module parameters - Inventory / Purch / Sales, Warehouse items, PLC status) and a field.
This field can be a standard field (Product life cycle state or inventory unit), and ISV field (Business rule status or AWHS quantity per pallet) or a customized field on InventTable or InventTableModule.
If the field contains a record ID, and the table to which this record ID refers can be identified, the field mapper will open an extra selection box where a field from the reference table can be selected. E.g. for the blocking reason description.
In the field mapping a lot of standard Microsoft Dynamics 365 for Finance and Operations table fields can be mapped to Citeria 1-8 (numeric fields), Analysis code 1-6 (string fields), User defined fields 1-15 (string fields).
A numeric value can be mapped to a string field.
Item category hierarchy
Default (and site specific) order settings
If order settings are overridden on site level, these settings are exported. Fall back to default order settings. Purchase units are converted into inventory units. Product variant level specific settings are not exported.
To export the warehouse, first select the field InventDimIdDefault, and then select the field InventLocationId.
Unit level
This is the reciprocal value of the quantity per pallet: quantity per pallet = 20 -> share in pallet = 0.05
Alternative is to export the factors in the EOQ logistics unit, especially when a pallet contains more than 100 ea etc.
If an automatic field mapping is specified for e.g. UDF 1, field UDF 1 will be sent to the article code master staging table as defined, and is no longer editable manually through the Article code master additional data form.
On these data sets, four different fields can be mapped to Free text 1, Free text 2, Free number 1, Free number 2.
Note that on the Transactions, these fields are named Transaction free field 1..4.
When the related field contains a record ID, in most cases it is possible to map the friendly value behind it. E.g. the name of the sales taker can be exported in free text 1.
Also business rule status and custom fields can be exported.
Examples:
Sales order taker: SalesTable.WorkerSalesTaker -> HCMWorker -> DirPerson.NameAlias
Sales order responsible: SalesTable.WorkerSalesResponsible -> HCMWorker -> DirPerson.NameAlias
Business rule status: SalesTable.DYSBRLStatus or PurchTable.DYSBRLStatus
Slim4 Integration integration > Setup > Field mapping
In projects on Slim4 Integration requirements can occur that are not part of the standard interface. E.g. the gross physical dimensions, the number of unique customers for this product in the past 24 months, or exporting customized fields etc.
For each UDF, Criterium, Analysis code field, choose one of the following options:
As described above in the Export interface setup, automatic field mapping can be specified for UDF fields 1..15, Criteria 1..8, and Analysis codes 1..6 in the Article code master for fields in the item table, products table or item module parameters, PLC status table, vendor table, external item data.
If any of these fields are already present in the article code master additional data, first blank these field values for each item before you can setup an automatic field mapping.
Through data entiy or manual Excel upload. Only possible for fields that are not mapped in the field mapper.
Only possible for fields that are not mapped in the field mapper.
There is an extension point in the Slim4 webservice interface that X++ developers can use to add customer logic that can update the data for Slim4. This code will be run as part of the update batch job. It will be started after the standard update jobs finish but before the DMF job starts that sends the data to the BYOD database.
To get an extension up and running the developer should add a class that implements the interface DYSSlim4ServicesIExportUpdateExtension. This interface contains 4 simple methods that the developer needs to implement. In the source code of this interface I described what these methods are supposed to do.
Based on the extension classes created the system will dynamically update the dialog of the batch job and add buttons for invoking your extension code.
Low-coding examples are available on request.
Slim4 Integration integration > Setup > Import > Additional import fields setup
In this extendable framework extra data can be passed from Slim4 Integration to Microsoft Dynamics 365 for Finance and Operations , together with the planned orders.
Create a new version and specify one or more field names. These field names can or must be present exactly with the same name in the JSON data that is posted by the webservice from Slim4 Integration.
Activate the version. This will automatically deactivate the older version if present.
Post the webservice planned orders.
The additional fields are imported into a sub table of the planned order import table, and this additional data can be used through customization.
Note