EV_PRODUCT_007 — Staged sales-order and AR-invoice import, diagnostics, and reconciliation surfaces
Deployment-specific product evidence for the data-import-ai sales-order and
accounts-receivable-invoice import path. It establishes inspectable
implementation structure, dry-run diagnostics, idempotency, a reversal path, and
the document fields available for reconciliation. It does not establish a
customer result, buyer acceptance, coverage for record types outside the named
hooks, or runtime performance at migration volume.
kind: evidence_catalog
schema_version: 1
evidence:
- id: EV_PRODUCT_007
type: internal_validation
title: 'Staged sales-order and AR-invoice import, diagnostics, and reconciliation surfaces'
source: >-
MCP server d8189168 hook_graph, flow_documents, and project_graph
responses captured during the create-proof authoring session for P_00012,
S_00011, and PF_MULTI_007 on 2026-08-02. The registered MCP client did not
attach in that session; the same server and the same three read-only tools
were driven directly over stdio.
publisher_or_owner: 'Naologic product repository via MCP server d8189168'
published_at: null
accessed_at: 2026-08-02
supports:
- >-
data-import-ai/import-in-progress-sales-orders and
data-import-ai/import-accounts-receivable-invoices exist as implemented
hooks. The AR-invoice hook is exposed as flow action
finance/finance.import-accounts-receivable-invoices. Its documented
lifecycle runs after the sales-order import, matching invoice lines back
to the sales-order lines the migration already created.
- >-
The AR-invoice import is diagnostic-first by design: unmatched or
invalid data is recorded in diagnosticReport rather than thrown, so a
dry-run surfaces data-quality issues in one pass instead of failing on
the first bad row. Its Phase 3 dry-run stops after calculation.
- >-
The AR-invoice import parses the source workbook, strips junk rows,
separates invoices from credit memos, groups rows by document number,
batch-resolves accounts, contacts, sales orders, items, packagings and
warehouses, matches sales-order lines by productId, variantId and
packagingId, and carries lineItemId onto the resulting invoice lines.
- >-
The AR-invoice import is idempotent: it skips invoices whose
invoiceNumber and credit memos whose creditMemoNumber already exist, and
uses skipUniqueNumber() so import-assigned numbers are preserved.
- >-
Imported invoices and credit memos are tagged isImported=true,
importSource=fileUrl, and suppressedJournalStages, and the
ensure-journal-entries hooks skip journal-entry creation for tagged
documents.
- >-
The AR-invoice import runs no cross-document transaction. Invoices and
credit memos are calculated and inserted one at a time; a single failing
document is recorded in insertErrors and does not roll back or block the
rest of the batch.
- >-
finance/invoice exposes data.salesOrderId with a declared relationship
to sales/order, data.orderLines.salesOrderId,
data.orderLines.lineItemId, and data.amountGrossTotal.
- >-
finance/invoice and sales/order both carry dataImportAllow true,
dataImportType immediate, dataImportMaxRows 100000, dataReportAllow
true, dataReportMaxRows 1000, revisionsEnabled false, and
auditTrailEnabled true.
- >-
data-import-ai/import-in-progress-sales-orders applies skipEvent() to
all of its write operations to bypass audit-trail processing for
imported documents, and sets shipping and billing addresses to
placeholder values that must be corrected after import.
- >-
data-import-ai/cleanup-imported-ar-invoices deletes imported invoices
and credit memos identified by dataPrivate.importSource. It is dry-run
by default, requires mode='delete' to execute, and is idempotent, so a
trial can be reset and repeated. Sibling cleanup hooks exist for
accounts payable and sales orders.
- >-
The AR-invoice hook documentation does not mention skipEvent or audit
trails. Whether that import writes audit-trail entries was not
established and remains unverified.
- >-
data-import-ai/import-routings throws bad_request on missing items,
invalid row data, or unreachable work-center types rather than
collecting diagnostics. Diagnostic-first behavior is specific to the
hooks named in this record and is not uniform across data-import-ai.
scope: >-
Naologic data-import-ai sales-order and accounts-receivable-invoice import
path, its diagnostics and reversal path, and the document fields available
for reconciliation.
confidence: medium
notes: >-
MCP calls were hook_graph op=search target="import", op=collection
target="data-import-ai", and op=hook against
data-import-ai/import-accounts-receivable-invoices,
data-import-ai/import-in-progress-sales-orders,
data-import-ai/cleanup-imported-ar-invoices and
data-import-ai/import-routings; flow_documents op=get against
finance/invoice and sales/order and op=fields against finance/invoice; and
project_graph op=search. These are implementation observations of the
product repository. They do not establish that any customer obtained a
result, that an acceptance criterion was met, or that coverage extends to
record types outside the hooks named. A search miss means unverified, not
absent. No live deployment or customer data was inspected and query_db was
not used.
Outstanding
- Record coverage is partial. Only the two named import hooks and their cleanup path were verified. Import coverage for other required operating records remains unestablished.
- Audit-trail behavior of the AR-invoice import is unverified. The
sales-order import bypasses audit-trail processing through
skipEvent(); the AR-invoice hook documentation is silent on the question. - Throughput is unverified. Response time and reliability at migration volume were not observed.
- This record carries no vertical scope. It establishes product surfaces only. Any proof citing it for directly applicable verticals must state that basis explicitly rather than inherit breadth from product universality.