気づけば一日過ぎていた。
注文書部分作成中。
処理はかなり複雑。
発注者側：Cart登録→取り置きor発注→（荷着）→蔵書目録登録
受注者側：受注→（発送）→在庫目録削除
流れは簡単で、ある意味図書館の貸出システムに似ている部分もある。
が、図書館と違うのは、図書館であれば、1図書館対複数利用者、（1：多）で済むのだが、
複数注文者対複数販売者の、（多：多）の関係になる点、
販売者も、不特定多数個人・複数古書店＆古書Project加盟店の3種で、切り替えなければならない。
この間データの処理が複雑に絡んでくる。
おそらく、こんなシステムはこれ迄世界中どこにもなかったと思う。
とはいえ一応、山は越した感じ。
そうそう、affではないが、個人サイトやblogからアクセスや新規user登録あった場合、自動的にpoint加算するプログラムも組み込んである。
これ、結構効果あるのではないかと思う。
当初は、どういう方法とれば可能になるかあれこれ迷っていたが、出来てしまえばかなり簡単。
といっても、これは1年前に実装していたのだが、今回見直して見て、我ながら良くできていると感心。
それと、不正利用があった場合には、登録削除とpoint没収の仕組みも作る予定。
どういう不正が行われる可能性があるかは現在考察中。
あぁ、目録追加もせねば・・・。
そうそう、各user目録データは、imageタグ使って他サイトHTML fileに取り込み表示できる。
これ使うと、各古書店目録公開も単純化できると思うけれど、Cart機能が付けれるかどうかはまだ良く解らない。つうか、出来るとは思うがまだあまり考えていない。
或いは自動サムネイル化画像表示だけの目録とか。（これは割と簡単）
一段落した頃には、そういう機能もつけていく予定。
ベース部分が出来てしまえば、遊び要素を色々つけていく事で表現を楽しむ事も色々出来ると思う。
遊び要素先行して、データ部分がいい加減なのはつまらないからね。
数千程度のデータで遊んでみたってくだらないと思っている。
ちょこちょこと、操作上の説明コメント書き込み。
セッション強制終了などは、説明記しておかないと、普通の人は「あれれ」と怪訝に思うだろうと思った次第。
テナことやっている間に、夜が明けた。眠い。
書誌データ追加で、
とやったら、https://www.yoshikawa-k.co.jp/cgi-def/admin/C-006/store/goods/gd_5.html
こんな頁に遭遇し、dir削っていったら、https://www.yoshikawa-k.co.jp/
こんな頁になった。
こんな拙い設定でも、月に3万円以上とっているのだねえ、と呆れた。
ここhttp://www.hondana.jp/で謳っている、
書協用format変換や送信、（説明はここ、http://www.jbpa.or.jp/database/registration.html#webentry）
こんなのは、簡単に出来る事だけどね。
・・・・月3万ですか・・・・クスクス。
ちなみに、吉川弘文堂のアドレスは、http://www.yoshikawa-k.co.jp/
ところで、http://www.hanmoto.com/shoshijouhou.html
ここには、仕様が違うことで、困惑している小出版社の悲鳴とでも云うべき事が記されている。
http://www.jpo.or.jp/
こういうのが立ち上がっているのだけれど、何やっているのかは良く解らない。
新刊は、この先のことだけ考えていれば済むわけで、100年前に出版された本の事など考慮の埒外で済むのだろうけど、古書扱う側はそういうわけにいかない。
と、グタ話記して、寝るろ。
今日も終日注文書部分作成。が、まだ仕上がっていない。
表示等、気になる部分を色々書き換え試している。
ある意味、この辺りがノウハウ。
セッション持続時間は上限3時間に設定。何度も自動Logout場面に遭遇する。(^^ゞ
これもまぁ、動作確認の一部ではある。
user基本登録事項に、郵便番号と都道府県名＆市郡名を入れるようにした方が良いような気がする。
おおよその到着日数が想定できるし、在外邦人の登録と云うこともある。（この場合は国名）
個人販売の場合、販売者住所・連絡先の登録は必須事項になるが、
注文書作成段階では、購入者に対して部分表示に留め、発注段階でメールに記載すると云う方法にするべきだろうね。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
