整合性を保つコツ｜誤入力を防ぐ業務ルール

ブリッジ葬儀には多くの自動処理が組み込まれていますが、自動処理がうまく動くためには 入力する情報の整合性 が必要です。「故人と喪主の所属が違う」「住所が古い」「金額がズレている」などの不整合は、後の業務 (請求書発行・法要案内・レポート集計) で問題を引き起こします。日常業務で意識すべきポイントを整理します。

1. 家族と お客様の所属関係

ルール

• 1 人のお客様 (Contact) は 必ず 1 つの家族 (Account) に所属 します
• 1 つの家族には 複数のお客様 が所属可能
• お客様が別の家族に異動する場合は、所属を変更 (削除→新規ではない)

よくあるミス

• ❌ 同じ「山田 太郎」さんを 2 つの家族の下に重複登録
• ❌ 喪主の所属家族が、故人の所属家族と異なる
• ❌ 婿養子・嫁入りで姓が変わったお客様の所属を変えていない

対処

• 検索バー で同名のお客様を事前確認
• 1 件目を更新 / 別の家族に紐づけ直し (削除はしない)
• 過去の施行情報・伝票への影響を確認

2. 故人 / 喪主 / 請求先 (施主) の役割と関係

ルール

• 「故人」(IsDead__c) はお客様 (Contact) のチェックボックス。死亡日入力時に自動 ON
• 「喪主」「請求先 (施主)」のフラグは Contact に存在しない。施行情報 (Ceremony) で Lookup として指定する
  • 喪主 = MournerName__c (お客様 Lookup)
  • 請求先 (施主) = OwnerName__c (お客様 Lookup)
• 故人との関係(RelationshipDeceased__c) / 喪主様との関係(RelationshipMourner__c) は施行情報の Text 項目

よくあるミス

• ❌ Contact 側で「喪主フラグ」「施主フラグ」を探そうとする (そんな項目はない)
• ❌ 施行情報で DeceasedName__c と MournerName__c を取り違える
• ❌ 同じ Contact を DeceasedName__c と MournerName__c の両方に紐付ける
• ❌ 「故人との関係」と「喪主様との関係」をどっち向きで書くか混乱する

対処

• 役割は Contact ではなく Ceremony で持つ ことを意識
• 故人との関係 = 故人から見たその人 (喪主が故人の長男なら「子」)
• 1 つの Contact = 1 つの自然人。役割 (故人 / 喪主 / 請求先) は施行情報ごとに割り当て

3. 住所の整合性

ルール

• 家族 (Account) の住所が マスタ (正規)
• お客様 (Contact) の住所は個別管理可能 (家族と別住所もある)
• 過去の伝票には 住所のスナップショット が記録 (家族住所を変えても過去伝票は不変)

よくあるミス

• ❌ お客様の住所だけ変えて、家族の住所は古いまま
• ❌ 家族の住所を変えたが、過去の伝票の宛名・住所は古いまま
• ❌ 半角・全角が混在

対処

• 住所変更時は 同期機能 (住所をご家族で同期する 参照) を使う
• 過去伝票で新住所を反映したい場合は 「伝票の宛名・住所を再取得」 ボタン

4. 施行情報の必須項目

葬儀タイプの必須項目

• 当家 (家族)
• 故人 (お客様)
• 喪主名 (MournerName__c) — お客様 Lookup
• 葬儀日時 (または通夜日時 / 火葬日時 のいずれか)

法要タイプの必須項目

• 親施行情報 (元葬儀)
• 法要種別 (BuddhistMemorialService__c)
• 請求先 (OwnerName__c) — お客様 Lookup
• 法要日時 (Houyou_datetime__c)

よくあるミス

• ❌ 喪主未設定で保存 → 関連自動処理 (UpdateFinalMournerDate) がスキップ
• ❌ 故人未設定で保存 → 会員契約の自動失効がスキップ
• ❌ 当家未設定 → おくやみ情報が紐付かない

対処

• 受電時点で 故人・喪主・当家 だけは必ず入力
• 日程は後で日程エディタで詰める

5. 伝票の宛名と請求先

ルール

• 請求先は 家族 (Account) が標準
• 法人取引は 会社 (Account) が請求先
• 宛名・住所は家族 / 会社から自動コピー (Flow: NewCreateCopyTextNameAndAdress)

よくあるミス

• ❌ 請求先未設定 → PDF の宛名が空欄
• ❌ 自動コピーされた宛名を直接書き換え + 家族住所も書き換え → 整合性崩れる

対処

• 請求先を必ず設定
• 宛名・住所を変えたい場合は伝票上で編集 (家族レコード本体は変えない)
• 家族住所を変えた場合は伝票で 「宛名・住所を再取得」 ボタンで反映

6. 価格タイプと会員価格

ルール

• 伝票の 価格タイプ は明細追加前に決定
• 価格タイプを途中で変更しても、既存明細の単価は 変わらない
• 会員価格を適用する場合は会員契約を選択

よくあるミス

• ❌ 明細を入れてから価格タイプを変えて単価がズレる
• ❌ 会員契約を選んだが価格タイプが標準価格のまま
• ❌ 会員価格適用なのに会員契約欄が空白

対処

• 伝票新規作成 → 価格タイプ確認 → 明細追加
• 会員契約 + 価格タイプの整合を確認
• 必要なら明細を一旦削除して再追加

7. 税率と税表示区分

ルール

• 各明細に 税率 が必須 (空欄だと税額計算がスキップ)
• 伝票全体に 税表示区分 (外税 / 内税) が必須
• 商品マスタにデフォルト税率を設定しておくと自動補填

よくあるミス

• ❌ 明細の税率を「非課」に設定したが、実は課税商品 → 税額が抜ける
• ❌ 標準にない税率 (12% 等) を 税率マスタに勝手に追加 → 伝票集計が壊れる (集計項目は 3/5/8/10% のみ)
• ❌ 内税商品に外税伝票で入れて単価がズレる

対処

• 商品マスタで正しいデフォルト税率を設定 (管理者作業)
• 伝票作成時に税表示区分を最初に決める

8. 入金と御入金額

ルール

• 入金は 請求伝票の関連リスト から追加
• 入金額を入れると 御入金額・残金が自動更新 (Flow: UpdateBillingSummaryToatal)
• 返金は 負の入金 で記録

よくあるミス

• ❌ 受領年月日 (ReceiptDate__c) を未来日付に設定 → 集計時にスキップされる場合あり
• ❌ 過入金分の返金処理を忘れる → 残金がマイナスのまま放置

対処

• 受領年月日は 実際の受領日
• 過入金は速やかに返金処理 (負の入金) で調整

9. ステータスの管理

ルール

• 見積: 見積中 → 見積確定 → (請求伝票化) or キャンセル
• 請求: 請求中 → 請求済 → 入金完了 / キャンセル

よくあるミス

• ❌ 見積確定にしないまま請求伝票を作ろうとして失敗
• ❌ 入金完了後もステータスが「請求中」のまま放置 → レポートでフィルタが効かない

対処

• ステータス変更を 業務ルールに組み込む (ステータス変更チェックリスト)

10. 会員契約の管理

ルール

• 1 人のお客様が複数の会員契約を持てる
• 故人の会員契約は 自動的に失効 (Flow: CeremonyUpdateMembershipInvalidFlg)
• 失効を取り消したい場合は手動で 「失効」 (InvalidFlg__c) チェックをオフ

よくあるミス

• ❌ 故人 + 喪主が同じ会員契約を共有 → 故人の施行で自動失効してしまった
• ❌ 失効した会員契約を伝票で選択しようとしてエラー

対処

• 共有会員契約の場合、別途新規会員契約を作成
• 失効した会員契約が出てきたら、「失効」 チェックの状態を確認

チェックリスト: 月次データ整合性レビュー

月に 1 回、以下を確認すると整合性が保てます。

• 重複お客様レコードの確認 (同名検索)
• 喪主未設定の施行情報の確認 (レポートで抽出)
• 入金完了に切り替わっていない請求伝票の確認
• 残金マイナスの請求伝票の確認 (過入金)
• 古い住所のままのお客様一覧 (家族住所と不一致)
• キャンセルしたまま放置の見積伝票

業務ルール例 (組織で定めるべきもの)

次に進む

• 裏で自動で動く処理を知る — 自動処理の前提条件
• 住所をご家族で同期する — 住所整合性のメンテ
• 困ったときの対処 — トラブルシューティング

📅 最終更新日: 2026-06-16