# Aluntas produktområder og typiske arbejdsgange ## Kunder, planer og abonnementer Et team kan oprette slutkunder og beskrive det, der sælges, som planer. En plan kan have fast pris, forbrugsbaseret pris eller trappebaseret pris og kan suppleres med prøveperiode, rabat, tilpassede felter og forskellige fornyelsesintervaller. Når en slutkunde køber en plan, opstår et konkret abonnement. Abonnementet har sin egen pris, betalingsmetode, startdato og livscyklus. Flere planer kan sælges samlet som en abonnementspakke, men de enkelte abonnementer kan bagefter ændres eller afsluttes uafhængigt. ## Fra abonnement til faktura Alunta klargør fremtidige abonnementstransaktioner ud fra abonnementets perioder, pris og eventuelle forbrugsdata. De klargjorte poster kan samles på en faktura. Enkeltstående fakturaer kan oprettes uden et abonnement. En faktura beskriver kravet; betalinger beskriver de beløb, der faktisk er registreret. En faktura kan derfor være ubetalt, delvist betalt eller betalt og kan have flere betalinger. Tilbagebetaling og kreditering er også særskilte handlinger og må ikke forveksles med at slette den oprindelige faktura. ## Checkout og selvbetjening Checkout kan bruges til salg af abonnementer, abonnementspakker og betalbare enkeltstående fakturaer. Kunden kan indtaste de oplysninger, teamet kræver, vælge blandt de betalingsmuligheder teamet har gjort tilgængelige og modtage en tilpasset bekræftelse. Den konkrete checkout- og selvbetjeningsoplevelse afhænger af teamets planer, apps, betalingsopsætning og indstillinger. Produktdokumentationen kan derfor forklare mulighederne, men den aktuelle opsætning skal kontrolleres med MCP-værktøjet `get_apps_overview` og relevante teamværktøjer. ## Betaling, bogføring og levering Alunta understøtter bankoverførsel og manuelle registreringer samt betalingsintegrationer som OnPay, Stripe, QuickPay, PensoPay, MobilePay og Leverandørservice. Ikke alle betalingsformer understøtter de samme køb eller abonnementsforløb, og en integration skal være forbundet og konfigureret for det konkrete team. Fakturaer, kunder, produkter og betalinger kan synkroniseres til et tilsluttet bogføringssystem. De understøttede bogføringsintegrationer omfatter e-conomic, Dinero, Billy og Uniconta. Fakturaer kan desuden sendes via almindelig e-mail eller, når kravene og opsætningen er opfyldt, via EAN/NemHandel. ## Data, analyse og automatisering Tilpassede felter og forbrugsparametre gør det muligt at gemme domænespecifikke kundeoplysninger og registrere det forbrug, som en pris afhænger af. Dashboard og analyseværktøjer kan vise blandt andet omsætning, MRR, vækst, churn, fakturaer og betalingsstatus. Alunta Radar kan overvåge relevante offentlige virksomhedsoplysninger for kvalificerede kunder. Teams kan bruge notifikationer, Slack, det offentlige API, webhooks og tredjepartsintegrationer til at reagere på hændelser. API- og webhookkontrakten findes i den offentlige integrationsvejledning og OpenAPI-specifikationen. ## Forhandler og ratebetaling En forhandler (betaler) er en kunde, der betaler udvalgte abonnementer på vegne af andre kunder og får én samlet faktura for dem. Dækningen angives pr. abonnement, så en forhandler kan betale alle, nogle eller ingen af en kundes abonnementer. Rater deler én serviceperiode på et fastprisabonnement med et interval, der er længere end en måned, i rater med hver sin faktureringsdato; hver rate opkræves eller faktureres for sig og afregnes for sig. Jeres egen AI kan se hver app gennem ét værktøj. `get_reseller_overview` viser forhandlerne (kundens uuid og navn) med, hvor mange kunder hver betaler for, hvor mange af deres abonnementer den dækker, og den månedlige værdi af de dækkede abonnementer pr. valuta; det kræver valget Kundedetaljer og viser ikke de kunder, der ligger bag en forhandler. Den månedlige værdi er det samme tal, som fanen Forhandler på en kunde viser som samlet beløb pr. måned: kun abonnementer, der kan faktureres i dag, tæller med (ikke abonnementer, der ikke er startet, er i prøveperiode, er sat på pause eller er forbrugsbaserede), men de tæller stadig som dækkede abonnementer. Slås appen Forhandler fra, fjernes alle betalerforbindelser. `get_installment_overview` viser, hvor mange abonnementer der betales i rater, alle rater fordelt på tilstand (betalt, faktureret og endnu ikke betalt, forfalden, kommende, ikke opkrævet fordi en betalingsfejl afsluttede abonnementet, og uden for abonnementets faktureringsperiode og dermed aldrig faktureret), hvad der mangler at blive betalt pr. valuta uden moms, og de næste rater, der forfalder, med abonnementets uuid, faktureringsdato og beløb. En forfalden rate er en rate, hvis faktureringsdato er nået; det er ikke bevis for, at den er forsinket eller mislykket, fordi opkrævnings- eller faktureringskørslen måske ikke har nået den endnu. Ingen af værktøjerne viser kontaktoplysninger, adresser, kort- eller udbyderdata eller faktura- og betalings-id'er. ## Radar og sundhedstjek Radar tjekker virksomhedsregistret hver dag for kvalificerede kunder (et CVR-nummer og et kørende abonnement) og registrerer et fund, når noget ændrer sig. Et fund er en observation, som kan kræve opfølgning, ikke en afgørelse om kunden. Sundhedstjekket sammenligner teamets fakturaer og deres synkronisering med e-conomic og rapporterer forskelle; et fund er en forskel, der skal gennemgås, ikke bevis for, at en faktura eller regnskabet er forkert, og en sag samler fundene om én faktura. Sundhedstjekket viser også de aktuelle tolerancer for små restbeløb og rykkernes separate DKK-minimum med systemets aktivitetsstatus. En dokumenteret og afstemt rest inden for tolerancen kræver ikke yderligere betalingsopfølgning i Alunta; den kan stadig stå i e-conomic. Grænserne godkender ikke faktura- eller momsafvigelser og ændrer ikke tidligere kontrolfund. En forklaret historisk øreafrunding er heller ikke i sig selv bevis for betaling. Resultatet viser tidspunktet for den seneste afsluttede kontrol; bilag og betalingskontroller kan være ændret siden. Hvor den gemte dokumentation er tilstrækkelig, forklarer sagen, om næste skridt er gennemgang hos jeres regnskabsansvarlige eller afklaring af Aluntas afstemning. Åbn fakturaen eller kreditnotaen og dens regnskabsdetaljer for at gennemgå betalingskontrollen. Et nyt sundhedstjek udfører ikke i sig selv en ny betalingsafstemning. Manglende dokumentkobling beviser ikke, at dokumentet mangler i e-conomic. Tekniske fejloplysninger kan foldes ud, og sager med kun forklaret historisk momsafrunding har en særskilt label. »Markér som kendt« kvitterer for gennemgangen og ændrer hverken betalinger eller udligning. Jeres egen AI kan se hver app gennem ét værktøj. `get_radar_overview` viser de overvågede, pausede og ikke-understøttede overvågninger (ikke-understøttet betyder, at registret ikke finder virksomheden, så CVR-nummeret skal rettes), de åbne fund fordelt på type og alvorlighed, virksomhedsstatussen bag de åbne fund om virksomhedens status (for eksempel under konkurs, konkurs eller ophørt, som en fast kode), den anslåede berørte årlige abonnementsværdi for kunder med åbne fund (hvad de betaler om året, ikke et forventet tab, og utilgængelig når en valutakurs mangler), de fund der er opdaget i en periode, og de kunder der kræver opfølgning med fundets type og alvorlighed og, for et fund om virksomhedens status, statuskoden; kundelisten kræver valget Kundedetaljer, og værktøjet er kun tilgængeligt, så længe Radar-abonnementet er aktivt. Det returnerer med vilje ingen registertekst, kun den faste kode, så for fakta bag et fund skal kunden åbnes i Radar. `get_health_check_overview` viser, hvornår sundhedstjekket sidst blev kørt, og hvordan kørslen endte, hvor mange sager og fund der er åbne (fra den seneste gennemførte kørsel, uden dem teamet har markeret som kendte) fordelt på alvorlighed, tjek og kategori, hvor mange fund der forsvandt af sig selv i en periode, og de åbne fund med den titel, appen viser; fundets fakturanummer kræver valget Fakturadetaljer, og værktøjet er kun tilgængeligt, så længe appen er slået til. En ny forskel i e-conomic eller på en faktura vises først efter næste kørsel. Ingen af værktøjerne returnerer beløb sammenlignet med e-conomic, noter eller brugernavne. ## Hvad AI-adgangen kan kombinere `search_product_knowledge` giver generel produktviden, API-kontrakt og ændringshistorik. Andre MCP-værktøjer giver aktuelle, teamafgrænsede tal og appstatus. Detaljer om konkrete slutkunder eller fakturaer er kun tilgængelige, når en administrator udtrykkeligt har aktiveret de tilsvarende datakategorier. Et team kan derudover godkende enkelte tilpassede kundefelter til skrivebeskyttet visning og filtrering; ikke-godkendte og nyoprettede felter forbliver private. Kundelister udelader feltværdierne, medmindre kaldet udtrykkeligt vælger godkendte feltnøgler efter at have læst feltkataloget. Et fyldestgørende svar bør derfor kombinere den generelle dokumentation med teamets aktuelle status. En funktion, der findes i Alunta, er ikke nødvendigvis aktiveret, tilgængelig eller færdigkonfigureret for det valgte team.