入金されたかどうかを追う

月締め請求の記事から、締める、帳票にする、税を合わせる、返品を差し引く、と書いてきました。出した請求が入金されたかどうかは、まだ持っていません。

請求のライフサイクルを閉じます。

状態を持たない

最初に決めたのは、入金済みのフラグを持たないことです。

入金額の合計と請求金額を比べれば、未入金か、一部入金か、入金済みかは決まります。それとは別にフラグを持つと、入金を1件消したときにフラグを戻し忘れる、という事故が起きます。

月締め請求の記事で請求済みフラグを持たせなかったのと同じ考え方です。状態が1か所にしかなければ、ずれようがありません。

入金は1件の請求に何回でもぶら下がります。分割で振り込まれる取引先があるので、1件しか持てない作りだと最初から足りません。

支払期日を決める

期日は取引先ごとに違います。翌月末、翌々月10日、当月25日。取引先に支払月と支払日を持たせました。

締め日と同じ並びに置いてあります。支払日の31も、締め日と同じく月末の意味です。 2月に31日は無いので、その月の末日に丸めます。月締め請求の記事で末日の扱いを決めておいたので、ここは考え直さずに済みました。

計算した期日は、締めた時点で請求に控えます。 あとから取引先の支払サイトを変えても、すでに出した請求の期日は動きません。締めた金額を動かさないのと同じ理由です。

一覧で見える

請求一覧に、入金の状態と支払期日を出しました。

期日を過ぎていて残額があるものに、超過のバッジを出します。 未入金かどうかだけだと、まだ期日前のものと催促すべきものが同じ見た目になります。

振込手数料が引かれる

B2Bでよくあるのがこれです。￥125,153を請求して、￥124,713が振り込まれる。差額の￥440は振込手数料です。

機械的に消していません。 一部入金のまま、残額￥440が残ります。

自動で消す作りにもできます。少額なら入金済みとみなす、という閾値を持たせる形です。やめました。手数料を引かれるのが取り決めどおりなのか、単に取引先が間違えたのかは、金額からは分からないからです。 前者なら値引きとして処理する、後者なら次回に繰り越す、といった判断は人がします。

備考に理由を書けるようにしたのはそのためです。あとで見たときに、なぜ￥440残っているのかが分かります。

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

入金の取り消しと修正ができません。 登録だけ作りました。取り消しは、誰がいつ直したかを残すかどうかも一緒に決めることになるので分けています。

入金の消し込みを自動化していません。 銀行の入出金明細を取り込んで金額と振込名義から請求を突き合わせる、というのが実務では効くところですが、外部との連携になるので入れていません。

残額の繰り越しがありません。 ￥440が残ったまま次の請求が出ます。次の請求に前回の残額を足す運用にするなら、締め処理で未入金の残額を拾うことになります。

督促の通知がありません。 期日超過は画面で見えるだけです。メールを出すなら、いつ誰に何回出したかを残すところから作ることになります。

まとめ

これで、締めて、請求書を出して、返品を差し引いて、入金を確かめるところまで一続きになりました。7本かけて、入力させたのは締め日、支払サイト、返還額、入金額の4つだけです。 残りはEC-CUBEが持っている受注の状態から読んでいます。B2Bの改修で画面が増えるのは、たいてい「読めるものを読まずに聞いている」ときだと思います。