住基・戸籍部門 設計書

• 企画キー: juuki-koseki-bumon(apps.yaml)
• kintoneスペース: 住基・戸籍部門(spaceId: 86)
• 関連ドキュメント: DFD / ER図

1. 目的

住民票の写し・戸籍謄本・印鑑登録証明書等、窓口で交付する証明書ごとの手数料をマスタで管理し、窓口での日次の現金収納状況(前日繰越現金・本日の収納合計・当日の残額)を精算するとともに、他の官公庁等からの公用請求(住民基本台帳法・戸籍法に基づく請求)の受付から交付までを管理する。JavaScriptカスタマイズは行わず、kintone標準機能のみで構成する。

2. アプリ構成

マスタアプリ(証明書手数料マスタ)を先に作成し、その後2つの業務アプリ(窓口収納日報・住民票・戸籍公用請求)を作成する。

3. 業務フロー概要

1. 市民課担当が「証明書手数料マスタ」に住民票の写し・戸籍謄本・戸籍抄本・印鑑登録証明書等、窓口で交付する証明書ごとの商品コード・商品名・区分・単価(手数料)を登録する。 2. 窓口担当者が日次で「窓口収納日報」に前日繰越現金を登録し、当日交付した証明書をhanbai_meisai(販売明細、サブテーブル)に商品名・数量・単価で積み上げていく。行ごとの金額(kingaku_h = 数量×単価)、本日合計(honjitsu_goukei = 販売明細のSUM)、当日の残額(toujitsu_zandaka = 前日繰越現金+本日合計)をCALCフィールドで自動集計する(下記5.参照)。 3. 警察・裁判所・他自治体等の官公庁から住民基本台帳法・戸籍法等に基づく公用請求があった場合、担当者が「住民票・戸籍公用請求」に請求機関名・請求根拠法令・対象者情報・請求書類種別を登録し、交付後に交付日・交付通数・手数料・決定状況を記録する。

4. 「証明書手数料マスタ」フィールド一覧

5. 「窓口収納日報」フィールド一覧

shouhin_mei_h(商品名)は、情報システム管理(ITSM)のソフトウェアライセンス管理10.と同じ理由(kintoneはサブテーブル内にLOOKUPフィールドを配置できない)により、「証明書手数料マスタ」をLOOKUPするのではなく手入力の文字列フィールドとした。証明書手数料マスタの商品名と一致させる運用ルールで担保する。

6. 「住民票・戸籍公用請求」フィールド一覧

フィールド定義・レイアウトの正はapps.yamlの該当エントリであり、本表はその要約。フィールドを追加・変更した場合は、apps.yamlの更新に合わせて本表も必ず更新すること。

7. 未決定・今後の検討事項

• 「窓口収納日報」のshouhin_mei_h(商品名、手入力)と「証明書手数料マスタ」の同期を保つ運用ルールの明文化(入力ミス防止のため、将来的にはドロップダウン選択肢化を検討)
• 複数窓口・複数担当者が同日に日報を起票する場合の集計方法(現状は1レコード=1担当者・1日を想定)
• 「住民票・戸籍公用請求」の決定状況と、実際の証明書交付システムとの連携要否

8. アプリ名の変更について(2026-07-05)

当初、各アプリ名はidea.mdの項目名をそのまま採用し、商品マスタ/日報/公用請求アプリとしていた。しかし日報は既存の滞納行程管理企画にも同名・同キー(nippou)のアプリが存在し、庁内の一覧やkintoneポータルで見分けがつきにくいという指摘を受け、次のとおり企画名を反映した固有の名称・キーに変更した(kintone上のappId自体は変わらない)。

この変更に伴い、scripts/create-apps.mjsに「既存アプリのnameがapps.yamlと異なる場合、PUT app/settings.jsonで同期する」機能を追加した(従来はnumberPrecisionのみ対象だった、上記コード冒頭コメント参照)。あわせて、fieldsNeedUpdateの選択肢(options)比較がkintoneからのGET結果のキー順序に依存しており、ラジオボタン・チェックボックス・ドロップダウンを持つアプリで--applyのたびに実際は差分がないのに再同期・再デプロイが走ってしまう既存バグを発見し、キー順序に依存しない比較に修正した(本企画に限らず全アプリに影響する修正)。