概要

「オンネット在庫」は「オンネット統合業務」の中にあって、POSレジ販売、出荷、発注・入庫、棚卸しなどの機能とマスタ連携しています。セット商品の作成・分解、入出庫予定データ連携、HT連携も保持しており、大変高機能です。ただ各社業務手順や在庫管理の対象品目（購入商品、原材料、仕掛品・副材料など）、マスタ項目（品目マスタ、在庫場所マスタなど）の違いで大きく異なるのが現実です。導入に当たっては程度の差はありますが、カスタマイズ作業は必要になります。カスタマイズ作業については、ソフトウエア部品の再利用や支援ツールで工数抑制を図っています。

「オンネット在庫」はクラウド上で動作し、全国どこからでも利用可能です。ハンディターミナル、その他モバイル端末データもクラウドで統合管理します。新たな省力化機器が出ても、接続手順が明確であれば「オンネット在庫」に接続可能と考えています。

「オンネット在庫」は入出庫伝票を介して連携する仕組み（疎結合）ですので、「オンネット在庫」のみの個別導入やお持ちの稼働中システムとの連動も可能です。その場合は、品目マスタ・在庫場所マスタとの連携機能が必要です。

機能範囲

「オンネット在庫」は入出庫（受け払い）伝票を登録し、在庫台帳を更新するという機能です。ロット管理や個別識別管理、入出庫予定、引き当てなど種々の管理要素が絡み、複雑になります。この管理要素を即時処理で台帳更新するのが望ましいのですが、システムを確実に運用させるためにバッチ処理を採用しています。かつてのメインフレーム時代の処理なので更新タイミングは要求間隔に合わせる努力をしています。即時更新も可能（ダーティ更新）ですが、数分単位で更新するのが妥当と考えています。大事にしているのは、何らかのミスや障害が起きてもデータ復旧できる仕組みです。

「ウチは即時更新が必要だ」とほとんどの会社の方がおっしゃいます。でも実際には、数分単位の運用で問題ない事を経験しています。
機能範囲は下表のとおりです。

入出庫（受払い）伝票登録

・在庫管理の起点

在庫残高（在庫台帳）更新

・前月末残、当月入庫、当月出庫、現残を管理

・台帳更新がバッチ処理

・必要により、即時更新も可能（DBトリガ、ダーティ更新）

棚卸

・理論在庫、現地棚卸、差異伝票作成

ロット（有効期限）管理

個別識別（シリアルNO）管理

予定入出庫伝票

・将来在庫把握のための情報

・受注引き当て、購入入庫情報などと関係

・システム連携以外に、手入力も可能

在庫振替

・在庫場所管振替処理

・即時振替、積送を加味した振替に対応

セット商品組立/分解

・セット商品の組み立て/分解

在庫場所管理

・預け在庫、預かり在庫への対応

・ロケーション（棚番）管理

各種デバイス連携

・バーコードスキャナー

・ラベルプリンタ

・ハンディターミナル（Windows、Android、iOS）

各種システム連携

・販売（受注・出荷）

・購買（発注・入荷・在庫切れ発注）

・生産（蔵入れ、原材料受払いなど）

補足説明

以下の補足説明はこれまで「オンネット在庫」のシステム適用した中で経験し気づいた内容です。これからも色々な気づきがあると思います。その都度考え方を整理し、システム改善を繰り返すことになります。

入出庫（受払い）伝票を処理の起点としているという事

他社の在庫管理システムの仕組みは分かりませんが「オンネット在庫」は入出庫伝票で在庫台帳を更新する仕組みにしています。
例えば「出荷データから直接に」「在庫場所振替データで直接に」在庫台帳を更新しないのです。台帳更新するために必ず入出庫伝票を作成して在庫台帳を更新するのです。こうすることでシステム間で修正処理を生じた場合、プログラムミスが時間をおいて判明した場合など、入出庫伝票を頼りに正しい値にすることができるのです。また、新たなサブシステム（機能）から在庫を操作する場合も入出庫伝票を通じて接続できるのです。

リアルタイム更新とは

世間一般ではリアルタイム（実時間）処理とは同時処理と理解されています。大きな間違いではないですが情報処理の世界では「処理要求やデータが発生したら直ちにコンピューターに入力し，その処理結果をそのときのシステムのおかれた環境の現実の時間の進行の中での働きに十分に間にあうだけの速さで出力する処理方式をいう」としています。
よく「オンネット在庫はリアルタイム処理じゃないの」と要件確定中に言われます。上述、下線部の「現実の時間の中で十分に間にあう速さで在庫台帳を更新します、だからリアルタイム処理です」と言います。
「在庫台帳の更新は秒単位で必要ですか？」について「必要です」の要件もあるでしょう。その時はトリガなどを使って同時処理を実装します。でも5分単位、30分単位で良い場合もあるでしょう。「ウチの仕事、秒単位だよ」「ほんと？アナタ、失礼ですが受領した納品書で直ぐに入庫データ作成しますか？」「同じ商品が同時に売れて、それがマイナス在庫になるケースが想定されますか？」と言いたい気持ちです。 それよりも安全、確実にシステム運用（合理的な運用）した方が良いと思いませんか？

在庫単価は、受け入れ時に金額登録

在庫評価額が必要になる場合があります。その際は入庫時に購入価格を登録する様にしています。その上で在庫金額の計算方法は（移動平均、最終受入単価など）各社個別に対応します。

棚卸作業の棚卸作業表のページ替えは各社異なる

棚卸作業表とは理論在庫表（今これだけ存在するはずだ）の出力です。この作業表で現地在庫を確認します。この作業表の出力単位は各社マチマチです。組織別、担当者別、品目分類別などです。データ内容はシステムから簡単に出力できますが、作業単位に複雑さがあります。「普通こう出すだろう」と言われますが「それ、普通ですか？」です。

棚卸の未入力は0ですか？

これも棚卸作業表に関する事項です。本当に恐縮ですが概ね「棚卸作業はいい加減なところがあります」です。これは仕方ない部分もあると思います。例えば原材料を山に積み上げていて、「実際量を現地で」といわれても実際には分かりません。その上で棚卸管理表に記入できていない品目が発生します。これは０だったのか見落としているのか分かりません。どう扱うかの取り決めが必要です。これも、「普通、こうだろう」と言われますが、「普通ですか？」です。

倉庫間振替は即時入出庫？

倉庫間振替伝票を作る際の話です。A倉庫からB倉庫に移動するとしましょう。データは出庫がA倉庫、入庫がB倉庫となります。この時同時に入出庫を確定させますが、A倉庫とB倉庫が離れていたら、積送中が発生します。どちらも可能です。

モノの数が合わないとモノの移動と登録データを連動させるために

よく「システムで金額が合わない」となります。システム屋の立場で申しますと、モノの数が正確でないと金額は当然ながら「合わない」になります。「モノの数を正確に扱う」ことと「金額を合わせる」は同時に達成されなければいけない、の認識は重要です。この認識のもとに実際のモノの動きとデータ登録を同時に行う事が求められます。その時に活躍するのが、商品、伝票に貼られたバーコードの読み取りです。スキャナー、ハンディターミナル、タブレットは大いに役立ちます。この機器導入効果は絶大です。

システム間連携の訂正データをどう考える

在庫管理システムは多くのシステムと連携します。受注、受け入れ検収、生産などの機能と関係します。例えば出荷情報から出庫データを作成し、在庫台帳を更新します。その後返品された場合、返品伝票を定義し、再販出来るのは在庫（入庫）としそうでないものは、別枠で入庫させる、ということになります。
自動化は可能でしょう。でも手書き返品伝票で入庫データを手動登録する手もあります。過剰な自動化を推進するのではなく合理的な手順を採るべきです。特に他システム（他機能）とは、入出庫伝票で疎結合しているからです。

置場（倉庫）情報には何が必要

在庫管理業務には置場の属性管理が重要です。これまでに次のような管理が必要でした。「倉庫の分類事項＝通常、預け、預かり、取引先、ダミー」「取引先との連携＝得意先コード、発注先コード」及び「発送日カレンダ」などです。今後もっと増えるでしょう。

支払いと請求は入出庫を起点とする場合がある

在庫管理の入出庫で売上計上、支払い計上があるというのは意外でした。販売の売上画面、購買の検収画面などがそれらの起点と考えていました。しかし出庫した数で売上、入庫した数で支払い処理することも効率化に寄与できることが分かってきました。ただ入出庫データから即、請求、支払いと言う訳にはいきません（訂正処理等が発生する）ので、「オンネット販売」「オンネット購買」に接続することになります。

主要画面