流通XML-EDIのJava化計画：その３：統一伝票の想定モデルと流通XML-EDIの問題点

　さて、昨日の話。統一伝票は、小売と卸間で、今実際使われているものなので（多分）、これと流通ＸＭＬ－ＥＤＩが合うかどうか、見てみました。

　はい。合わないです。

流通XML-EDIの想定するモデルと、統一伝票の想定するモデルで合わなさそうなところ

・統一伝票では、問屋（卸）間、さらに工場までも含めているので、直送という概念があります。つまり、ものの流れとお金の流れは一致しません。流通XML-EDIのメッセージでは、そういうものは、たぶん、表現できなさそう。

・統一伝票では、返品の伝票があります。流通ＸＭＬ－ＥＤＩには、返品はない？

　ってかんじで、あわないんです。
　実際に、小売のシステム、卸のシステムを開発するとなると、現状の伝票の流れを元にモデル化するか、統一伝票の流れをもとにモデル化するということになると思います。
　そうすると、流通ＸＭＬ－ＥＤＩで考えられているモデルとかなりずれてくると思います。

　なので、流通ＸＭＬ－ＥＤＩをもとに考えられたクラスがJavaで出来ていて、それを実際のモデルに合わせる際にextendsするのであれば、できそうだし、そういう、フレームワークとしてとらえるのであれば、流通ＸＭＬ－ＥＤＩは役に立つと思います。

　でも、流通ＸＭＬ－ＥＤＩって、システムとしてできてるのよね。
　これに手を入れて修正するって言うのは。。１から作り直したほうが早かったりして(^^;)
　（だって、返品の「業務」ロジックを考えないといけなくなっちゃうんですよ。これ採用したら！）

---

　なお、統一伝票をJavaで表現する場合、この伝票自体を１つのクラスにしてしまえばよさそうですが、流通ＸＭＬ－ＥＤＩは、交換する６種類のＸＭＬデータに対して１つずつクラスを定義したほうがいいと思います。

Kondaraを継承して「ももんが」Linuxになってたのね！

　ウィリアムのいたずらは、ここ数年（３、４年位かな）Linuxからはなれていたので、しらなかったんですけど、Kondaraを継承して、momongaになってるんですね。

　いや、本家のおばかブログを書いていて、Turbo Linuxに、乙部綾子さんの写真集をつけたら！ってかいたところで、
　「そうそう、デジタルファクトリ（昔Kondara Linuxの販売元だった）、売り場にテレビ（ビデオ再生用）いれて、やってたけなあ」
　と思い、「乙部さんのビデオ広告でTurboLinuxを売ったら。。」って書こうと思って、デジタルファクトリしらべたら？？

　　ないじゃん

　えーっと、じゃあ、Kondaraは

　　ないじゃん。

　えーっとえーっと。。。っていうんで、しらべて行き着いたのが、このページ
Kondaraの流れを継ぐMomonga Linux 1がリリース -プロジェクト発足から2年
　なるほどー。ももんがって、こんだらのことかあ。。。
　このへんのいきさつを知らなかったので、「ももんがってなに？」とおもってた。

---

　で、ももんがのホームページをみたら、

momonga projectで開発するツールに「パッケージ更新ツール」おお、これできると便利だよね。
　で、どうなったんだろう。。。これ？？
　つーか、どんなのだか、詳細がわからないのであった。

VBAの本をたくさん書いてる大村あつしさんって、ジャパネットたかたの社長に似てない？？

どーでもいい話なんだけど、

VBAの本を、たくさん書いてる、「大村あつし」さんって、
ジャパネットたかたの社長に似てない？？

比較写真
大村あつしさんは、ここ
ジャパネットたかたの高田社長は、ここ

いや、本当に、どうでもいい話なんだけどね（＾＾；）