Files
accounted/lib/articles/validate-revenue-account.ts
T
Jakob WennbergandClaude Sonnet 5 ec27228a8e style: remove em/en dashes repo-wide, add CLAUDE.md rule against them (#890)
Em dashes (—) and en dashes (–) had spread across comments, docs, tests,
and a few UI strings, reading as AI-generated boilerplate rather than
house style. Replaced each with punctuation matching its context: colon
for explanatory clauses, comma for asides, plain hyphen for numeric/legal
ranges (e.g. "21-23§"), "to"/"till" for date ranges, parentheses for
paired-dash asides. messages/en.json and messages/sv.json were fixed by
hand together to keep sv/en in sync.

Left untouched where the dash is the functional subject rather than
decorative punctuation: date-range-parser.ts's separator regex,
charset-repair.ts's CP1252 byte-mapping table (and its test), the SIE
encoding mojibake docs, generic-csv.ts's minus-sign normalizer, the
agent system-prompt files that already instruct against em dashes, and
a golden iXBRL test fixture compared byte-for-byte.

Also fixes two bugs surfaced along the way: an off-by-one in
ApiKeysPanel's scope-label split (a leftover from an earlier partial
pass), and a charset-repair test that had lost the literal en-dash it
exists to verify.

Regenerated the agent atom seed migration (skills:generate) since 27
SKILL.md files changed. Added a CLAUDE.md rule against em/en dashes,
with an explicit carve-out for the functional-dash cases above.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-04 15:58:06 +02:00

70 lines
2.4 KiB
TypeScript

import type { SupabaseClient } from '@supabase/supabase-js'
import { getBASReference } from '@/lib/bookkeeping/bas-reference'
/**
* Classify a per-article revenue-account override against the company's chart:
*
* - 'ok' : active class-3 account in the chart; accept as-is.
* - 'activatable' : a class-3 account that is merely missing/inactive: either
* an inactive chart row or a known BAS class-3 number not yet
* in the chart. Routes translate this to ACCOUNTS_NOT_IN_CHART
* so the standard activate-and-retry dialog flow applies
* (same UX as the journal entry form).
* - 'invalid' : anything else: a non-revenue account or a number unknown to
* both the chart and the BAS catalogue. Never bookable.
*
* Throws on an unexpected DB error so the route wrapper maps it to the canonical
* envelope.
*/
export type RevenueAccountStatus = 'ok' | 'activatable' | 'invalid'
export async function checkRevenueAccount(
supabase: SupabaseClient,
companyId: string,
account: string,
): Promise<RevenueAccountStatus> {
const { data, error } = await supabase
.from('chart_of_accounts')
.select('account_class, is_active')
.eq('company_id', companyId)
.eq('account_number', account)
.maybeSingle()
if (error) throw error
if (data) {
if (data.account_class !== 3) return 'invalid'
return data.is_active ? 'ok' : 'activatable'
}
const ref = getBASReference(account)
return ref?.account_class === 3 ? 'activatable' : 'invalid'
}
/**
* True when `account` exists in the company's chart of accounts as an ACTIVE
* class-3 (revenue/intäkt) account. Used to guard the optional per-article
* revenue-account override so a typo or a non-revenue account can never be
* pinned to an article (and later booked). Never trust the client.
*
* Throws on an unexpected DB error so the route wrapper maps it to the canonical
* envelope; a simple "account not found" resolves to `false`, not an error.
*/
export async function isValidRevenueAccount(
supabase: SupabaseClient,
companyId: string,
account: string,
): Promise<boolean> {
const { data, error } = await supabase
.from('chart_of_accounts')
.select('account_number')
.eq('company_id', companyId)
.eq('account_class', 3)
.eq('is_active', true)
.eq('account_number', account)
.maybeSingle()
if (error) throw error
return !!data
}