注文書作成部分は一応出来上がり。
あとはメール送信部分。
ここは、point処理プログラムや、在庫処理＆蔵書処理プログラムと連動する部分になるので、今少し煮詰めが必要。
注文書送信時点では、受注側在庫については受注状態として、検索非表示。
が、確定はしていないので、発送完了までは、在庫状態に戻せる設定にしておく必要がある。
発注側では、Cart取り置き状態から、発注済み状態に移し、荷着の時点で蔵書目録に追加。
両者の処理には若干のtime rugが生じるから、その処理をどうするのが良いか・・・。
双方の処理が完了する時点を待って、同時にpoint処理を行う？？
いや、発注側のpoint処理は荷着段階で良いと思うけれど、受注側は受注時点で行わないと問題が発生しそうだね。仮の減算だけ行っておくべきか。
荷着のpoint加算手続きは能動的に行われるだろうから、その時点で受注側も仮状態から確定状態にする処理にすべきか。
point不足状態では、販売目録作成は出来ない設定なんですね。
受注が出来るようにするかどうかは検討課題。
「注文がありました」メールだけ送信するようにして、point加算を促すとかにしたほうがいいのか、あるいは、ある程度のpointマイナス状態を容認するべきなのか・・・・。
この辺りはまだ決めていない。まぁ枝葉のことではあるけれど、この部分の基準作らないとプログラムは組めない。
・pointマイナス状態で、目録追加は不可
・-500pointで、受注不可。在庫検索非対象。
この辺りかな。
この状態が続き、販売目録掲載期間過ぎたものは、自動的に目録削除だし、放置状態続けばuser登録も自動削除。
幽霊userをいかに排除するかというのは結構大事なことで、無意味なサーバー負荷減らす事に繋がる。
ところで、user販売目録は、一応現在公開しているBsearchの検索対象にはなるけれど、user登録しないと購入は出来ない様に設定する。そうすることで取引のトラブルを避ける。
あぁ、そうか、先に蔵書目録作成用プログラム作らないといけないか。
同時に販売目録作成プログラムも必要だ。機能＆処理は連動するからねぇ。
その為には、一旦サーバーに仮upしてみないといけないねぇ。
（今は非公開領域で動作確認してる）
以前upしたものは、探せば見つかるだろうし、一応動作もするはずだけれど正しく動作するとは限らない。つうか、現サーバーに対応していない部分があると思う。
一応メール送信部分作ったけれど、イマイチだ。
Shop用と個人出品用では作り分けした方が良いように思う。
ふむ。Cartのデータ構造変えた方が良いような気がしてきた。
Cartデータ構造の変更完了。4時間ぐらいかかってしまった。
まぁ、関連する部分の変更など色々やっていた為でもあるのだが・・・・。
これで注文メールを、相手先に応じてかなり自由度高く設定しやすくなるし、処理も速い。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
