「売上伝票」を問い直す

　販売管理システムに「売上伝票」は必要なのだろうか。そんな疑問が昔からある。順を追って説明しよう。

　売上伝票とは、簿記でいう「５伝票制」に含まれる伝票のひとつで、売上にともなう仕訳を記録するための専用様式である。たとえば下のような売上伝票が起票されたとすれば、「売掛金５万円／売上５万円」の仕訳が登録されたことになる。取引が発生する度に「仕訳帳」に貸方と借方の勘定科目を個々に書き込むやり方に比べると、「伝票」は日々の仕訳を手軽に記録してゆくための便利な工夫である。

　　　　　　　　　　売 上 伝 票

　売上日　20XX年11月25日
　 顧客　大日本帝国産業株式大会社

№　商品名　　　　売上数　売上単価　　売上額
―――――――――――――――――――――
01　商品Ａ　　　　　10個　 　5,000円　50,000円

　５伝票制にもとづく手作業の事務作業があって、これを合理化するためのコンピュータシステムを作るとしよう。データベースには、勘定科目マスターや勘定残高テーブル、それに５種類の伝票（売上伝票、仕入伝票、入金伝票、出金伝票、振替伝票）が含まれるだろう（図１では一部の伝票のみ記載している）。テーブル構造としては、見出し明細形式のテーブルのセットがひとつの伝票タイプに対応する。

図１

　ユーザが「売上登録」あたりの機能を使って売上伝票データを新規登録すると、勘定残高が自動更新される。元帳（勘定残高）への転記の手間が省けた。

　さて、上記の構成では売上管理機能が会計システムに寄生する形で置かれていたが、それを独立したモジュールとして切り出したものが、世に言う「販売管理システム」である。これを上記の体制と比べてみると、だいぶ勝手が違う。

　まず、販売管理システム上でユーザは基本的に「売上登録」をしない。その代わりに何をするかは、会社の売上基準によって異なる。出荷基準であれば出荷指示書にもとづいて「出荷報告」を実施する。検収基準であれば、顧客から受け取った検収報告書にもとづいて「検収報告」を実施する。前者の結果として、出荷データが登録・更新される。するとシステムが、出荷テーブルに固有な業務ロジックにもとづいて、売上実績データの登録と残高更新とを実行する。元帳への転記ばかりか、伝票を起票する手間まで省かれている。

　なお、売掛残高の更新を引き起こす取引は、出荷や検収に限らない。返品や他勘定振替、受領といった多様な取引にもとづいて、残高は変化する。それらの定型的な取引について、専用の取引管理用テーブルとデータ保守機能が用意される。それぞれの取引管理用テーブルが、売上実績データの追加と残高更新を引き起こす「売上の元ネタ」になる（図２は生産管理システムでの例）。販売管理システムを使うことで、ユーザは売上や売上基準のことを考えずに「売上の元ネタ」となる各種取引の管理に集中できる。

図２

　他の違いとしては、図１の売上伝票が「仕訳そのもの」である一方、図２の売上実績が「売掛変動履歴」くらいの意味合いに矮小化されている点を挙げられる。なぜそのようになるかというと、図２の構成において「仕訳そのもの」は「（１伝票制の）仕訳伝票」として会計システム上に配置されているはずだからだ。売上実績は「仕訳の元ネタ」ではあっても「仕訳そのもの」ではない。

　したがって売上実績は、会計システムとのインタフェース・データとして仕訳に変換できて、かつ互いに跡付けできるように設計されればいい。売上伝票の形式にこだわる必要はないのである。

　にもかかわらず多くの販売管理システムでは、売上データがいまだに売上伝票であるかのように設計されている。売上伝票を実装することは、図１のような素朴な構成で電算化する際には自然だった。しかし、会計システムと融合していた売上管理機能が独立したモジュールとして切り出される際に、売上伝票のあり方も考え直されるべきだったのではないか。

　そういうわけなので、私は販売管理システム上で売上データを売上伝票であるかのように扱うことをずっと昔にやめてしまった。仕入伝票や入出庫伝票も同様の理由で、それぞれ仕入実績や受払実績に置き換えた（図３は生産管理システムでの例）。ようするにそれらが見出し／明細形式から単独のテーブルに変化しただけなのだが、システム構成がよほどスッキリした実感がある。

図３

　この意味で私は「現行のパネルや帳票の仕様を手がかりにして設計する」という分析的手法の有効性を、腹の底では信用していない。現行仕様は重要な参考情報ではあっても、あるべきシステムの影でさえもない可能性がある。目視できるものに惑わされずに抜本的に考える。それがシステム設計という仕事だ。