6d7c2bdf35
tests / pest (push) Failing after 8m35s
Details
tests / assets (push) Successful in 22s
Details
tests / release (push) Has been skipped
Details
Three things the product owed its customers and did not have. **Who is on the other side.** There was no consumer/business flag anywhere, and `vat_id` was standing in for one — which it cannot: a business without a VAT number is an ordinary small business, and a consumer with one does not exist. It is asked at sign-up now, correctable in the portal, and NULL where nobody has been asked. Unknown is read as CONSUMER everywhere it decides a right, because that mistake costs us a refund while the other one takes a statutory right away from somebody who has it. Reverse charge asks the recorded type instead of the number: an explicit consumer is charged the domestic rate whatever `vat_id` says — previously they were not, and anyone could zero their own VAT by getting a number verified. An unrecorded type still falls back to the verified number, so no contract that is already running changes rate. **The fourteen-day right of withdrawal** (FAGG, §312g BGB), for consumers only, at every door: the window is stamped on the contract when it is concluded, the customer exercises it from the portal, an operator records one that arrived by telephone or post, and both go through one action that refuses a business customer on the server rather than by hiding a card. The money follows the paperwork rather than being computed beside it. The invoice is cancelled by a Storno with its own gapless number — nothing is ever edited or deleted — a new invoice states the pro-rata value of the service actually delivered (FAGG §16, by days over the term paid for), and the refund is exactly the difference between the two documents. Where the consumer never expressly asked for the service to begin at once, they owe nothing and the whole amount goes back. `StripeClient::refund()` is new, keyed so a retry cannot send the money twice. The service ends through EndInstanceService and the `cancellation_scheduled` machinery that was already there. **The cancel button for modules.** BookAddon::cancelAtPeriodEnd() had no caller in the interface at all, so a customer could book a recurring charge in two clicks and had no way to stop it. It is on the module card now, with the date it runs until and a way back while the cancellation is still pending — and putting a module back settles nothing, because the term it was cancelled for was paid for in advance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| AddonCancellationTest.php | ||
| AddonEntitlementTest.php | ||
| ApplyPlanChangeTest.php | ||
| ArchivePullAccessTest.php | ||
| CustomDomainAccessTest.php | ||
| CustomerTypeTest.php | ||
| ExportTargetFormTest.php | ||
| FinanceSettingsTest.php | ||
| GrantAddonTest.php | ||
| GrantInvoiceTest.php | ||
| GrantSubscriptionTest.php | ||
| InvoiceArchiveTest.php | ||
| InvoiceListTest.php | ||
| InvoiceMailTest.php | ||
| InvoiceMathTest.php | ||
| InvoiceNumberTest.php | ||
| IssueInvoiceTest.php | ||
| PendingPlanChangeTest.php | ||
| PlanCatalogueTest.php | ||
| PlanChangeTest.php | ||
| ProofRegisterTest.php | ||
| RenewalInvoiceTest.php | ||
| StorageAllowanceTest.php | ||
| StripeAddonBillingTest.php | ||
| StripeBillingTest.php | ||
| StripePlanChangeTest.php | ||
| WithdrawalTest.php | ||