2014年12月28日日曜日

RfQ Topic / RfQ / RfQ Response (ベンダー回答の記録、決定、購買発注)

前回作成した RfQ を購買発注してみます。

Menu -> Requisition-to-Invoice -> RfQ Response

にて該当する RfQ を表示させてみます。
ここでは登録済みの RfQ Topic 「 RfQ Tpic 2G Mem」にて抽出しました。

以下の画面のように、2ベンダーに対して RfQ が出ているのがわかります。

ベンダーから何かしらの回答があった場合、この情報を更新していきます。

Grid 表示から単票表へトグルボタンを使って画面を切り替えます。

RfQ をベンダーへ送付後、回答をベンダー毎に記録し、選定の透明化を図ることができます。

ベンダー毎に子タブの Response Line は生成済みであり、下矢印ボタンにて詳細の確認画面を開くことが出来ます。


さらに子タブの Response Quantity にて提案価格情報を記録します。
ここではRfQ を出した2ベンダーのうち1つは単価 80円で提案してきたとします。
価格そのものは必須項目ではありません。
ベンダーを選定した基準はなんなのかを後に解るようにしておく必要があります。
ベンダーからの回答の記録が完了したら親タブに戻り、プロセスアイコンから 「Check Complete」を選択し、ベンダーからの回答を確定させます。
(Response Quantity -> Response Line -> RfQ Response )

確認ダイアログが出ますので問題無ければOKを押し確定です。
Check Completeすると、RfQ Response 画面 Complete にチェックが入ります。
同様に競合のベンダー「ウィーストロン」も回答情報を記録して Check Completeします。
ちなみにこちらの提案単価は 77円としています。
価格や納期、その他選定の基準を明確に記録、検討後に発注先を決定します。
決定したベンダーの RfQ Response に Selected Winner のチェックを入れます。
ここでは同一製品に対して提案単価が安かった(77円)の「ウィーストロン」に発注することにしました。


RfQ を出しているベンダーから回答があったかどうかは RfQ Unanswered / RfQ Response にて確認することができます。
下記画面は RfQ Response です。
ホンへー、ウィーストロン両方とも回答済みであることがわかります。
(逆に RfQ Unanswered  にはなにも表示されません)


 ベンダーからの回答がそろい、ウィーストロンに発注することに決めた( Selected Winner にチェック済み)ため、この RfQ は確定し発注します。

RfQ Response のプロセスアイコンからCreate Purchase Order を実行します。
 確認ダイアログがでますのでOKをします。
 特にメッセージが出るわけではないのですが、Purchase Order を確認すると確かに今まで登録してきた一連のRfQ が購買発注(起票)されています。

あとは以前実行した購買の確定をすればOKです。
Purchase Order の Document Action  にて Complete を実行します。

RfQ Response / RfQ Line / RfQ Quantity のそれぞれに 同様の入力項目があるのですが、現時点ではそれぞれの棲み分けがまだ理解出来ていません。
もしかしたら運用ルールで決めるべきことかもしれないのですが、詳細は後日の研究テーマです。

2014年12月19日金曜日

RfQ Topic / RfQ / RfQ Response (購買・相見積もり依頼の送信まで)

以前 相見積もりの RfQ (Request for Quotation) を試して見たことがあります。
そのときはその概要が理解できずにリタイヤ。

改めて動作の確認をしてみました。
実は個別のパラメータについては理解できていない事も多いのですが、まずは確認した大まかな動きだけ記録しようと思います。



Menu から Requisition-to-Invoice 以下を見ると RfQ に関係しそうなメニューは下の5つがあります。

RfQ Topic
RfQ
RfQ Response

RfQ Unanswered
RfQ Response

下2個(RfQ Unanswered/ RfQ Response) は確認レポートなのでとりあえず置いておいて。。
上3個 (RfQ Topic / RfQ / RfQ Response)の関係を考えてみます。



以前試したときにうまくいかなかったのは、RfQ Topic / RfQ の登録まではなんとなく進むものの、 Menu から RfQ Response を新規登録できなかったためです。

正しくは RfQ Response は Menu から新規登録するものではなく、 RfQ のプロセスで生成するものでした。

上の図のように

1:どのベンダーに見積もりを依頼するかを RfQ Topicにて登録します。
 ここでの例は、 2Gのメモリの見積もりを2つのベンダー(ホンへーとウィーストロン)に出すことにしています。

2:その RfQ Topicに対して、何の製品をどの程度の数量見積もりを出すのかを RfQ に登録します。
 ここでの例は 2G Memory を 500個購入する場合の相見積もりを想定しています。


3:登録した RfQ のプロセスにて、 Create & Invite を実行すると、1で登録したベンダー毎に2で登録した場合のベンダーからの回答を記録する RfQ Response が生成されます。
 この例では1で登録した2つのベンダー(ホンへーとウィーストロン)に対し、回答を記録し、結果をランク付けし、Selected Win を決定します。

まずはここまでやってみます。

Menu -> Requisition-to-Invoice -> RfQ Topic
必須は Name のみ、「RfQ Tpic 2G Mem」と入力し保存します。

保存後 Subscriber が新規追加可能となります。
必須は  
Business Partner
Partner Location

ちょっと不思議だったのはデフォルトでUser/Contact に実行者の上田さんの名前が入っていることです。
Business Partner 選択後 は Business Partner の User/Contact に登録した人しか選択できないことからもベンダー側の連絡先の人が入ると思うのですが、、

これもちっちゃな疑問ですが、 Business Partner を検索するとき、 Customer に Yes がデフォルトで入っているのが気になったりします。。。
ま、No に変更すればいいのですが、、

 Business Partner 選択後、 User/Contact は ベンダーの連絡先の担当者を選択します。
RfQ Topic として、見積もり依頼を出す2つのベンダーの登録を行いました。


ここまでで RfQ Topic (どのベンダーに見積もり依頼を出すか)の登録を終え、次に RfQ (見積もりが欲しい製品と数量)を登録します。
必須項目は
Name
Sales Representative
RfQ Topic
Response Date



Nameはここでは「Tpic 2G M 20141219」としました。

Sales Representative は社員だれでも選べるわけではなく、 Business Partner に Sales Representative にチェックが付けられている人だけです。
私の理解が足りないため、なぜ営業担当者の名前が必要なのかが今ひとつ理解出来ていません。たしかにこの RfQ のプロセス(右上の歯車アイコン)からCreate Sales Order を実行することができるので、この場合はわかるのですが、、、
例えばパーツの相見積もりとか、初期在庫積み上げの時とか営業担当者は特定できないと思うのですが、、
ま、とりあえず西島さんの名前でも入れておきます。
RfQ Topic は先ほど登録した「RfQ Tpic 2G Mem」を選択し、見積もり依頼先のベンダーと紐づけます。

Response Date は初期に必須ということは、回答期日かな?とか思うのですが、純粋に読めば回答日付。疑問を持ちつつ今回はスルー

保存すると Document No が採番され、Line の新規追加が出来るようになります。
必須を表す赤文字の項目はないのですが、、、

どう考えても Product は必須でしょ。

とりあえず Product は 「M002_2G Class6」入れて、、
保存すると Quantity が新規追加可能となります。


ここでは Quantity (数量)は 500
Purchase Quantity にもチェックを入れます。

保存しつつ RfQ まで戻ります。(2回↑矢印)
プロセス(歯車)アイコンを押して、表示されるメニューから Create & Invite を実行します。

実行すると確認ダイアログが表示されます、
invitation をベンダーに送付するかのチェックをした上で実行します。
(これをチェックするとベンダーの担当者にメールが行くのでは?未確認です。)

処理はあっさりおわり、
Menu -> Requisition-to-Invoice -> RfQ Response
で一覧を見ると、今作成したベンダーからの回答記入&選考用のデータが生成されているのが解ります。
(その他のレコードはテスト用のものなので、無視してください。)

この時点で未回答の見積もり依頼を見てみると、
Menu -> Requisition-to-Invoice -> RfQ Unanswered
を見ると当然2レコードとも抽出されます。
(逆に Menu -> Requisition-to-Invoice -> RfQ Response で見積もり完了を抽出しても何も表示されません)

とりあえず長くなってきたので、今回はこのへんで。。
続きはベンダーからの回答を受けて RfQ Response を更新しつつ購買発注の生成まで行きたいと思います。


2014年12月16日火曜日

iDempiere 想定業務フロー 1-10 入金 1-11 出納

だいぶ長くなってきて、間延びしてきました。
今は備忘録の部録なのでとりあえずなんでもかんでも書いていますんでご容赦ください。
今回は購買のところと似ているので駆け足で。

(いづれHPなどにまとめていきたいと思っています。)

前回までで Invoice を Create しました。
次にPayment (AR Receipt) (入金)と Bank/Cash statement (出納)で、一連の販売系処理を完了します。

Menu -> Open Items -> Payment

赤字項目(必須項目)は
Document Type
Business Partner

Business Partner は Invoice を作成した Amadon を選びます。

で、入力後に油断して保存をすると、ワーニング。
例によって 
Error: Mandatory: Bank Account

やっぱりこの項目も赤字にすべきだよなー、と思いつつ登録。
登録方法は購買の時と同じなので省略、今回は Sales Order 用として作成。

Bank Account登録後、 先ほどの Payment で Bank Account を指定します。
ここでは登録した みずほ_minolta sales account_012345678 を選択します。 
 Document Action で Complete すれば、Allocation : 1000040 とか表示されて消し込み無事完了
 次は 1-11 出納です。

Menu -> Open Items -> Bank/Cash Statement を開きます。
Bank Account を選択し、Create Lines from で処理済みのPayment を選択します。

選択後に Document Action を Complete すれば完了。

あまり役にたちませんでしたが、マスターの依存関係はこんな感じ。


最後は駆け足でしたが、購買・販売の基本フローは完了です。

次はバリエーションに行くか、インフラに行くか、開発に行くか、、、、
ちょっと更新お休みして考えようかな。

余談ですが、独学で(ググりながら)iDempiereを学ぶのはやはり相当時間を要しますね。
私は現時点、あえていろいろ壁に当たりながら理解を深めていく方を選んでいますが、、通常はトレーニングなどで時間を買う方が「効率」が良いことは疑いありません。

行き詰まりながらもあちらこちら参考にさせていただいている中で、 OSS ERP Solutions様のHP内容すばらしく、大抵最後はここにたどり着きます。
このブログご覧になる方は当然ご存じだと思いますが、あらためてリンクさせていただきます。
http://www.compiere-distribution-lab.net/idempiere-lab/トレーニング/


iDempiere 想定業務フロー 1-8 出荷 1-9 請求

出荷は3つの方法があるようです。
Quote-to-Invoice -> Shipments -> Generate Shipments (Manual)
                                                   -> Generate Shipments
                                                   -> Shipment (Customer)

Generate Shipments (Manual) は対応する受注伝票をマニュアルで選択し、出荷処理します。
Generate Shipments はバッチプロセスです。
Shipment (Customer) は現在不明。。後日課題です。

今回は
Generate Shipments (Manual) にて、対象となる SO (Sales Order/受注伝票)を選択します。

いろいろ確認する中で、今更気がついたことがあります。
Product Name や Business Partner Name, Contact などに2バイト系(漢字)があるとレポートに表示されないようです。(もちろん設定などで解決するのでしょうが、今は通すことを優先して、漢字が含まれていない 製品や顧客を使います。)

(全部書き直す気力も無いので、、、わかりにくくてすいません)

で、
突然ここで顧客、製品が変わります。

親タブ(受注ヘッダ)
Customer : Amadon
Customer / Location : 1-1-1 Yotsuya Shinjuku ku Tokyo 162-0001 Japan
Customer / Contact : Daisuke Ito

子タブ(受注明細)
Product : Portable two
Quantity : 5
Unit Price : 6,750 -> 6,700
Warehouse : misato W/H


明細まで入力したら親タブに戻り Document Action を Complete します。
納品書を表示してみるとこんな感じにでました。
フォーマットをなにもいじっていないので、ちょっと乱れていますが後日修正方法は研究します。
ちなみに現在の状態(デフォルト)では漢字は表示されず。このあたりも調査を要します。


Complete 後に子タブを改めてみると

Reserved Quantity 5
Delivered Quantity 0
Invoiced Quantity 0

となっており、この受注が在庫を引き当てていること、まだ出荷されていない(請求もされていない)ことがわかります。


続いて1-8 出荷を指示します。

Menu -> Quote-to-Invoice -> Shipments -> Generate Shipments (Manual)

適当なフィルターをかけると該当の SO伝票が選択できます。

選択してOKボタンを押すと、紙で出力される伝票イメージを見ることができます。
例によって何も手をつけていないため表示が崩れています。。(ここはスルー)





出荷の指示が終わると、数量の状態が変わります。
Reserved Quantity 0
Delivered Quantity 5
Invoiced Quantity 0
次は1-9請求です。
ほぼ出荷と同様、

Menu -> Quote-to-Invoice -> Sales Invoices -> Generate Invoices (Manual)

出荷と同様SOを選択すると紙の請求書の出力イメージを見ることができます。

完了すると数量の状態が変わります。
Reserved Quantity 0
Delivered Quantity 5
Invoiced Quantity 5

ここまでで受注から出荷、請求まで来ました。
次は入金、出納に挑戦です。

一通り流れが見えたら次はバリエーションをどう考えるか、、、

iDempiere 想定業務フロー 1.7 販売 (折り返し)

前回 Quote-to-Invoice (販売プロセス)にて 1.7 受注を開始しました。
Sales Order (受注)をするのに必要なマスターをたどっていくと、現時点下の様な依存関係が出てきました。

1:Sales Order を作成するために Business Partner を設定する必要がある。
2:Business Partner を設定するために Business Partner Group を設定する必要がある。
3:Business Partner Group を設定するために Price List を設定する必要がある。
4:Price List / Version を設定するために Price List Schema を設定する必要がある。


前回の最後でPrice List Schema の設定が終わったので、Price List /Version の設定からです。

Price List /Version 画面のPrice List Schema の
項目で、前回登録した  PO-InitialSchema を選択し、 Create Schema Lineボタンを押します。


確認ダイアログが出て、OKをすると、、

製品の新価格が設定されます。

製品「音メモ君2号」の販売価格はこのようになりました。

参考までに:こちらが購買時に作成した「音メモ君2号」の価格


現時点 販売、購買ともBase Price List を設定していないため、 Product / Purchasing のList Price と PO Price を参照しています。 Standard Price の Price Down % の指定のみ変えているため Standard Price に9,900円と8,800円の差が発生しています。
(値付けの運用については後日掘り下げたいと思います)

Version の名前は日時だけではなく、意味のある名前にした方がよいでしょう。
ここでは SO-Initial としておきます。

↑を押して Price List に戻り、Name に SO-PriceList と入力し、 Sales Price List にチェックを入れ保存します。

現在地の再確認。
1:Sales Order を作成するために Business Partner を設定する必要がある。
2:Business Partner を設定するために Business Partner Group を設定する必要がある。
3:Business Partner Group を設定するために Price List を設定する必要がある。
4:Price List / Version を設定するために Price List Schema を設定する必要がある。

4’:Price List Schema を登録 (SO-InitialSchema)
3’:Price List Version を登録 (SO-Initial) , Price List を登録 (SO-PriceList) 

まで来ました。ようやく Business Partner Group の設定です。

Partner Relations -> Business Partner Rules -> Business Partner Group
Nameは Tier3 Customer とかにしておきますか。
Tier3 とは失礼ですが、顧客によりシビアに優先度を定めた方が日々の運用で混乱を抑えられると思います。現在のように需要と供給の関係において需要が低い場合はその重要性は薄いのですが、需要が拡大した場合に声の大きさだったりその場の思いつきで出荷先がアロケートされないようあらかじめ優先付けルールを定めておく、あるいは準備をしておくことは大切です。( iDempiere の話から脱線しました、、)

Price List は先ほど登録した SO-PriceList を選択します。



現在地
1:Sales Order を作成するために Business Partner を設定する必要がある。
2:Business Partner を設定するために Business Partner Group を設定する必要がある。
3:Business Partner Group を設定するために Price List を設定する必要がある。
4:Price List / Version を設定するために Price List Schema を設定する必要がある。

4’:Price List Schema を登録 (SO-InitialSchema)
3’:Price List Version を登録 (SO-Initial) , Price List を登録 (SO-PriceList) 
2’:Business Partner Group を登録  (Tier3 Customer)

まで来ました。次は Business Partner の設定です。
Partner Relations -> Business Partner Rules -> Business Partner

Business Partner Group に上で設定した Tier3 Customer
Name に 高田電気
Customer チェックボックスにチェックして、、

他にも必要そうな設定もチラホラありますが、今はまだ我慢します。(いろいろ一緒にいじるとわかりにくくなる)


現在地
1:Sales Order を作成するために Business Partner を設定する必要がある。
2:Business Partner を設定するために Business Partner Group を設定する必要がある。
3:Business Partner Group を設定するために Price List を設定する必要がある。
4:Price List / Version を設定するために Price List Schema を設定する必要がある。

4’:Price List Schema を登録 (SO-InitialSchema)
3’:Price List Version を登録 (SO-Initial) , Price List を登録 (SO-PriceList) 
2’:Business Partner Group を登録  (Tier3 Customer)
1’:Business Partner を登録 (高田電気)

さて、いよいよ Sales Order は登録できるのでしょうか?
販売担当の西島さんでログオンしなおして、

Menu -> Quote-to-Invoice -> Sales Orders -> Sales Order
Business Partner に上で登録した 高田電気を選択すると。。。。


Partner Location が赤くなってしまいました。
選択しようにも空白のみ表示されてしまいます。Business Partner に登録していないので当然ですね。

というわけで、ちょっと後戻り、、

Business Partner の子タブ Location に Name と Address を設定します。
ここではそれぞれ 高田馬場本店、東京都 高田馬場 を設定しました。
--------追記
標準では漢字を使うと、注文書に表示されないようです。(設定の問題)
とりあえずアルファベットを使っておいた方が無難でしょう。
--------------
保存し、 Sales Order に戻ると、Location に今登録した 高田馬場本店が選択できるようになっています。

あとで混乱しないように、一応Target Document Type を POS Order から Standard Order に変えておきます。(あまり意味が無いかもしれませんが、極力単純化しておきたくて、、)



Business Partner / Location を入力すると、 SO のヘッダーの保存が可能になります。
(Warehouseは登録済みの前提)

次に、子タブの Order Line (明細)にてどの製品を何個かを指定します。
Product は必須だと思うのですが、なぜか赤文字ではありません。
Quantity(数)は 1 がデフォルトで入っているのですが、これはいいのか悪いのか?
必要ならカスタマイズって感じでしょうか?

ここでは
Product : 音メモ君2号
Quantity:5

ついでに Unit Price (Product を決定すると自動的に埋め込まれる)は Standard Price 9,900円のところ 9,850円としておきました。(数値がどこに反映されるか確認するため)

ようやく Sales Order を Complete することができました。

登録した SO は Open Orders にて確認することができます。
Menu -> Quote-to-Invoice -> Sales Orders -> Open Orders  


ちなみに数量指定時に手持ち在庫が足りないときにはワーニングのメッセージがでます。
(これは購買で 50個入庫済みの状態で、上記5個は引き当て済み、追加で100個のSOを作成してみたところです。在庫は 45個と正しく表示されています。)


プロセスが依存するマスターを載せておきます。(購買であまり意味を感じなかったけど、一応)



お疲れ様でした。