PHP PDO 利用での商品と在庫管理処理について

Question

そもそも可能かどうか？という点からの質問になるので、特にコードなど載せずに質問させていただきます。

・目指したい機能 ＝ トランザクションのコミットを発行するまでの間に、数回、クライアント画面上で処理を実行したい。その間、在庫を押さえたい

環境 PHP5.6 MySQL5.0.11
業務で使っている管理画面が、主に３つ
・工場
・倉庫
・営業
この中で、
工場は完成品の個数と倉庫への在庫情報入力、発送予定の入力などを実行
倉庫は、工場からの入荷と、顧客の元への発送記録を入力
営業は、顧客向けの配送指示を入力

この一連の流れの中で、営業が顧客から注文を受け、商品コードを入力して受注数も入力するのですが、注文数に応じてオプションをいくつか選ぶ必要があるのですが、商品コードを入れてから在庫数をいったん確認して、オプションの照会指示もかけなければならないため、1画面で必要な情報を全て引いてくることが難しく、数回に分けて画面に必要な情報を集めてきて、最後にDBに反映させる必要があります。しかも、個数によっては工場向けの指示と倉庫向けの指示が同時に行われるため、これも、1画面で処理を難しくさせるいったんでもあります。

そこで、営業が発注確定する間、同じ商品コードのモノについて排他ロックをかけざるを得ないのはokということで進めるのですが、いろいろ調べた限りでは、php の処理が完了するときに pdo も破棄されるため、画面をまたぐプーリングができなそうですが、実際に方法はないのでしょうか？

例えば、ホテルや飛行機の予約も同じだと思いますが、空室、空席をある一定時間の間、在庫情報から引き抜き、利用者情報を入力するまでの間、空きを保証するようなシステムは、自前で疑似トランザクションを仕立てているのでしょうか？
（PHP + MySQL に限ってということです）

よろしくお願い申し上げます。

Answer 1

まず、どこの部署から出てきた要件なのか？というのが１つのポイントです。
0. システム部、工場、倉庫、営業、会計（監査）のどの部署から出てきたのでしょうか？
そしてその件について他の部署へはどの程度まで強制できますか？
0. 現行システムにない現状のオペレーションを確認するのもいいかもです。

---

＜＜ 本題 ＞＞
内容を見る限りでは仮引当・予約引当に当たります。
発注残の扱いによって在庫テーブルの持ち方が変わるので一般論でしかいえませんが、
仮引当数は（顧客からの）受注情報（伝票）テーブルと在庫テーブルの両方に持つような形で設計してください。
これは後で消込をするためです。消込タイミングはいろいろなタイミングがあるので、業務要件＆システム要件について設計する必要があります。

---

＜＜ 注意事項 ＞＞
在庫引当に関わることなので、確認が大変です。
業務経験年数が豊富な方にまず在庫の考えについて確認したほうが
特に在庫テーブルからの出力伝票及び売上/会計連動しているならその数値の扱い
出荷予定の扱いも気になりますが・・・

具体的な話は出来ませんでしたので、参考まで。

Comments

[kei344]

もしかして質問内容をエディタで作ってコピー＆ペースしていませんか？teratail のバグで記述内容が表示されないというものが以前有ったので、ペースト後に何文字か記入してみてください。

[umyu]

コピー＆ペーストしたのが原因みたいですー。ご指摘ありがとうございましたー。

Answer 2

Webアプリとするなら、擬似的なトランザクション処理をすることになると思いますが、一連のアプリ挙動をもう一度整理したほうがイイんじゃないですかね？
処理によってはデータの持ち方が変わってくるので、設計をきちんとしたほうが良いかと思います。

例えばですが、途中で処理を中止するとかもありそうなんで、
・処理途中のものは再度アプリを立ち上げるとそこから継続
・処理途中のものは一定期間が経つとキャンセル
等の考慮が必要になってくるかと思います。

比較的融通がききそうなのは、トランザクション用のテーブルを作って、そこで
・処理ステップ
・登録開始時間
等を持たせて、試しながらやってみることですが、追加要件次第では破綻する気がします。

Answer 3

在庫数のフィールドに「予約中」のフィールドを追加するのはどうでしょうか。
最初の画面で在庫数を-1して、予約中を+1します。
最後に確定したら、予約中も-1するような運用で。
途中でやめた場合は予約中を-1、在庫数を+1するといいと思います。

Comments

[退会済みユーザー]

途中でやめた判断ってどうやってするんでしょうか？

[SVC34]

少なくとも誰が、いつ、いくつ予約したかを管理していないと取り消しが出来ませんよ

Answer 4

それぞれ、解決方法を見いだしていただいた皆様に、御礼申し上げます。
今回は、設計の大まかな方針を示してくださった umyu氏 をベストにさせていただきましたが、その他の皆様からのアイディアも大変参考になりましたので、実際のところ、今回の場合は、どの回答が良いとか判断ができないと思っています。

本題の解決策についてですが、もう一度設計と仕様を練り直すことにしました。
今まで何となく使っていた rollback を大々的に活用できないモノか？と考えたのが事の発端でしたが、そもそも機能の思想が違うところにあることに気が付きました。

よって、今回の解決方法としては、
・疑似トランザクションをこしらえる
・仮引き当てテーブルを持ち、在庫参照については常に仮引き当ても参照しながら個数を保証する
・仮テーブルに寿命を設定し、在庫参照時に寿命を考慮しながら、定期メンテではバッチで期限切れレコードを掃除＝自前ガベッジコレクションを付ける
という方針で、全体の業務の流れを組み立て直すことで話し合いがまとまりました。

今回の案件の出所は、営業マターではあるのですが、もともとは工場からで、イケイケの営業中心の発注管理のため、在庫のズレが恒常的で、人力で在庫を合わせていたというすごいところだったので、新しい管理システムを組む流れでしたが、話を詳しく聞いて在庫がズレる理由がよくわかりました（笑）

最後、余談が混ざりました。失礼しました。
いろいろなアイディアをいただいた方々に改めて御礼申し上げます。