業務システムを組む時に考慮すべきポイントその2 赤伝・黒伝

こんにちは。最近は主にラクーンレントに携わっているハッタです。

今川のエントリに続き、業務システムについて書きたいと思います。
今回のテーマは「赤伝・黒伝」です。

赤伝・黒伝とは

今川も書いていたように、売上/仕入などの「お金」に関係するシステムは、売上日などデータの発生基準となる日付が重要となります。
そして、その日付を対象に「締め処理」というものが行われます。

締め処理とは、ある期間に発生したデータを確定させる処理で、確定データを元に請求書を発行したり、IR資料を作成したりします。
請求書やIR資料など外部に向けた帳票・資料を発行するということは、その元となるデータは発行後は基本的に修正できないということになります。

しかしながら、多くの業務システムではデータの入力過程において人力による処理が必要となり、それゆえに入力ミスというものが起こりえます。
入力ミスの対象となるデータがまだ締め処理を経ていないものであれば、対象のレコードを修正することで対応できますが、すでに締め処理を行い外部に発行されたものであれば単純に修正するというわけにはいきません。

そこで必要となる考え方が「赤伝・黒伝」です。(赤伝票・黒伝票とも言います)
修正対象のレコードをUPDATEするのではなく、下記のように2件のレコードをINSERTすることで、最終的に修正後の数字を残すという手法です。
赤伝: 修正対象となるレコードを打ち消すレコード = 元のレコードの金額 * -1、元のレコードと同じ品目など
黒伝: 修正後の金額、品目など

たとえば、2021/9月に発生した10,000円の売上が、2021/10月に伝票を精査した結果、9,000円であることが発覚した場合、下記のようになります。
このとき、9月発生の売上10,000円はすでに締め処理が行われて確定していて修正できないため、修正データは間違いが発覚した10月分として計上することになります。
売上データ

仕訳

金額だけの修正の場合は、赤伝・黒伝の2件をINSERTせずに差額分の1レコードのみINSERTするという方法もありますが、(上記の例なら-1000円のレコードのみ)
仕訳の内訳として商品の品目ごとに数値を管理することもあり、そういった場合は赤伝が必須となります。
たとえば、9月に商品Aの売上として計上していたものが、10月に実は商品Bだったことが発覚した場合、下記のようになります。
売上データ

仕訳

入力ミスが起きやすいのは入金業務

売上の修正について説明しましたが、昨今はECであったり、CORECなどの受発注システムやEDIなどがあるので、売上の入力ミスはそこまで多くは発生しないのかなとも思います。
しかし、入金についてはまだまだミスの起こりうる余地が大きいと感じています。
単純な入金金額だけならば、金融機関のAPIなどが充実しているのでミスの削減はしやすいと思いますが、入金業務には「入金引当」というものがあります。
入金引当とはザックリ説明すると、「銀行口座に振り込まれたお金が、何に対するものなのか対象のデータと紐づけをして確定させる」ということです。

決済手段としてクレジットカードやPaidなどの決済サービスを利用すれば、入金元が集約できるので入金引当の自動化もやりやすくミスを減らせますが、各取引先ごとに銀行振込で対応していると人力による入金引当は避けられません。
入金引当で起こりうるミスとしては、入金元の取引先を誤認した、複数種類の品目の売掛金のある取引先からの入金で引き当て対象の品目を間違った、などがあります。

売掛金の仕訳を取引先ごとに管理することもあり、そういった場合は下記のようになります。
入金データ

仕訳

終わりに

以上、業務システムで起こりがちな入力ミスに対応するための手法としての「赤伝・黒伝」の紹介でした。
DXという言葉が飛び交う昨今、効率化・自動化が進みミスの起こらない環境を構築するのが望ましいですが、人手の介入をゼロにするというのは現実的ではありません。
そして人間が扱う以上、何かしらのミスは起こりうるものという前提で設計・開発していきたいですね。

さて、ラクーングループは一緒に働く仲間を絶賛大募集中です！
業務システムに関するエントリが続いたように、弊社はBtoBのサービスを運営していることもあり、業務知識を活かせる場面も多くあります。
業務系エンジニアからWEBエンジニアへのキャリアチャレンジをお考えの方にとって、過去の経験も活かしやすい環境かなと思います。
もちろん、バリバリのWEB畑の方も大歓迎です！
ご興味を持っていただけましたら、こちらからエントリーお待ちしています！