Architecture, implementation decisions, and verification scope for the ERP connection to the ASP.
How the AI FDE operated
The AI FDE stayed inside the implementation cycle. It read the evidence, mapped the system, changed the implementation, exercised the flow, and corrected failures against the governing source or observed state.
Establish the governing rules and inspect the real ERP behavior.
Trace invoice data through records, posting setup, and extensions.
Implement setup, events, submissions, API paths, and background work.
Run representative flows and inspect what the system actually produced.
Resolve failures against source evidence, then rerun the right layer.
Technical architecture
Business Central remains the operational system. Filing is registered around its transactions, then handled through a separate submission lifecycle with explicit status and inbound paths.
BC transaction
Canonical data
PINT AE XML
ASP lifecycle
Status + inbound
Posting
Register filing work without making accounting depend on the network.
Queue
Send, refresh state, and keep terminal documents out of repeat polling.
Inbound staging
Keep the original payload even when accounting conversion fails.
Technical proof
The difficult parts are often small enough to miss in a broad architecture diagram. They are also where apparently complete integrations break.
01 · Document history
The implementation reads the original invoice type from stored submitted XML instead of recomputing it from configuration that may have changed later.
Filed history
Filed as 380
Stored in submitted XML
Inherits 381
Uses what was filed, not today’s setup
02 · Content assertions
Structural validation may prove an element exists without proving its value is right. The test system therefore asserts on business content emitted by AL.
Presence ≠ correctness
The element is present. Its value can still be wrong.
The implementation checks the business content that moved.
03 · System state
Business Central can ignore unknown or read-only fields while returning success. The harness reads records back and verifies the stored value.
Transport ≠ state
A successful response is only the start of the check.
Verification
Structural validity, business content, ERP behavior, and live network state are checked separately. That makes failures easier to locate and harder to wave through.
Rules and XML
ERP behavior
Operational UX
Network state
catalogue instances in the offline examiner design
commercial decision-tree cases in the sandbox plan
manual client behaviors defined for inspection