> 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/28-slip-design-philosophy.md). # 伝票の設計思想｜「請求先ごとに 1 通」の考え方 ブリッジ葬儀の **伝票 (Slip)** には、他社の葬儀システムとは異なる **重要な設計思想** があります。これを理解しておくと、見積・請求・供物一覧の運用がスッと腑に落ちます。担当者だけでなく、システム検討中の方にも知っておいて頂きたい考え方です。 ## ひとことで言うと > **「請求先ごとに 1 通の伝票」を作る。** 商品が葬儀品でも供物でも、伝票の中に混在させて OK 。 供物一覧の集計は「商品マスタの **供物フラグ** が立っているもの」を横断で拾うので、自動で揃う。 ## 1 件の葬儀で発生する伝票のイメージ 例: **松岡家の葬儀施行** で、当家からの直接の請求と、参列者からの供花を扱うケース。 ``` [施行情報] [伝票 (請求先ごと)] [明細] [供物一覧 PDF] ───────────────── ───────────────────────── ─────────────────── ────────────── 松岡家 葬儀施行 ───▶ 葬儀 (当家向け) ───▶ 商品 (祭壇) ─┐ 商品 (棺) │ 商品 (料理) │ 商品 (返礼品) │ 商品 (供物) ◀ 供物 ─────┤ │ ───▶ 供花 (ご友人 A) ───▶ 商品 (供物) ◀ 供物 ─────┤ 全伝票の │ 供物明細を ───▶ 供花 (勤務先 B) ───▶ 商品 (供物) ◀ 供物 ─────┤ 横断集計 商品 (供物) ◀ 供物 ─────┤ │ ───▶ 供花 (同級生 C) ───▶ 商品 (供物) ◀ 供物 ─────┘ ``` ポイントは: * 伝票は **請求先ごとに 1 通** 。当家用 1 通 + 供花贈呈者 3 名分の伝票 = 計 4 通 * **当家向けの見積/請求の中に「供物」商品を入れても OK** (例: 自社買付の祭壇供物など) * **「供物一覧」は商品マスタのフラグで拾う** 、伝票の種類で分けない ## 他社システムとの違い 多くの他社葬儀システムは、以下のような構造になっています。 ### 他社方式: 「葬儀請求」と「供物請求」を別画面で ``` [施行情報] ├─ 葬儀請求 (画面 1) │ └─ 葬儀品の明細だけ └─ 供物請求 (画面 2) └─ 供物の明細だけ ↑ ここから供物一覧を出力 (構造的に分離されているため) ``` これは **「供物一覧 PDF を出すために、データ構造の段階で『供物』を分離している」** からこうなっています。 ### 他社方式のデメリット | 課題 | 内容 | | ------------- | ---------------------------------- | | 入力画面が 2 つ | 葬儀と供物で行ったり来たりが必要 | | 当家分の供物を扱いにくい | 「当家自身が用意する供物」の入れ場所が曖昧 | | 集計のために合算操作が必要 | 葬儀請求 + 供物請求 を合算する処理が別途必要 | | 柔軟性が低い | 「供物だけの請求書」「供物入り当家請求書」のような混在パターンに弱い | ## ブリッジ葬儀方式のメリット ### ① 入力画面が 1 つに統一 請求先ごとに 1 つの伝票エディタで、葬儀品でも供物でも自由に追加できます。「葬儀請求と供物請求の画面切り替え」がありません。 ### ② 当家向け請求書に供物も同居 OK 当家への請求書の中に、自社買付の供物 (祭壇供物・親族供花など) を入れられます。同じ請求書で 1 通として処理。 ### ③ 外部からの供物注文も、シンプルな伝票 1 通 参列者・取引先からの供物注文 (例: ご友人 A の供花) は、その人を **請求先** にした伝票を 1 通作るだけ。葬儀本体の伝票とは分離されているので、混乱しません。 ### ④ 供物一覧は商品マスタが正 「**この商品は供物一覧に出すか出さないか**」は **商品マスタ側のチェック** (`Product__c.IsShownOnList__c` 「供物一覧に表示」) で制御します。 伝票が当家向けか供花贈呈者向けかに関係なく、**供物一覧 PDF は施行情報配下の全伝票** から、フラグが立った商品の明細を **自動集約** します。 > つまり「供物一覧の出し分け」のためにデータ構造を分ける必要が無い。これがブリッジ葬儀の核心。 ## 業務シーン別の伝票の作り方 ### シーン 1: 一般葬 (当家請求のみ・供物なし) 伝票: **1 通** (当家請求) 明細: 祭壇・棺・料理・返礼品 など 供物一覧 PDF: 該当明細無し → 空欄 ### シーン 2: 当家請求 + 自社供物 (祭壇供物など) 伝票: **1 通** (当家請求) 明細: 祭壇・棺・料理・返礼品 + **「供物」フラグ商品** (祭壇供物・親族供花など) 供物一覧 PDF: 当家伝票内の供物明細 (例: 親族供花 ◯◯) のみ表示 ### シーン 3: 当家請求 + 参列者からの供物受付 伝票: * 1 通目: **当家請求** (葬儀代・料理・返礼品 など) * 2 通目: **ご友人 A** 請求 (供花 ¥15,000) * 3 通目: **勤務先 B** 請求 (供物 2 点) * 4 通目: **同級生 C** 請求 (供花 ¥10,000) 供物一覧 PDF: **全 4 伝票横断** で「供物」フラグ商品を集約 → 5 件並ぶ ### シーン 4: 法人葬 (会社が請求先 + 多数の供花) 伝票: * 1 通目: **法人 (◯◯株式会社)** 請求 (葬儀本体) * 2 通目以降: 各供花贈呈者の請求 (取引先・関係企業 など) 請求先が会社の場合も、ブリッジ葬儀では Account レコードタイプ「会社」を **請求先** にした伝票として作成。同じ枠組みで運用できます。 ## 伝票区分 (SlipType\_\_c) で「葬儀」と「供物」を分ける v2.3.0+ では、伝票に **「伝票区分」(`SlipType__c`)** という Picklist が必須で入りました (UI で必須入力)。 | 値 | 用途 | | ------ | -------------- | | **葬儀** | 当家への請求 (葬儀本体) | | **供物** | 参列者・取引先からの供物注文 | ### 区分が業務に効くポイント 1. **価格タイプの自動継承** — 「葬儀」区分のみ会員価格を継承。「供物」区分は標準価格 (誤適用防止) 2. **供物一覧 PDF の対象** — `OfferingConfig__mdt` の設定により、どの区分の伝票を集計対象にするか組織で選択 3. **集計の見通し** — 同じ施行情報に紐づく伝票でも、葬儀と供物を区分で分けることで集計しやすい > 同じ「請求先 1 通」の設計を保ちつつ、**業務的な意味で 2 種類** (当家請求 = 葬儀 / 外部供物注文 = 供物) を識別できるようにしたのが伝票区分です。 ## 関連するパッケージ機能 このシンプルな設計を活かす機能群: | 機能 | 内容 | | ---------------------------------------------- | ---------------------------------------------- | | **`Product__c.IsShownOnList__c` (供物一覧に表示)** | 商品マスタ側で「供物一覧の対象か否か」を制御 | | **`SlipDetail__c.IsShownOnList__c` (供物一覧に表示)** | 明細レベルでも個別制御可能 (商品の既定値から上書き) | | **`SlipDetail__c.FudaOrder__c` (札順)** | 供物一覧 PDF の並び順を明細レベルで指定 (将来バージョン強化) | | **`OfferingConfig__mdt`** | 供物一覧の集計対象とする伝票レコードタイプ (見積 / 請求 / 発注) を組織で選択 | | **供物一覧 PDF** | 上記の設定を全部踏まえて、施行情報配下の全伝票から該当明細を集約・並び替えして 1 枚に印刷 | ## こんなときに「設計思想」が効いてくる ### 「外部供花の取引先請求書だけ作りたい」 ブリッジ葬儀: 該当供花贈呈者を請求先にした伝票を 1 通作成 → PDF 出力するだけ。当家請求とは独立しているので影響なし。 ### 「当家請求書に供物代も含めたい」 ブリッジ葬儀: 当家伝票の明細に **供物商品を 1 行追加** するだけ。 ### 「同じ施行で複数の供物贈呈者からの注文をまとめて 1 通の請求書にしたい」 ブリッジ葬儀: それぞれの伝票を作って、**合算請求 (BillingSummary)** にまとめれば 1 通に集約可能 ([合算請求書を作る](/nori/17-billing-summary.md) 参照)。 ### 「供物一覧から特定の伝票だけ除外したい」 ブリッジ葬儀: 該当伝票の明細レベルで `IsShownOnList__c` を OFF にすれば、供物一覧から除外。 ## まとめ | 観点 | ブリッジ葬儀 | 他社一般 | | ------- | --------------------------- | ------------------- | | 伝票の単位 | **請求先ごとに 1 通** | 葬儀請求と供物請求を別画面で分ける | | 当家伝票に供物 | **OK (同居可能)** | 画面が違うので別 | | 入力画面 | **共通 (1 つ)** | 葬儀用と供物用 で別画面 | | 供物一覧の出力 | **商品マスタの供物フラグ** で横断集計 | データ構造で予め分離されているので合算 | | 柔軟性 | **高** (混在 OK / 外部請求もシンプル) | 制約あり (型に当てはめる) | | 学習コスト | **低** (伝票エディタは 1 つだけ覚えれば良い) | 業務パターンごとに画面の使い分け要 | ブリッジ葬儀の伝票は、「**業務の実態をデータ構造に押し付けない**」という考え方で設計されています。葬儀は同じ施行でも、当家請求 / 供花贈呈者 / 法人 / 取引先など多様な請求先が混在しがち。それを **「請求先 = 1 伝票」というシンプルなルール 1 本** で受け止め、横断的な集計 (供物一覧・施行情報の総施行高 など) は **タグ / フラグ / 集計フィールド** で実現する設計です。 ## 次に進む * [供物一覧の運用 (供花・供物の管理)](/fur-no-1-woniu/35-flow-offering-list.md) — このページの設計を活かした供物業務 * [見積書を作る](/ji-ben-cao-zuo/05-create-quote.md) — 伝票エディタでの実操作 * [合算請求書を作る](/nori/17-billing-summary.md) — 複数請求を 1 通にまとめる方法 * [伝票エディタを使いこなす](/nori/10-slip-editor-deep-dive.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/28-slip-design-philosophy.md?ask= ``` 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.