System requirements and administration
Purpose
This page complements the general setup guidance with prerequisites and the administrative baseline. It describes the licensing and operating prerequisites, explains how barcode components should be understood, and outlines the administrative functions for record types, keys, and XML-based import and export.
1. Check system requirements carefully
Automotive can only run reliably when product licensing, app status, and technical supporting components fit together. The legacy documentation explicitly distinguishes between on-premises and cloud scenarios.
| Topic | What must exist | Why it matters |
|---|---|---|
| Business Central and module enablement | matching BC base and enabled Automotive modules | Without this baseline, functions may be visible but not fully usable |
| Cloud operation | installed app and active module licensing | Cloud projects do not follow old local installation assumptions |
| On-premises operation | additional local technical components depending on project scope | Legacy processes like local fonts or DLL-based barcodes depend on them |
| Barcode generation | service connection or historically local barcode components | Many automotive reports and labels require machine-readable barcodes |
2. Classify barcode basics correctly
Historically, Automotive used installed barcode fonts such as Code39 and Code128 in on-premises systems. For 2D barcodes like PDF417, an additional program was required.
For current projects, the important points are:
- barcode fonts are a legacy concept from local installations,
- in modern SaaS and Universal Code scenarios, service-based barcode generation is the relevant path,
- even where on-premises still knows local methods, project planning should no longer rely on local font logic alone.
Key rule: the real question today is not just whether a font is installed, but whether the chosen barcode path fits the operating model and product version.
3. Administration: record types and keys
Under administration, functions are grouped that matter mainly for system foundation and later maintenance of core tables.
Record types
Record types describe internal identifiers, partly following VDA. They are essential for data structures and data transfer between systems.
For users and key users, this means:
- do not change record types freely,
- do not reinterpret VDA-related structures locally,
- make adjustments only with a clearly agreed technical and business decision.
Keys
Keys are used to manage VDA-defined values. At initial setup the baseline is usually prefilled, but later additional values may be needed, for example for:
- further currencies,
- additional units of measure,
- preference indicators,
- project-specific additions within the VDA framework.
Whenever keys are extended, use the official code from the respective standard. Local replacement values create reporting and interface problems later.
4. Setup import and export functions
Administration provides XML-based data structures for import and export of certain setup data.
| Function | Typical use |
|---|---|
| Export/Import Automotive base data | align baseline configuration between environments |
| Export/Import Automotive permissions | transfer permission sets and user profiles from test or reference systems |
| Export/Import MDE configuration | transfer mobile or scanner-related baseline settings |
| Export/Import MDE captions | synchronize mobile texts or labels |
These functions are especially useful when a test system was already aligned from a business perspective and the configuration should be transferred into another environment in a controlled way.
Control steps before business setup starts
- Confirm that licensing and app status fit the planned operating model.
- Define the barcode concept clearly: legacy local or modern service-based.
- Leave record types unchanged unless there is an agreed project reason.
- Extend keys only with official VDA codes.
- Validate import and export functions in a test environment first.
Typical error patterns
| Situation | Possible cause | Check |
|---|---|---|
| Functions are visible but not usable | module enablement or licensing is incomplete | check product and module activation |
| Barcode output behaves inconsistently | legacy font logic and modern service logic are mixed | define one barcode operating model clearly |
| Interface values look implausible | keys were extended locally instead of according to VDA | compare key values with the standard and project rules |
| Permissions differ from the test system | permissions or profiles were not transferred correctly | inspect the permission import/export process |
Result
- You know the technical and licensing minimum requirements for Automotive.
- You can classify record types, keys, and administrative functions safely.
- You avoid common baseline mistakes before sales, purchasing, EDI, or barcode processes even start.
Links