●こんなサービス
例えば、こんな商品を販売していたとしましょう
ハンバーガー：￥３００
ポテト：￥１００
ドリンク：￥２００
サラダ：￥１５０
そして、セットメニューは
ハンバーガーセットＡ ￥５５０
【ハンバーガー、ポテト、ドリンク】 ￥５０お得
ハンバーガーセットＢ ￥５８０
【ハンバーガー、サラダ、ドリンク】 ￥７０お得
●お腹がすいている
あなたは空腹を感じて、このお店に入りました。
メニューを見ました
どれを選びますか？
恐らく、セットＡかセットＢでしょうね。
でも、もしかしたらセットＡ＋ハンバーガーかもしれません。
この場合は、￥８５０でしょうか？ ￥５０お得のままですね。
●かなり空腹なら
セットＡとセットＢをお願いしようと思いました。
でも、ドリンク２杯は飲めません
どのように注文しますか？
セットＡ＋（セットＢ−ドリンク） ￥１，０００
（セットＡ−ドリンク）＋セットＢ ￥９８０
おーー！ 二つ目の方がいいですねー！
全く同じ商品を提供するのに、注文のされ方で販売価格が異なるって？
もう、いっその事（セットＡ＋セットＢ）−ドリンクを作りましょうか？
いくら？
うーん！ いっぱい買ってくれてるんだからも少し値引こう！
すると ￥９１０かな！
計算は、セット内の単価をこのように設定
ハンバーガー：￥２５０ （−￥２０）
ポテト：￥１００
ドリンク：￥１８０ （−￥３０）
サラダ：￥１３０ （−￥２０）
この単価はセット内で購入された場合とし
計算すると、￥９１０
全部単品で購入すると￥１，０５０だから￥１４０お得
良い感じ！
●この考え方が最良？
最良かって聞かれると、もっといい案がいろいろ出てきそうな気がします
ただ、セットＡとセットＢの両方を販売することはしませんって判断は無いでしょう
でも、新システムではそれが起こるんです(笑)
入力しようとするとエラーではじかれます。
どうする？
この場合、バラします。
一個のセットを残して、他のセットを単品にばらします。
あーーーーーーめんどくさー！
去年まで使っていた当社システムでは（今も一部で使っていますが）
システムが勝手により分けてくれていたから
入力者は、セットＡとセットＢを両方入力出来ていたんです。
●手間暇増える
事がいっぱいの新システム
私がシステム責任者なら
こんなシステム、死んでも作りません
