月締め請求の記事の最後に、請求書のPDFは次に書きますと予告しました。そのときの見立てはこうです。見積書のPDFは納品書の出力を継承するだけで済んだ、請求書も同じだろう、ただし背景PDFの壁は今度こそ逃げられない。
半分外れました。背景の壁より手前に、継承そのものが届かない壁がありました。
作るもの
月締め請求の明細画面に、出力ボタンを1つ足します。

押すと請求書のPDFが落ちてきます。締めた金額と、そこに入っている受注の一覧が載ったものです。
見積書と何が違ったか
見積書のときは、納品書のPDFを作るクラスを継承して、違うところだけ差し替えれば済みました。タイトル、有効期限、フッター、ファイル名。帳票の骨格は納品書と同じだったからです。
請求書は骨格が違います。
| 納品書・見積書 | 請求書 | |
|---|---|---|
| 1枚の単位 | 1つの出荷 | 1つの請求 |
| 明細の行 | 商品 | 受注 |
| 数量と単価 | ある | ない |
| 金額 | その受注の合計 | 締めた合計 |
本体のクラスは、この違いをまたげない作りになっています。PDFを組み立てる入口は出荷番号の配列を受け取って1件ずつ回すもので、購入者情報を描くメソッドも明細を描くメソッドも、引数が出荷そのものです。
請求には出荷がありません。渡すものがない。組み立ての流れは1つも通りませんでした。
受け継げたもの
では継承した意味がなかったかというと、そうでもありません。
| 受け継げた | 受け継げなかった |
|---|---|
| 日本語フォントの指定 | PDFを組み立てる入口 |
| 座標を指定して文字を置くメソッド | 購入者情報を描くメソッド |
| 表を描くメソッド | 明細を描くメソッド |
| フッターに発行日を出す処理 | 背景PDFの読み込み |
| 店舗情報を描くメソッド | |
| 余白とフッターの初期設定 |
継承の値打ちは道具のほうにありました。 とくに日本語フォントの指定と表を描くメソッドは、自分で書くと面倒なところです。日本語が化けない設定と、行の高さを内容に合わせて伸ばす表が、そのまま使えました。
自分で書いたのは、請求先を描く、請求番号と締め日と金額を描く、明細を組み立てる、この3つだけです。
背景PDFを捨てた
ここからが予告していた壁です。
EC-CUBEの納品書は、A4の枠と見出しが印刷されたPDFを下敷きにして、その上に値を描いています。見積書のときは下敷きをそのまま使い、「お買上げ明細」「[ご注文日]」「[注文番号]」「総合計金額」の4つが見積書に残ったままになりました。あのときは、見積書としては読めるので目をつぶっています。
請求書でも同じことをやってみました。
![納品書の背景を敷いた請求書。「総合計金額」「お買上げ明細」「[ご注文日]」「[注文番号]」の見出しが印刷されていて、自分で描いた請求番号・締め日・件数・ご請求金額と重なっている](/_astro/b2.BYk0DZf4_ZbAPzc.webp)
目をつぶれる状態ではありません。印刷された見出しと、自分が描いた値が重なっています。
避けようとすると、印刷済みの見出しが空いている場所を探して値を置くことになります。それは背景の都合に合わせて請求書の体裁を決めるということで、順番が逆です。しかも「総合計金額」も「お買上げ明細」も請求書には合いません。
下敷きを外しました。 白紙にページを起こして、見出しも自分で描きます。

下敷きを外すと、枠も罫線も見出しも自分の持ち物になります。増えた仕事は見出しを描く数行だけでした。背景PDFを作り替えるより、捨てるほうが早い場合があるというのが今回の結論です。
納品書と同じ体裁を守りたいなら、請求書用の背景を作ることになります。ただしそのときは、値を描く座標も全部合わせ直しです。背景と座標は必ず一組で動きます。
座標で踏んだところ
表を描くメソッドには、開始位置が固定で書かれています。納品書の下敷きで表が始まる高さです。下敷きを外したのだから合わないだろうと思って読みましたが、そのままで無理がありませんでした。 上半分に宛名と金額、下半分に明細という並びは、納品書も請求書も変わらないからです。ここは触っていません。
踏んだのは別のところです。金額を右に寄せようとして、X座標とY座標を順に指定したら、金額が左端に寄って締め日の行と重なりました。
原因はY座標を設定する処理でした。この処理には、X座標を左余白に戻す働きが付いています。 Xを指定してからYを指定すると、Xの指定が消えます。本体の基準座標を決めるメソッドがまさにこの順で書かれているので、それを呼んでいるかぎり右端に何かを置くことはできません。Yを先に、Xを後に、と入れ替えて直りました。
本体の総合計金額が左寄りの位置にあるのは、下敷きの箱がそこにあるからだと思っていましたが、この順番のせいでもあったのかもしれません。確かめていないので推測です。
この記事で扱っていないこと
インボイス制度の要件を満たしていません。 登録番号が入っていません。税率ごとの内訳もありません。受注ごとの税込合計を並べて足しているだけです。適格請求書として出すなら、税率ごとに分けて集計するところから作り直しになります。
(追記:締めてから消費税を計算し直すで足しました。受注ごとに丸めた税額を足すと、締め単位で丸めた額と6円ずれます。)
振込先も印影もありません。 実際に取引先へ送る書面としては、まだ足りません。
出力した記録を残していません。 何度でも出せますし、発行日はボタンを押した日が入ります。再発行すると日付が変わります。控えと同じものを出し続けたいなら、最初に出した日を請求側に持たせることになります。
罫線は明細の表にしか引いていません。 白紙に文字を置いただけの体裁です。
まとめ
| 判断 | 理由 |
|---|---|
| 継承はする | フォントと表の描画は自分で書くと面倒 |
| 組み立ては引き継がない | 明細の単位が商品から受注に変わる |
| 背景PDFは使わない | 印刷された見出しが請求書に合わない |
| 表の開始位置は触らない | 上に宛名、下に明細の並びは同じ |
見積書のときは「本体を編集せずに継承できた」と書きました。今回も本体は1行も編集していませんが、継承で受け取れたのは道具だけです。帳票の種類が増えるほど、本体のクラスは骨格ではなく道具箱として使うことになると思います。