TAMURA Toshihiko
tamur****@bitsc*****
2002年 12月 13日 (金) 10:00:02 JST
梅田さん、こんにちは。 田村です。 mac_user <mac_user****@itpma*****> wrote: > (2)の方法で問題ないと思います。 > > 内税の場合に、精算時に税金を計算するメリットは、顧客、店舗、税務署の > いずれにもないと思います。 はい、そうですね。 > 可能であれば、少し面倒かもしれませんが税率表示が消えれば、よりスッキリする > のではないでしょうか。 > > ============================================================ > ご購入までもう一歩! > 数量 商品名 金額 > 1 test980 980円 > 1 test3590 3,590円 > 小計: 4,570円 > ヤマト宅急便 1 X 4.4 送料: 1,160円 > 合計: 5,730円 > ============================================================ 内税と外税が混在することがあるという話題がありましたが (混在がどの程度あるのか、分かりませんが)、 その場合には、税率の欄をそのまま記入すれば対応できるので、 そういった利点はあると思います。 > > [欠点] > > 将来、異なった税率が混在することがあれば、帳簿処理が問題になるかも。 > > 勘定系システムを osCommerce と連動して開発している店舗は無いか、 > もしあったとしも稀なケースでしょうから、osCommerce としては、顧客との > 「精算」がスムーズに行われることが第一義だと思います。 > > その後の会計処理は、現状では、言い方は悪いのですが精算時にいくら税金を預かって > いようが、決算上の年間「売上」に対する税率で申告するのが通例です。 > > 仮に将来、もし税率が松竹梅の３段階になったとしても、おそらく > > 売上 × 松の割合 × 松の税率 > 売上 × 竹の割合 × 竹の税率 > 売上 × 梅の割合 × 梅の税率 > > で、松竹梅の割合合計が１００％になるよう計算することになるのでしょうけれど、 > それぞれの割合の算出は osCommerce ではなく、勘定系システムにまかせれば良いと > 思います。 (2)の方法では、内税の商品について、 税額そのものの計算はともかく、 各商品がどの税種別(税率)なのかを区別する手段が、 osCommerceの側にはなくなってしまいますよね。 まあ、各商品の仕入れ個数は別に把握できているでしょうから、 その数量と対応税率を管理することなんかは、 通常の業務の範囲内なんでしょうか。 # ともかく、税率の混在自体は仮定の話でした。 正直言って、(2)の方法で済ませたいという気持ちはあります。 -- 田村敏彦 / 株式会社ビットスコープ E-mail:tamur****@bitsc***** http://www.bitscope.co.jp/
