2011年5月27日金曜日

Performance tuning

1. Online Mode

  • Tr: ST12


2. BackGround Mode

  •    Tr: SM36


--> Input General Data(Such as Job name, Exec. Target(client))

--> Set Step information(First: BTCLOOP, Next: ZXXXX)

  •    Tr: ST12(BackGround Mode --> Execute ----> Debug BTCLOOP)

2010年11月1日月曜日

【機能検証】累计交货数量

Question From IT PUB
http://www.itpub.net/thread-1362356-1-1.html

【要件】
累计交货数量到不同层次取不同销售定价:
据销售业务需要,想要根据客户当月累计提货数量分段定价,和个人收入计所得税类似:实际交货3000吨,按执行顺序1000按照1000元结算、1051吨按1100结算、剩余按1200元结算。

【Method】
1. Master
・ Condition type: Graduated Scales PB02
1000t ---> $1000
1050t ---> $1100
9999t ---> $1200
2. Customazing
・ Copying Control(Billing) :
・ Reference documents
・ Data flow
・ Billing Quantity
・ Copying requirements
・ Pricing

【Test Result】
・ Could not reach the Request when Billing.

2010年10月27日水曜日

[MM業務]数値管理

数字はツールであって、ゴールではない
  From 【週刊 戦略調達 vol.81 2010.10.26】

以下抜粋:
 数値目標、数値管理をどう使いこなすか、数値目標にどう振り回されないようにするかというのは、一サッカーチームだけの問題ではない。ビジネスの世界でも、数値目標、数値管理は何らかの形でほぼすべての企業のあらゆる現場で用いられている。担当レベルから経営トップの様々な意思決定、評価に数字が使われる。その時に誤った数値に基づいて意思決定、評価していては、望むべき結果が得られない。誤った数値が出てくるのは、必ずしも数値目標のプレッシャーに負けての悪意のあるものばかりではない。単に間違い、ミスということもよくある。数値を扱う時には、データを提出する側もそれを使う側も、数字は意図的あるいは誤って正しい数字が出てこないことが多々あるということを、常に頭の片隅に置いておいた方がよい。

 たとえば、我われ調達・購買の世界では、よく価格、コスト削減額といった数値が使われる。サプライヤから非常に魅力的な価格が提示された時、すぐにそれに飛びついてはいけない。なぜ、その価格が出せるのか、それが持続可能かものか、少し考えてみよう。その価格に飛びついて、折角、苦労して技術、製造部門を説き伏せて、そのサプライヤに切り替えた所、その価格は単に今回の注文に限った挨拶価格で、次からの注文ですぐに値上げを要請してくるかもしれない。競合に比べて1割も価格が異なるのであれば、他社にはない技術を用いている、材料・部品を上手く調達している、工程が簡素化されている等の何らかの工夫か、あるいは、それまで調達活動をまったく徹底していなかったといった理由があるはず。

 こうした視点は管理者、経営者にも不可欠だ。調達・購買担当者が5%のコスト削減を達成したと報告してきたら、手放しで喜ぶ前にそのコスト削減がどのようになされたかを確認してみよう。単に物流費を切り出して、物流部門に付け替えただけかもしれない。あるいは、単に新規品の取引で初回見積から5%下げただけかもしれない。これでは、貴社のコスト構造、損益分岐点は何も変わっていない。

 コスト削減には、取引条件、取引先、仕様など何らかの変更が伴う。担当者の言っているコスト削減が本物ならば、数値の裏にあるそうしたストーリーを報告するのは簡単だ。反対に、出てきた数値にそうした裏付けがなかったら、何かがおかしいと疑うべき。

 一つの数値だけ見ていては何も分からないが、その原因、波及効果に思いを寄せれば、その数字が本物かウソかはすぐ分かる。数字一つに一喜一憂するのではなく、その数字がそうであるならば、何がなされ、何が起こっているべきかまで考えよう。そして、そういう施策が打たれているか、起こるべき波及効果が出ているか、違う数字や情報を集めてみよう。そうすることによって初めて元の数値が何を意味するのか、本物の数字かウソのものかが分かってくる。そして、今、何が起こっているのか、これからどうすべきなのか、色々と語りかけてくれる。そうすれば、数字に惑わされることなく、目指すゴールを達成するためのツールとして、上手に数字を活用することができる。

 数字そのものは嘘はつかない。数字が嘘をつくのは、それを使う人間によってのみだ。

2010年10月22日金曜日

【機能検証】外注

【要件】
 1. 

【システム図】

【検討ポイント】
 1. 

【実装方法】
 1. マスタ
  ・外注先が得意先として登録
  ・品目の販売エリア関連データを登録
 2. カスタマイズ
  ・購買伝票タイプが外注カテゴリ使用の可能(NB ← L)
  ・出荷プラントの出荷データ(在庫転送オーダー → プラントの出荷データ)
  ・出荷プラントの出荷タイプ(購買管理 → 外注発注)
  ・購買伝票タイプが外注カテゴリ使用の可能(NB ← L)

2010年10月21日木曜日

【機能検証】会社コード間在庫転送プロセス

【要件】
 1. 同じグループに属する二つの会社
 2. 2Step

【システム図】


【検討ポイント】
 1. 内部請求書の価格

【実装方法】
 1. マスタ
  ・入庫プラント2200が関連販売エリアで得意先マスタ22000を登録
  ・供給プラント(1200)は購買組織(2200)で仕入先マスタを登録(10000)
 2. カスタマイズ
  ・出荷伝票タイプおよび確認規則(購買伝票タイプUB ← 出荷タイプNLCC、確認規則RP、Ship.Sch.)
  ・購買伝票タイプ、ワンステップ転送、不足納入許容範囲 (OneStepにチェックを入れない)

2010年10月19日火曜日

【機能検証】会社コード内在庫転送プロセス

【要件】
 1. 分散倉庫は中央倉庫から部品を在庫転送で調達する。
 2. 中央倉庫の出庫は出荷活動(ピッキング、梱包、納品書印刷など)で処理する。

【システム図】

【検討ポイント】
 1. 1Step Or 2 Step

【実装方法】
 1. マスタ
  ・入庫プラント1400が関連販売エリアで得意先マスタ14000を登録
  ・品目マスタの供給プラント(1200)を登録
  ・品目マスタの調達タイプ(F:外部調達)、特殊調達タイプの設定

 2. カスタマイズ
  ・出荷伝票タイプおよび確認規則(購買伝票タイプUB ← 出荷タイプNL、確認規則RP)
  ・購買伝票タイプ、ワンステップ転送、不足納入許容範囲 
  ・得意先コード14000を入庫プラント1400に割り当て
  ・販売エリア(1000、12、00)の供給プラント(1200)への割り当て

【機能検証】会社間販売プロセス

【要件】
 グループ傘下の別会社の在庫から得意先に直接出荷する。

【システム図】

【検討ポイント】
 1. 供給プラント:マスタレコードより提案される
   ・ 得意先/品目情報レコード
   ・ 得意先マスタレコード
   ・ 品目マスタレコード

【実装方法】
 1. カスタマイズ:
   ・ 出荷プラント(1200)が受注販売組織(2200)、流通チャンネル(10)へ割り当て
   ・ 出荷プラント(1200)が販売エリア(1000、12、00)へ割り当て → 会社間請求
   ・ 定義: 内部得意先コード (販売組織別) 22000
 2. マスタ:
   ・ 品目:販売組織(2200)、流通チャンネル(10) → 出荷プラント(1200)
   ・ 出荷プラント(1200)が販売エリア(1000、12、00)へ割り当て → 会社間請求
   ・ 得意先マスタコード(22000)を販売エリア(1000、12、00)で登録する

【実装結果】
 ・ 価格関連
 ・ 請求関連