支付條款與支付凍結_第1頁
支付條款與支付凍結_第2頁
支付條款與支付凍結_第3頁
支付條款與支付凍結_第4頁
支付條款與支付凍結_第5頁
已閱讀5頁,還剩18頁未讀, 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、 HYPERLINK / 支付條款支付條款是企業進行日常購銷過程中對收付款項的事先約定。曾服務過的某家外資企業,支付條款實際上是作為采購和銷售合同的一部分,比如對國外的采購訂單(采購合同)的打印是一定要打印出數頁面特不詳細的附加采購條款的,這些條款包括支付條款,運輸條款(By Air,By Sea or By car),貿易條款(EXW,CIF,FOB),包裝條款,保險條款甚至賠償條款等,下面詳細介紹下支付條款。第一步:定義國家和公司代碼層次的支付方法。Tcode:FBZP配置路徑:應收應付-業務交易-收款-自動收款目錄下,自動付款配置一個Tcode:FBZP解決。首先付款方式必須在“國家的支

2、付方法”配置中在國家代碼層定義,在該層次有些操縱參數(確實玩的花稍),然后選“公司代碼的支付方法”在公司代碼層次上定義付款方法,如圖1,圖1是個合成圖。圖1-12:首先在國家層次定義付款方法比如S,再在公司代碼層次定義.圖1-3456:支付方法能夠設置該方法是”收款”依舊”付款”,最大最小金額操縱,是否同意外幣,支付通知操縱,細微之處見功夫。第二步:定義支付凍結緣故Tcode:SE16-V_T008圖2中,解釋3個概念.”更改支付建議”:選上了表示在建立支付建議時凍結標志能夠被更改,關于付款建議請參考書其它相關部分,比如F-47手工建立預付定金請求,F110自動付款或自動建立付款請求.“手工收

3、付凍結”:選上此標志后能夠凍結付款,收款一般就不要凍結了,現在,假設應付憑證行項目有了 標志V,那個標志通常是從供應商的支付條款中帶出,如圖3,則F-53不能付款除非審批人用FB02更改憑證去掉該凍結標志V,這類似審批動作,但也只能做到一級審批,要明白審批通常是你放審罷我又登場,要依照金額大小不同分不次級審批的,If so,僅僅一個凍結標志就不大好辦了?!安豢尚薷摹?假如選擇此標志,則需要通過工作流才能修改該凍結標志,審批這種游戲中國企業都喜愛玩,假如設置了該標志,收付立即凍結得啟動工作流審批才行,比如凍結標志P,選擇了該標志,將不能用諸如FB02手工輸入和更改。多好,接著擴展開去,凍結這東西

4、好呀,適合任何需要多級審批的業務,有一天,一個用戶問道,資產報廢ABAON能否審批一下,默認是過帳就產生會計憑證,眼睛黃了,默認功能實現不了,因此凡是財務憑證產生前最好都能加上個凍結標志等待審批。第三步:定義支付條款和分期支付的支付條款Tcode:OBB8(OME2)|OBB9合成圖3是OBB8定義支付條款和FB60供應商一般發票記帳的畫面,支付條款包括定義基準日期(Baseline Date),凍結代碼,付款方式,是否為分期付款和折扣類型,解釋下圖3各項的意思。解釋下合成圖3的意思。圖3-146789:基準日期計算可設置了固定日和附加月份,基準日期可設置為記帳日期,憑證日期,手工的輸入日期,

5、假如選擇了”沒有默認值”則必須手工輸入基準日期。現在假設供應商的支付主數據中設置了該支付條款(注意供應商主數據的采購數據里也有支付條款),假設FB60進行供應商一般發票校驗,記帳日期是2007/05/17,因為基線日期的缺省值為記帳日期2007/05/17,而基準日期計確實是固定月份1/固定日1,即最終的基準日期是2007/05+01(記帳期間05+固定月份1)/01(固定日1)。圖3-6付款條款使用的是固定日期1-15-30,則付款條件顯示的天數/折扣實際就是圖3-9的0/5,2/14,N/29。圖3-2:表示該支付條款可同時用于付款和收款。圖3-3:設置該支付條款的凍結標志為V,即確定應(

6、收)付時,立即凍結必須等待審批后才能(收)付款,付款方式為Z,表示使用匯票付款,假如選上右邊那個“”是什么意思呢?過程是如此的,我們在供應商/客戶主數據維護支付條款,記帳時將默認帶到憑證中,顯然在實際業務中,供應商的不同業務可能對應不同的支付條款,因此可能在記帳時修改支付條款,現在有個問題,假設默認的支付條款ZST1差不多帶出凍結標志為V和付款方式Z,你選擇了一個沒有在該兩者選上右邊那個“”的支付條款,則新的支付條款可不能被帶出而是使用了源支付條款ZST1的凍結標志為V和付款方式Z 。圖3-5:表示該支付條款為分期付款,下面會再介紹那個東西。圖3-10:假如選擇”經常性條目: 從主記錄提供”標

7、志,則象周期性分錄的支付條件(到期日,現金折扣)從客戶或供應商主記錄里獵取,而不是從周期性分錄的原始憑證里提取。支付條款定義了3個期限,如圖4,那個付款條款實際上是5/15,2/30,n/45,那個地點直接使用的是付款天數和折扣率。特不地,假如選擇了圖4-5的分期付款標志,則表示該支付條款可包括數個實際的支付條款,如圖8。注:支付條款中的付款條塊的現金折扣不能超過公司代碼層設置的最高現金折扣百分比(Tcode:OBA4定義)。有個朋友曾問到幾個關于支付條款的設計問題,第一,關于不采納公歷年度月份為會計期間的企業假如希望只在期初期中期末才付款的支付條款如何做?第二,供應商送貨/開票時刻日期和企業

8、驗貨時刻存在一定差異,因此企業送貨日期和客戶驗貨日期之間也有一定差異,這些日期可能還較長,這些差異一定程度會阻礙收(付)款到期日期,如何解決?為了計算出所謂的”合理的”到期日,然后他建議在會計憑證中建立供應商送貨日期,企業收貨日期,企業發貨日期,客戶收貨日期,真是服了。分析下系統的設計邏輯,首先,確定收付款到期日的實際上只有一個日期即基線日期,收付款到期日是基線日期+付款條件的天數決定的,而上面差不多分析了基線日期的自動取得邏輯,基線日期的引入起碼在記帳時通過手工更改能夠解決任何復雜的收(付)款到期日期的計算邏輯,收付款的到期日既不是由什么供應商送貨(客戶的收貨)日期決定,也不是企業的收發貨日

9、期決定而是由基線日期決定,也確實是講應首應付的帳齡由它決定?,F在假設供應商送貨時同時開票給企業,日期是2007/04/05,企業收貨時刻是2007/04/08,質檢時刻是2007/04/10,應付會計記帳時刻是2007/04/15,都沒有關系,通常,我認為基線(準)日期應該為供應商發票開票日期,現在則在OBB8中可定義基線(準)日期以憑證日期為準,應付會計發票校驗時的記帳日是2007/04/15,在憑證日期填寫原始發票時刻2007/04/05,那個日期自動帶到基線(準)日期。在一個國內項目中,發票校驗由后勤人員做,由于種種緣故,供應商5月初送來的發票(發票日期2007/05/01,支付條款為1

10、月到期)在7月初才開始校驗,實際上早過期了,后勤講應該以咱們這邊發票校驗開始算到期日,照他的邏輯,假如他12月才校驗,供應商可能等企業付款等的花兒都謝了,你講這是什么事?沒方法,中國國情就如此,欠鈔票是大爺。事實上基準日期本就應該統一為供應商開票日期,否則ERP設計為這點雞毛蒜皮的日期確定糾纏不休有意義嗎?假如你覺得供應商送貨環節和企業質檢環節還需要一段時比如15天,則兩家企業協商好比如將30天到期的支付條款連續為45天到期不就行,但絕對不能象上面的后勤人員無休無止不進行校驗。講,現在就算以企業收貨或質檢時為基線(準)日期,那就手工填寫更改該基線(準)日期,能夠想象,假如一個企業和供應商/客戶

11、如何算基線(準)日期這種小事都沒協商好,如何能辦好企業?因此支付條款的那幾個設計問題全然就不是問題。圖5是一個應付行項目憑證和會計行項目表格BSEG的合成圖,考慮到不同的供應商(客戶)可能使用不同的支付條款,或同一支付條款也可能被修正,或者用戶可能手工修改基準日期什么的,設計者索性將所有的支付條款寫入了行項目,如此的好處是保證不同憑證的支付條款的完整性,設想一下,設想一下會計憑證行項目只記錄支付條款編號ZST1,某供應商使用該支付條款,第一筆應付是圖4帶出的5/15,2/30,n/45,現在第二筆手工修改了一下行項目希望成為4/10,2/30,n/45,假如行項目只記錄編號,就無法實現,還有,

12、假如在第三筆應付時用戶依照新的業務更改了付款條款為5/15,2/30,n/60 , 假如行項目只記錄編號,則第一筆應付應該是5/15,2/30,n/45就變成了新的付款條款5/15,2/30,n/60,顯然關于這種時刻相關(Time-Dependent)的內容應該記錄其歷史記錄?;貞浺幌拢瑥娬{三點:(1).不管是配置依舊業務操作,不要試圖使用任何其它日期去確定收付到期日,而應該使用統一的基準日期。(2).既然統一使用基線日期去確定到期日,假如在當時記錄憑證中同意靈活修改該日期,將可解決任何復雜的支付到期邏輯。應收應付出的到期日=基準日期 + 支付條件的天數,到期日不同意修改而是自動依照OBB8

13、設置的邏輯計算出的,要修改假如修改基準日期到期日自動跟著修改。(3).在憑證行項目中記錄隨時可能變更時刻相關全部支付條款內容。第四步:塞進主數據.Tcode:XK01|XD01圖6-12:供應商主數據包括一般數據,公司代碼數據和采購組織數據,在公司代碼數據的支付交易和采購組織數據的采購數據中都有支付條款(付款條件),一個是在財務模塊記帳生效,比如一次性供應商的發票校驗將使用該付款條件,另一則和后勤模塊相關,自動帶到采購訂單(MIGO)-再自動帶到后勤發票校驗(MIRO),有人講財務模塊和后勤模塊設置倆付款條件,何苦呢?是如此的,有的專用的財務供應供應商和后勤沒啥關系,哦,對了,那也可在財務中設

14、一個就行,有一個解釋是,設計者淘氣慣了,想和咱們做迷藏玩。圖6-3:當用諸如FB60供應商應付確定時將自動帶出“支付數據”中的付款條款ZST1。圖6-4:自動付款(Tcode:F110)中使用的付款方式和付款凍結標志。我們明白付款條款ZST1也可設置付款方式和付款凍結標志。圖6-5:對供應商PIGGYS開采購訂單時將默認使用該付款條件ZR03。如圖7。同樣客戶主數據的“公司代碼數據”的“支付交易”Tab頁的支付數據和“銷售區域數據”的“開票憑證”的“交貨和付款條款”都可設置付款條款,同樣一個是自動帶到財務模塊,一個和銷售模塊聯系。分期付款的行項目自動拆分生成前面所過,支付條款數據是記錄在行項目

15、中的,在實務中,經常會有如此的支付條款,比如你購買供應商1000萬物資,30天內付50%現金,60天內電匯20%,其余30%則在3個月后使用支票付清,同時3個支付時期供應商還可能給你現金折扣,如此就可使用分期付款支付條款,如圖8。圖8-12:支付條款ZST1包括ZR01-ZR04四個分條款,主意個分條款的百分比合計必須是100%,否則記帳會有錯誤。圖8-3:現在供應商發生1000元應付,則自動拆分成4個行項目,注意每個行項目的付款條件正是ZR01-ZR04 。支付條款的基準日期涉及應收應付的帳齡分析,關于帳齡分析請看相關章節。一個小小的支付條款考慮都如此周全,因此我每想一次就預備罵一次,莫非這

16、些個搞ERP設計的家伙都TMD不是人媽養出來的?和支付條款相關ERP模塊:I.資金打算層次可分現金存款層,應收預測,應付預 測等,支付條款決定了預測收付款日,這對資金預測的正確性特不重要,詳細參 考本書的TR章節。II.特不是應收的催款,正確的到期日通過支付條款計算出來。III.應收應付的帳齡分析,正確的到期日特不關鍵。淺談財務憑證的各種日期會計憑證的抬頭和行項目的幾個日期,看看您能否講出各個日期的作用:BKPF-BLDAT:Document dateBKPF-BUDAT:Posting Date(決定財務期間)BKPF-CPUDT:document Entry dateBKPF-WWERT:

17、Translation dateBKPF-REINDAT:Invoice Receipt DateBKPF-INTDATE:Interest Calc. DateBKPF-PSODT:Last change dateBSEG-AUGDT:Clearing Date(清帳日期)BSEG-AUGCP:Clearing Entry DateBSEG-VALUT:Value Date(起息日)BSEG-BZDAT:Asset value dateBSEG-ZFBDT:Baseline date for due date cal.(基準日期,用于帳齡分析)BSEG-ZOLLD:Customs DateB

18、SEG-VRSDT:Insurance dateBSEG-ANFAE:Bill of exchange payment req due dateBSEG-MADAT:Last dunned on dateBSEG-SPGRT:Blocking reason dateBSEG-LIFNV:Last Adjustment DateBSEG-DABRZ:Settlement reference date需求:供應商開的發票過來,先付95%,剩下5%做質保險金,三個月后再付。MIRO正常業務,假設處理如下:Dr:GR/IR 100元 應交稅費-增值稅進項 17 元 Cr:應付帳款-某供應商 117元依

19、照需求,希望達到如下效果:Dr:GR/IR 100元 應交稅費-增值稅進項 17元 Cr: 應付帳款-某供應商 117*0.95元 條款:立即支付 應付質保金-某供應商 117*0.05元 條款:三個月后支付利用分期付款支付條件可達到以下目的:Dr:GR/IR 100元 應交稅費-增值稅進項 17元 Cr: 應付帳款-某供應商 117*0.95元 條款:立即支付 應付帳款-某供應商 117*0.05元 條款:三個月后支付不能變換科目,除非使用科目修改增強,依照邏輯修改科目應付帳款-某供應商為應付質保金-某供應商。解決方法(Tcode:OBB8/OBB9):(1).OBB8假設建立3個支付條款,

20、0001表示立即支付,0002表示3個月后支付,0009表示包括支付條款0001和0002的”母”條款,0009需要選擇“分期付款”標志。(2).OBB9定義如下,百分比和收付條款0001/0002,如下圖: 如此就達到分期付款的目的,分期付款的參數兩個:一是百分比,二是子條款,子條款中又包括諸如付款方式,現金折扣率,付款帳齡計算的基準日期等詳細信息。假如需要,可使用增強OBBH將科目置換為應付質保金-某供應商。在SD模塊, 分期付款業務也經常發生,比如客戶也會扣除質保金后續到質保期才予以支付;比如某些客戶迫于資金周轉壓力可能無法一次性交清全部貨款,討論一下后一情況在SAP中的實現。(1).銷

21、售交貨:Dr: 發出商品 Cr:產成品(2).銷售實現和結轉成本I.確定收入依照規定,分期付款銷售收入確認時刻應為約定付款的時刻,確定收入分錄:Dr:應收賬款-某客戶Cr:主營業務收入 應交稅費-增值稅-銷項II.結轉分期付款銷售成本分期付款發貨先把全部成本記入到發出商品(類中間科目),每依照合同到期確認一筆收入后,再按比例結轉相應的銷售成本。Dr:主營業務成本Cr:發出商品(3).發票開具由于分期付款開具發票的方式有兩種:a.一次性全額開具增值稅發票。假如是提早一次全額開增值稅發票,則需要按發票金額全額繳納增值稅,這比較符合稅法規定:” 發貨就需確定收入,確定收入就開發票”, 但對企業不利,需要提早繳納增值稅,還有人講:一次性開票的增值稅發票日期會造成ERP系統的銷售收入(一次)和分期銷售收入日期(多次)不符。既然都一次全額開票,實際上在系統中也就不需要再使用什么發出商品核算,就走正常銷售,應收和收入都全部確定在當期,

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論