Arbetsflöden: vad du faktiskt ska göra

Fyra av flödena nedan är registrerade som MCP-prompter (manadskoll, kvittojakt, momskoll, foreslakontering) och kan dyka upp som färdiga åtgärder i din klient. Den här sidan är den utförliga versionen.

Gemensamt för alla: börja med get_bookkeeping_status, sluta med en kort rapport på svenska, och lova aldrig att något är bokfört.

1. Månadskoll

När: användaren frågar "hur ligger jag till" eller vill ha en avstämning.

1. get_bookkeeping_status för läget och nästa deadlines.
2. list_todo_transactions för vad som väntar på att bokföras.
3. list_review_items för vad som väntar på ett beslut.
4. list_missing_underlag för brister i underlagen.
5. get_radgivning för deadlines, preliminärskatt och 3:12.

Sammanfatta kort. Föreslå de tre viktigaste åtgärderna, i den ordning som minskar risk mest: närmaste deadline först, sedan saknade underlag, sedan obokförda transaktioner.

Varje siffra du nämner ska ha ett verktyg bakom sig. Skriv ut vilket.

2. Kvittojakt

När: bokförda utbetalningar saknar kvitto. Det är den vanligaste bristen i en småföretagsbokföring, och den enda som blir svårare med tiden.

1. list_missing_underlag för arbetslistan. Varje rad har transactionId, date, description, amount och eventuellt vendor.
2. Gruppera per leverantör.
3. För rader med vendor: följ agentPlaybook i användarens egen inloggade webbläsare, öppna portalUrl och hämta rätt dokument.
4. Ladda upp med upload_receipt och skicka alltid med transactionId, så kopplas dokumentet till rätt transaktion i stället för att gissas fram.
5. Rader utan vendor: gissa inte portal. Samla dem och föreslå att användaren vidarebefordrar kvittot till organisationens kvittoadress eller laddar upp manuellt.

Regler som gäller hela flödet:

• Endast fakturerings- och kvittosidor. Aldrig kontoinställningar, aldrig säkerhetssidor. Ändra ingen inställning.
• Är portalen utloggad: stanna för den leverantören, be användaren logga in själv, fortsätt med nästa. Fråga aldrig efter lösenord eller engångskoder.
• Matcha på belopp och datum. Bankraden är i SEK, fakturan kan vara i USD eller EUR: samma datum plus minus några dagar och en rimlig växelkurs. Kan du inte identifiera dokumentet säkert: hoppa över och säg det.
• Uppladdning kostar AI-anrop och är begränsad till 20 per timme. Vid 429: rapportera hur långt du kom och stanna.

Avsluta med en tabell:

3. Momskoll

När: inför en momsdeklaration.

1. Ta reda på organisationens momsperiod med get_radgivning. Hitta inte på perioden.
2. get_moms_report för exakt den perioden.
3. Förklara rutorna kort på svenska.
4. Flagga sådant som ser konstigt ut: negativa rutor, belopp som avviker kraftigt mot historiken, moms utan underlag.

Du avgör ingenting. Du flaggar. En momsdeklaration är användarens ansvar gentemot Skatteverket, och Astrid lämnar inte in den åt någon.

Kör alltid list_missing_underlag för perioden också. Avdragen ingående moms utan underlag är exakt det Skatteverket underkänner.

4. Föreslå kontering

När: obokförda banktransaktioner har hopat sig.

1. list_todo_transactions. Rader med pendingReview: true har redan ett förslag: hoppa över dem.
2. Kolla pendingReview i statusen. Ligger det redan mycket i kön: fråga användaren innan du fyller på.
3. categorize_transactions för de återstående. Utan transactionIds tas de nyaste obokförda. Högst 100 per anrop, och varje transaktion kostar ett AI-anrop av 20 per timme.
4. Sammanfatta vad som lades i kön.
5. Påminn användaren om att godkänna i Granska. Du kan inte göra det åt hen.

Behöver du föreslå en verifikation som inte utgår från en banktransaktion (en periodisering, en rättelse, en manuell post): använd propose_verification, och läs list_journal_entries först för att hitta hur organisationen konterat liknande poster tidigare.

5. Lär av organisationen innan du föreslår

Det här är inte ett eget flöde utan ett steg som hör hemma i alla de andra, och det är skillnaden mellan en agent som hjälper och en som skapar granskningsarbete.

Innan du föreslår en kontering:

1. list_journal_entries med ett datumintervall bakåt, och sök efter samma leverantör i beskrivningarna.
2. get_journal_entry på en träff för att se de faktiska raderna och kontona.
3. Använd samma kontering. Organisationens egen historik väger tyngre än vad du tror är rätt.
4. list_review_items med status: "MODIFIED" visar förslag människan ändrade innan hen godkände. Det är den starkaste signalen som finns om hur just den här organisationen vill ha det.

Finns inget prejudikat: skriv det i reasoning. "Ingen tidigare bokning för den här leverantören, föreslår X baserat på beskrivningen" är ett ärligt förslag. Ett tvärsäkert påstående utan grund är det inte.

Felhantering

Rapportera aldrig så här