担当者アカウントの記事で、受注の会員は発注した担当者本人になる、会社宛にまとめるなら集計する仕組みを別に足すことになる、と書きました。B2Bの棚卸しでも、受注を会社単位でまとめる処理がありません、と断っています。

卸売の請求は月締めです。ここが空いたままだと、作った承認フローも見積も、最後の請求で手作業に落ちます。片付けます。

作るもの

取引先に締め日を持たせます。管理画面の会員編集に1項目増えるだけです。

管理画面の会員編集。性別、職業、誕生日、ポイントの下に「締め日」の選択欄があり、20日が選ばれている

締め日が来たら、その取引先の未請求の受注をまとめて1件の請求にします。

管理画面の月締め請求。上に締め日を指定して締めるフォーム、下に請求一覧。株式会社スイーツ商会が2026/08/31締めで4件¥344,300、東京商事株式会社が2026/08/20締めで6件¥488,400、大阪物産株式会社が2026/08/10締めで3件¥129,800

締め日は取引先ごとに違います。20日締めの会社、末日締めの会社、10日締めの会社が混ざっていても、指定した日を締め日にしている取引先だけが対象になります。

明細は、その請求に入った受注の一覧です。

請求INV-202608-00001の明細。請求先は東京商事株式会社、締め日2026/08/20、請求金額¥488,400(6件)。明細に6件の受注が並び、発注者は山田 太郎と、担当者バッジのついた鈴木 花子が交互に出ている

管理者の発注と担当者の発注が1枚にまとまっています。会社単位というのはこれのことです。

作ったものは5つです。

つくるもの役割
締め日取引先の会員が持つ。1〜31。31は月末の意味
請求締めた結果。件数と合計と請求先名称を控える
受注から請求への参照どの請求に入ったか。空なら未請求
締め処理対象の取引先を探して、未請求の受注をまとめる
管理画面締める、一覧、明細、取り消し

締めた金額は動かさない

いちばん迷ったのがここです。

請求金額を、見るたびに受注から集計する作りにもできます。テーブルが1つ減るので、そのほうが素直に見えます。やめました。受注は締めたあとも編集できるからです。

管理画面の受注編集では、明細行を足せます。値引き行も入れられます。送料も変えられます。締めたあとにそれをやると、都度集計では先月出した請求書の金額が後から変わります。 紙で出したものと画面が合わなくなる。

なので、締めた時点の件数と合計を請求側に持たせました。受注をあとで直しても請求は動きません。

請求先の名称も控えています。 会員が退会しても、誰宛の請求だったかが読めるようにするためです。会員への参照は残していますが、表示に使うのは控えたほうの名称です。

代わりに諦めたことがあります。締めたあとに受注を直しても、請求は追いかけません。 直したぶんを反映したいなら、その請求を取り消して締め直すことになります。差額を次回に繰り越すような処理は入れていません。

請求済みフラグを持たせない

受注に「請求済み」の真偽値を1つ持たせる手もありました。これもやめています。

フラグと請求が別々にあると、ずれます。 請求を取り消したときにフラグを戻し忘れれば、その受注は永久に請求されません。逆にフラグだけ立って請求が無い状態も作れてしまいます。

持たせたのは、請求への参照1本だけです。空なら未請求、入っていればその請求に含まれている。状態が1か所にしかないので、ずれようがありません。 取り消しは、参照を空に戻してから請求を消すだけです。

実際に大阪物産の請求を取り消してみると、請求一覧が3件から2件になり、含まれていた3件の受注が未請求に戻りました。締め直すと同じ内容で作り直されます。

期間で切らない

締め日と聞くと「先月21日から今月20日まで」と期間で切りたくなります。切りませんでした。

拾う条件は**「まだどの請求にも入っていない受注」**です。期間の始まりを決めていません。終わりだけ、締め日の終わりで止めています。

理由は取りこぼしです。締め日をまたいでから発送済みになった受注、前回の締めのあとに確定した受注。期間で切ると、これらはどの期間にも入らずに消えます。開始日を持たなければ、遅れて条件を満たしたものは次の締めで必ず拾われます。

画面の大阪物産がその例です。8月10日締めで3件が入っていますが、いちばん古い受注は7月25日のものです。7月10日の締めのあとに発送済みになったので、7月の請求には入らず、8月の請求に乗りました。

代償もあります。締め忘れると、次回の請求が2か月分になります。 期間で切っていれば「7月分」として後から出せますが、この作りでは出せません。毎月きちんと締める運用が前提です。

どの受注を含めるか

対応状況で絞っています。

対応状況含めるか理由
新規受付・対応中含めない金額がまだ動く
発送済み・入金済み含める出したものを請求する
キャンセル・返品含めない請求するものがない
承認待ち含めない稟議が通っていない

いちばん下は承認フローの記事で足したステータスです。何もしていないのに外れているのは、含めるものを並べる形で書いたからです。足したステータスが勝手に請求へ紛れ込まないようにするなら、除外を並べるより、含めるものを並べるほうが安全です。

基準日は受注日にしました。出荷日ではありません。1件の受注に出荷が複数ぶら下がると、出荷日も複数になるからです。 分割出荷が締め日をまたいだとき、その受注をどちらの月に入れるかを決めきれませんでした。受注日なら1つに決まります。

出荷したぶんだけを請求したい会社には、この基準は合いません。そこは扱っていません。

月末締めをどう扱うか

締め日は数字で持っています。末日を選ぶと31が入ります。

2月に31日はありません。ここを素通りさせると、末日締めの取引先が2月だけ締められなくなります。

指定した日がその月の末日だったときは、締め日がその日以上の取引先をまとめて拾います。 2月28日に締めると、締め日を29、30、31にしている取引先が全部入ります。末日でない日を指定したときは、その日と一致する取引先だけです。

締める日拾う取引先
8月20日(末日ではない)締め日が20日の取引先だけ
8月31日(末日)締め日が31日の取引先
2月28日(末日)締め日を28日以降にしている取引先すべて

会社の範囲は作り直さない

請求先をどう決めるか。ここは新しく作っていません。

担当者アカウントの記事で会員に足した親子関係を、そのまま使います。親がいれば親が請求先、いなければ自分が請求先。 それだけです。

受注を集めるときも、請求先本人の受注と、その親が請求先である会員の受注を拾います。明細に出ている担当者バッジは、親を持っている会員の発注という意味です。

多段稟議の記事で親子を3階層に伸ばしましたが、請求では直下の担当者までしか見ていません。課長の下に担当者、部長の下に課長、という構成にすると、部長で締めたときに担当者の受注が入りません。稟議のラインと請求のまとまりは、必ずしも同じ形ではないということです。ここは要件を聞いてから決める部分だと思います。

管理画面に足したもの

会員編集の締め日は、テンプレートを触らずに出しています。フォームに項目を足すとき、EC-CUBEの管理画面にはエンティティ拡張の項目を自動で描く仕組みがあります。項目にその指定を付けておくと、本体の会員編集テンプレートが勝手に並べてくれます。会員編集画面は行数が多いので、コピーせずに済むのは大きいところです。

月締め請求の画面は、受注管理メニューの下に足しました。管理画面のナビゲーションは、決められたクラスを1つ置くと本体が読み取ってメニューに混ぜてくれます。

EC-CUBE 4.4 で引っかかったところ

この実装は4.2や4.3の書き方で書き始めたので、4.4で動かすときに3つ引っかかりました。同じところで止まる人がいると思うので書いておきます。

引っかかったところどうなるか
フォームとナビゲーションのメソッドに戻り値の型がない致命的エラーで管理画面が開かない。インストールも失敗する
ルートをアノテーションで書いているルートが登録されない。画面が404、メニューのリンク生成でエラー
エンティティ拡張のあとにプロキシを作り直していない列はあるのに保存されない。エラーは出ない

上2つはSymfonyの世代が上がったことによるものです。4.4にはアノテーションを読むバンドルが入っていないので、ルートは属性で書きます。詳しくは4.4でプラグインが動かなくなる変更点にまとめてあります。

3つ目がいちばん厄介でした。エラーが出ないまま、拡張した列だけがnullで入ります。 プロキシを作り直しても、Doctrineは古い定義がキャッシュに残っていればそちらを読み、拡張した列を含まないINSERTを組み立てます。キャッシュを消してから確かめてください。

この記事で扱っていないこと

正直に書いておきます。

請求書のPDFがありません。 金額を確定させるところまでです。見積書の記事と同じく納品書の出力を継承する形になりますが、あのとき当たった「文言が背景PDFに印刷されている」壁は請求書でも来ます。見積書は逃げられましたが、請求書は逃げられません。

(追記:請求書のPDFは納品書の継承では届かないに書きました。背景の壁より手前に、継承そのものが届かない壁がありました。)

入金の消し込みがありません。 請求を出したあと、入金されたかどうかを持っていません。請求に状態を1つ足すところから始まります。

消費税を締め単位で計算し直していません。 受注ごとに計算済みの税額を含んだ合計を足しているだけです。締め単位で端数処理をやり直す商習慣の取引先には合いません。

請求番号は連番ではありません。 締めた年月と会員の番号から作っています。取引先ごとに毎月1件なので重複はしませんが、通し番号が要るなら採番の仕組みを別に足すことになります。

まとめ

決めたことそうした理由
締めた件数と金額を控える受注は締めたあとも編集できる
請求済みフラグを持たせない状態が2か所にあるとずれる
期間で切らない遅れて条件を満たした受注を取りこぼさない
受注日で締める分割出荷だと出荷日が1つに決まらない
会社の範囲は親子関係を使う取引先の実体はすでにある

締め処理そのものは短い処理です。時間がかかったのは、締めた金額を動かさないためにどこへ何を持たせるかを決めるところでした。 請求は出したあとが長いので、あとから金額が変わらないことのほうが、集計が正確であることより大事だと思います。