(57)【要約】【課題】  届出仕様で記述されている届出分類ＤＢを、受注仕様で記述されている届出分類ＤＢに変換する過程をコンピュータ化する。【解決手段】  自動車の属性毎に提供可能仕様のリストを記憶している車両仕様ＤＢ２２と、属性の仕様の組合せの可否を記憶している制約条件ＤＢ２４と、属性の仕様の組合せで特定される届出仕様と届出分類の関係を記憶している届出仕様による届出分類ＤＢ２８と、届出仕様による届出分類ＤＢ２８に記憶されている届出仕様を、その届出仕様を特定する属性の仕様の組合せに展開した車両仕様による届出分類ＤＢ３０と、自動車の受注に必要な属性と仕様の組合せを記憶している受注仕様ＤＢ２６と、車両仕様による届出分類ＤＢ３０に記憶されている属性の仕様であって、受注仕様ＤＢ２６に記憶されていない属性の仕様を受注仕様ＤＢ２６に記憶されている属性の仕様に置換える手段３３を備えている。【選択図】  図２
2006277423.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータ装置であり、
商品の属性毎に提供可能仕様のリストを記憶している「商品仕様ＤＢ」と、
「一つの属性の仕様」と「他の属性の仕様」の組合せの可否を記憶している「制約条件ＤＢ」と、
「属性の仕様」の組合せで特定される分類用仕様と商品分類の関係を記憶している「分類用仕様による商品分類ＤＢ」と、
「分類用仕様による商品分類ＤＢ」に記憶されている分類用仕様を、その分類用仕様を特定する「属性の仕様」の組合せに展開した「商品仕様による商品分類ＤＢ」と、
商品の受注に必要な「属性と仕様」の組合せを記憶している「受注仕様ＤＢ」と、
「商品仕様による商品分類ＤＢ」に記憶されている「属性の仕様」であって、「受注仕様ＤＢ」に記憶されていない「属性の仕様」を、「制約条件ＤＢ」に記憶されている制約条件によって、「受注仕様ＤＢ」に記憶されている「属性の仕様」に置換える関係を演算する手段と、
前記演算手段で演算された関係を利用して、「商品仕様による商品分類ＤＢ」に記憶されている「属性の仕様」の組合せを、「受注仕様ＤＢ」に記憶されている「属性の仕様」の組合せに置換える手段と、
を備えている「受注仕様による商品分類決定用ＤＢ」の作成装置。
【請求項２】
コンピュータ装置であり、
自動車の属性毎に提供可能仕様のリストを記憶している「車両仕様ＤＢ」と、
「一つの属性の仕様」と「他の属性の仕様」の組合せの可否を記憶している「制約条件ＤＢ」と、
「属性の仕様」の組合せで特定される届出仕様と届出分類の関係を記憶している「届出仕様による届出分類ＤＢ」と、
「届出仕様による届出分類ＤＢ」に記憶されている届出仕様を、その届出仕様を特定する「属性の仕様」の組合せに展開した「車両仕様による届出分類ＤＢ」と、
自動車の受注に必要な「属性と仕様」の組合せを記憶している「受注仕様ＤＢ」と、
「車両仕様による届出分類ＤＢ」に記憶されている「属性の仕様」であって、「受注仕様ＤＢ」に記憶されていない「属性の仕様」を、「制約条件ＤＢ」に記憶されている制約条件によって、「受注仕様ＤＢ」に記憶されている「属性の仕様」に置換える関係を演算する手段と、
前記演算手段で演算された関係を利用して、「車両仕様による届出分類ＤＢ」に記憶されている「属性の仕様」の組合せを、「受注仕様ＤＢ」に記憶されている「属性の仕様」の組合せに置換える手段と、
を備えている「受注仕様による届出分類決定用ＤＢ」の作成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受注仕様から商品分類を決定するために用いるデータベースを作成する装置に関する。
【背景技術】
【０００２】
最初に、主要用語の意味を説明する。
「商品」：譲渡や貸し渡しの対象となる有体物をいう。特に、多種類が存在する商品をいう。
「属性」：複数仕様から選択可能な項目をいう。例えば、商品が自動車であり、同一車種でありながら、１５００ｃｃのエンジンと１８００ｃｃのエンジンから選択可能である場合には、排気量が一つの属性となる。本明細書では、大分類ということもある。
「仕様」：属性の水準をいう。１５００ｃｃのエンジンを持つ商品は、「エンジン」という属性の仕様が「１５００ｃｃ」であることになる。
例えば、図３に例示するように、「パワーウインドウ」という属性には、「前席のみ」という仕様と、「前席＋後席」という仕様と、パワーウインドウが装着されて「いない」という仕様が存在し、「リヤヘッドレスト」という属性には、「あり」という仕様と、「ない」という仕様が存在し、「グレードパッケージ」という属性には、「Ｄパッケージ」という仕様と、「エコパッケージ」という仕様と、「なし」という仕様が存在し、「アイドルストップシステム」という属性には、「あり」という仕様と、「なし」という仕様が存在し、「ホイール」という属性には、「スチール」という仕様と、「アルミ」という仕様と、「マグネシウム合金」という仕様が存在し、「バンパー」という属性には、「大型」という仕様と、「小型」という仕様が存在する。
【０００３】
「ＤＢ」：コンピュータに読取り可能にデータを記憶しているデータベースをいう。
「商品仕様ＤＢ」：商品の属性を一覧表に持ち、属性毎に提供可能仕様のリストを記憶しているＤＢをいう。
「車両仕様ＤＢ」：商品が自動車である場合の商品仕様ＤＢをいう。
「制約条件」：商品の設計等によって、物理的または技術的に提供できない「属性と仕様」の組合せが存在する。例えば「エンジン」が「１５００ｃｃ」の商品には「バンパー」が「小型」のものしか装着できないといったことがある。あるいは、図４（Ａ）に例示するように、「グレードパッケージ」が「Ｄパッケージ」であれば、「リヤヘッドレスト」という属性は、「あり」という仕様となり、「ない」という仕様は提供できないといった制約条件が存在することがある。あるいは、図５（Ａ）に例示するように、販売戦略等によって、「グレードパッケージ」が「Ｄパッケージ」という仕様であれば、「パワーウインドウ」という属性は、標準的に「前席＋後席」という仕様となり、「前席のみ」という仕様がオプションで選択でき、「なし」という仕様の商品は販売しないことがあり、「グレードパッケージ」が「なし」という仕様であれば、「パワーウインドウ」という属性は「ない」という仕様となり、「前席のみ」という仕様や、「前席＋後席」という仕様の商品は販売しないことがある。これらも制約条件である。
【０００４】
「商品分類」：「属性の仕様」の組合せによって決定される商品の種類を、長さ、重量、価格等の指標によって分類したものをいう。エンジンが１５００ｃｃの自動車の重量とエンジンが１８００ｃｃの自動車の重量は相違し、バンパーが大型の自動車の長さとバンパーが小型の自動車の長さは相違し、グレードパッケージがＤパッケージの自動車の重量とエコパッケージの自動車の重量は相違する。自動車という商品を譲渡する場合には、自動車税、重量税、取得税等が課税されるが、その課税額は、自動車の長さ、重量、価格等によって異なってくる。そこで、課税額毎に自動車を分類しておく必要がある。例えば、エンジンが１５００ｃｃでグレードパッケージがＤパッケージは何番の分類であり、エンジンが１５００ｃｃでグレードパッケージがエコパッケージは何番の分類であり、エンジンが１８００ｃｃでグレードパッケージがＤパッケージは何番の分類であり、エンジンが１８００ｃｃでグレードパッケージがエコパッケージは何番の分類であるのかを判別可能にしておかなければならない。自動車を分類できないと課税額が決まらず、課税額が決まらなければ自動車を販売することができない。
上記は課税額を決定するのに必要な分類を例示したが、それ以外に、例えば品質保証期間を決定するために商品を分類する必要がある場合もあれば、完成検査項目を決定するために商品を分類する必要があることもある。
「届出分類」：自動車の場合、課税額等を決定するために、自動車を分類し、それを行政庁に届けておく必要がある。行政庁に届けられている自動車の分類を届出分類という。
「分類用仕様」：例えば、エンジンが１５００ｃｃでグレードパッケージがＤパッケージでアイドルストップシステムがない自動車は何番の分類であり、エンジンが１５００ｃｃでグレードパッケージがＤパッケージでアイドルストップシステムがある自動車は何番の分類であるという場合、両者に共通する「エンジンが１５００ｃｃ」で「グレードパッケージがＤパッケージ」である点をまとめて扱うと簡便化される。例えば、それをまとめてα１仕様と表現することにすると、「α１仕様でアイドルストップシステムがない自動車は何番の分類であり、α１仕様でアイドルストップシステムがある自動車は何番の分類である」といったように、分類体系が簡単化される。例えば「エンジンが１５００ｃｃ」で「グレードパッケージがＤパッケージ」であるという「属性の仕様の組合せ」で特定される分類用仕様（先の例でいえばα１仕様）を利用すると、商品分類ＤＢが簡単化される。自動車の場合、属性の数が多く、属性あたりの仕様の数も多く、商品分類も多い。分類用仕様を駆使して届出分類ＤＢが完成されている。自動車の重量や長さ等が同じものを一つの分類用仕様にまとめながら届出分類ＤＢを完成しないことには、届出分類ＤＢを完成することすらできない。
「届出仕様」：商品が自動車である場合の分類用仕様をいう。自動車の分類用仕様は、届出分類とともに、行政庁に届けられている。「α１仕様でアイドルストップシステムがない自動車は何番の分類である」といったことが行政庁に届けられている。
【０００５】
「受注仕様」：例えば自動車の場合、属性の数が極めて多い。いくら多くても、属性毎の仕様が決定されなければ、自動車の種類（「属性の仕様の組合せ」によって決定されるものを「種類」ということにする）は決まらない。しかしながら、前記した「制約条件」が存在するために、すべての属性毎に仕様を決定しなければならないものでもない。図４（Ａ）に例示した場合、「グレードパッケージ」が「Ｄパッケージ」であれば、「リヤヘッドレスト」は「あり」に決定される。すなわち、「リヤヘッドレスト」という属性の仕様は、「グレードパッケージ」という属性とは独立に仕様を決定する必要がなく、「グレードパッケージ」という属性の仕様を決定すれば「リヤヘッドレスト」という属性の仕様は決定される。
このように、自動車の種類を決めるためにはすべての「属性の仕様」を決定する必要はなく、制約条件が存在することから、「特定の属性の仕様」さえ決めれば自動車の種類が最終的に決定されることがある。自動車の種類を最終的に決定するのに必要な属性をここでは「受注属性」という。また需要者が選択可能な「受注属性と仕様」の組合せを示すデータを受注仕様という。図９は、受注仕様を例示している。制約条件が存在することから、２重丸に示す「グレードパッケージ」の仕様さえ選択すれば、一重丸に示すように、「パワーウインドウ」の属性や「リヤヘッドレスト」の属性や「アイドルストップシステム」の属性の仕様が決定され、パワーウインドウやリヤヘッドレストやアイドルストップシステムの属性については仕様を決定する必要がないことを例示している。「グレードパッケージ」の仕様や、「エンジン」の仕様等、限られた属性の仕様さえ決定すれば、自動車の種類が決定される場合を例示している。
図９で２重丸で例示する属性が受注属性である。図３の車両仕様ＤＢに用意されている属性のうちの一部が受注属性である。受注属性は、通常、需要者が商品選択しやすい属性が選択されている。
【０００６】
行政庁が課税額等を決定するために知る必要がある分類用仕様（届出仕様）と、需要者が商品選択に際して重視する受注仕様は、対応しないことが多い。そもそも両者は別の目的のために選択されているからである。
【０００７】
上記の事情から、商品を受注すると受注仕様が決定される。すると、その受注仕様から商品分類（自動車の場合には届出分類）を決定する必要がある。そのために、受注仕様で商品分類（届出分類）を記述するデータベースを用意する必要がある。
現状では、商品仕様（車両仕様）と、制約条件と、受注仕様と、分類用仕様（届出仕様）を熟知し、制約条件を縦横に駆使しながら特定の仕様から他の仕様に紐付けていく能力が鍛え抜かれた熟練者のスキルに依存して、受注仕様で商品分類（届出分類）を記述するデータベースを用意している。
その作業を担当できる作業者は限定されており、特定作業者に依拠している。その作業には多大の時間を要しており、苦労の種となっている。商品はますます多様化しており、作業はますます複雑さを増しており、ヒューマンミスが避けられなくなりつつある。
【０００８】
用途を異にするデータベース間でデータ項目を変換する技術が特許文献１に開示されている。
【０００９】
【特許文献１】特開２００３−２３３７６５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
特許文献１の技術によると、コンピュータ装置を利用することによって、用途を異にするデータベース間で変換処理をすることができる。
しかしながら、分類用仕様（届出仕様）と受注仕様は、全く異なっていることが多い。届出仕様から受注仕様に変換するまでには様々な条件が存在しており、特許文献１の技術では変換できない。
現状では、商品仕様（車両仕様）と、制約条件と、受注仕様と、分類用仕様（届出仕様）を熟知し、制約条件を縦横に駆使しながら特定の仕様から他の仕様に紐付けていく能力が鍛え抜かれた熟練者のスキルに依存して、受注仕様で商品分類（届出分類）を記述するデータベースを用意している。
商品はますます多様化しており、作業はますます複雑さを増しており、ヒューマンミスが避けられなくなりつつある。コンピュータ装置によって、受注仕様から商品分類（届出分類）を決定することを可能とするデータベースを作成する技術が待望されている。
【課題を解決するための手段】
【００１１】
本発明では、図１に模式的に示されているように、「受注仕様による商品分類決定用ＤＢ」１４を作成するコンピュータ装置を創作した。このコンピュータ装置は、図１に模式的に示されているように、商品の属性毎に提供可能仕様のリストを記憶している「商品仕様ＤＢ」２と、「一つの属性の仕様」と「他の属性の仕様」の組合せの可否を記憶している「制約条件ＤＢ」４と、「属性の仕様」の組合せで特定される分類用仕様と商品分類の関係を記憶している「分類用仕様による商品分類ＤＢ」８と、「分類用仕様による商品分類ＤＢ」８に記憶されている分類用仕様を、その分類用仕様を特定する「属性の仕様」の組合せに展開した「商品仕様による商品分類ＤＢ」１０と、商品の受注に必要な「属性と仕様」の組合せを記憶している「受注仕様ＤＢ」６と、「商品仕様による商品分類ＤＢ」１０に記憶されている「属性の仕様」であって、「受注仕様ＤＢ」６に記憶されていない「属性の仕様」を、「制約条件ＤＢ」４に記憶されている制約条件によって、「受注仕様ＤＢ」６に記憶されている「属性の仕様」に置換える関係を演算する手段１２と、その演算手段１２で演算された関係を利用して、「商品仕様による商品分類ＤＢ」１０に記憶されている「属性の仕様」の組合せを、「受注仕様ＤＢ」６に記憶されている「属性の仕様」の組合せに置換える手段１３を備えている。
【００１２】
本発明では、分類用仕様が「属性の仕様」の組合せで特定されることに着目し、「分類用仕様による商品分類ＤＢ」８をまず、分類用仕様を特定する「属性の仕様」の組合せに展開した「商品仕様による商品分類ＤＢ」１０に変換する。
「商品仕様による商品分類ＤＢ」１０に展開される仕様は商品仕様であるが、受注仕様には含まれていないことがある。そこで、「商品仕様による商品分類ＤＢ」１０に変換するだけでは、受注仕様が決定されても商品分類を決定することができない。
そこで本発明では、「商品仕様による商品分類ＤＢ」１０に展開される仕様であって、「受注仕様ＤＢ」６に記憶されていない「属性の仕様」を「受注仕様ＤＢ」６に記憶されている「受注属性の仕様」に置換える。このときに、「制約条件ＤＢ」４に記憶されている制約条件を利用し、「受注仕様ＤＢ」６に記憶されていない「属性の仕様」を「受注仕様ＤＢ」６に記憶されている「受注属性の仕様」に置換える関係を演算する。以上によって、「分類用仕様による商品分類ＤＢ」８を、「受注仕様による商品分類決定用ＤＢ」１４に変換することができる。
本発明は、「分類用仕様による商品分類ＤＢ」８を「受注仕様による商品分類決定用ＤＢ」１４に直接的に変換するのではなく、まず「商品仕様による商品分類ＤＢ」１０に変換し、次いで「受注仕様による商品分類決定用ＤＢ」１４に変換する過程を採用する。各変換過程には、コンピュータによる変換ロジックが採用でき、一連の変換過程をコンピュータ化することができる。２回の変換に分解することによって、コンピュータによって実行可能な置き換えロジックを採用可能とし、「分類用仕様による商品分類ＤＢ」８を「受注仕様による商品分類決定用ＤＢ」１４に変換することに成功した。
【００１３】
本発明は、商品が自動車である場合に特に有用である。自動車の場合、自動車分類を予め届け出ておく必要があることから、ここでは届出分類という。またその分類に利用する分類用仕様を届出仕様という。
本発明のコンピュータ装置は、図２に模式的に示されているように、「届出仕様による届出分類ＤＢ」２８を、「受注仕様による届出分類決定用ＤＢ」３４に変換する。
このコンピュータ装置は、自動車の属性毎に提供可能仕様のリストを記憶している「車両仕様ＤＢ」２２と、「一つの属性の仕様」と「他の属性の仕様」の組合せの可否を記憶している「制約条件ＤＢ」２４と、「属性の仕様」の組合せで特定される届出仕様と届出分類の関係を記憶している「届出仕様による届出分類ＤＢ」２８と、「届出仕様による届出分類ＤＢ」２８に記憶されている届出仕様を、その届出仕様を特定する「属性の仕様」の組合せに展開した「車両仕様による届出分類ＤＢ」３０と、自動車の受注に必要な「属性と仕様」の組合せを記憶している「受注仕様ＤＢ」２６と、「車両仕様による届出分類ＤＢ」３０に記憶されている「属性の仕様」であって、「受注仕様ＤＢ」２６に記憶されていない「属性の仕様」を、「制約条件ＤＢ」２４に記憶されている制約条件によって、「受注仕様ＤＢ」２６に記憶されている「属性の仕様」に置換える関係を演算する手段３２と、その演算手段３２で演算された関係を利用して、「車両仕様による届出分類ＤＢ」３０に記憶されている「属性の仕様」の組合せを、「受注仕様ＤＢ」２６に記憶されている「属性の仕様」の組合せに置換える手段３３を備えている。
【００１４】
「届出仕様による届出分類ＤＢ」２８を、直接的に「受注仕様による届出分類決定用ＤＢ」３４に変換しようしてしても、変換過程があまりに複雑となり、コンピュータ処理することができない。
本発明では、「届出仕様による届出分類ＤＢ」２８を、「車両仕様による届出分類ＤＢ」３０に変換する。届出仕様は、「属性の仕様の組合せ」で特定されていることから、この過程はコンピュータ処理することができる。
「車両仕様による届出分類ＤＢ」３０には、車両仕様ではあるが、受注仕様には含まれていない車両仕様が含まれていることがある。そこで、「車両仕様による届出分類ＤＢ」３０に変換するだけでは、受注仕様が決定されても届出分類を決定することができないことがある。
そこで本発明では、「車両仕様による届出分類ＤＢ」３０に展開されている車両仕様であって、「受注仕様ＤＢ」２６に記憶されていない「属性の仕様」を「受注仕様ＤＢ」２６に記憶されている「受注属性の仕様」に置換える。このときに、「制約条件ＤＢ」２４に記憶されている制約条件を利用し、「受注仕様ＤＢ」２６に記憶されていない「属性の仕様」を「受注仕様ＤＢ」２６に記憶されている「受注属性の仕様」に置換える関係を演算する。以上によって、「届出仕様による届出分類ＤＢ」２８を、「受注仕様による届出分類決定用ＤＢ」３４に変換することができる。
本発明は、「届出仕様による届出分類ＤＢ」２８を「受注仕様による届出分類決定用ＤＢ」３４に直接的に変換するのではなく、まず「車両仕様による届出分類ＤＢ」３０に変換し、次いで「受注仕様による届出分類決定用ＤＢ」３４に変換する過程を採用する。各変換過程には、コンピュータによる変換ロジックが採用でき、一連の変換過程をコンピュータ化することができる。２回の変換に分解することによって、コンピュータによって実行可能な置き換えロジックを採用可能とし、「届出仕様による届出分類ＤＢ」２８を「受注仕様による届出分類決定用ＤＢ」３４に変換することに成功した。
【発明の効果】
【００１５】
本発明によって、「分類用仕様（自動車の場合には届出仕様）による商品分類（自動車の場合には届出分類）ＤＢ８（自動車の場合には２８）」を、「受注仕様による商品分類（自動車の場合には届出分類）ＤＢ１４（自動車の場合には３４）」に変換する過程をコンピュータ化することに成功した。
熟練者のスキルに依存して実行していた処理を自動化することが可能となり、処理時間が短縮され、ヒューマンミスを防止することが可能となった。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の好適な実施形態を説明する。
（形態１）制約条件は、技術的ないし設計的事情による制約条件と、営業戦略による制約条件で構成されている。
【実施例】
【００１７】
以下に本発明を自動車という商品に適用した実施例を説明する。本発明は、自動車に限って有用な技術ではなく、多種類が存在する商品に対して一般的に適用可能である。
図３は、商品の属性毎に提供可能仕様のリストを記憶している「商品仕様ＤＢ」２であり、自動車の場合には自動車の属性毎に提供可能仕様のリストを記憶している「車両仕様ＤＢ」２２に記憶されている情報の一例を例示している。この場合、「パワーウインドウ」という属性（大分類ということもある）には、「前席のみ」という仕様と、「前席＋後席」という仕様と、パワーウインドウが装着されて「いない」という仕様が存在し、「リヤヘッドレスト」という属性には、「あり」という仕様と、「ない」という仕様が存在し、「グレードパッケージ」という属性には、「Ｄパッケージ」という仕様と、「エコパッケージ」という仕様と、「なし」という仕様が存在し、「アイドルストップシステム」という属性には、「あり」という仕様と、「なし」という仕様が存在し、「ホイール」という属性には、「スチール」という仕様と、「アルミ」という仕様と、「マグネシウム合金」という仕様が存在し、「バンパー」という属性には、「大型」という仕様と、「小型」という仕様が存在することを例示している。
以下では、例えば「パワーウインドウ」という属性を記号Ａで示し、「前席のみ」という仕様を数字１で示し、「前席＋後席」という仕様を数字２で示し、パワーウインドウが装着されて「いない」という仕様を数字３で示す。例えばＤ１は、「アイドルストップシステム」という属性Ｄが、「あり」という仕様の商品（自動車）であることを意味する。
「車両仕様ＤＢ」２２に記憶されている情報は、技術的ないし設計的な限界条件を意味するものであり、そこに含まれていない「属性の仕様」は製造不能であるが、そこに含まれている「属性の仕様」の組合せの全部が製造可能であることを意味しない。
【００１８】
図４は、「一つの属性の仕様」と「他の属性の仕様」の組合せの可否を記憶している「制約条件ＤＢ」４，２４の一例を例示している。
例えば、図４（Ａ）では、技術的ないし設計的な限界条件から、「グレードパッケージ」が「Ｄパッケージ」であれば、「リヤヘッドレスト」という属性は、「あり」という仕様となり、「ない」という仕様は製造できないことを示している。図４（Ｂ）では、「グレードパッケージ」が「Ｄパッケージ」であれば、「アイドルストップシステム」という属性は、「なし」という仕様となり、「あり」という仕様は製造できないことを示し、「グレードパッケージ」が「エコパッケージ」であれば、「アイドルストップシステム」という属性は、「あり」という仕様となり、「なし」という仕様は製造できないことを例示している。
【００１９】
図５は、「一つの属性の仕様」と「他の属性の仕様」の組合せの可否を記憶している「制約条件ＤＢ」４，２４の他の一例を例示している。
例えば図５（Ａ）では、販売戦略等によって、「グレードパッケージ」が「Ｄパッケージ」という仕様であれば、「パワーウインドウ」という属性は、標準的に「前席＋後席」という仕様となり、「前席のみ」という仕様がオプションで選択できるという型式１となり、「なし」という仕様の型式は販売しないことを例示している。あるいは、「グレードパッケージ」が「なし」という仕様であれば、「パワーウインドウ」という属性は「ない」という仕様の型式３となり、「パワーウインドウ」が「前席のみ」という仕様や、「前席＋後席」という仕様の型式は販売しないことを例示している。なお実際には、「グレードパッケージ」が「Ｄパッケージ」という仕様である場合、「パワーウインドウ」という属性は、標準的に「前席のみ」という仕様となり、「前席+後席」という仕様がオプションで選択できるという型式２も販売されることを例示している。
図５（Ａ）に例示する制約条件は、専ら販売戦略によるものであり、販売仕様ＤＢに記憶されている。
図５（Ｂ）は、図５（Ａ）から型式情報を省略した情報であり、販売戦略等によって、「一つの属性の仕様」と「他の属性の仕様」の組合せの可否が定められていることが理解される。擬似的な制約条件となっていることが理解される。
【００２０】
図６は、分類用仕様（自動車の場合には届出仕様）を例示している。分類用仕様（届出仕様）は、商品（自動車）の「属性の仕様」の組合せで特定される。
例えば、分類用属性（届出属性）の一つにＡパッケージという属性があり、その属性が「あり」という仕様と「なし」という仕様では、商品分類（自動車の場合には届出分類）が相違してくることを例示している。ここで、Ａパッケージという属性が「あり」という分類用仕様（届出仕様）は、パワーウインドウとリヤヘッドレストの双方を持つことを意味しており、パワーウインドウとリヤヘッドレストの一方または双方とも持たない場合には、Ａパッケージという属性が「なし」という分類用仕様（届出仕様）になることを例示している。
例えば、「パワーウインドウとリヤヘッドレストの双方を持ち」「アイドルストップシステムがある」自動車は何番の分類であり、「パワーウインドウとリヤヘッドレストの双方を持ち」「アイドルストップシステムがない」自動車は何番の分類であるという場合、両者に共通する「パワーウインドウとリヤヘッドレストの双方を持つ」である点をまとめて扱うと簡便化される。例えば、それをまとめてα１仕様と表現することにすると、「α１仕様でアイドルストップシステムがない自動車は何番の分類であり、α１仕様でアイドルストップシステムがある自動車は何番の分類である」といったように、分類体系が簡単化される。図６は、パワーウインドウとリヤヘッドレストの双方を持つ自動車は、自動車の重量や長さ等に関して共通に扱える一方、パワーウインドウとリヤヘッドレストの一方または双方を持たない自動車とは、自動車の重量や長さ等に関して共通に扱えないことを例示している。「属性の仕様の組合せ」で特定される分類用属性（先の例でいえばα属性）を利用すると、商品分類ＤＢ８（自動車の場合は届出分類ＤＢ２８）が簡単化される。自動車の場合、車両仕様ＤＢ２２の属性の数が多く、属性あたりの仕様の数も多く、商品分類も多い。分類用仕様（届出仕様）を駆使して届出分類ＤＢ２８が完成されている。自動車の重量や長さ等が同じものを一つの分類用仕様（届出仕様）にまとめながら届出分類ＤＢ２８を完成しないことには、届出分類ＤＢ２８を完成することすらできない。
分類用属性（届出属性）βは、アイドリングシステムの有無によって、自動車の重量や長さ等が、分類を異にするほど相違してくることを例示している。分類用仕様（届出仕様）が、商品仕様（車両仕様）自体であることもある。
【００２１】
図７は、分類用仕様（自動車の場合には届出仕様）と商品分類（届出分類）の関係を記憶している分類用仕様による商品分類ＤＢ８（自動車の場合には届出仕様による届出分類ＤＢ２８）の記憶内容を例示している。
届出属性αの仕様が１であり、届出属性βの仕様が１であり、届出属性γの仕様が１である商品（自動車）の分類（型式）はＷ１であることが例示されている。自動車の場合、型式が決定されると、自動車税、重量税、取得税等の課税額が決定される。
【００２２】
図９は、商品（自動車）の受注に必要な「属性と仕様」の組合せを記憶している「受注仕様ＤＢ」６，２６の一例を示している。
図４と図５に例示した制約条件が存在することから、図９の２重丸に示す「グレードパッケージ」の仕様さえ選択すれば、一重丸に示すように、「パワーウインドウ」の属性や「リヤヘッドレスト」の属性や「アイドルストップシステム」の属性の仕様が決定され、パワーウインドウやリヤヘッドレストやアイドルストップシステムの属性については仕様を決定する必要がない関係にあることを例示している。「グレードパッケージ」の仕様や、「エンジン」の仕様等、限られた属性の仕様さえ決定すれば、商品（自動車）の種類が決定される関係にあることが例示されている。
図９で２重丸で例示する属性が受注属性であり、「受注仕様ＤＢ」６，２６には、受注属性の組合せが記憶されている。「グレードパッケージ」の仕様や「エンジン」の仕様等、「受注仕様ＤＢ」６，２６に一覧表示されている属性の仕様さえ決定すれば、他の属性の仕様が一意に決定され、他の属性の仕様まで選択する必要はない。
図３の車両仕様ＤＢに用意されている属性のうちの一部が受注属性である。受注属性は、需要者が商品選択に利用しやすい属性が選択されている。「受注仕様ＤＢ」６，２６は、図３と図４に例示した制約条件と、図５に例示した制約条件に基づいて用意されている。図５に例示した制約条件は、販売仕様ＤＢに記憶されている。
【００２３】
図１３は、「届出仕様による届出分類ＤＢ」２８を「車両仕様による届出分類ＤＢ」３０に変換する過程を示している。
ステップＳ２では、届出仕様を車両仕様に引当てる。図６に例示したように、例えば、分類用属性（届出属性）がＡパッケージであるα属性が「あり」という届出仕様は、パワーウインドウとリヤヘッドレストの双方を持つことを意味しており、届出属性がＡパッケージであるα属性が「なし」という届出仕様は、パワーウインドウとリヤヘッドレストの一方または双方を持たないことを例示している。
すると、図８に例示するように、α１という届出仕様は、パワーウインドウとリヤヘッドレストの双方を持つ車両仕様に等しく、図３を参照すると、（Ａ１またはＡ２であり）かつ（Ｂ１）であることに等しいことがわかる。また、図８に例示するように、α２という届出仕様は、パワーウインドウとリヤヘッドレストの一方または双方を持たない車両仕様に等しく、図３を参照すると、（Ａ３でありＢ１であり）または（Ａ１でありＢ２であり）または（Ａ２でありＢ２であり）または（Ａ３でありＢ２であり）であることに等しいことがわかる。
図８の５４は届出仕様を例示しており、６２はそれを車両仕様に展開した関係を例示している。
図１３のステップＳ２では、図６に例示した届出仕様と車両仕様の関係を利用して、図８の届出仕様５４を車両仕様６２に展開する。
【００２４】
図１３のステップＳ４では、引当て関係を展開し、総組合せをリスト化する。例えば、α１という届出仕様は、（Ａ１またはＡ２であり）かつ（Ｂ１）であるという車両仕様を、図８の６２に示すように、（Ａ１かつＢ１）または（Ａ２かつＢ１）であることに展開する。
図１３のステップＳ６では、届出仕様が異なるにもかかわらず、車両仕様に展開したら同一の展開結果になってしまった事象の発生を監視する。この事象は、本来的には発生しないはずであるが、図８の展開関係を厳密に展開しないとかかる事象が発生する。例えば、α２という届出仕様は「パワーウインドウとリヤヘッドレストの一方または双方とも持たない車両」であり、「全車両」から「パワーウインドウとリヤヘッドレストの双方を持つ車両」を除外した関係にある。そこで、α２という届出仕様を「全車両」に展開すると、α２が「パワーウインドウとリヤヘッドレストの双方を持つ車両」を含むように展開される。この場合、「パワーウインドウとリヤヘッドレストの双方を持つ車両」はα１に対して展開されている。そこで「パワーウインドウとリヤヘッドレストの双方を持つ車両」はステップＳ６でイエスとなる。この場合、「パワーウインドウとリヤヘッドレストの双方を持つ車両」はα１に属するから、α２から消去すればよい。図１３のステップＳ８では、この処理を実施する。以上の処理の後、届出仕様を車両仕様の組合せに展開する関係を確定する（ステップＳ１０）。
図８は、以上の処理結果を例示している。図１０は、一連の変換過程の処理結果を例示しており、届出仕様５４が、車両仕様の組合せ６２に変換されている。
図８と図１０に示すように、車両仕様の組合せ６２に展開された段階では、受注仕様ＤＢ６，２６に含まれていない属性の仕様が含まれており、まだ受注仕様から届出分類を決定することができない。図１０に示すように、車両属性Ａ，Ｂ，Ｄは、受注仕様ＤＢ６，２６に含まれていない。
【００２５】
図１４は、届出分類ＤＢ２６に含まれている届出仕様を、車両仕様の組合せ６２に展開した段階から、受注仕様ＤＢ２６に含まれている仕様だけに変換するまでの処理を示している。
図１４のステップＳ２０は、届出分類ＤＢ２８に含まれている届出仕様５４を車両仕様の組合せ６２に展開した段階で、受注仕様以外の仕様が存在するか否かを判定する処理であり、通常はイエスとなる。届出分類ＤＢ２８に含まれている届出仕様５４を車両仕様の組合せ６２に展開したら受注仕様だけで記述される場合（通常はありえない）は、ノーとなり、処理はステップＳ４０に進む。ステップＳ４０では、不能な組合せを排除する。届出分類ＤＢ２８には、制約条件が反映されておらず、制約条件に反する組合せが含まれている。本装置によると、届出分類ＤＢ２８に記憶されている届出仕様５４が受注仕様の組合せに展開されるために、制約条件に反する組合せを容易に発見することができる。ステップＳ４０で制約条件に違反する組合せが排除されることによって、受注仕様から商品分類（自動車の場合は届出分類）を決定するためのＤＢ１４，３４が完成する（ステップＳ４２）。
【００２６】
通常は、届出分類ＤＢ２８に含まれている届出仕様５４を、車両仕様の組合せ６２に展開した段階では、受注仕様以外の仕様が含まれており、図１４のステップＳ２０がイエスとなる。図１０の場合、車両仕様の組合せ６２に展開した段階では、受注仕様以外の属性Ａ，Ｂ，Ｄが含まれている。
この場合、ステップＳ２２で、非受注仕様と受注仕様の間に制約条件１が存在するか否かを判定する。ここでいう制約条件１は、図４に例示したように、技術的ないし設計的な限界条件から、組合わせて製造することができない条件を意味している。図４の場合、「グレードパッケージ」が「Ｄパッケージ」であれば、「リヤヘッドレスト」という属性は、「あり」という仕様となり、「ない」という仕様は製造できないことを示している。図３から「グレードパッケージ」が「Ｄパッケージ」であるＣ１の場合には、「リヤヘッドレスト」が「あり」というＢ１の仕様となり、Ｂ１はＣ１に置き換えられることを例示している。同様に、「グレードパッケージ」が「なし」であるＣ３の場合には、「リヤヘッドレスト」が「なし」というＢ２の仕様となり、Ｂ２はＣ３に置き換えられることを例示している。図１０の４４ｂは、制約条件１から、非受注仕様のＢ１は受注仕様のＣ１に置き換えられ、非受注仕様のＢ２は受注仕様のＣ３に置き換えられることを例示している。図３のステップＳ２２では、制約条件１を探索し、非受注仕様を受注仕様に置き換えられるか否かを判定する。置き換えられる場合には、ステップＳ３６に進み、置き換えが一意に決定されるか否かを判定し、一意に置き換えられる場合には、ステップＳ３８で置き換える。図１０の置換１は、ステップＳ２２でイエスとなったことから生じた置き換え結果を示しており、４４ｂの置き換え関係を利用して置換えている。
図４（Ｂ）は、別の制約条件１を例示しており、「グレードパッケージ」が「Ｄパッケージ」であれば、「アイドルストップシステム」という属性は、「なし」という仕様となり、「あり」という仕様は製造できないことを示し、「グレードパッケージ」が「エコパッケージ」であれば、「アイドルストップシステム」という属性は、「あり」という仕様となり、「なし」という仕様は製造できないことを例示している。すなわち、Ｃ１であればＤ２であり、Ｃ２であればＤ１であるいう制約条件１が存在している。従って、非受注仕様のＤ１は受注仕様のＣ２に置き換えられ、非受注仕様のＤ２は受注仕様のＣ１又はＣ３に置き換えられることを例示している。図１１の置換２は、ステップＳ２２でイエスとなったことから生じた置き換え結果を示しており、４６ｂの置き換え関係を利用して置換えている。
【００２７】
図１４のステップＳ２４では、非受注仕様と受注仕様の間に制約条件２が存在するか否かを判定する。ここでいう制約条件２は、図５（Ａ）に例示したように、販売戦略等から、組合わせて製造しない条件を意味している。販売戦略等によって、「グレードパッケージ」が「Ｄパッケージ」という仕様であれば、「パワーウインドウ」という属性は、標準的に「前席＋後席」という仕様となり、「前席のみ」という仕様がオプションで選択でき、「なし」という仕様の商品は販売しないことがあり、「グレードパッケージ」が「なし」という仕様であれば、「パワーウインドウ」という属性は「ない」という仕様となり、「前席のみ」という仕様や、「前席＋後席」という仕様の商品は販売しないことがある。図５（Ａ）の販売戦略等による制約条件は、販売仕様ＤＢに記憶されている。図５（Ｂ）は、図５（Ａ）から型式情報を省略した情報であり、販売戦略等によって、「一つの属性の仕様」と「他の属性の仕様」の組合せの可否が定められていることが理解される。これを、制約条件２による擬似的制約条件とする。図１１の４８は販売戦略等による制約条件２を例示しており、５０ａはそれによる擬似的制約条件を例示している。擬似的制約条件５０ａによって、Ｃ１（グレードパッケージがＤパッケージ）であればＡ１（パワーウインドウが前席のみ）か又はＡ２（パワーウインドウが前席＋後席）であり、Ｃ３（グレードパッケージがなし）であればＡ３（パワーウインドウはない）であることを例示している。すなわち、非受注仕様のＡ１は受注仕様のＣ１に置き換えられ、非受注仕様のＡ２は受注仕様のＣ１に置き換えられ、非受注仕様のＡ３は受注仕様のＣ３に置き換えられることを例示している。図１１の置換３は、ステップＳ２４でイエスとなったことから生じた置き換え結果を示しており、５０ｂの置き換え関係を利用して置換えている。
【００２８】
図１１の置換３によって、届出仕様α１、α２、β１、β２等のすべてが、受注仕様のみの組合せに置換されたことがわかる。
ここまで置き換えると、ありえない組合せを排除し、組合せの意味する結果を簡単化することが可能となる。例えば届出仕様α２は受注仕様Ｃ３に置き換えられることが判明する。届出仕様α２の置換結果３では、受注仕様がＣ１でありかつＣ３であることがありえず、結局意味あるのは受注仕様がＣ３でありかつＣ３であるというＣ３の場合しかありえないからである。
以上の置換結果が置換４に例示されており、届出分類ＤＢ２８に存在する届出仕様α１は受注仕様Ｃ１に置換え、届出仕様α２は受注仕様Ｃ３に置換え、届出仕様β１は受注仕様Ｃ２に置換え、届出仕様β２は受注仕様Ｃ１又はＣ３に置換えればよいことが判明したことを例示している。
図１４のステップＳ２２，Ｓ２４，Ｓ３６によって、「車両仕様による届出分類ＤＢ」３０に記憶されている「属性の仕様」であって、「受注仕様ＤＢ」２６に記憶されていない「属性の仕様」を、「制約条件ＤＢ」２４に記憶されている制約条件によって、「受注仕様ＤＢ」２６に記憶されている「属性の仕様」に置換える関係が演算されることがわかる。図１４の図１４のステップＳ２２，Ｓ２４，Ｓ３６とそれを実行するコンピュータ装置によって、「車両仕様による届出分類ＤＢ」３０に記憶されている「属性の仕様」であって、「受注仕様ＤＢ」２６に記憶されていない「属性の仕様」を、「制約条件ＤＢ」２４に記憶されている制約条件によって、「受注仕様ＤＢ」２６に記憶されている「属性の仕様」に置換える関係を演算する手段と、その演算手段で演算された関係を利用して、「車両仕様による届出分類ＤＢ」３０に記憶されている「属性の仕様」の組合せを、「受注仕様ＤＢ」２６に記憶されている「属性の仕様」の組合せに置換える手段が構成されていることがわかる。
以上によって、図７に例示した「届出仕様による届出分類ＤＢ」２８の記憶内容６０が、「受注仕様ＤＢ」２６に記憶されている「属性の仕様」に置換えられる。その一例が図１２に例示されている。図１１から、届出仕様α1は受注仕様Ｃ１であり、届出仕様α２は受注仕様Ｃ３であり、届出仕様β1は受注仕様Ｃ２であり、届出仕様β２は受注仕様Ｃ１またはＣ３であることが判明している。すると、届出仕様がα1でありかつβ1である分類はありえないことがわかる。届出仕様がα1でありかつβ1であるとして届けられている型式Ｗ１は、販売戦略等によって、実際には販売されないことがわかる。また、届出仕様がα1でありかつβ２である場合には届出分類Ｗ２に相当する旨の記述は、受注仕様でみると、受注仕様がＣ１であれば届出分類Ｗ２に相当する旨を記述していることがわかる。
以上によって、受注仕様から届出分類を決定するためのＤＢ３４が得られることがわかる。受注仕様が決定すれば、その受注仕様から届出分類を決定することが可能となる。
【００２９】
図１４のステップＳ２６では、さらに置換するために、共通する中間装備で合成可能な制約条件があるかないかを判定し、あればステップＳ２８で制約条件を合成し、さらに置き換えをすすめる。ステップＳ３０とステップＳ３２によって、すべての制約条件１，２を活用して置き換えるまで、処理を繰返す。
【００３０】
「届出仕様による届出分類ＤＢ」２８の記憶内容６０が、不合理なものであることもある。届けるべき届出仕様と届出分類が届けられていないこともありえる。あるいは、受注仕様が不足しており、種類を決定することができないこともある。何らかのヒューマンエラーが存在していれば、ステップＳ３４でエラーが発生する。図１４の処理を進めることによって、受注仕様から届出分類を決定するためのＤＢ３４が得られるだけでなく、ヒューマンエラーが存在しているかいないかを検証することにも利用できる。
【００３１】
図１５は、受注仕様から届出分類を決定するためのＤＢ３４を得る最終段階を示しており、ステップＳ５０では、車両仕様による届出分類ＤＢ３０において、標準引当しか存在しない仕様を削除する。ステップＳ５２では、車両仕様による届出分類ＤＢ３０を受注仕様に置換え、受注仕様から届出分類を決定するためのＤＢ３４に変換する。ステップＳ５４では、受注仕様が複数存在するか否かを判定し、存在する場合には、追番（図７参照）を追加し、同一類番のすべての組合せについて展開する。ステップＳ６０では、不可能な組合せの類番から追番を削除する。以上によって、受注仕様から届出分類を決定するためのＤＢ３４を得ることができる。
【００３２】
以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。また、本明細書または図面に説明した技術要素は、単独であるいは各種の組み合わせによって技術的有用性を発揮するものであり、出願時請求項記載の組み合わせに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。
【図面の簡単な説明】
【００３３】
【図１】分類用仕様で商品を分類しているＤＢ８から、受注仕様で商品を分類するＤＢ１４に変換する装置の全体を模式的に示す図。
【図２】届出仕様で自動車を分類しているＤＢ２８から、受注仕様で自動車を分類するＤＢ３４に変換する装置の全体を模式的に示す図。
【図３】商品仕様ＤＢ２（車両仕様ＤＢ２２）の一例を示す図。
【図４】制約条件１の一例を示す図。
【図５】制約条件２の一例を示す図。
【図６】分類用仕様（届出仕様）と商品仕様（車両仕様）の組合せの関係を例示する図。
【図７】分類用仕様（届出仕様）と商品分類（届出分類）の関係を例示する図。
【図８】分類用仕様（届出仕様）を商品仕様（車両仕様）の組合せに展開した一例を示す図。
【図９】受注仕様と商品仕様（車両仕様）の関係を例示する図。販売仕様も例示している。
【図１０】ＤＢの変換過程のその１を順に示す図。
【図１１】ＤＢの変換過程のその２を順に示す図。
【図１２】分類用仕様（届出仕様）を受注仕様に置換えた商品分類（届出分類）を例示する図。
【図１３】分類用仕様（届出仕様）を商品仕様（車両仕様）に展開する処理手順を示す図。
【図１４】商品仕様（車両仕様）に置換えた商品分類（届出分類）を、受注仕様に置き換える処理手順の１を示す図。
【図１５】商品仕様（車両仕様）に置換えた商品分類（届出分類）を、受注仕様に置き換える処理手順の２を示す図。
【符号の説明】
【００３４】
２：商品仕様ＤＢ
４：制約条件ＤＢ
６：受注仕様ＤＢ
８：分類用仕様による商品分類ＤＢ
１０：商品仕様による商品分類ＤＢ
１２：置換関係演算手段
１４：受注仕様に置換えられた商品分類ＤＢ
２２：車両仕様ＤＢ
２４：制約条件ＤＢ
２６：受注仕様ＤＢ
２８：届出仕様による届出分類ＤＢ
３０：車両仕様による届出分類ＤＢ
３２：置換関係演算手段
３４：受注仕様に置換えられた届出分類ＤＢ
【図１】
2006277423.tif 000003
【図２】
2006277423.tif 000004
【図３】
2006277423.tif 000005
【図４】
2006277423.tif 000006
【図５】
2006277423.tif 000007
【図６】
2006277423.tif 000008
【図７】
2006277423.tif 000009
【図８】
2006277423.tif 000010
【図９】
2006277423.tif 000011
【図１０】
2006277423.tif 000012
【図１１】
2006277423.tif 000013
【図１２】
2006277423.tif 000014
【図１３】
2006277423.tif 000015
【図１４】
2006277423.tif 000016
【図１５】
2006277423.tif 000017