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>
70 lines
2.4 KiB
TypeScript
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
|
|
}
|