In mechanical and plant engineering, sales is never just about quantities and prices. It's about technical intent: requested flow, pressure, head, temperature, media, materials, standards, and constraints.
Yet in many ERP systems, this engineering reality is either:
- squeezed into free-text fields, or
- hard-coded directly into sales documents
Both approaches break down as soon as products become configurable, engineered-to-order, or connected to external selection tools.
With BC Engineering, we are introducing a new concept that cleanly separates commercial processes from engineering truth: Technical Contexts.
The Challenge: Engineering Data Does Not Belong on Sales Lines
Sales documents are designed for:
- pricing
- quantities
- delivery
- commercial workflows
They are not designed to host:
- pump duty points
- motor sizing criteria
- application-specific constraints
Adding dozens of technical fields directly to sales lines leads to:
- rigid data models
- pump-specific logic in generic processes
- poor extensibility for future products
Engineering data needs structure, validation, and reusability — without polluting core ERP documents.
The Solution: Technical Contexts
BC Engineering introduces a generic, abstract Technical Context that can be attached to a sales line — without the sales line needing to know what kind of product it represents.
How it works conceptually
- A Sales Line represents the commercial intent
- A Technical Context represents the engineering intent
- The context contains a structured set of technical attributes
This keeps responsibilities clean:
- Sales stays simple and stable
- Engineering data becomes flexible and extensible
Attribute-Based, Not Hard-Coded
Instead of fixed fields like:
- Requested Flow
- Requested Head
- Medium
- Temperature
BC Engineering uses an attribute-based model.
Attribute Definitions
Define what data exists:
- Attribute code (e.g. FLOW, HEAD, TEMP)
- Data type (decimal, text, option)
- Unit of measure
- Validation rules
- Applicability (pump, motor, generic)
Attribute Values
Store the actual values per technical context.
This means:
- Different items can require different data sets
- New product types can be introduced without schema changes
- Engineering rules evolve independently of documents
One Concept, Many Use Cases
Because Technical Contexts are abstract, they are not limited to pumps.
They can be used for:
- Pump selection and duty point definition
- Motor sizing
- Seal or elastomer selection
- Engineered spare parts
- Custom assemblies
- Future product families not yet defined
All without touching the sales line structure.
Seamless Integration With External Tools
Technical Contexts are designed to integrate cleanly with:
- pump selection software
- configuration engines
- variant rule trees
- BOM generation
- digital documentation
- digital nameplates and digital twins
The ERP becomes the single source of truth, not a data graveyard.
Engineering Data With Lifecycle Awareness
Technical Contexts can be:
- created automatically when an item is added
- validated based on product type
- locked once an order is released
- reused for service, documentation, or replacements
Engineering decisions remain traceable — from quote to delivery and beyond.
Why This Matters
| Traditional Approach | Technical Context Approach |
|---|---|
| Engineering data in free text | Structured, validated data |
| Pump-specific fields | Product-agnostic model |
| Hard to extend | Designed for growth |
| ERP-centric thinking | Engineering-centric thinking |
This is how modern CPQ and engineering platforms work — now fully integrated into Microsoft Dynamics Business Central.
Conclusion
Engineering data deserves its own structure.
With Technical Contexts, BC Engineering bridges the gap between:
- sales and engineering
- ERP and selection tools
- today's products and tomorrow's variants
Without compromises, without workarounds, and without locking you into pump-specific logic.
Commercial clarity on the surface. Engineering truth underneath.