2 Commits (5aedef2b3576b3ccfd7f2437502f3b826dc58992)

Author	SHA1	Message	Date
nexxo	e0c0bb2c29	Release v1.3.83 — Fortschritt zeigte Übersetzungsschlüssel ... Unter jedem Schritt stand `dashboard.step_state.done` statt eines Wortes — im Adminbereich UND im Kundenportal, wo derselbe Stepper jemanden durch die Einrichtung seiner Cloud begleitet. Die Schlüssel gab es in keiner der beiden Sprachdateien. Die Paritätsprüfung aus R16 konnte das nicht finden: sie vergleicht Deutsch mit Englisch, und die beiden waren sich einig. Der Aufruf ist zusätzlich zusammengesetzt (`__('dashboard.step_state.'.$state)`), also findet ihn auch keine Suche nach festen Zeichenketten. Der neue Test rendert deshalb das Bauteil und prüft alle vier Zustände in beiden Sprachen. Dazu ein Test, der heute Nacht hochgegangen ist: PortalInvoicesTest verbot die Zeichenkette '01.08.2026' — das Datum aus einer alten Attrappe. Heute ist der 1. August 2026, und die echten Rechnungen des Tests tragen das Ausstellungsdatum von heute. Eine Zusicherung, die ein Datum verbietet, verbietet auch den Tag, an dem es echt wird. Was die Attrappe ausmachte, war ihr Satz, und den prüft der Nachbartest über 'Nächste Abbuchung' — stabil, weil er nirgends sonst entsteht. 2235 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 02:08:28 +02:00
nexxo	8ca0d4d257	Say the same thing to the customer, the register and the bank ... Five places where the product told somebody a figure that nothing behind it produced. **The invoice page showed five invoices nobody was ever issued.** A mock that outlived its purpose: CP-2026-0003 to CP-2026-0007, a prefix belonging to no configured series, all "paid", a spend curve from 179 to 198 € and a next charge of 198 € on 01.08.2026 — behind ['auth','verified','customer.active'], so every signed-in customer saw it. Their real invoices existed in `invoices`, were rendered as PDFs and mailed to them, and appeared nowhere in the portal at all. The page now lists their own documents, newest first, with the numbers, dates and totals off the frozen snapshot, a Storno marked as one, and a download. The PDF route resolves the document against the signed-in customer in the query — a URL anybody can type is not made private by not printing it. No next charge and no chart: nothing here computes what Stripe will take next cycle, and a figure nobody has worked out is worse than a blank space. **The setup fee was quoted everywhere and charged nowhere.** On the price sheet, on the booking page, set by the operator in the console — and CompanyProfile::setupFeeCents() had no reader outside the two sentences that quoted it. It is charged now, as a second non-recurring line on the same checkout session, which Stripe puts on the initial invoice only. `orders.setup_fee_cents` records how much of the charge it was, so the whole total still goes back on a withdrawal while the register holds the PACKAGE's charge against the contract price and the invoice prints the fee as a line of its own. The booking page was also quoting the fee NET under the same sentence the website quotes GROSS — 99,00 against 118,80 — and now quotes what will be taken. **An upgrade click cancelled a booked downgrade and delivered nothing.** Nothing in this application marks a cart order paid, so the customer traded a downgrade they had genuinely booked for a cart line that would never be fulfilled. The booking now stands until the upgrade actually lands on the contract, where ApplyPlanChange clears it. The fulfilment seam is reachable for every type that can be paid — a module and a storage pack book through BookAddon, which was the missing path from a paid order to a SubscriptionAddon and left AddonPrices, SyncStripeAddonItems and clupilot:end-cancelled-addons with no caller behind a payment. A paid traffic pack logs an error rather than pretending: the metered allowance is a standing count of packs while a top-up is sold for one month, and which of the two is meant is not a guess to make here. That no path to `paid` exists yet is now stated in both places rather than in one. **The proof register called correct charges wrong.** expected_gross_cents used the CUSTOMER's rate, which is zero under reverse charge, against the domestic gross Stripe actually took — so matches_catalogue was false for every EU business sale charged exactly the advertised amount, and for every renewal on a contract with a module, which was held against `price_cents` alone. It compares against TaxTreatment::chargedCents() and against the whole term now. Where no money moved, charged and the flag are null instead of the expected figure agreeing with itself, and a plan change records the terms with the pro-rata figures in the snapshot rather than money that arrives again on Stripe's proration invoice. **The seller's own VAT id was on the invoice, unlabelled**, between the register number and the court. Labelled — and the footer's composition moved out of the TCPDF method, because inside one the only way to read what it says is to render a PDF and un-subset its fonts. One test enshrined a figure the code does not produce: a reverse-charge purchase recorded with no charged amount, asserting 17900/0/17900, where OpenSubscription always passes the charged figure and a real one records 21480/0/21480. Another asserted that an upgrade click cancels a booked downgrade. Full suite: 1676 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 01:30:24 +02:00