疑問点なんぞを

疑問点と云うか、自分でなんとかしろやって話かも知れないんですが。

消費税はやっぱりめんどい

今まで担当してきたシステムの多くは、例えば売上の場合、売上計上時に消費税算定をしてました。

 売上No 行 商品             数量 単価    売上    消費税 
 ------ -- ---------------- ---- ------- ------- -------
 001     1 ギャンブル大将      1   9,045   9,045     452
 001     2 インベーダー作戦    1   9,045   9,045     452

これが請求時に面倒を起こして(請求全体の売上金額合計から算定される消費税額と誤差がでる)、ああ大変だってのはid:rokugen:20050815#1124087829に書いてみましたが、それもこれも、仕訳大統一理論により、売上計上と同時に仕訳を起こさなければいけなかったからです。売掛金を捉える為にはこの時点で消費税を求めんといかんのです。

 借方               | 貸方
 -------------------|-------------------
 売掛金       9,497 | 売上        9,045
                    | 仮受消費税    452
                    
 これが2つ分。

さて、既に俺は仕訳大統一理論を捨てた訳ですから、売上計上時には別に売掛金なんて事考えずに、商品をいくつ売ったか、その単価はいくらかだけ考えれば良いのです。

 売上No 行 商品             数量 単価    売上   
 ------ -- ---------------- ---- ------- -------
 001     1 ギャンブル大将      1   9,045   9,045
 001     2 インベーダー作戦    1   9,045   9,045

渡辺さんモデルを見てみましょう。売上明細に関するテーブルはないので、販売管理システム側からそのサマリーが収められるらしい「得意先別月次売上SUM」のカラムを確認。

  • 得意先C
  • 年度
  • 月序
  • 月初売掛金残高
  • 月初前受金残高
  • 月間課税売上高
  • 月間免税売上高
  • 月間非課税売上高
  • (後略)

ふむふむ、売掛金じゃなくて、売上高となってますね。恐らく、売上明細で消費税は持たない(持ってても参考項目程度)に違いない。

ただし、税区分によってカラムが分かれてるのでそれは持ってそうです。これは旧来ならば補助科目で持ってたようなもんなんですが、業務別データベース設計のためのデータモデリング入門にもある通り、補助科目なんてもんは会計の枠組以上の情報を仕訳に求めようとするから必要になるんであって、本来なら販売管理システム側で管理すべきで、その主張がここに表出してるんではないでしょうか。勝手に云ってますけど。

そんな訳で、仕訳を作る時、つまり、仕訳データ管理の「仕訳生成処理(売上収益)」の説明には

 №  <借方>     <貸方>
======================================
 01【月間売上増(月間課税売上高+月間免税売上高
           +月間非課税売上高)】
    売掛金      売上
---------------------------------------------------

てな感じで全部足し込んじゃってますね。

ほんじゃ消費税はどうすんのかなって云うと、請求単位で算定して請求書に表記、と思ったんですが。請求見出しテーブルを見てみると

  • 請求№
  • 取引先C
  • 請求日
  • 請求金額
  • 事業所C
  • 年度
  • 月序

ないんですなーこれが。考えてみれば、請求に対する消込なんかないので、請求書に請求金額にかかる消費税を明記したかったら、算定して請求書に出してやりゃいいだけなんで、カラムは要らないんだよなー。そうかそうか。

次に回収、売上受領指示テーブルを見てみる。

  • 売上受領№
  • 得意先C
  • 取引区分
  • 取引日
  • 取引額
  • 値引額
  • 割引額
  • 振込手数料
  • 前受金額
  • 消費税区分
  • 仮受消費税額 ←これこれ
  • (中略)
  • 統一参照№
  • 受領額
  • (後略)

ありましたねー。金額が色々とありますが。

値引、割引は回収時に登録するんですね、なるほど。で、合わせてこの回収のタイミングで消費税に対する入金を登録する形のようです。

で、受領額は導出項目で、仕様はこう。

取引額−値引額−割引額−振込手数料+前受金額

て事は、取引額は売掛金残を消すための金額って事ですね。受領額は得意先が口座に振り込んだ額から、仮受消費税分を除いた金額、って事のようです。

消費税区分を見ると、自動設定と手入力があります。これは、1つの請求に対して得意先が分割で入金して来た場合に手入力するのかな。例えば1,000円 + 消費税50円の請求に対して、1回目は500円の入金、2回目に550円の入金って時、消費税は1回目は0円、2回目は50円と入れる、とか。

どんどん話が拡散しとりますが。やっぱり今までのやり方とあまりに違うんで、段々不安になってきました。特に最初に出来る売掛金に消費税分が入ってこない所とか。やってみますか。

請求はこうだとします。話がややこしくなるんで誤差が出ない金額にしました。

■請求期間 6/21〜7/20
 
 前月残  入金額  当月売上 消費税 請求金額
 ------- ------- -------- ------ --------
       0       0    1,000     50    1,050
 ■明細
 ID  売上日 商品             数量 単価    売上   
 --- ------ ---------------- ---- ------- -------
   1 07/20  ギャンブル大将      1     700     700
   2 07/20  インベーダー作戦    1     300     300

で、今までのやり方だと売上計上時の仕訳はもう出来てるんで、この時点での仕訳はこうですね。面倒なので合算してしまえ。

 借方               | 貸方
 -------------------|-------------------
 売掛金       1,050 | 売上        1,000
                    | 仮受消費税     50

で、1,050円の入金がありましたよ、と。手数料は100円としましょう。手数料にかかる消費税は取り敢えず無視。

 借方               | 貸方
 -------------------|-------------------
 当座預金       950 | 仮受金       1,050
 振込手数料     100 |

ほいで消し込んだよー。

 借方               | 貸方
 -------------------|-------------------
 仮受金       1,050 | 売掛金       1,050

残を見てみましょう。まとめてしまえ。

 借方               | 貸方
 -------------------|-------------------
 売掛金           0 | 売上         1,000
 当座預金       950 | 仮受消費税      50
 振込手数料     100 | 仮受金           0

では、今回のやり方でやりましょう。売上計上しました、と。月次売上受領取引SUMテーブルに記録されます。そこから、仕訳データ管理の「仕訳生成処理(売上収益)」の仕様に基づいて、月次バッチで仕訳が出来ます。

 借方               | 貸方
 -------------------|-------------------
 売掛金       1,000 | 売上        1,000

こうです。消費税は関係ありません。

前述の請求書を出した後、翌月に得意先から請求額通りに(税込みで)現預金で入金がありました。これは売上受領指示テーブルに登録され、月次売上受領取引SUMテーブルに合算され、やはり月次バッチで仕訳が出来ます。かなりはしょって書くとこうですかね。

売上受領指示テーブル
 取引額 手数料 消費税 受領額 
 ------ ------ ------ -------
  1,000    100     50     900

で、サマリーテーブルの「月間売掛回収額(現預金)」ってカラムには、受領額が入る、みたい。で、すると月次バッチで出来る仕訳はこう。

月間売掛回収額(現預金)
 借方               | 貸方
 -------------------|-------------------
 当座預金       900 | 売掛金         900

月間売掛金振込手数料
 借方               | 貸方
 -------------------|-------------------
 振込手数料     100 | 売掛金         100

月間仮受消費税額(現預金)
 借方               | 貸方
 -------------------|-------------------
 当座預金        50 | 仮受消費税      50

ほんじゃさっきと同じように残をみてみましょう。

 借方               | 貸方
 -------------------|-------------------
 売掛金           0 | 売上         1,000
 当座預金       950 | 仮受消費税      50
 振込手数料     100 | 

おおおー、仮受金0円がない事以外ピッタリです。素晴らしー。これで、消費税の誤差の雑収入だの消込だのから解放されるどー!

売上受領指示画面が??

さて、ここまで考えて、ふと画面イメージを見ると、気になる所があります。売上受領指示の登録画面です。

                売上受領明細データの追加

    売上受領№ *AUTO
        得意先 XXXXXXXXXXXXXXX
        受領先 XXXXXXXXXXXXXXX
 現在売掛残高 999,999,999-
 現在前受残高 999,999,999
      取引区分 現預金受領
       計上日 99/99/99 
      取引口座 XXXXXXXXX|▼|
     受領額 999,999,999  (a)
     値引額 999,999,999  (b)
     割引額 999,999,999  (c)
   振込手数料 999,999,999  (d)
    前受金額 999,999,999  (e)
    消費税区分 XXXXXXXX|▼|
   仮受消費税 999,999,999  (f)
  売掛金増減額 999,999,999- (g=a+b+c+d-e-f)
        摘要 XXXXXXXXXXXXXXXXXXXX
  取引後売掛残 999,999,999-
  取引後前受残 999,999,999

   [戻る]    [OK] 

アンダーラインが引いてある所が入力項目なんですけど、うー判りにくい。

これを見ると、売掛金増減額、すなわち売掛金残を消すのに使える金額、つまりは売上受領指示テーブルの「取引額」の欄の横に、

(g=a+b+c+d-e-f)

とあります。よく見ると、受領額から消費税を引いてるんですね。さっきのテーブル定義の説明とちょっと違うのです。

ここでひっかかって、しばし悩んでたんですけど、これは「-f」は要らないんじゃないかなあと思うのですがどうでしょう。

あと、テーブル定義の属性区分では取引額が「固有」、受領額が「導出」となってますが、画面の動きと一致していないように思えます。取引額が他の入力項目の値によって画面上で算定され、導出されているからです。

それとも俺が根本的に間違ってんのかな。受領額が月次サマリーの月間売掛回収額になるってのからして合ってないとか?うーん、悩んだんだけど。

与信の事

与信管理ってのは財務管理のスコープ外になるんだと思いますが、売掛残、前受金残、さらに未決済手形金額を用いて算定した債権残が関わるので、やっぱり気になります。

俺が今まで関わったシステム(と云っても何せ29歳まで遊び人でしたから、そんな数はこなしてないんですが)では、与信限度額と云うのは得意先、正確に云えば複数の得意先を束ねる(事もある)与信先と、部課の単位で管理してました。

つまり、与信先 + 部課 の複合キーなのです。

与信残は、限度額から債権残を引いたものですから、債権残もまた、部課単位で捉えられないとダメって事です。

売上計上の場合、部課は売上見出しに登録されます。そして請求見出しはそれと関係なく、売上明細をまとめあげるので、一つの請求の中で複数の部課の売上が混在してる訳です。

さて、得意先は請求書を見て入金して来る訳ですから、部課なんかしったこっちゃありません。入金額を上手い具合に部課単位に按分する仕組みが必要に思えてきます。

これが今までやってた売上明細に対する消込って奴です。

でももうあの苦しみには戻りたくないです。どうにかして与信管理を明細単位の消込なしに出来ないもんかと、あれやこれや考えてんですが、ギブアップ。うーん頭痛い。

これは現在開発中の販売管理モデルで、ってところでしょうか。うーむ。

とにかく

何が一番、うおーと思ったかと云えば、やっぱり消費税ですね。回収時に初めてデータとして捉えると云う。

どうしても卑近な例で、自分が買い物する時とか思い浮かべて、個々の商品の消費税金額表示などにひっぱられちゃってた気がします。

でもまだ若干の不安があるなあ。理由はないんですけど、実案件でお客様を交えて検討して初めて地に足が付きそう。