1

私はあまりビジネスマンではないので、(クライアントからの売掛金を処理する) アプリケーションで請求書のデータ構造 (インメモリとデータベース スキーマの両方) をどのように設計すればよいかわかりません。

請求書の項目に関する質問です。アイテムには、名前またはテキストによる説明、単位あたりの価格、および数量の値があることが既にわかっています (したがって、単位あたりの価格に数量を掛けると、行の合計が得られます)。ただし、特に両方がパーセンテージまたは固定額として表現できる場合は特に、行ごとの割引と税金をどのように考慮に入れる必要があるのか​​ わかりません。次に、操作の順序を考慮する必要があります（固定価格です減税は増税前か後か？）

私が考えているDBスキーマは次のとおりです。

InvoiceItems
    InvoiceId        bigint
    ProductId        bigint NULL       -- Optional reference to the product this item is generated from
    Description      nvarchar(255)
    PricePerUnit     money
    Quantity         decimal(9,4)
    AdjustmentBT     money NULL        -- before-tax fixed-value price adjustment 
    AdjustmentBTPerc decimal(9,4) NULL -- before-tax percentage price adjustment
    Tax              decimal(9,4) NULL -- tax as a percentage
    AdjustmentPT     money NULL        -- after-tax fixed-value price adjustment 
    AdjustmentPTPerc decimal(9,4) NULL -- after-tax percentage price adjustment

したがって、行合計は次の関数です。

LineTotal = ( ( ( ( ( PricePerUnit * Quantity ) + AdjustmentBT ) * AdjustmentBTPerc ) * Tax ) + AdjustmentBT ) * AdjustmentPTPerc

またはRPNで：

LineTotal = PricePerUnit Quantity * AdjustmentBT + AdjustmentBTPerc * Tax * AdjustmentBT + AdjustmentPTPerc *

私は請求書を扱う人ではなく、このプログラムを書いている相手からのフィードバックが限られているので、考えすぎているのかどうかはわかりません。十分な柔軟性を提供する必要がありますが、複雑になることはありません。このアプローチでは、各請求書の項目は次のようになります。

Description | PricePerUnit | Quantity | Before-tax Adjustment | Tax | Post-tax Adjustment | %computedTotal%

...調整フィールドは、「%」文字の有無に応じて、入力された値をパーセンテージまたは固定値として解釈します。

4

2 に答える 2

1

クライアントから「物事がどのように機能するか」についてサポートを受けられない場合は、すでに問題が発生しています。単純な事実は、アプリケーションのこの部分に対する「承認」基準がなく、たまたま重要であるということです。

これがどのように計算されるかについて、彼らからより良い要件を得る必要があります。

多くの場合、割引は乗算ではなく加算されます。

具体的には：

$100 with a 10% discount (on sale) and 20% discount (coupon)

Discount total Additive: $100 * (10% + 20%) = $100 * 30% = $30 discount

Discount total Multiplied: 
    $100 * 10% * 20% =
    $100 * (100 - 10%) * (100 - 20%) =
    $100 * .90 * .80 =
    90 * .80 =
    $72 = $28 discount

したがって、明らかに、これらのケースのルールが何であるかを知ることが重要です。

たとえば、税金はほぼ常に追加されます。5% の州税と 2% の地方税がある場合、$5 + $2 の税金がかかります。

割引情報を別のテーブルに入れ、コードを使用することをお勧めします。

簡単な表:

discount_key - primary key
discount_code - code for humans
description - what kind of discount
percent_discount - percent of discount - OR - 
fixed_discount - Fixed amount discount
gl_acct_id - GL account to post discount amounts to.

そして、各項目 (および請求書...) を割引タイプに関連付けます。その理由は、多くの場合、割引の種類が問題になるためです (10% オフ クーポンの割引は、10% オフの開封済みアイテムの割引とは異なります)。アカウントの目的上、これらの割引は個別に追跡される傾向があります。

あなたの税情報はおそらくアイテムに関連付けられているはずです。税管轄区域が 1 つしかない場合は、1 パーセントの金額で問題ありません。それ以外の場合は、割引テーブルのような同様のテーブルを指定します。複数の管轄区域がある場合は、個々の税率のリストのマスターとなる税グループを指定します。

請求書全体にも適用される割引が必要です (すべてが 20% オフなど)。

最終的に、製品、数量、割引コード、割引合計、税合計、明細合計を含む詳細明細表が作成されます。これは、請求書の印刷に適しています。転記の場合、複数の税金がある場合は、個々の税金を再計算する必要があります。明細項目ごとに個別の税明細を使用する方がよい場合があります。それ以外の場合は、詳細行番号から直接作業できます。

とにかく、ここで重要なことは、要件についてクライアントの理解を深める必要があるということです。割引は、複雑で悪名高い領域です。私が働いていたある場所では、割引システムをほぼ完全に、毎年4年間、ほぼ完全に作り直しました. (ただし、古いコードを保持することを忘れないでください。古いシステムを使用した古い請求書があります!) これは、マーケティングが割引ポリシーを推進し、マーケティング担当者が気まぐれであるためです。

ああ、会計へようこそ。「どれくらい大変ですか？」

于 2013-06-14T04:31:40.990 に答える