得意先マスタ のバックアップ(No.3)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- 得意先マスタ へ行く。
- 1 (2014-06-26 (木) 11:04:17)
- 2 (2015-08-07 (金) 16:34:56)
- 3 (2016-02-17 (水) 12:02:49)
- 4 (2016-03-29 (火) 10:45:03)
主要マスタのひとつである、得意先マスタについて。
概要 †
得意先マスタとは、ざっくり債権の計上先あるいは販売活動の登場人物と言える。
前者は顧客ないし顧客の支払を代わりに行う先および口利き料の請求先など、後者は価格決定プロセスの登場人物であるディーラー、販売分析の登場人物である営業員や末端消費者が該当する。
ちなみに、技術名称がKUNNRであることは、Customerがドイツ語でKundeであることに由来し、末尾のNRはNumberと思われる。 余談だが、技術名称はドイツ語と英語がルー語のように入り乱れていて面白い。
大括りな住み分け †
- 得意先勘定グループって何? 概要で挙げた登場人物たちを区分けする要素である。詳細はリンク先参照。
コード体系 †
基本的な考え方については番号範囲に譲るとして、大きくは登場人物の住み分けと似ている。
これにもう少し加えるならば、
- 情報検索の効率
- 範囲指定による機能の制御
- 可視性の向上によるミスの低減 といったところ。
上記を鑑みると、登場人物はどういった性質で分けられているか、その性質に合致するのは完全無意か否か、有意箇所があるならどの部分か、といったところから始めるのがベターか。 もちろん、〜のように検索でき、レポーティングできれば非常によろしいというニーズありきでデザインするのも一案であるし、むしろ論拠が明確であるため、犠牲にする要素があったとしても無下に攻撃を受けることもないかと思う。
詳細 †
他の主要マスタと同じく、階層構造となっており、下記に大別した。 但し、テーブルについては、あまりにも多いため得意先マスタ/関連テーブル参照。
- 得意先マスタ/一般ビュー 名称や住所など取引先として唯一無二の情報を保持し、Table:KNA1に格納される。 集中アドレス管理の概念が登場する前の名残として名称や住所の項目が存在するが、正となるのはアドレス番号で紐付けたADRC等のテーブルであることはお忘れなく。
- 得意先マスタ/消費税ビュー 欧州圏の得意先が国コードごとに持つ消費税登録番号を保持し、Table:KNASに格納される。
- 得意先マスタ/銀行ビュー 得意先の取引する銀行情報を保持し、Table:KNBKに格納される。 得意先からは基本的に入金を受けるのみであるため銀行口座などの情報は使用せず、用途は振り込み元の銀行の照合と返金に限られるため、マスタ管理している事例はあまりないように思う。
- 得意先マスタ/会社コードビュー 統制勘定や本店勘定など取り扱う会社コード依存に住み分ける項目を保持し、Table:KNB1に格納される。
- 得意先マスタ/販売エリアビュー 取引のデフォルト通貨コードやインコタームズなど取引する販売エリアごとに住み分ける項目を保持し、Table:KNVVに格納される。
- 得意先マスタ/取引先機能 受注先や請求先などの取引先機能について販売エリアごとに保持し、Table:KNVPに保存される。
まとめページ †
関連ページ †
- 得意先マスタ/ワンタイム得意先
- 得意先マスタ/一般ビュー
- 得意先マスタ/会社コードビュー
- 得意先マスタ/出荷先
- 得意先マスタ/勘定グループ
- 得意先マスタ/取引先機能
- 得意先マスタ/受注先
- 得意先マスタ/得意先グループ
- 得意先マスタ/得意先価格決定区分
- 得意先マスタ/得意先値引グループ
- 得意先マスタ/得意先勘定設定グループ
- 得意先マスタ/支払人
- 得意先マスタ/消費税ビュー
- 得意先マスタ/請求先
- 得意先マスタ/請求書一覧日程
- 得意先マスタ/販売エリアビュー
- 得意先マスタ/銀行ビュー
- 得意先マスタ/関連テーブル
- 得意先マスタ/項目ステータス
【スポンサードリンク】
amazon_book_sap_system_implement is not found or not readable.
コメントはありません。 Comments/得意先マスタ