# Planer, prismodeller og abonnementer En plan beskriver, hvordan et abonnement prissættes og fornyes. Alunta understøtter faste priser, enheds- eller forbrugsbaserede priser og niveauinddelte priser. Priser gemmes i den mindste valutaenhed, for eksempel øre. ## Intervaller og valuta En plan kan have priser for en eller flere fornyelsesintervaller og valutaer. Niveauinddelte planer gemmer priser på hvert niveau i stedet for som almindelige fornyelsesintervaller. Et konkret prisopslag skal derfor altid være bevidst om prismodellen, intervallet og valutaen. ## Skift mellem prisniveauer På et niveauinddelt abonnement kan en administrator vælge **Skift prisniveau** og flytte abonnementet til ethvert niveau, som de senest indberettede parametre tillader. Det gælder også et gratis niveau. Alle planens parametre skal være indberettet før en nedgradering, og det valgte niveau skal have en pris for abonnementets nuværende og allerede planlagte intervaller. En øjeblikkelig opgradering træder i kraft med det samme og kan danne en forholdsmæssig regulering for resten af perioden. Andre opgraderinger og alle nedgraderinger planlægges til den første fremtidige faktureringsperiode, der endnu ikke er låst af en faktura eller betaling. Abonnementet fortsætter imens; det opsiges ikke. Hvis den nuværende tier vælges, annulleres en udskiftelig planlagt tier-ændring. En forholdsmæssig regulering, der ikke faktureres eller trækkes med det samme, venter på abonnementets næste faktura. Betales abonnementet automatisk med gemt kort, trækker den næste fornyelse reguleringen sammen med den nye periode, så den faktura, trækket afregner, er betalt fuldt ud. En regulering, der opstår efter trækket, venter på det næste. En kreditering, der er større end trækket, venter også på en senere faktura i stedet for at nedsætte en betaling, der allerede er trukket. Det almindelige skift låser ikke abonnementet. Automatisk tier-evaluering fortsætter derfor bagefter og kan opgradere abonnementet igen, hvis de indberettede værdier kræver det. Planens indstilling for nedgraderinger bestemmer stadig, om fremtidige fald sker automatisk ved næste periode eller skal vælges manuelt. **Overskriv tier** er en særskilt administrativ undtagelse. Den kan gennemtvinge et niveau og låser automatisk evaluering, indtil overskrivningen ophæves fra dashboardet. API-kald kan indberette parametre på et låst abonnement, men kan hverken ændre tier eller ophæve låsen. Integrationer kan læse tier, lås og en eventuel planlagt ændring med `GET /subscriptions/{uuid}/tier` og vælge en tilladt tier med `PUT /subscriptions/{uuid}/tier`. En planlagt ændring returnerer både sin ikrafttrædelsesdato og et snapshot af tier-navnet. Hvis plankonfigurationen senere bliver inkonsistent, kan `target_tier` være `null`, selv om `scheduled_tier_change` stadig er synlig. ## Nedgang i licensantal På en licensbaseret plan bestemmer indstillingen **Nedgang i antal**, hvad der sker, når et lavere antal indberettes midt i en periode. Et indberettet antal er et øjebliksbillede af, hvad kunden har, så det sættes på abonnementet med det samme uanset indstillingen. Det indstillingen styrer, er **afregningen**. **Fra næste fornyelse, uden kreditering** er standard for licensplaner oprettet efter at indstillingen blev indført. Den igangværende periode beholder det antal og den pris, den blev aftalt til, der dannes ingen kreditering og ingen negativ regulering, og den lavere pris slår igennem ved næste fornyelse. **Straks, med forholdsmæssig kreditering** er den oprindelige adfærd og gælder alle licensplaner, der fandtes før indstillingen blev indført. Kunden krediteres for de resterende dage af perioden. En **stigning** i antal uden fremtidig dato træder i kraft med det samme, uanset indstillingen. Hvis den øger prisen, kan den give en forholdsmæssig opkrævning. På en plan med udskudt afregning måles opkrævningen fra det antal perioden faktisk fakturerer - aldrig fra et lavere indberettet tal - så en kunde aldrig opkræves igen for licenser, de ikke er holdt op med at betale for. Abonnementet viser derfor to tal: `quantity` er det antal kunden har nu, og `current_period_quantity` er det antal den igangværende periode fakturerer. De er forskellige indtil fornyelsen. En ny indberetning uden fremtidig dato erstatter simpelthen den forrige. Indstillingen håndhæves alle steder, hvor et antal indberettes: i appen, via `PUT /subscriptions/{uuid}/quantity` og fra forbrugsindberetninger på en gauge-parameter. To ting er værd at vide. MRR følger abonnementets antal, så en nedgang slår igennem i MRR på indberetningsdagen, selvom den først afregnes ved fornyelsen. Og hvis næste periode allerede er faktureret forud, kan den ikke omprissættes - så slår nedgangen først igennem perioden efter. ## Planens katalog og den konkrete aftale Planen er kataloget over mulige priser og intervaller. Et eksisterende abonnement er den konkrete aftale og beholder sine valgte vilkår, selv om planen senere skjules eller får en ubrugt katalogpris ændret. En plan kan kun sælges i checkout, når den er synlig, har en pris for den valgte valuta og det valgte interval, og har den betalingsopsætning som købet kræver. En ubrugt almindelig interval-/valutapris kan redigeres fra planens pristabel. En pris, der bruges af abonnementer eller aktive betalingslinks, skal ikke ændres for at omskrive gamle aftaler; opret en alternativ pris eller ændr den konkrete aftale gennem abonnementets ændringsflow. Tierpriser og forbrugspriser har særskilte editorer. ## Licens og forbrug En almindelig licensplan ganger enhedsprisen med abonnementets antal. En licensplan kan også have en grundpris med inkluderede licenser: periodeprisen er `base_price + max(0, quantity - included_quantity) × unit_price`. Antallet er samlet antal licenser og mindst én; ubrugte inkluderede licenser reducerer ikke grundprisen. En stigning kan give en forholdsmæssig regulering, mens en nedgang følger planens valgte afregning. `quantity` er det aktuelle antal, mens `current_period_quantity` er det antal den igangværende periode fakturerer. Grundpris, inkluderet antal og pris pr. ekstra licens konfigureres pr. interval og valuta. Eksempel: 149 kr. inkl. én bruger plus 79 kr. pr. ekstra bruger giver 307 kr. for tre brugere, før moms og rabat. En årsbetaling bruger sin egen års-prislinje. Grundprisen opkræves ikke igen ved en antalsændring midt i perioden; reguleringen følger forskellen mellem gammel og ny samlet periodepris. Ændringer, som ikke ændrer prisen, udløser ingen selvstændig nul-faktura. I planernes CSV-eksport betyder kolonnen **Price** enhedsprisen for licensplaner; **Base price** og **Included quantity** viser grundprisen og det inkluderede antal separat. For andre prismodeller er **Price** intervalprisen eller den laveste tierpris. Aftalens grundpris og inkluderede antal følger abonnementet og periodernes historik. En individuel ændring af stykprisen ændrer kun prisen pr. ekstra licens. På fakturaen vises sammensatte licenspriser som én abonnementsydelse med samlet pris og en forklaring af licensantallet, ikke som samlet antal gange ekstralicensprisen. Modellen understøttes ved enkeltplan-checkout, manuel oprettelse og abonnements-API'et. Den kan ikke bruges i bundles, tilbud eller ved import til en eksisterende plan med disse vilkår. Alunta administrerer antal, ikke masterbrugerroller eller de enkelte slutbrugeres identiteter. Der tilføjes ikke en licenseditor i kundeportalen. En forbrugsplan bruger rapporterede værdier, som kan registreres på kunden eller via den offentlige API. Forbrug, der registreres for et bestemt abonnement (Registrer forbrug fra abonnementet i appen eller `POST /subscriptions/{uuid}/usage`), afregnes på det abonnement og afvises med `subscription_not_started` eller `subscription_ended`, hvis datoen ligger uden for abonnementets periode (forbrug dateret inden for perioden kan stadig registreres, efter abonnementet er afsluttet, indtil dets sidste periode er faktureret); forbrug dateret i en pause eller prøveperiode gemmes, men afregnes ikke. Forbrug, der registreres på kunden uden at nævne et abonnement (`POST /customers/{uuid}/usage-events`), afregnes på kundens nyeste aktive abonnement, der måler parameteren, og gemmes uden at blive afregnet, hvis der ikke er et. Kontrollér parameter, enhed og periode, før faktureringen låser data. En synlig forbrugsværdi er ikke i sig selv en færdig fakturalinje, og forbrugsbaserede abonnementer skal ikke læses som en fast MRR-pris. ## Tilbud, prøve og intropris En prøveperiode er en pris-nul-periode; et introtilbud er en tidsbegrænset pris for nye køb; en individuel rabat ændrer en konkret aftale; og en rabatkode gælder nye self-service-køb. De fire begreber må ikke blandes sammen. Ved manuel oprettelse af et enkeltstående abonnement kan teamet vælge en individuel rabat med navn, beløb eller procent og enten uden slutdato eller med en varighed i måneder eller år. Den gælder fra den første betalingsperiode efter en eventuel prøveperiode og erstatter planens intropris for dette abonnement; uden en individuel rabat gælder planens intropris som normalt. En rabat, der kun dækker en del af en fastprisperiode, beregnes forholdsmæssigt. Forbrugsabonnementer understøtter kun procentvis rabat, som gælder hele forbrugsperioden. Rabatten bevares, hvis teamet vælger **Fakturér ikke nu**. En rabat tilføjet efter oprettelsen kan kun ændre ulåste perioder; allerede udstedte eller betalte perioder ændres ikke. Individuel rabat kan ikke bruges i bundles eller sammen med tilbud eller rabatkoder. På kortabonnementer skal engangsbeløb faktureres særskilt, når abonnementet har individuel rabat. Gennemgå den første faktura og den næste planlagte periode, når flere tilbudselementer bruges samtidig. ## Opsigelsesvarsel På planens side findes kortet **Opsigelsesvarsel**. Her vælger teamet enten intet varsel eller en af fire typer: indeværende periode + N perioder, løbende måned + N måneder, N måneders varsel til udgangen af en periode, eller et fast antal dage eller måneder fra opsigelsesdagen. Type, længde og enhed er ét vilkår og gemmes sammen med knappen "Gem ændringer". Samme indstilling kan sættes og ændres via planens API-felt `notice_period` (`null` fjerner varslet), og planen og abonnementerne viser det som et objekt med `type`, `length`, `unit` og `label` (`label` er altid engelsk i API'et og i webhooks og ignoreres, hvis den sendes tilbage). Varslet er en del af aftalen med kunden, så det kopieres fra planen til abonnementet, når abonnementet oprettes. En senere ændring af planens varsel gælder kun nye abonnementer; eksisterende abonnementer beholder deres varsel, og et planskift beholder abonnementets varsel frem for at tage planens. Et varsel kan kun forlænge en opsigelse, aldrig forkorte den: slutdatoen er aldrig tidligere end udgangen af den igangværende periode, og beskyttede perioder kan give en senere dato end varslet. Det gælder ikke i en prøveperiode eller for et abonnement, der ikke er startet endnu, og en pause forbruger ikke varslet og forkorter det heller ikke. Eksempler på de fire typer og på, hvem der er bundet af varslet, står i afsnittet om opsigelsesvarsel i guiden om abonnementets livscyklus. Teamet er selv ansvarligt for, at vilkårene er lovlige over for private kunder; Alunta kontrollerer det ikke. ## Egne felter Brugerdefinerede felter har en fast ejer: plan, abonnement eller kunde. Brug den stabile nøgle og den definerede datatype. Et felt på planen bliver ikke automatisk et felt på abonnementet, og API-/webhook-svar indeholder kun de ejere, som den aktuelle offentlige kontrakt beskriver. ## Sikker adgang til plankataloget `get_plan_catalog` er slået fra som standard og kræver, at en administrator eksplicit aktiverer Plan- og prisdetaljer under AI-adgang. Værktøjet kan derefter returnere plannavn, prismodel, konfigurerede priser, checkout-synlighed og begrænsninger på betalingsudbydere. Det returnerer ikke slutkundedata, abonnementstal, fritekstbeskrivelser, bogføringskoblinger eller interne ID'er. ## Opkræv licensopgraderinger med det samme I dashboardets ændring af antal kan du vælge **Træk det gemte kort med det samme** for en opgradering med virkning fra i dag og et tilknyttet kort hos en af nedenstående udbydere. **Fakturér med det samme** opretter alene reguleringsfakturaen. Dashboardet viser, hvis betalingen afvises eller afventer bekræftelse; antallet er stadig ændret. Genåbn ændring af antal og behold samme antal for at genforsøge en endnu ikke faktureret opkrævning. Kontrollér betalingsstatus, før du giver ekstra adgang. For et individuelt licensabonnement, der betales direkte med dets gemte kort via OnPay, Stripe, QuickPay, PensoPay eller CostPlus, send `charge_immediately: true` til `PUT /subscriptions/{uuid}/quantity`. Alunta trækker den forholdsmæssige regulering inklusive eventuel moms først og opretter derefter en betalt reguleringsfaktura. Brug en aktuel stigning og undlad `invoice_immediately`; det eksisterende flag opretter en faktura uden at trække kortet. Afventende og afviste betalinger opretter ingen faktura. Det indberettede antal gemmes stadig, så integrationen skal kontrollere `meta.collection_status`, før den giver adgang til ekstra kapacitet: `captured` bekræfter betalingen, mens `no_eligible_transactions` betyder, at der ikke er noget ekstra beløb at opkræve. Gentag samme antal og flag for at hente eller færdiggøre den eksisterende opkrævning uden dobbeltbetaling; kun en bekræftet afvisning tillader et nyt forsøg. Andre vilkårsændringer og opsigelse er blokeret, indtil en afventende eller gennemført opkrævning er faktureret, og den almindelige fakturering udelader den. En bekræftet afvisning frigiver reguleringen til almindelig fakturering eller eftergivelse. Automatisk kortopkrævning er ikke nødvendig for dette eksplicitte kald, men skal slås til separat for automatiske fornyelser.