20年近く使い続けた請求書システムを変えることに抵抗があり、新しいフォ

質問

20年近く使い続けた請求書システムを変えることに抵抗があり、新しいフォームを付け加えることなどで対応できないか考えています・・・良い案があったら教えてください！

以下の順序で請求先によって消費税の計算方法を区別しようとしたのですが、中身が大幅に変わることで後々の不具合などに応対できるか心配で、他の案を探しています！

1標準モジュールに以下のコードを作成しました。
Public Function TaxInterPre(iNum As Variant, cVal As Variant) As Currency
On Error Resume Next
TaxInterPre = 0
If (IsNull(iNum) Or IsNull(cVal)) Then Exit Function
Select Case iNum
Case 1
TaxInterPre = Int(cVal)
Case 2
TaxInterPre = funcSG(cVal)
End Select
End Function

Public Function funcSG(ByVal xCy As Currency) As Currency
If xCy > 0 Then
xCy = Int(xCy + 0.5)
Else
xCy = Int(xCy - 0.5)
End If
funcSG = xCy
End Function

2得意先名テーブルに税区分フィールドを追加し、入力規則を1 Or 2としました。

3請新フォーム(請求書新規作成)と請修フォーム(請求書修正)のレコードソースとなっているクエリにそれぞれ税区分フィールドを追加しました。

4以下のマクロを作成しました。
アクション　値の代入
アイテム　[Forms]![請新フォーム]![消費税額]
式　TaxInterPre ( [税区分] , Forms![請新フォーム]![税抜金額] *0.05)

アクション　値の代入
アイテム　[Forms]![請修フォーム]![消費税額]
式　TaxInterPre ( [税区分] , Forms![請修フォーム]![税抜金額] *0.05)

5得意先名登録フォームに税区分フィールドを追加しました。

回答No.1

piroin654 · ベストアンサー

以前も申し上げましたが、得意先番号と請求先番号が
別々に管理され、得意先番号と請求先番号につながりが
ない、という現状ではどのようにシステムを補強しても
どのような有効な関数などを取り入れても使い物に
ならないということをもう一度確認してください。

それが解消できれば、以前提案した方法は何の障害も無く
システムに組み込むことができたはずです。

消費税の切り替えは、必要な個々の関数の作成や関数の
呼び出し方法については質問すれば誰かが案を出してくれます。

しかし、もとになるシステムの保守が20年の間にいろいろな
人が付け加えていった結果、得意先番号と請求先番号が
別々に管理されるということになったのかもしれません。
それでは、ある得意先の売上げと請求額はどのように
して特定していたのか、という疑問がおおいに残るのですが。

システムの中で、得意先に関することは、販売実績の閲覧
であろうと請求書の作成であろうとすべて得意先マスタに
登録している得意先番号で行なうべきです。

たとえば、商品番号にしても出荷と入荷の商品番号が違って
いれば何もできなくなるのは自明のことです。

システムを膨らませていく毎にいろいろな人の考えたものが
入っていきます。しかし、得意先番号のような商売の根幹
に関わるようなデータがシステム全体で一貫して使用され
ていないならば、いろいろな提案も行き違いになるのは
目に見えています。

質問の中の関数には私も関わった手前、このように申し
あげている次第です。ekusenさんがシステムを業務の
変化に合わせて、あるいは先取りして再構築したいという
気持ちは良く分かります。また、部分的にいろいろ
変更していくことで業務に支障の出ることが起きは
しないかという心配もわかります。しかし、アバウトな
提案はさておき、質問を凝視して裏の事情を考えながらの
提案は、時としてこのようなことが後から判明すると
お互いの混乱の元になります。それは他のekusenさんの
質問でも同様です。

苦言を呈すようになってしまいましたが、ekusenさんの
やる気と切実さはわかっているつもりです。以前の
質問をもう一度読み直してみます。

お礼

ありがとうございます！

こちらのシステムで得意先の売上を管理していないのでこのようなことになったのかもしれません・・・

請求先コードの名前を得意先コードに変えて対応できるのでしょうか？
ちなみに請求先コードと得意先コードは同じ値です。

得意先名テーブルの得意先コードが"1"で請求明細テーブルの請求先コードが"∞"でリレーションシップがあるのですがそれでもだめでしょうか・・・？

回答No.3

layy

長い目で見たときに、
「内税・外税」の仕様と「税率」の仕様で
どちらが将来仕組みが変わるかと言われたら「税率」の方だと思うので、
これを機に「税率」の仕様もシステム化（フォームから設定値更新で済む等）の
方が良いかと思います。

funcSGについては、それ単体で意味があるのかどうか、
分ける必要もないように思います。

お礼

ありがとうございます！
税率のシステムを変える方向で一度進めてみます。

回答No.2

layy

「消費税の計算方法を区別」というのは内税・外税の話ですか、税率ですか？。

実現になるかわかりませんが、
「消費税率１０％」というのもチラホラ言われています。
システム化改善でこれは視野に入れないのでしょうか？。

共通化できるものは、共通化で良いと思います。

funcSGはTaxInterPreからしかＣＡＬＬされないのかどうか、
ほかからもＣＡＬＬされることがあるのかどうか、そこはわかりません。

お礼

ありがとうございます！

請求書で外税で小計を載せて、消費税額を載せて、合計額も載せているので外税の話だと思います。

funcSGはTaxInterPreと同時に作成したのでTaxInterPreからしかCALLされません。

消費税率の変更はマクロの式の変更で対応する予定なのですが、これではやはり問題があるのでしょうか？