Propose Bill-Date Correction
Workflow #2 — the next-day QBO follow-up: correct a bill's TxnDate/DueDate to the vendor invoice date. Queued for approval; applied as a QBO sparse update.
Overview
MCP tool propose_bill_date_correction — agent-callable, but it only queues: it creates a pending proposal (Proposal CreatedProposal CreatedEventv0.1.0A propose_* command queued a mutation: a Proposal now exists in status `pending` with a freshly-minted per-card widget t...Ownervisionary-engineeringMapView docs) on the Approval Bus (command service — owns the queue)Approval Bus (command service — owns the queue)Servicev0.1.0The command side: owns the proposal queue. propose_* only queue; a cleared human approves in the card; only then does th...Publishesproposal-created, proposal-approved +3Subscribespropose-vendor-bill, propose-bill-date-correction +6Ownervisionary-engineeringMapRepoView docs and returns the approval card. No vendor write happens here. Watch the full lifecycle: Propose Bill-Date Correction — command lifecyclePropose Bill-Date Correction — command lifecycleFlowv0.1.0One propose_bill_date_correction call end to end — the recommended FIRST live command: single reversible field, QBO-only...Ownervisionary-engineeringView flowView docs.
On approval BillDateCorrectionApplier (workflow #2)BillDateCorrectionApplier (workflow #2)Servicev0.1.0Applies an approved bill-date correction: re-fetches the bill for a fresh SyncToken, then sparse-updates the one date fi...Publishesaccounting-read, qbo-update-billSubscribesproposal-approvedOwnervisionary-engineeringMapRepoView docs re-fetches the bill for a fresh SyncToken, then sparse-updates the one date field via QBO Update Bill (sparse)QBO Update Bill (sparse)Commandv0.1.0Sparse-updates one field on an existing bill using a fresh SyncToken (bill-date correction).Ownervisionary-engineeringMapView docs — the optimistic-lock 409 path is tested. Lowest-blast-radius mutation in the set: single reversible field on an existing record, no external party sees it.
Response shape note (CQRS): the tool returns the public pending proposal (id, kind, summary, status) so the host can render the approval card — the command’s real “return” is the proposal id; the mutation result only ever exists on the proposal record after a human approves.
Reading this page: a message page renders its contract and its one hop — who sends it, who receives it (that is EventCatalog’s grain: message = contract). The service page shows this workflow’s full fan-out (its
sends); the flow shows the lifecycle step by step.
Input schema
Architecture diagram
Input (from the zod tool schema)
1YYYY-MM-DD
1Default TxnDate
TxnDate DueDate