5 Commits (v1.3.62)

Author	SHA1	Message	Date
nexxo	b32c6fc33f	Sell the year as well as the month, and say what it saves ... Both prices have existed since the catalogue did — one `plan_prices` row per term, each with its own Stripe Price, and the checkout has taken a `term` all along. Nothing ever sent one. The shop showed the monthly figure, the order page posted no term, and the yearly Price sat there being paid for by nobody. **The console asks for free months, not a second price.** It used to take the yearly TOTAL as its own free-form figure, so nothing in the system knew WHY 588 belonged to a package costing 49 a month — and no page could say "zwei Monate gratis" without a person working it out again and writing it somewhere it would then drift. Now: the monthly price and how many of the twelve months are free. The total is derived from the two (PlanVersions::yearlyCents), previewed live on the form, and written to the catalogue from the same arithmetic. `free_months` sits on the VERSION, beside the capabilities publication freezes, because that is what it is — part of the terms a customer bought. The migration reads it back out of the prices that already exist rather than defaulting to nought: an installation selling twelve-for-ten must not lose that on a deploy. Only an exact division counts; a hand-negotiated yearly figure keeps its amount and simply goes unexplained. **The customer chooses.** A switch on the order page and on the public sheet, both figures rendered and one shown, so switching costs no request. The headline stays "per month" in either term — a yearly total as one big number reads as five times dearer at a glance — with the amount actually taken, the net figure, the months free and what twelve monthly payments would have cost underneath. The form posts the term the customer was looking at, and the checkout picks that term's Stripe Price. The billing card now says which term is running. It states a monthly figure whatever the term, so a yearly customer was reading a number that never appears on a statement. Also: **a Blade comment must never spell a directive.** Blade compiles what is inside `{{-- --}}` too — the comment is stripped from the output, but its directives are compiled on the way there. A comment explaining why the parenthesised php directive had been avoided produced exactly the open PHP tag it warned about, and the rest of the file was swallowed as PHP source: no exception, no warning, the page one block short. That is how the term switch vanished after being written. BladeCommentsTest scans for the forms that open a tag. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 15:44:35 +02:00
nexxo	c354ad1463	Make mails readable on a phone, and let an operator look at one ... Three things the owner reported, and one sentence that promised something this product does not do. **The mails had a fixed width.** components/mail/layout.blade.php set width="600" and width:600px, so every phone showed a 600px canvas in a 390px window and one had to scroll sideways to read a sentence. Now the table is width="100%" with max-width:600px — fluid, with 600 as a ceiling rather than a floor. A mail cannot fix this with a media query (Outlook renders with Word and drops <style> blocks), which is why the whole file is inline attributes and why the shrinking has to be built in. Side padding went 40px -> 24px in the layout and in all nine mail views: 40 each side leaves 278px of a 390px screen to read in. **There was no way to look at a mail.** An invoice mail needs an invoice, a maintenance announcement needs a window, and "register an account to see whether the confirmation reads well" is not a workflow — which is how the fixed width survived for months. App\Services\Mail\MailPreviews builds all nine from sample data, every record with make() and never create(), so a preview leaves no invoice, order or window behind and draws no number from a series. Two ways to see one: in a tab as the document itself, or sent to the signed-in operator's own address. There is no recipient field — that would be a form for mailing strangers. sendNow(), not send(): every mailable here implements ShouldQueue, and send() defers to the queue for those, which would have put a failure in a worker's log while the button reported success to somebody waiting for the mail. The test caught that. **The booking page had no shell.** Order declared layouts.portal — the bare shell the sign-in pages use, no navigation and no padding — so the page sat flush against the top and bottom of the window with no way back to anything. layouts.portal-app, like every other portal page. **The consent box said something untrue.** Its refusal read "otherwise we can only build your cloud once the withdrawal period has ended", which describes a path that does not exist: nothing here delivers fourteen days later, and an unticked box simply means no order. Said plainly now, and said on the page before somebody runs into the refusal. Also: GrantedPlanPortalTest asserted assertDontSee('179'), which matches any id containing those digits — and ids climb through a suite run because a rolled-back transaction does not reset an auto-increment counter. It passed alone and failed in company. Asserts on '179,00' now, which is what a leaked price would actually look like. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 14:50:37 +02:00
nexxo	9da1358802	Stop charging VAT to the customers who owe us none ... A verified EU business outside Austria gets reverse charge — rate 0, no VAT line, the note on the invoice — and was still charged 214,80 € for a 179,00 € package, because one Stripe Price carried the domestic gross for everybody. There is no VAT line on their document to reclaim, so it was a flat 20 % surcharge on exactly the customers who read their invoices, and the document then stated the whole 214,80 € as net at 0 %, so they self-accounted their own VAT on a base a fifth too large. A Stripe Price can ask who is buying after all: there are two per sellable thing now, the domestic gross and the bare net, both live on one Product, and the checkout picks by TaxTreatment. The rule is Austria B2B 20 %, other EU B2B without VAT — a domestic business still pays the gross, reclaims it as input tax, and the price on the website is still the price charged for them. - stripe:sync-catalogue mints and archives both halves of every pair, per plan and per module; `reverse_charge` on stripe_plan_prices/stripe_addon_prices says which is which, and joining it on subscriptions.stripe_price_id says which one a running contract is billed on. A rate change moves the gross Price and leaves the net one alone, because the net owes nothing to the rate. - A status that changes after the sale converges: a verification (or a lapse) makes stripe:reprice-subscriptions move the contract onto the other Price with PRORATE_NONE, because the term is already paid for. The module items follow the same way. - Downstream follows: the invoice total equals what was taken, the proof register expects the figure this customer is actually charged (so a correct reverse-charge sale is no longer flagged as a mismatch, and an overcharged one is), the setup fee obeys the same rule, and the booking page quotes what it will charge. - StripeClient gained activatePrice(). Archived Prices were brought back in our own table and left inactive at Stripe, so a rate that moved and moved back pointed the catalogue at a Price no checkout could be opened for. An unverified number is still charged the gross — an unchecked string must never be a discount — and where the net Price is missing the checkout refuses rather than reaching for the domestic one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-30 02:15:41 +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
nexxo	f85f57152e	Let the customer buy it themselves, and tab the integrations page ... Every path on the site ended in "anfragen": a mailto: link and a promise to answer the same working day. That is an afternoon of somebody's time per customer, for a product whose whole point is that the machine does the work — and it scales exactly as far as one inbox does. Now: sign in, pick a package, pay, and provisioning starts by itself. The pieces were already there — Stripe holds a Price per plan version (the catalogue sync writes the ids), the webhook opens the contract, the pipeline builds the VM — and what was missing was the checkout session between them. CheckoutController opens one and gets out of the way; the purchase becomes real on the webhook, which stays the only place allowed to believe a payment happened. The success URL is a redirect target and therefore a URL anybody can type, so it says "we are building it", not "you have paid". Nothing in the request may decide the price. The plan key arrives from a form and everything else is re-derived from the catalogue, including the plan VERSION, so a version published while the customer types their card number cannot change what they were quoted. Two cases that are not errors: no capacity is a parked order (already built), and an existing customer is sent to the plan change rather than sold a second, empty cloud that bills twice. The site says what it can keep. "danach wissen Sie … wie Ihre Daten sicher umziehen" was a promise made before seeing the thing it is about: we do not know where a visitor's data is, what shape it is in, or whether it can be moved at all. Migration is named as its own question, looked at first and quoted afterwards. The integrations page gets the settings page's treatment for the same reason: it was one narrow column of six cards, so an operator connecting DNS scrolled past Stripe to reach it and the raw .env editor sat at the bottom of everything. Three tabs by what a section is FOR — services we buy from outside, our own machines, the file underneath — the same axis the page was rebuilt around when it stopped being split by storage mechanism. The tab is in the query string; unlocking survives a switch, because a confirmed password is a session fact and not a property of a tab. The .env tab is Owner-only, like the editor it holds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-29 19:42:28 +02:00