ブリッジ葬儀サイトへ戻る

機能の深掘り

伝票の設計思想｜「請求先ごとに 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 通に集約可能 (合算請求書を作る 参照)。

「供物一覧から特定の伝票だけ除外したい」

ブリッジ葬儀: 該当伝票の明細レベルで IsShownOnList__c を OFF にすれば、供物一覧から除外。

まとめ

観点

ブリッジ葬儀

他社一般

伝票の単位

請求先ごとに 1 通

葬儀請求と供物請求を別画面で分ける

当家伝票に供物

OK (同居可能)

画面が違うので別

入力画面

共通 (1 つ)

葬儀用と供物用 で別画面

供物一覧の出力

商品マスタの供物フラグ で横断集計

データ構造で予め分離されているので合算

柔軟性

高 (混在 OK / 外部請求もシンプル)

制約あり (型に当てはめる)

学習コスト

低 (伝票エディタは 1 つだけ覚えれば良い)

業務パターンごとに画面の使い分け要

ブリッジ葬儀の伝票は、「業務の実態をデータ構造に押し付けない」という考え方で設計されています。葬儀は同じ施行でも、当家請求 / 供花贈呈者 / 法人 / 取引先など多様な請求先が混在しがち。それを 「請求先 = 1 伝票」というシンプルなルール 1 本 で受け止め、横断的な集計 (供物一覧・施行情報の総施行高 など) は タグ / フラグ / 集計フィールド で実現する設計です。

次に進む

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