> For the complete documentation index, see [llms.txt](https://support.bridge-funeral.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.bridge-funeral.com/nori/23-data-integrity-tips.md).

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

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

## 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) の住所は個別管理可能 (家族と別住所もある)
* 過去の伝票には **住所のスナップショット** が記録 (家族住所を変えても過去伝票は不変)

### よくあるミス

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

### 対処

* 住所変更時は **同期機能** ([住所をご家族で同期する](https://github.com/thinkeight/bridge-cms/blob/main/README.md) 参照) を使う
* 過去伝票で新住所を反映したい場合は **「伝票の宛名・住所を再取得」** ボタン

## 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 回、以下を確認すると整合性が保てます。

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

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

| ルール例  | 推奨運用                   |
| ----- | ---------------------- |
| 受電時   | 必ず家族・お客様の特定 → 活動記録     |
| 訃報受電  | 必ず施行情報を作成 (日程未確定でも OK) |
| 見積作成  | お客様 OK で「見積確定」に変更      |
| 請求書発行 | PDF 発行後にステータス「請求済」     |
| 入金完了  | 入金レコード追加後にステータス「入金完了」  |
| 月締め   | 取引先別の合算請求を作成 (法人取引のみ)  |
| 退社時   | 自分の活動ログ・ToDo を保存       |

## 次に進む

* [裏で自動で動く処理を知る](https://github.com/thinkeight/bridge-cms/blob/main/README.md) — 自動処理の前提条件
* [住所をご家族で同期する](https://github.com/thinkeight/bridge-cms/blob/main/README.md) — 住所整合性のメンテ
* [困ったときの対処](https://github.com/thinkeight/bridge-cms/blob/main/README.md) — トラブルシューティング

***

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://support.bridge-funeral.com/nori/23-data-integrity-tips.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.