kintoneで販売管理システムを作るときの、過去受注の単価変更業務に関する注意点

kintoneで販売管理システムを作るときの、過去受注の単価変更業務に関する注意点

今回は、過去受注の単価変更業務に関する注意点について考えてみたいと思います。

kintoneで動く販売在庫管理システム「でっちどん」は下記バナーから。

kintoneで動く販売在庫管理システム「でっちどん」

弊社が考える注意点は次の3つです。

(1)何を根拠にシステムの単価を変更するか。

こちらは販売管理システムの運用に関する注意事項です。過去の受注単価の変更は、将来の売り上げに影響を与えます。そのため、お客様からの単価変更の依頼書、或いは、新たな注文書を発行してもらい、それを根拠にシステムの単価を変更するのが望ましい運用だと考えます。

(2)すでに一部出荷済みの場合の単価変更ポリシーを予め決めておく

例えば、当初100個×50円 で受注したとします。70個がすでに出荷済みの状態で残りの30個の単価変更を要求された場合の処理方針を予め決めておくのが望ましいです。

いくつかありますが、元の受注データを分割することが、標準的な処理方針の一つです。

前述の例の場合、

100個×50円 の受注を、①70個×50円 と ②30個×新単価 の2つの受注データに分割します。

ここまではポリシーさえ決まっていれば、kintoneで対応するのはそんな難しくないかなと思います。
一番難しいのが3点目です。

(3)毎月の受注残高、受注高を時系列で集計している場合のロジック

こちらについては、文章だと少し伝わりづらいですが、販売管理システムの導入時によく問題となる事項です。以下にて解説します。

毎月の受注残高、受注高を下記のように集計する企業があるとします。

前月末受注残高(A)
当月受注高(B)
当月出荷高(C)
当月受注残高(A+B-C)

さて、この場合に過去受注分の、単価変更が発生した場合、単純に考えると、前月末受注残高(A)が変化してしまいます。しかし、毎月の集計において、過去の確定数字が動的に変化するのはあまり好まれません。

従って、過去受注分の単価変更が発生した場合、その変化分を、(B)当月受注高に反映させるロジックを販売管理システムに組み込む必要があります。

kintoneでそれに対応する場合、下記のいずれかになるかなと思います。

  1. 月をまたいだ場合は基本赤黒(但し注文番号を同一管理する必要があるので、1伝票N明細行の場合かなり難しい)
  2. 月締め段階の受注残をデータとして残しておき、出荷以外の受注額・受注数量の変動分をあとから集計できるようにする。
  3. 受注額・受注数量の変化をリアルタイムで別ログでとっておく。

正直なところ、弊社がkintoneで構築する場合も、この課題はなかなか100点の解決が難しいなと感じている次第です。

今回は、少し細かい話になりましたが、販売管理システム導入を検討されている皆様の参考になれば幸いです。

kintoneで動く販売管理システム「でっちどん」を開発しています。

ご興味があるかたは、下記リンクよりぜひ資料請求、ご相談等お寄せください。


ノウハウ記事作成者:松村 稔 https://x.com/kai0707

1978年 岐阜生まれ。上海レンユアー代表。

2003年から上海で日系企業向けに業務システムの構築サービスを提供。日本向けにもシステム開発サービスを提供。

属人化を排除しつつ、お客様独自の強みを強化する業務システム構築を得意とする。

大規模な工場系基幹システムから、クラウドを活用した商社向けの販売管理システムまで、幅広い経験を活かして、小規模な会社ながら多数の大手企業のシステム導入に参画。