価格表・商品属性・単位・GST を1つのERPで統合する実践ガイド（インド中小企業向け）

多くのインドチームが抱える 価格と商品マスタの混乱

インドで流通や製造の事業を運営しているなら、商品データはおそらく5つの異なる場所に分散しています。営業チームはスプレッドシートで価格表を管理し、倉庫はホワイトボードで個数と箱数を追跡し、購買チームはキログラム単位で仕入れ、経理は月末に会計ソフトで消費税を適用しています。顧客から見積もりを求められたとき、3人が3つのファイルを開いて1つの質問に答える状況です。

ひび割れは請求書の段階で最も早く現れます。プネーの販売店は同じ商品を小売業者にはある価格で、中小企業の買い手には別の価格で販売しますが、どちらも「レート」という1つの単一な列から引き出されます。コーヤンブトゥールの製造業者は工場では1箱を24個、営業シートでは20個と定義しているため、まとまった注文のたびに手作業で数え直す必要があります。色やサイズのような属性は商品写真の中にしか存在せず、チームは赤のバリエーションと青の在庫を区別できません。

インドの中小企業に関する研究は、この混乱の規模を示しています。申告エラーの調査では、約70%の中小企業が還付税額の不一致を報告し、56.7%が誤った請求書明細、43.3%が間違った税計算を挙げています。根本原因はGSTの計算そのものではありません。価格、単位、属性、税のデータが別々のサイロに分かれており、監査人が強制するまで調整されないことです。一つの正しい情報源であるはずのERPが、5つの意見の不一致の源になっています。

4つのスラブへの統合と改訂されたHSNコード体系を伴うGST 2.0は、サイロ方式を維持できないものにします。税率が変更されるたびに、チームは価格表を開き直し、単位換算を再確認し、属性を再確認し、税を再適用しなければなりません。これら4つのマスタのいずれかが古ければ、請求書は誤り、電子請求書は拒否され、買い手の還付税額はブロックされます。

価格・単位・属性・GSTが一緒に存在するとどう変わるか

インド市場向けに構築されたモジュラー型ERPは、これら4つのマスタを結びつけ、1つの商品レコードが下流のシステムに必要なすべての情報を運べるようにします。基幹システムはこれらのそれぞれを第一級のモジュールとして実装しており、設計は流通・製造チームの実際の働き方に沿っています。

ルールベースの上書きを持つ価格表

商品ごとに1つのレート列ではなく、プラットフォームは名前付きの価格表を保存します。価格表は価格決定ルールと割引ルールの集合体です。各ルールには値の適用方法を制御するタイプがあります。固定価格ルールは商品の基本価格を完全に上書きします。割引率ルールは0%から100%の割引を適用します。割引額ルールは定額のルピー割引を適用します。これらのエンティティは価格表・価格ルールモジュールに存在し、エンジンはルール実行後の最終単価を返します。

ルールは特定の商品または商品カテゴリー全体を対象にでき、カテゴリールールはカテゴリー階層をさかのぼり、最も近い上位のルールが優先されます。各ルールには最小数量と有効期間の開始日・終了日もあるため、数量割引や季節価格は設定項目であり、スプレッドシートの保守作業ではありません。価格計算の結果は最終価格と並んで基本コストも公開するため、マージンは取引成立後に発見されるのではなく、見積もり時点で確認できます。

優先順位は意図的で監査可能です。顧客固有の価格表が最優先され、次に顧客の既定の価格表、そして商品の基本価格となります。結果は価格の出所も記録するため、買い手がレートに異議を唱えたとき、チームはそれを生成した正確なルールを示すことができます。

双方向換算を持つ計量単位

計量単位はフラットなリストではなく、階層として定義されます。単位は名前、書類用の記号、そして基準単位をいくつ含むかを示す含有数量を持ちます。1箱は10個を含みます。1ケースは12箱を含みます。1パレットは10ケースを含みます。換算サービスはこの階層を双方向にたどるため、2パレットを個に換算することも500個を箱に換算することも、従業員が手作業で維持する参照表ではなく、1つの操作で済みます。

インドにとって重要なのは、単位が商品と包装単位に付属することです。商品は固有の在庫単位を持ち、それぞれの代替販売可能な包装単位は在庫単位に対する換算係数と、既定の取引単位を示すフラグを持ちます。そのため1つの商品をキログラムで仕入れ、個で在庫し、カートンで販売でき、すべての数量が同じ基準に調整されます。これはGST申告をクリーンにする基盤です。課税数量と請求数量が常に一貫しているからです。

商品属性とバリエーション生成

サイズ、色、等級のような属性は自由テキストではなく、マスタレコードです。属性は値のリストを持ち、属性ラインは属性を商品テンプレートに付加します。バリエーション生成サービスは選択された値のデカルト積を取り、組み合わせごとに1つの在庫可能な商品を作成します。色として赤と青、サイズとして小と大を選択すると、4つのバリエーションが自動的に生成され、それぞれが固有のSKUを持ちます。

これはGSTと在庫がバリエーションを気にするため重要です。誤ったバリエーションの出荷は、返品、再在庫コスト、消費税のクレジットメモになります。バリエーション行列が構造化された属性から生成されるとき、倉庫は正確なSKUをピックし、価格表はバリエーションごとにルールを保持でき、請求明細はその特定の品目の正しいHSNと税率を運びます。

設定可能な税エンジンによるGST

プラットフォームの税は、価格決定の中に埋め込まれた列ではなく、別個の設定可能なマスタです。税設定は名前、0%から100%までの税率、販売税の負債勘定、購買税の資産勘定を持ち、勘定サブタイプは書き込み時に検証されます。各商品は税設定を付加するため、軽減税率の品目はそのスラブに、標準品目は別のスラブに既定値となり、税率は下流で再入力されるのではなく入力時に正確になります。

この分離についての設計は意図的です。価格計算は単価、コスト、適用された割引を返し、税を除外します。税は専用の商品税経路で解決されます。この分割こそがGSTをクリーンにするものです。課税額が割引によって誤って膨らむことはなく、割引が税の包含によって歪められることもありません。請求書時点で2つのストリームは正しく結合されます。これはGST 2.0の照合が期待する構造そのものです。

実際のシナリオ

アーメダバードにある約180の有効なSKUと3つの顧客階層を持つ中堅電気機器販売店を考えてみましょう。小売業者はカートン単位で購入し、リスト価格が適用されます。中小企業の買い手はケース単位で購入し、リストから8%の割引を受けます。2つの大手機関買い手は12の高売上SKUについて交渉した固定価格を持っています。

モジュラー型ERPを採用する前、このチームは3つの価格スプレッドシート、倉庫の壁に貼られた換算早見表、そして誰かが記憶で更新する消費税率の列を維持していました。GSTスラブが変更されるたびに2日間の調整が必要で、毎四半期、公認会計士は少なくとも12件の請求書で単位と税率がHSNと一致しないものを見つけていました。

価格表、計量単位、属性、税設定が1つの基幹システムで連携すると、同じ事業は異なる動きをします。販売店は階層ごとに1つずつ、計3つの価格表に加え、2つの機関買い手向けの専用価格表を設定します。各高売上SKUは買い手の価格表で固定価格ルールを持ち、交渉されたレートが自動的に適用され、基本価格が受注画面に露出することはありません。数量割引は最小数量ルールを使うため、50カートンの注文は経営者への電話なしで大量価格を引き当てます。

計量単位は包装の現実を処理します。在庫単位は個です。20個のケースと240個のカートンは換算係数を持つ包装単位であり、カートンで入力された受注は倉庫がピックする在庫単位に正しく換算され、消費税の請求書は正しい数量と単位コードを報告します。属性は電圧と色のバリエーションを定義し、各バリエーションは親の税設定を継承しながら固有のSKUと在庫を持ちます。

税エンジンはGSTを店員ではなく商品に結びつけます。18%のスラブが適用されるとき、それは商品の税設定がそう指示しているからであり、販売税は入力時に負債勘定に、購買税は資産勘定に転記されます。期末決算では、課税額がスプレッドシート間で分割されていなかったため、請求明細と調整されます。中小企業の運転資金サイクルにとって、この照合スピードは今月還付税額を請求することと来四半期まで待つことの違いです。

この基幹システムはあなたの事業に適しているか

このアプローチは、単一の価格列とフラットな単位リストを成長させ、超えてしまったインドの流通・製造チームに適合します。同じ商品を異なる買い手タイプに異なる価格で販売する場合、異なる計量単位で仕入れ・販売する場合、バリエーションを写真で管理する場合、あるいはGSTスラブの変更が数日間の対応を引き起こす場合、この4マスタモデルはあなたの営業の現実のために構築されています。

少数のSKUを1つの価格で1つの単位で扱う場合には必須ではありません。しかし成長するインド企業の多くはその閾値をすぐに超え、何年ものスプレッドシートの漂流の後に追いつくコストは、初日から構造化されたマスタで始めるよりもはるかに高くなります。

よくある質問

小売業者、中小企業の買い手、大手機関顧客で異なる価格を維持できますか？

はい。別々の名前付き価格表を作成でき、価格計算時に顧客固有の価格表が優先され、次に顧客の既定の価格表、そして商品の基本価格にフォールバックします。固定価格、割引率、割引額の各ルールで、交渉レート、階層割引、季節価格を同じシステムで表現できます。

個、箱、ケース、キログラムのような計量単位はERPでどう処理されますか？

単位は階層を形成し、各単位は基準単位をいくつ含むかを定義します。換算サービスはこの階層を双方向にたどるため、在庫単位と包装単位の間の換算は自動です。各商品は換算係数を持つ複数の販売可能な包装単位を持て、フラグが既定の取引単位を示します。

還付税額と監査のためにGSTはどのようにクリーンに適用されますか？

税は別個の設定可能なマスタです。各税設定は0%から100%までの税率を持ち、販売税の負債勘定と購買税の資産勘定にリンクし、サブタイプは書き込み時に検証されます。各商品は税設定を付加するため、正確なGST税率が入力時に既定値となります。価格計算は課税価格を返し税を除外し、税は別途解決されるため、課税額と割引が照合のためにクリーンに保たれます。

重要なポイント

価格表、商品属性、計量単位、GSTは4つのツールで解決すべき4つの問題ではありません。それらは4つの角度から見た1つの商品マスタです。ERPがこれらを接続されたモジュールとしてモデル化するとき、チームはスプレッドシートの調整をやめ、請求書、ピックリスト、GST申告が設計によって一致することを信頼し始めます。

価格・単位・税の手作業による調整をやめましょう

基幹システムは、ルールベースの上書きを持つ価格表、双方向の計量単位階層、属性主導のバリエーション生成、設定可能なGST税エンジンを1つのモジュラー型基幹システムに統合しています。クレジットカード不要で最大2ユーザーまで使える無料プランで始めて、事業が実際に運営される通りに商品マスタを設定しましょう。Kikan Systemを始める。

関連記事

• 基幹システムにおける消費税の出納元帳構造
• ERPでの消費税出納元帳マッピング
• 消費税の期末照合と基幹システム
• 統一されたマスタデータとデータ品質