kintoneで販売管理システムを作るときの分納の扱い方

今回は、kintoneで販売管理システムを作るときの分納の扱い方について考えてみます。

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

販売管理システムの重要な機能として、対お客様の業務である受注業務、出荷業務があります。

出荷業務をシステム化するにあたり、構築前に注意しておく点は多々ありますが、本日はその中の「分納」について、紹介します。

例えば、受注が100個で、1回目の出荷が30個、2回目の出荷が70個であった場合、１受注：N出荷に対応している設計にした場合は、

1. 受注100個入力
2. 出荷30個入力
3. 出荷70個入力

の３ステップで処理が完了します。しかし、１受注：１出荷という前提で、分納に対応していない設計にした場合、

1. 受注100個入力
2. 受注数を100個から30個に変更
3. 出荷30個入力
4. 70個の新受注を入力
5. 出荷70個入力

この様にステップが２個増えてしまいます。２ステップとはいえ、日々の運用でこれが続くと年間換算すると大変な時間になってしまいますし、ミスが発生する可能性も高まります。

ただ、kintoneはアプリ間の数字の差引きを苦手としているため、標準機能だけで組む前提で且つ、業務的にも分納の発生が稀であれば、思い切って後者の形でシンプルに作ってしまうのも選択肢の一つです。構造が簡単になりますので、バグ等も発生しにくいです。

きちんと分納対応する場合は、受注アプリと出荷アプリを分けて、出荷アプリの出荷数合計を受注に書き戻す。という様な処理が必要となりますので、プラグインを使用したり、JavaScriptでのカスタマイズが必須にあってきます。

実業務と現状のkintone組み込みのスキルセット等を考慮して、適切な設計ができるとよいと思います。

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

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

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

1978年 岐阜生まれ。上海レンユアー代表。
2003年から上海で日系企業向けに業務システムの構築サービスを提供。日本向けにもシステム開発サービスを提供。
属人化を排除しつつ、お客様独自の強みを強化する業務システム構築を得意とする。
大規模な工場系基幹システムから、クラウドを活用した商社向けの販売管理システムまで、幅広い経験を活かして、小規模な会社ながら多数の大手企業のシステム導入に参画。