swaits
d5b9e5cf99
An invoice is issued, not edited. Without `confirmed` the create tools now preview: the posting (with the accounts' codes, which the live chart may not hold yet), the number it will take, its due date, terms and early discount, warnings, and for an invoice the DRAFT copy of the PDF, handed over as a file. Nothing is written and no number is used up. With `confirmed` the invoice posts, takes the number the preview showed, and files the issued copy with itself in the same call: `receipt.attached` on its entry plus the link to the invoice, its SHA-256 in the event (A-1, A-7, B-40). The copy the customer received is therefore the copy in the books, and `books.document`'s re-created page can never be mistaken for it. The result also carries a `mailto` link for a human to send it; the books never send (A-4). A bill keeps what the plan says a bill is: the vendor's own invoice number, the vendor's invoice filed on its entry as its evidence, and, in books that have declared `documents_v2`, an account on every line, so no bill can land in General Expenses by default any more (A-9, A-10, A-13). A vendor number entered twice is refused unless the caller says why, and the reason is journaled with the second bill (B-40 item 4). Books that have not declared the feature keep recording bills exactly as before, so the owner's books keep working between units (D-39, 8.0.4). Terms are resolved in one place and in one order: the due date given, else the terms given, else the customer's or vendor's own default, else the books' `invoicing.default_terms`; a document given only a due date stores no terms, so an old-shape invoice is still written byte for byte as before (B-39, A-13). D-55: a party carries the owner's full contact block (phone, contact person, billing and shipping addresses, billing email). It rides the same `party.updated` event behind `documents_v2`, and an invoice's bill-to is snapshotted at issue with the billing address and billing email in place of the general ones when the party has them — `PartySnapshot::from_party` is the one place that rule lives, so a later edit cannot change what was sent, and the next invoice takes today's details. Tests: the wire tests are the new `crates/ledger-cli/tests/documents.rs` (preview writes nothing, the DRAFT copy, the issued copy's SHA-256 equals `books.get_receipt`'s, numbers run, a bill's file and terms, the duplicate refusal, the line-account rules, the terms fallback, the `party_id` alias and the ambiguity it refuses, the contact block's set and clear, and the bill-to at issue); `format_upgrade.rs` gains `documents_v2_refused_until_consent` and the cut-over test now refuses and then makes a document carrying a new field (8.0.6 item 3); the store tests are `the_contact_block_round_trips_and_replays` and `an_invoice_keeps_the_billing_details_it_was_issued_with`, and `books_written_under_older_rules_still_open` gains a hand-written contact-block event (8.0.6 item 1). Merge does not need the owner's go-ahead: the live books refuse a write that needs `documents_v2` until he gives it, and take every other write as before (8.0.6 item 6). No figure moved: S4 moves none.
57 lines
2.4 KiB
Rust
57 lines
2.4 KiB
Rust
//! The CPA handoff package, and the reports, worksheets, and text helpers
|
|
//! the server's tools and the viewer both make: built from the books
|
|
//! read-only, through [`PackageBooks`] (the server's
|
|
//! [`ledger_store::Store`], the viewer's [`ledger_store::Snapshot`]).
|
|
//!
|
|
//! ```text
|
|
//! GOAL: the server (books.export_cpa_package, books.vendor_1099) and the
|
|
//! viewer make the same package and the same 1099 worksheet, byte
|
|
//! for byte, from one piece of code, and neither can change the
|
|
//! books making them.
|
|
//! SOURCE: the books.export_cpa_package and books.vendor_1099 contracts
|
|
//! (ledger-mcp server.rs; docs/mcp-interface.md), moved here
|
|
//! unchanged so the viewer, which reads the books only through a
|
|
//! Snapshot and doesn't depend on ledger-mcp, builds them too.
|
|
//! INVARIANTS:
|
|
//! 1. Read-only: nothing here writes anywhere (the books, the vault, a
|
|
//! file). The builders return bytes; recording a file that holds
|
|
//! full TINs (ledger-mcp tin_files.rs) and handing it over are the
|
|
//! caller's.
|
|
//! 2. Full TINs come only from the TIN source the caller gives
|
|
//! ([`TinSource`]); without one, a worksheet carries last fours only.
|
|
//! 3. The same books, settings, and request give the same bytes,
|
|
//! whichever [`PackageBooks`] they are read through.
|
|
//! ```
|
|
|
|
mod attention;
|
|
mod books;
|
|
mod iif;
|
|
mod invoice;
|
|
mod k1_tax;
|
|
mod package;
|
|
mod reports;
|
|
mod text;
|
|
mod tins;
|
|
mod vendor_1099;
|
|
|
|
pub use attention::{
|
|
Attention, Integrity, Report, Severity, Target, files_1099, find, find_with, reconcile_prompt,
|
|
w9_missing, w9_prompt,
|
|
};
|
|
pub use books::PackageBooks;
|
|
pub use iif::export_iif;
|
|
pub use invoice::{draft_invoice_document, invoice_document, issued_invoice_document};
|
|
pub use k1_tax::{open_text, tax_basis_csv};
|
|
pub use package::{Package, PackageRequest, build_package, package_file_name};
|
|
pub use reports::{
|
|
Settings, as_of_date, bs_statement, cash_flow_for, cash_flow_statement, member_capitals,
|
|
pnl_statement, report_members, report_meta, statement_range, year_earnings,
|
|
};
|
|
pub use text::{csv_escape, money, parse_date, share_text};
|
|
pub use tins::{TinSource, tin_kind, tin_type_key, vault_tin};
|
|
pub use vendor_1099::{
|
|
VENDOR_1099_CSV_HEADER, Vendor1099Worksheet, Vendor1099WorksheetLine, form_1099_label,
|
|
payment_accounts, vendor_1099_csv, vendor_1099_csv_name, vendor_1099_report,
|
|
vendor_1099_worksheet,
|
|
};
|