販売・在庫・請求連携の設計実務

販売管理、在庫表、請求ソフトが別々に動き、同じ数字を何度も入力している。静岡の中小企業でシステムの相談を受けると、この状態から話が始まることが少なくありません。入力の手間だけでなく、売れたのに在庫が残る、請求額だけ直し忘れるといった食い違いも起きます。

私が現場の打ち合わせで最初に確認するのは、APIとCSVのどちらが高性能かではありません。どの時点の数字を正しいと扱い、何分遅れると仕事に支障が出るのか。ここを決めると、必要な連携方法が見えてきます。

先に決めるのは「どの画面の数字を正とするか」

販売、在庫、請求の各システムが同じ項目を持っていても、全部を相互に書き換える設計は危険です。たとえば商品名は販売側で管理し、実在庫数は倉庫側、請求確定額は請求側を正本にする。項目ごとに更新元を一つ決めます。

静岡市から焼津、藤枝方面まで商品を届ける卸売業を例にすると、営業担当が受注を直した直後に倉庫担当も数量を直すことがあります。両方の修正を無条件で通せば、後から入った数字で上書きされます。「受注変更は販売側から在庫側へ送る」と流れを固定するのが安全です。

商品コード、取引先コード、伝票番号もそろえます。名称だけで照合すると、「株式会社」の有無や全角・半角の違いで別データになりがちです。人が読む名前とは別に、変わらない番号で結ぶ。地味ですが、あとで効く設計です。

APIは、システム同士が決められた窓口を通じてデータを受け渡す仕組みです。店頭で売れた数量を在庫へ反映し、その結果を受注画面へ戻すような処理を、人の操作を待たずに動かせます。複数店舗やネット受注で在庫を共有する業務と相性がよい方法です。

ただし、APIがあるだけでは連携できません。取得できる項目、書き込める範囲、一定時間に呼び出せる回数、仕様変更の通知方法まで確認が必要です。相手サービスの契約内容によっては、連携機能が別料金または対象外の場合もあります。

受託開発では、通信が途切れたときの再処理も決めます。同じ売上を二度送っても二重計上しない識別番号を持たせ、失敗分だけを再送する。エラーを担当者へ知らせる画面や記録がなければ、自動化したぶん発見が遅れます。

CSVは、表計算ソフトでも開ける文字データです。古い販売ソフトから決まった時刻に出力し、請求システムへまとめて取り込む用途なら、APIより小さく始められることがあります。月末に担当者が内容を確認してから請求を確定する会社では、この一手間が安全装置になります。

気をつけたいのは、列の順番や日付表記を担当者が変えてしまうこと。見出し名、文字の種類、空欄の扱い、取り込み済みファイルの保管先を固定します。メール添付で回すより、権限を設定した所定の保管場所へ置き、処理結果を残すほうが追跡しやすくなります。

CSVは古い方法だから劣る、という話ではありません。朝に一度だけ前日分を会計へ渡す仕事なら十分な場合があります。反対に、店頭とネットで同じ一点物を売るなら、翌朝更新では間に合いません。業務の締め切り次第です。

更新回数を増やすほど新しい数字を見られますが、処理負荷と保守費用も増えます。一般的な目安として、店頭とネットの共有在庫は五分から十五分ごと、前日の売上集計は閉店後または翌朝一回でも運用できるケースがあります。請求は日中に仮集計し、締め処理後に確定させる形が現実的です。

大事なのは、データが取れなかった状態を売上ゼロと表示しないことです。「対象なし」と「連携失敗」を分け、最後に正常更新した時刻も見えるようにします。朝礼や締め作業で、現場が迷わず判断できます。

見積金額だけを比べると、連携後の修正費用が見えません。打ち合わせでは、少なくとも次の内容を文書に残します。

試験では、きれいな見本データだけでなく、取消、返品、同名商品、未登録の取引先も流します。普段は出ない例外を先に通しておくと、本番初日の手戻りを減らせます。現場担当者が試験結果を確認できる時間も、開発日程に入れておくと安心です。

最初から全業務をつなぐ必要はありません。まず受注から在庫だけを連携し、安定してから請求へ広げる進め方もあります。現在の販売画面、在庫表、請求書の見本があれば、重複入力と数字の分かれ目を具体的に確認できます。

NIR株式会社では、静岡の業務手順を聞き取り、既存ソフトを残す部分も含めて設計します。まだAPIの有無が分からない段階でも、システム導入・開発を無料で相談するから状況をお聞かせください。今の運用を崩さず、効果を確かめられる範囲から一緒に整理します。