債権/債務について、[[支払基準日>財務会計/支払基準日]]をベースにした[[支払期日>財務会計/支払期日]]を求めるための項目。
* 概要 [#n1500b20]
名称は「支払」条件だが、債務についてだけでなく債権の回収条件も包含し、大きくは基準日・締め日・サイト・[[支払方法>財務会計/支払方法]]（回収方法）の4つの要素で構成される。
基準日は[[転記日付>財務会計/転記日付]]と[[伝票日付>SAPの共通用語/伝票日付]]のいずれかであるか、締め日は単に20日締めであれば20など日にちをDDの形で入力し、サイトはそこからの日数となる。
** 実務における支払条件 [#w6baadb0]
よくあるものを挙げていく。
*** 電信為替送金 [#lf9e986d]
電信送金、電信振込などと呼び、買い手が売り手の指定銀行に電信で振り込む。
Telegraphic Transfer Remittance、T/T Remittanceなどと表記する。
T/T Remittance in Advance paymentといって、[[前受金請求>販売管理/前受金請求]]をしたりもする。
送金手数料・経由銀行手数料・口座振替手数料等が発生するため、売主と買主のどちらが負担になるかは重要な決めとなる。
*** L/C [#f6c3f51b]
買い手の代金決済を銀行が保証する書類で、Letter of Creditと表記する。
詳細は、[[信用状>販売管理/信用状]]参照のこと。
*** D/P [#h7691239]
Documents against Paymentと表記する、手形決済で[[信用状>販売管理/信用状]]がないもの。
決済方法の流れは[[L/C>販売管理/信用状]]と一緒だが、銀行は買い手の代金決済について何ら保証も義務も負わない。
サイトが無く、引き受け時に引き落としがある。
*** D/A [#kf7be22a]
Documents against Acceptanceと表記する、手形決済で[[信用状>販売管理/信用状]]がないもの。
決済方法の流れは[[L/C>販売管理/信用状]]と一緒だが、銀行は買い手の代金決済について何ら保証も義務も負わない。
こちらはサイトがあり、決済が遅れると金利負担がある。
つまり、得意先決済の遅れに対するリスクを自社が持つことになるため信用していないと無理なわけだが、インドや中国などではT/Tは為替が厳しくて使えないケースもあること、またリスクを銀行が持つL/Cよりもハードルが低いために利用されるという側面がある。
** SAPにおける支払条件 [#l96e1a42]
SAPでの、支払条件もろもろについて。
*** マスタとの関連 [#ya4bac51]
[[伝票>SAPの共通用語/伝票]]入力時に提案するため、[[得意先マスタ]]の[[会社ビュー>得意先マスタ/会社コードビュー]]および[[販売ビュー>得意先マスタ/販売エリアビュー]]、[[仕入先マスタ]]の[[会社ビュー>仕入先マスタ/会社コードビュー]]および[[購買ビュー>仕入先マスタ/購買ビュー]]に保持する。
ロジ側では[[販売ビュー>得意先マスタ/販売エリアビュー]]および[[購買ビュー>仕入先マスタ/購買ビュー]]、会計側ではそれぞれの会社ビューが読み込まれる。
*** 粒度について [#wca51184]
なお、私見だが、定義するにあたってはテキストにB/L DateだとかDelivery Dateなどの「基準系」は含めない方が良いと考える。
理由は、SAPにとっては入力者が[[転記日付>財務会計/転記日付]]や[[伝票日付>SAPの共通用語/伝票日付]]といった値の誘導元あるいは[[支払基準日>財務会計/支払基準日]]や[[有効日日付>販売管理/有効日日付]]といった直接指定する項目に''何を入力するか''という違いしか無いにもかかわらず、内容が重複したコードが山積するためである。
そうなってしまうと、[[検索ヘルプ>SAPのオブジェクト/検索ヘルプ]]を使っても入力者が混乱してしまうし、販売側での現金値引ソリューションをはじめとした支払条件のコードそのものが機能に登場する場合、あるいはレポーティングの切り口となる場合に、覿面に煩雑になってしまう。
[[外部帳票>アドオン/フォーム]]への出しっぷりという話であれば、見栄えの問題もあるが、コメントなりフリーテキストに入れるのが吉かと思う。
*** 統制について [#h6db731e]
ある顧客で、「マスタから提案された支払条件以外使うのはダメ。統制上の問題がある」というReqirementがあり、経理のおばちゃんが煩く口にしていた。
はっきりいってそれは''拡大解釈しすぎ''である。
言わんとしていることはわかる。会社同士の契約であれば、基本的にはBaseのtermがあるので、それが変わることはあまりなく、変更するとしたら取引先に便宜を図ったりしているに違いない！とでも言いたいのだろう。
例えば自社の経費支払いであれば、支払い条件に差をつける理由はない。
しかし、営業活動（本業）においては必ずしもそうではなく、担当していた商社ではtradeごとにいくつかの支払条件を使い分けていたのだが、単に''そういった相手先あるいは商いであればokだし、そうでなければNG((というか、あまりなかろう))''という話であり、半分定型のような商いをする相手先か否かという観点が抜けていたのだ。
支払条件のコード自体の粒度にもよるが、履歴も残るし後々トレースすることもできるため、''極端に言えば、別にどうだっていいのだ。''
早期に支払う代わりに安くしてもらったり、入金がずいぶんと先になる代わりに有利な条件での商いができることもある。
もちろん、資金繰りの予測などの観点から言えば統一されているに越したことはないけれど、あまり統制やコントロールという言葉に振り回されないようにしたい。
~
~
CENTER:【スポンサードリンク】
#htmlinsert(amazon_book_sap_system_implement)
~
~
----
#pcomment(reply)
