| title | seed — 初期データ | |||
|---|---|---|---|---|
| status | current | |||
| scope | 会計コア | |||
| audience |
|
|||
| updated | 2026-09-20 | |||
| supersedes | ||||
| related |
|
会計コアが動き始めるために必要なデータ。ペルソナ（docs/02）の 株式会社アルタイルシステムズを前提にしてある。
デモデータではない。 仕訳の入った通しの体験シナリオはフェーズ 7 で別に作る （docs/04）。ここにあるのは 「新しく会計コアを立ち上げたとき、最初に入っていてほしいもの」だけである。
DDL を先に流してから、番号順に流す。
pwsh -NoProfile -File tools/clb/sql.ps1 -File Designer/seed/001_organization_and_periods.sql| # | ファイル | 内容 |
|---|---|---|
| 001 | 001_organization_and_periods.sql |
事業所情報・第 18 期・月次期間 12 本・採番 |
| 002 | 002_departments.sql |
部門 6 件（全社共通 ＋ 5 部門） |
| 003 | 003_tax_categories.sql |
税区分 10 件 |
| 004 | 004_accounts.sql |
勘定科目 105 件・既定税区分 |
各マスタの扱い（所有・誰が編集するか・版と削除）は docs/12_マスタ台帳 が持つ。
税区分（003）を勘定科目（004）より先に流す。勘定科目が既定税区分を参照するためである。
「課税売上（標準税率）」であって「課税売上 10%」ではない。その日に何 % かは制度ルールが決める
ので、名前に数値を埋めると税率が変わった日にマスタ名が嘘になる（20 §2）。
画面には rate_kind から解決した税率を出す。
ペルソナは個別対応方式（docs/02 §3）なので、 課税売上対応／共通対応／非課税売上対応は取引ごとに選ぶ必要がある。 既定値で埋めると「値は入っているが意味がない」状態を作り、 誰も気づかないまま控除税額が嘘になる（docs/15 §4-1）。
経理担当・経理責任者のアカウントは dev/ に置き、上の 001〜004 には入れない。
置き場所・扱い・理由は
ADR-0039。
dev/001_demo_user_roles.sql はアカウントを作らない。役割を付けるだけである。
hash / salt は CLB の PasswordHashHelper が作るもので、SQL では作れない
（ClaudeCodeForDesigner/_specs/Authentication.md）。手順は 2 段になる。
- サーバを 1 度起動する。 ユーザーテーブルが空なら CLB が
adminを作る - 最初の 1 人にシステム管理を与える（新しい DB での 1 回だけ）:
UPDATE app_users SET is_sysadmin = 1 WHERE user_name = 'admin';マイグレーションではやらない（新しい DB ではadminがまだ居ないので空振りする。 ADR-0032） adminでログインし、システム管理の画面で 2 人を作る——soumu_ippan（経理担当）とsoumu_bucho（経理責任者＝総務部長。docs/02）。 利用者名は役職から採る（開発者が決めた。2026-08-31。役割そのままの名前は長くて打つのが面倒だから）。 識別名とパスワードは、Designer/LocalEnvironment.md（Git 追跡外）の「開発用アカウント」節に 開発者があらかじめ書いたものを使う（雛形はLocalEnvironment.md.sample。ADR-0039）。 この登録は Claude が行ってよい。表に行が 1 つも無いときだけ開発者に頼む （規則と理由は docs/31 §3）dev/001_demo_user_roles.sqlを流す（sqlCLI）。役割が付く
締め出してしまったときの戻し方。 役割は画面から自分でも編集できるので、 最後のシステム管理者が自分の
is_sysadminを外す・can_access_appを落とすと、 次の 1 リクエストから入れなくなり（qa/01 F-28）、 画面から戻す手が無くなる。sqlCLI で直す:UPDATE app_users SET is_sysadmin = 1, can_access_app = 1 WHERE user_name = 'admin';保存の手前で止める関門はまだ無い（qa/02 R27-10）。
なぜ 3 を画面からやるか。 上に書いたとおり
hash/saltを SQL で作れないので、アカウントを作る操作は画面からしかできない。 値は追跡外に置く（31 §3）。 役割の付与（4）は機械で再現できるので、そこだけをファイルにしてある—— DB を作り直すたびに、役割の割り当てを手で思い出さずに済む。
雑収入・貸倒損失・固定資産売却損益などは取引の中身で課税区分が変わる。 既定値を置くと間違ったまま通ってしまうので、あえて空にしてある。
BusinessApp.Schema.Tests が DDL ＋ この初期データをインメモリ SQLite に適用し、
制約に反していないこと・数と内容が期待どおりであることを検査する。
- 2026-08-24 勘定科目の決算書表示区分（
statement_section）を入れていない。 会社計算規則が定める区分であり、記憶で書かない（32_調査のルール）。 一次情報を確認してから入れる。フェーズ 4 の着手前 - 2026-08-24 補助科目（
sub_accounts）の初期データが無い。普通預金の金融機関別など、 実際に使う口座が決まらないと作れない。デモデータを作るフェーズ 7。 2026-09-08 に重みが変わった——ADR-0038 §3 で 補助科目が 2 値になったので、uses_sub_account = 1の 3 科目（普通預金・当座預金・定期預金）は、 補助科目を作るまで明細に使えない（計上の関門が止める）。初期データだけで動かす環境では、 その 3 科目が使えないことを承知して使う - 2026-09-08 取引先の初期データが無い（12 §2 の台帳。作れないのは同じ理由で、
実際の相手が決まらないと書けないからである）。
requires_partner = 1の 6 科目は、取引先を 1 件登録するまで明細に使えない （15 §1-2。計上の関門が止め、取引先マスタに登録するよう案内する——文言は写さない）。 上の補助科目と同じ扱いで、デモデータを作るフェーズ 7 に取引先ごと入れる
既に使っている DB に「取引先を要する」を採り入れるときは、次の 1 本を流す （マイグレーションはデータを書かない——ADR-0020。 データ行の同値の網はフェーズ 3 に入る）。画面から 1 件ずつオンにするのと結果は同じである。
UPDATE accounts SET requires_partner = 1
WHERE code IN ('1300', '2100', '4010', '4020', '4030', '5010');オンにするのはいつでもできるが、計上済みの明細がある科目ではオフに戻せない （15 §1-2 の一方通行。使い始める前なら戻せる）ので、 6 科目の外にも立てるなら、流す前に決める。初期データの顔ぶれはこの 6 科目で確定（開発者の決定。2026-09-11。 利用者が自分の科目に「取引先を要する」を立てられるから、製品が広げない——理由と逐語は 15 §1-2）。