SAP財務學習筆記_第1頁
SAP財務學習筆記_第2頁
SAP財務學習筆記_第3頁
SAP財務學習筆記_第4頁
SAP財務學習筆記_第5頁
已閱讀5頁,還剩68頁未讀 繼續免費閱讀

下載本文檔

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

文檔簡介

1.CO分割后臺配置〔1〕OKES:保護劃分結構〔IMG→控制→本錢中心會計→實際過賬→期末結算→作業分配→劃分→定義分割結構〕OKES進去之后要先保護分解結構,點擊新條目,然后把需要保護的內容進行保護,點擊保存即可。選擇一個分解機構然后點擊為設置選擇,結構名稱、分配、控制范圍都是可選的,可以根據實際情況進行選擇。進入界面后,然后點擊新條目,點擊后即可對需要進行分割的作業類型和本錢要素進行保護,也可以是本錢要素組和作業類型組。〔2〕將分解結構分配給本錢中心:OKEW(IMG→控制→本錢中心會計→實際過賬→期末結算→作業分配→劃分→將分割結構分配給本錢中心)選擇在控制范圍內的一個根本生產類本錢中心點擊修改,選擇將要分配的本錢中心,選擇完之后選擇把需要分配的本錢中心分到那個分割結構就選擇那個分割結構

選中之后點擊分配按鈕即可完成分配工作。2.CO本錢要素會計1.本錢要素會計概念1.1初級本錢要素每一個初級本錢要素都對應一個總帳損益類帳戶,輸入源自于公司外部的直接本錢,所有損益類帳戶的財務數據都要通過初級本錢要素輸入到本錢中心。1.2次級本錢要素是會計科目表中所沒有的,只會在治理會計中使用,一般用于費用分攤和作業的結轉。每一個次級本錢要素都只在CO內部起作用而不影響FI過帳,主要用于本錢分配,結轉中使用。更像是一個中轉科目,比方說費用-中轉。如下例所示:①DR:本錢CR:費用-中轉

②DR:費用-中轉CR:資金

1.3分配與分攤分配與分攤對于本錢要素的來說是一個很重要的功能。并且這功能就類似于固定資產折舊一樣,一月只能執行一次。分配的功能是與初級本錢要素相關的,分攤的功能是與次級本錢要素的功能相關的。這兩個功能同樣都可用到方案〔預算〕與實際發生額中。如可創立一個循環,將某本錢中心〔可超過一個以上〕的初級本錢要素〔可超過一個以上〕,按一定的比例分配給其他本錢中心〔可超過一個以上〕,當然也將這循環分為幾個段,各段間相應的要求可以不一樣,這樣每月末執行時,就可以很好地反映初級本錢要素的流向情況。同樣的,也可創立一個分攤循環,將某本錢中心〔可超過一個以上〕的初級本錢要素〔可超過一個以上〕重新組合成為一個次級本錢要素,然后再將其按一定的比例分配給其他本錢中心〔可超過一個以上〕,當然也將這循環分為幾個段,各段間相應的要求可以不一樣,這樣每月末執行時,就可以很好地反映次級本錢要素的流向情況。分配與分攤的區別在于,分配是將某一本錢中心的初級本錢要素分給另一本錢中心,被分配的初級本錢要素會與被分配的本錢中心的相同的初級本錢要素一并反映,而分攤那么是將次級本錢要素分攤到另一本錢中心,與被分攤的本錢中心的初級本錢要素一同反映,這樣有利于區分本本錢中心的發生的費用與分攤過來的費用的界限。需要說明的是,同一利潤中心下的本錢中心的分配或分攤,并不影響該利潤中心的利潤額,但跨利潤中心進行分配或分攤,那么影響了不同利潤中心的利潤額,兩種方法產生〔分配或分攤的規那么相同時〕的影響一致。

簡單點講A打包發B是分攤,A不打包到B是分配,舉例,如果IT中心的所有費用打包出來就是分攤,如果只是網絡費用就是分配。1.4本錢控制范圍用于在企業范圍內本錢核算信息的統一規劃和控制。在SAP系統提供的本錢控制范圍內,可以方便地對其責任中心的本錢核算信息使用相同的方法進行統一方案、記錄和任意分組統計。

1.5功能范圍是針對各個本錢對象中的相應費用科目進行屬性歸類。

2.后臺配置CEA〔本錢要素會計〕的后臺配置比較簡單,本錢要素可以手工創立也可以自動創立。如圖

圖1【1】automaticcreationCostelements:可以通過系統自動建立本錢要素,通過建立一個BATCH〔批輸入會話〕的方式可以批量的建立本錢要素。當然也可以手工建立。這個我們實際可以在T-code:SM35看到建立好的BATCH〔批輸入會話〕。

圖1【2】建立本錢要素:和前臺的實際上是一樣的T-CODE:KA01。

圖1【3】定義本錢要素組:本錢要素組實際上是本錢要素的集合,我們在做配置的時候可以充分利用本錢要素組。例如,在結算配置里面可以應用本錢要素組,如果有增減本錢要素,只需要改本錢要素組即可,而不用更改結算參數配置。切記,后臺配置盡量使用本錢要素組。

圖1【4】本錢要素類別:如表所示1初級本錢/本錢降低產生的利潤對應所有費用本錢類科目11收入11對應銷售收入類科目12那么對應銷售退回類科目12銷售扣除22外部結算21/22用來做結算用,比方在內部訂單或PS結算以及生產訂單結算時候需要用到21內部結算31訂單/工程結果分析31為在制品結算必需使用41為本錢核算單使用41間接費用率42分攤42分攤使用43作業類型使用43內部作業分配90資產負債表科目對應的本錢要素資產負債表科目只能是統計性本錢要素,當然通過后臺也可以建立屬性為“1〞的本錢要素。摸索:資產類科目為什么不能建立本錢要素?

T-code:OBMSG/OBA5

通過修改消息可以把資產負債類科目建立為本錢要素,消息號碼為KI098.3.本錢要素應用3.1初級本錢要素

〔1〕對從CO之外過來的費用進行分類

〔2〕前提:首先必須是FI中的損益費用,如圖2.初級本錢要素除了對應損益科目外也沒見過再怎么搞的了,注意,損益包括〔收入、本錢、費用等〕,有的科目要不要到底建立本錢要素,那就要看企業的需要了。

〔3〕利用功能范圍的本錢要素:功能范圍是針對各個本錢對象中的相應費用科目進行屬性歸類。當費用很多的時候我們完全可以利用本錢要素+功能范圍的方式,這個以后我們也會詳細解釋。

3.2次級本錢要素SAP的科目由此分為資產負債類科目,損益類科目,需要本錢要素的一定是損益類科目,但是損益類科目不一定需要本錢要素,為了區分不同本錢對象〔如訂單、本錢中心、銷售訂單、物料等〕的本錢就需要本錢要素,這樣過帳的時候會指向對應的本錢對象,一般可以OKB9預設本錢對象.如果不設本錢要素,對應損益科目接收的費用直接過帳到利潤中心,所謂損就是本錢費用,益就是收入,當然如果按單生產需要收入區分不同訂單的收入,那么收入科目同樣需要本錢要素。這些所說的跟科目直接關聯的都是初級本錢要素〔通過科目號碼創立本錢要素〕。次級本錢要素也就是為了方便歸集相應的初級本錢要素,通過分割跟初級本錢要素相連只在CO層面過帳的本錢要素,所以次級本錢要素的借貸只能是本錢對象之間進行,而初級本錢要素不一樣,可以通過資產類科目過帳到損益類科目時產生并指派到本錢對象,也可以從本錢對象轉到另外的本錢對象〔KB11N要求初級本錢要素〕。這些都是本錢流的表達,如訂單確認通過作業類型和次級本錢要素的關聯從本錢中心過帳到訂單〔訂單任務清單工序工作中心對應本錢中心〕,同時次級本錢要素是方便記帳,例如機器、廠房等的折舊費你不可能每張訂單進行相應的折舊,而是每個月折舊到本錢中心,再按占用工作中心工時比率分攤這些費用,由于每個月的訂單數量都是很難固定的,當然折舊費只是實際過帳到本錢中心的一局部費用,所以實際發生的費用也是不會固定的,所以通過預先KP26的作業單價從本錢中心過帳到訂單跟本錢中心實際接收的費用要相等比登天還難,所以需要用到作業價格重估MFN1/CON2,而我們不可能按每種初級本錢要素建立對應的作業類型〔當然SAP已經想到了防止有人可能真的那么做,所以已經寫代碼不允許作業類型和初級本錢要素直接關聯一起〕,否那么報工不知道要費多少頭牛,所以這樣就需要用到次級本錢要素,這樣從本錢中心過帳到訂單的是次級本錢要素,而本錢中心實際接收的費用是初級本錢要素,要將這些費用本錢做為訂單本錢,實際上本錢中心只是本錢轉移的作用,食進去的是初級本錢要素,拉出來的是次級本錢要素,而食什么樣的初級本錢要素拉出對應的哪些次級本錢要素,接收的本錢要素將少量幾個次級本錢要素替代N多的初級本錢要素,這就需要用到作業分割OKES將初級本錢要素對應到作業類型,而作業類型主文件上就對應由次級本錢要素〔當然需要將分割結構指派到本錢中心OKEW),這就將次級本錢要素和初級本錢要素范圍〔本錢要素組〕對應起來。訂單確認的時候工時是實際作業數量,當時的取價是KP26保護的方案價格,其實這就是預先支付一樣,最后多還少補〔實際作業價格重估算〕這就取KBK6的單價,KSS2執行分割得到作業類型對應初級本錢要素范圍在本錢中心當期發生的實際累計金額,KSII根據分割金額處以該本錢中心對應作業類型的當期實際發生的小時數得到單價并更新KBK6里的單價。這樣本錢中心實際發生的初級本錢要素費用跟過帳到訂單的次級本錢要素費用對應起關系,實際作業價格重新估算的時候差異〔分正差異和負差異,負的方向相反〕將過帳到訂單。3.CO本錢中心會計1.本錢會計概念1.1本錢中心本錢中心是企業內的最小職責單位,是每一筆費用的具體接收者。創立本錢中心主數據時必須將每個本錢中心分配給標準層次結構的某個節點,標準層次結構反映了本錢中心與本錢中心、本錢中心與本錢中心組、本錢中心組與本錢中心組之間的關系。標準層次結構中的每個節點代表一個本錢中心組,當然除了標準層次結構中的本錢中心組之外,還可根據業務需求在標準層次之外自己定義需要的本錢中心組。舉個例子:由于本錢中心的考核重點在于它不會形成可以用貨幣計量的收入,所以一般情況下我們根本上都是把每個職能部門作為本錢中心。比方財務、行政、人事、平安等部門都可以作為本錢中心治理。當然,生產車間是不是本錢中心?我們可以肯定的答復,如果按本錢核算的劃分,我們有可以分為生產性本錢中心和非生產性本錢中心,也就是我們在定義本錢中心類別的時候所要用到的〔本錢中心類別參照本錢中心配置章節〕。注意,生產性本錢中心期末余額為零,因為期末應該全部結轉到產品本錢。摸索:如果生產性本錢中心期末有余額該如何處理?生產性本錢中心期末可能會出現本錢中心吸取過量或吸取缺乏,建議一次性轉入銷售本錢。1.2作業類型作業類型代表由本錢中心生產輸出的一些形式。作業類型的通用例子包括勞動小時數或機器時間的分鐘數。作業類型用于根據所進行的作業單位數從發送方本錢中心向另一CO對象〔如本錢中心、內部訂單、生產訂單等等〕分配本錢。單元價格用于評估作業數量。作業類型分配的優點是將數量和價值流組和在一起。所要求的作業數量在工藝流程中指定,這給產品本錢方案中和本錢對象上提供了詳細的本錢控制信息。

作業類型代表了部門之間提供的一類效勞或作業。如IT效勞,修路作業都可以定義為作業類型,其主數據如下:

圖1-1作業類型1.3作業價格定義本錢中心提供效勞和執行功能的性質,用來把本錢分配到其他的本錢中心。例如一類工時工資為50元/小時。可以利用本錢中心的實際本錢或方案本錢自動計算作業類型的價格,本錢和作業方案完成后,系統通過將方案本錢除以方案的作業輸出數量計算作業工資。1.4統計指標統計指標定義一些適用于本錢中心、利潤中心、內部定單或過程的可測量值。例如包括本錢中心的雇員總數、長途的分鐘數、“事務〞本錢中心中進行車輛維修的雇員數等等。

統計指標其實就是費用分攤依據。其主數據如下:

圖1-2統計指標主數據【圖】1是指固定的指標,比方說我們固定是30平方,那么就是30,不考慮別的因素影響。

【圖】2是累計指標,比方固定是30平方,上一年是20平方,那么就是50平方,它是一個累計值。

1.5本錢中心費用方案指按本錢中心、本錢要素的方案。可以作為考核的指標,在月底可以生成按本錢中心、本錢要素的方案額和實際額的比較報表。本錢中心方案與“本錢對象控制〞集成,那么必須能夠將間接費用治理本錢傳遞到產品本錢控制。因為本錢對象〔如生產訂單〕不能是分配或評估的接收方,間接費用附加費用和作業類型分配可用于完成從間接費用治理到本錢的轉帳。

1.6本錢中心作業量方案按本錢中心、作業類型制定作業數量方案。作為計算作業價格的根底數據。

1.7功能范圍是針對各個本錢對象中的相應費用科目進行屬性歸類。

1.8本錢中心標準層次是針對各個本錢對象中的相應費用科目進行屬性歸類。

1.9小結本錢中心主數據一般從前臺用戶端進行保護,但也可以從后臺配置端進行保護;主數據中的信息是可以根據時間段來進行保護的,也就是說在不同的時間段可以有不同的值;〔統計性關鍵指標除外〕一旦有數據過帳后就不能刪除;可以根據需要組合成不同的組。

圖1-3本錢中心主數據小結2.后臺配置CCA的后臺配置很簡單,只是需要把一些簡單的參數調整就可以,當然我們建議還是摘用COPY的方式,另外,建議全部摘用系統標準的配置參數。2.1本錢中心的激活與標準層次結構首先在本錢控制范圍下,COSTcenters是需要激活狀態的,同時Hierarchy是需要指定的圖1-4CCA配置2.2本錢中心類別和功能范圍摸索:功能范圍到底是做什么用的?不用功能范圍有什么影響?當你建立本錢中心組的時候,在本錢中心主檔資料Control頁面里可以關聯一個Functionarea,這樣你就可以通過設置功能區域來區分費用歸屬〔如銷售部門,治理部門,輔助生產車間,主生產車間等〕那么在進行費用歸集的時候。舉個例子,比方資產折舊,科目本身是無法區分屬于生產費用還是治理費用,但在建立資產主檔的時候,輸入資產對應的本錢中心,而本錢中心里關聯了Functionarea,這樣就到達了區分科目性質的目的,只需要設置一個折舊費用科目而不用再進一步細分〔銷售費用-折舊、治理費用-折舊、制造費用-折舊等〕。月末可以Byfunctionarea出損益表。

圖1-5本錢中心類別3.本錢會計應用3.1本錢中心會計整理流程本錢中心整理的應用包括了主數據、方案預算、實際過賬和信息系統,具體功能如圖1-6本錢中心會計整體流程圖所示。我們將按照分類分述各個功能點。

圖1-6本錢中心會計整體流程圖

3.2本錢中心主數據

內容:本錢中心〔組〕、統計指標、作業類型、本錢要素

事務代碼:Ks01|Ks02|Ks03|KL01|KL02|KL03|KK01|KK02|KK033.3本錢中心預算與本錢中心方案

事務代碼:KP06|KPZ2

本錢方案

【圖】1,是輸入的本錢中心,當然我們也可以使用本錢中心組。

【圖】2,是本錢要素,即是通過這個對應關系對應到了哪個本錢要素的哪個本錢中心的方案是多少?

【圖】1方案固定本錢與2方案變動本錢,為什么變動本錢不可以輸入,去看看我的本錢要素中的解釋。本錢預算

雖然后臺有一個本錢中心的預算參數設置,但是本錢中心的預算無法做到控制,只能最后出報表比照實際發生與預算值。摸索:本錢中心方案和本錢中心預算的區別:本錢中心方案是針對本錢要素的,而本錢中心預算是針對本錢中心的。

3.4本錢中心應計本錢本錢中心的應計本錢是說可以通過應計本錢的規那么在方案的根底上算出應計本錢,老外搞的東西很復雜,連這個也算功能?

3.5實際過賬

事務代碼:KB31N|KB11N

統計指標輸入在ECC60后就是統計功能了,大家自己去測試吧。但是這個東東可以作為分配分攤的標準。

本錢中心重過帳是指入錯了本錢中心調整一下而已。

摸索:本錢中心重過賬的后臺配置?

本錢中心重過賬默認情況下是不生成FI憑證的,不知道SAP為什么要把這個也作為一個配置。

【圖】1定義集成變式。

【圖】2分配給公司代碼,經過上述配置后KB31N即可生成FI憑證。

3.6本錢中心信息系統本錢中心的報表如以下列圖所示,其中有一定要說的是,在查看報表時我們可以選擇不同的匯率和選項〔要進入專家模式〕,另外還可以通過各種工具來開發自己喜歡的報表。

4.CO內部訂單1.內部訂單概念

1.1內部訂單內部訂單用于方案、收集、監視和結算在公司內部進行的特定操作或任務。內部訂單可用于不同的目的。這種功能分類反映在不同的訂單類型中,其屬性定義了在系統中處理訂單的方式。SAP系統內內部定單分為兩類:實際定單和統計性定單。統計性定單,例如用工程內部訂單來治理在建工程,在月末無須結轉本錢。

1.2內部訂單的常規類型間接費用訂單:費用訂單用于歸集特殊事件和暫時工程本錢的對象。費用訂單主數據創立的同時可以保護結算規那么,也可于費用訂單結算前保護結算規那么。費用訂單分統計性費用訂單和真實費用訂單。假設是統計性費用訂單那么不用保護訂單結算規那么,因為統計性費用訂單只用于報表分析的用途。

投資訂單;用于監視在固定資產生產過程中發生的本錢,如建造存儲設施。

1.3內部訂單主數據內部訂單主記錄有幾個不同的局部,每個中包含有帶預定義字段組的標簽頁。可以在“自定義〞中更改標簽頁的標題,還可以單獨地將字段分配給標簽頁。標準的訂單主記錄數據布局具有以下標簽

頁:①分配(包含機構分配,如公司代碼、業務部門、利潤中心等)

②控制(包括訂單狀態信息、訂單貨幣、統計訂單指示器等)③期末結算(包含計算間接費用的本錢核算表單名、結算參數等)

④一般數據(包含申請人、責任人等)

⑤投資(在上面的示意圖中沒有顯示。包含資產投資訂單所需的參數)

摸索,訂單類型如何在系統中劃分?

其中,【圖】1所示是我們自定義的的內部訂單類型。01內部訂單(Tcode:KO01)04本錢控制生產訂單(Tcode:KKF1,只核算本錢,可不建立BOM和工藝路線)05生產本錢歸集器(Tcode:KKF6N,通常根據生產版本建立)10PP生產訂單(Tcode:CO01,要求相關產品建立有BOM和工藝路線)30保護訂單(Tcode:IW31,設備維修工單)40流程訂單(Tcode:COR1,流程行業的生產訂單,一般要求建有配方)1.4內部訂單主要功能

預算:按總額、年度、月度進行預算控制。還可以做別的不,當然可以,吼吼~

方案:內部訂單的費用本錢方案功能可和MM模塊和生產能力方案集成,用于監視

實際本錢并和實際本錢比照分析,從而為治理決策者提供依據。

輔助核算:和國產軟件的輔助核算工程很像。可以通過內部訂單來歸集費用,如在F-02做憑證錄入時候可以選擇某一統計型內部訂單,那么就可以查看到這個工程的費用情況。

分析:可以隨時分析內部訂單的方案/實際發生額比照,各不同期間的實際/實際比照,按月/季指標分析,分析內部訂單發生的行工程,對訂單的未清項等進行分析。

工程結算:大修工程、研發工程、在建工程工程以及技措技改工程〔靠,簡直就和PS模塊解決的問題差不多,真是物美價廉的東東,那么這個到底和PS有啥區別,別急,老方會在SAP方丈-PS七日通中講到。

2.后臺配置

2.1定義內部訂單類型

首先在本錢控制范圍下,內部訂單是需要激活狀態的,同時還需要對內部訂單定制很多參數。

【圖】1定義結算參數文件,結算參數文件也決定了結算規那么〔我們會在后面講到〕。

【圖】2定義方案參數文件。

【圖】3定義預算參數文件。

【圖】4定義工程類別參數文件,還記得吧,投資、費用、生產和結果分析。

【圖】5打上這個勾,對前臺來說是可以把內部訂單建立時候自動切換到下達狀態。

【圖】6定義字段選擇,這個就不用說了吧,和字段狀態組的感覺是一樣的。

2.2定義內部訂單預算參數

通過定義預算參數文件我們可以對預算做N多的參數控制,下面詳細的介紹預算參數配置。

【圖】1Past:指可以對過去幾年做預算控制。

【圖】2Future指可以對未來幾年做預算控制,Star指預算的開始年度,如不填寫默認為當前年度。

【圖】3總值控制,可以跨年度。

【圖】4年度預算控制,不可以跨年度,為什么內部訂單不能做期間控制呢????

【圖】5定義匯率類型,參考我的SAP方丈-匯率詳解

【圖】6投資治理-程序類型預算,到底做什么用的到現在老方也沒搞懂,難道是和投資治理的接口???哪個大蝦知道還望指點。

【圖】7沒搞懂這是啥子,默認1是自動選擇的。

【圖】8定義的小數位數,默認為2位。

最后別忘了把預算參數文件分配給內部訂單。

2.3定義內部訂單預算容差限制通過預算容差可以限制預算執行到百分比后的動作,如圖中所示,預算超百分90%〔不包括90%〕可以1警告2mail3錯誤提示。

2.4定義分配結構51407.html

本錢中心:可以把內部訂單的要素直接結轉到本錢中心,如公用的折舊中心?還記得一個折舊要幾個本錢中心共同承擔嗎?不記得,還得打屁屁~~~哎,老方手都痛了。

內部訂單:千萬不要把內部訂單再結算到內部訂單,因為死循環,為啥?自己想想吧。

WBS:CO-IO到WBS遷移,誰問的這個問題來的?

網絡:同上。

獲利段:PSG

銷售訂單:?

固定資產:可以把在建工程結轉到FXA〔固定資產〕,還記得AIBU嗎?

總賬科目:可以把內部訂單結轉到某個科目。例如我們可以把在建工程的內部訂單結轉到在建工程科目〔資產類〕,研發類結轉到〔研發支出〕。我想這種做法當期作為損益月末一次性調整就是為了出具財務報表的需要。

是不是我講的東西你還沒太看懂,沒有關系,多看幾遍吧。慢慢就懂了。這個東西其實就是需要多測試,沒什么難的。

2.5定義預算參數文件

【圖】1定義訂單是否能夠被計算,如果統計型訂單要選擇3.

【圖】2還記得我們前面定義的那些東西吧,全部對應上吧。

【圖】3默認的結算類型,GL,這個做啥用,到保護結算規那么的時候大家就會看到哈。OHYEAH~

【圖】4標識,100%結算還是可以按百分比結算,還是可以按權重結算等等,這個配置我們在保護結算規那么的時候也會看到。

【圖】5指定哪個東西可以結算。

【圖】6還記得最大結算規那么,別說你忘了,打屁屁的。

源結構應用:

在介紹分配結構的結算本錢要素時,訂單結算時要么使用原始科目(默認使用),要么使用結算本錢要素(通常很少使用),訂單能規集的的東東有哪些呢?很簡單就是損益,會計科目只有兩大類:資產負債表科目和損益類科目,損益又分本錢費用類和收入類。

假設某科研內部訂單既規集了費用支出(包括薪酬、差旅和技術使用費等多種費用),同時又發生了一定收入,現在需要將所有的費用支出統一結算到一個〞科研支出〞科目,而收入那么結算到〞營業外收入-**〞科目,此時就需要使用源結構。

3.內部訂單主數據

事務代碼:Ko01|Ko02|Kob1

【圖】1還記得這個是在哪里配置的吧?【圖】2這個就是控制內部訂單是統計型還是實際型的地方【圖】這幾個地方后臺配置都講過了。4.內部訂單預算費用歸集

事務代碼:KO22|KO23|F-02|MB1A

【圖】前面講過了內部訂單只能做年度預算,不能做期間。哎,真是遺憾。

對內部訂單記賬時可以通過F-02,記得字段狀態組要選內部訂單必輸。同時,人工費用也是一樣的道理,至于發料,是用的移動類型261.料工費都齊了,不知道你是否還有其他疑問?

5.內部訂單結算詳解

事務代碼:KO88

6.內部訂單應用在SAP系統中可以通過內部訂單實現對工程工程和固定資產購置預算的自動控制。具體使用分兩種情況:1、對于工程工程,每一個工程建立一個結算型內部訂單,月末需結算到在建工程,工程完工后將在建工程結算到固定資產,并對整個工程實際支出進行預算控制。這里需要明確一點:內部訂單是否結算,對于預算控制并不會產生影響。費用只要在內部訂單上走一遭,不管是否已經結算了,都會將預算分配。2、對于非工程工程,可以按照管控的精細程度,考慮是全年建一個統計型內部訂單、一個在建工程主數據〔或者每個資產建一個統計型訂單,并分配到資產主數據中〕,并對其進行預算控制,內部訂單無需結算到在建工程,摘購后直接將在建工程結算至固定資產。對非安裝性在建工程如果要進行費用的明細統計,使用統計型內部訂單有兩種方式:一種是將統計型內部訂單分配到在建工程主數據里,資產購置本錢過賬時會自動的平行記到統計型內部訂單中;再有一種是在進行資產購置時,在摘購訂單中填入相應的內部訂單號和在建工程號。例如:非安裝設備和折舊資金返還的摘購及入賬同時計入統計型內部訂單和在建工程〔在建工程為實際記賬,內部定單只起統計和預算控制的作用,可查詢到每一項明細支出〕。摘用SAP系統的內部訂單后的好處:1、將改變企業手工控制預算的現狀,如果超出預算,那么在下摘購訂單時系統就會發出超預算報警,不允許摘購發生,這有助于事前控制住公司的預算,并可進行預算和實際的比照;2、內部訂單能詳細記錄工程中發生的費用,如是施工費、材料費、設備款、前期費、開辦費等,有利于進行明細工程的核算和分析。5.CO離散行業本錢核算1.本錢核算的相關概念1.1本錢核算變式通過本錢核算變式定義了生產訂單的本錢核算使用什么樣的方法。

1.2本錢估算變式本錢估算變式定義了在評估的時候摘用什么價格,如方案價格、商品價格、前期作業價格等等。

1.3本錢核算表定義間接費用處理方式。

2.產品本錢核算總攬【圖】1產品本錢方案指對生產貨物或效勞創立的本錢評估。如果在R/3系統中的PP(產品方案)模塊中有可用的數量結構(物料清單及工藝路線),那么可使用PP數據自動創立本錢評估。如果在r3中無數量結構可用,可通過單元本錢核算手工輸入本錢核算工程。【圖】2在本錢對象控制中,產品生產或效勞中發生的本錢在本錢對象(如生產定單)上收集。使用哪個本錢對象依賴于您的控制要求。可能是銷售定單、生產定單、加工定單或生產本錢收集器。“本錢對象控制〞用于計算在產品以及期末結算差異。【圖】3實際本錢核算用于在期末時計算實際產品本錢。結果將作為已關閉期間的加權平均價格傳送到物料主數據。

圖4-1本錢核算

3.產品本錢核算應用下面以生產一臺汽車為例解釋按單生產的本錢核算過程。

3.1主數據

3.1.1作業類型定義作業類型直接人工,間接人工,折舊,其他。其中:直接人工指F〔生產〕類型的發生的本錢流,間接人工指車間治理人員〔本錢中心類型?〕,折舊,其他〔不包含上面的其他費用〕。摸索?為什么作業類型中沒有定義材料作業?分別定義如下作業類型用于作業本錢核算。作業類型描述屬性本錢要素DLAB01直接人工直接薪酬43ILAB01間接人工薪酬43MAC01機器工時所有折舊43POW01動力水電氣油有關費用43OTH01其它非以上所有費用43

圖4-2作業類型主數據3.1.2本錢要素定義本錢本錢要素用于結轉作業所形成的本錢流,本錢要素由于是用于內部作業分配〔屬性請參見CO第一夜本錢要素會計〕。如圖4-3

圖4-3本錢要素主數據

3.1.3統計指標T-code:KK01|KK02|KK03

詳見1.46.CO利潤中心會計1.利潤中心會計概念

1.1利潤中心利潤中心往往處于企業內部比較高的層次,一般具有對立的收入來源或能視同一個具有對立收入的部門,一般還具有獨立的經營權。

1.2利潤中心劃分

簡單來說利潤中心可以是任意一個盈利單位,處于本錢中心的上層利潤中心的設計可以考慮以下幾個方面:地理劃分(地點,位置)產品類別劃分(產品組,產品線)業務類型劃分(生產,銷售,研發)需要考核收入,本錢和費用的單位,通常設為利潤中心

1.3利潤中心考核

利潤中心考核利潤。

2.后臺配置

PCA的后臺配置很簡單,只是需要把一些簡單的參數調整就可以,當然我們建議還是摘用COPY的方式,另外,建議全部摘用系統標準的配置參數。同時,由于利潤中心的很多參數來源于控制范圍,所以需要把控制范圍上的相關參數激活。

2.1定義控制范圍并激活利潤中心

圖1-1定義控制范圍【圖】定義控制范圍是必須的,因為利潤中心是在控制范圍下才能正常使用。同時,必須在控制范圍中profitcenterACT打上勾表示對利潤中心在控制范圍下已經激活。

【圖】1DUMMYProfitCenter定義的是虛擬的利潤中心,虛擬利潤中心的作用我們會在后面講到。

【圖】2利潤中心頂層標準層次名稱,功能是和本錢中心的標準層次很類似。

【圖】3屬于同一profitcenter的costcenter間的CO操作比方分攤數據不post到利潤中心會計,原文中說到Eliminationofinternalbusinessvolumeensuresthattransactiondatabetweentwoobjectsofthesametypethatareassignedtothesameprofitcenter,主要是為了減少不必要的數據量。

【圖】4定義利潤中心的貨幣,系統可以選擇控制范圍貨幣,集團貨幣和利潤中心貨幣,建議選擇統一的貨幣,畢竟在貨幣轉換時比較麻煩。

【圖】5表示貨幣是否在利潤中心間傳遞。

【圖】6定義控制Indicators,即利潤中心激活在哪個年度內有效。但是值得注意的是系統并沒提供在此處增加年度,如增加2023年度。

【圖】中設置PROFITCENTER增加年度的路徑,本例中我們需要增加2023年年度。

【圖】錯誤信息提示在利潤中心的BASICSETTING中的設置有問題導致無法通過,這個是因為我們沒有設置DUMMY〔虛擬利潤中心〕,虛擬利潤中心我們會在利潤中心主數據講到。

【圖】1LINEITEMS表示是否需要傳輸實際數據的行工程。

【圖】2Onlinetranster表示FICO數據是否實時傳輸到PCA。

2.2允許余額結轉

【圖】允許余額結轉,即設置是否允許2KES〔前臺,利潤中心余額結轉操作〕做年度余額結轉。

小結:通過上面幾個步驟的設置利潤中心的后臺配置搭建起來,當然這些都是最簡單的功能,有人會問,PCA難道就這么簡單嗎?我說不。那為什么你講的這么簡單?因為在國內的應用其實就有這么多,就算是SAP現有的案例來看利潤中心也只是用到了利潤考核。最多也只是用利潤中心出具了資產負債表和損益表,以及CASHFOLLOW等等。那么別的功能至少在國內還沒見。所以掌握了上面的一些配置足以應付了。至于更多的功能和應用我想在我的?SAP財務實戰?一書中再做探討,由于國內現在這方面的資料很少,所以有些時候還是我個人觀點,如有什么錯誤,還請大家原諒。

3.利潤中心主數據

3.1利潤中心〔KE51〕

利潤中心建立中盡量可以使用標準層次,有時系統會出現鎖定,可以通過SM12解鎖。

3.2標準層次〔KCH1〕

利潤中心的標準層次用處和本錢中心是完全一樣的,但是有一點值得注意的是,有些操作是可以在標準層次中進行的,但是在前臺卻不可以,比方刪除利潤中心的時間段或更改利潤中心的屬性等,這可能是因為在系統中是把標準層次作為最高的級別所造成的。

圖標準層次

3.3利潤中心組〔KCH1〕利潤中心組和本錢中心組的用處完全相同,值得關注的是,盡量使用利潤中心組這樣的好處在于:

①便于對利潤中心的治理。

②便于系統配置。例如,在后臺配置了一個參數是基于利潤中心組結算的,那么如果利潤中心變動的話只需要改動前臺的利潤中心而不用改動后臺配置,當然,這需要保證所改動的利潤中心是在后臺所配置的利潤中心組下。

3.4虛擬利潤中心

虛擬利潤中心:在名字上解釋就是非實體的利潤中心,我們可以把他當做是一個過渡的利潤中心。

相關鏈接:次級本錢要素,次級本錢要素一向讓大家很難理解,說是新東西吧有不太符合PRCGAAP,其實次級要素就是一個中轉科目而已,所以虛擬利潤中心又何嘗不是利潤中心會計的中轉呢?

虛擬利潤中心的作用?

在啟用利潤中心功能后,在輸入前臺信息時很有可能會忘填寫利潤中心,對于這種情況系統會自動填制利潤中心DUMMY即虛擬利潤中心。當然如果對利潤中心做強制輸入設置就不存在虛擬利潤中心的問題。

企業組織的摸索?

按事業部,按銷售地區還是按產品線,在國內見的比較多還是按事業部,說實話事業部還是事業群還不是學國外。哎~~~~

虛擬中心的建立〔KE59〕:

【圖】虛擬中心主數據,數據建立后在INDICATIOR中系統自動選中了虛擬利潤中心,同時,在〔0KE5〕中系統也回填了DUMMY。

4.利潤中心分配

4.1利潤中心憑證過賬〔9KE0〕

利潤中心是可以POSTdocument的,當然其實在SAP中很多都有DOCUMENT這個概念。用處是在于對利潤中心可以記賬同時也可以在利潤中心之間進行分配分攤等等操作。

圖利潤中心過賬

4.2利潤中心分攤分配〔3KE5|4KE5〕

利潤中心分攤分配的概念和本錢中心是一樣的,再次不做詳細解釋,不同處在于利潤中心ASSESSMENT是send和REC.都是PROFITCENTER,至于CYCLE都是一樣的。

5.轉移價格

簡單一點講由于國內應用較少,請參照?SAP財務實戰?一書。

6.利潤中心報表

6.1利潤中心標準報表

利潤中心本身提供了一些標準的報表(類似于本錢中心報表),比方實際和方案的比照等等。見以下列圖,但是我們在應用時候更多的是要求出具三大表,利潤中心會計本身也提供這樣的Tool.

利潤中心報表工具〔KE81〕DrilldownReporting

利潤中心報表工具是系統內定的一些模板〔8A打頭的〕,當然我們可以通過這些工具來編制利潤中心報表,但是在實際的應用中還是選擇開發方式較多。

圖利潤中心報表工具

6.2利潤中心其他報表〔GRR1|ABAP〕

6.2.1資產負債表

在系統中顯示利潤中心下的資產負債表是比較困難的,因為在記賬時需要對每一個資產負債表工程輸入利潤中心,有時是比較難實現的。下面把幾個要點分解如下。

①物料主數據利潤中心〔必選〕

②總賬憑證過賬利潤中心〔必選〕

③發票校驗利潤中心〔必選〕

④訂單開票利潤中心〔必選〕

⑤其他利潤中心〔必選〕

當然,有可能漏選利潤中心,那么系統就會啟用虛擬利潤中心。我們可以通過確認或批倒批量修改錯誤信息;如果覺得麻煩就直接改表吧,不過那可是不講八榮八C的做法,在此并不建議使用。

6.2.2利潤表

在系統中顯示利潤中心下的,當然這需要在本錢中心保護的時候〔KS01〕保護到正確的利潤中心,然后在報表時候的選擇屏幕中參加利潤中心欄位,這樣就可以出具不同利潤中心下的利潤表。

7.利潤中心幾個應用實例

把這局部內容單獨放在?SAP財務實戰?中,敬請關注。7.CO物料分類帳1.物料分類帳概念中國會計準那么規定:對存貨的核算必須摘用歷史本錢法(即實際本錢法),如果企業摘用方案本錢法或者定額本錢法進行日常核算的,應當按期結轉其本錢差異,將方案本錢或者定額本錢調整為實際本錢。這句話的意思就是說如果使用方案本錢法,那么實際本錢:方案本錢+差異〔在已銷產品和未銷產品間分配〕=實際本錢在好多國產軟件中平常的存貨收發業務財務都不記帳,解釋是當時確定不了物料的實際本錢,只有到月末才計算出“實際本錢〞,有人說這是一種很“無聊的月末加權平均法“,它模擬的是手工模式核算,粗略地迎合了財務核算需求,對本錢治理來說意義不大,因為本錢治理要求是事前預算,事中控制,事后才分析。標準本錢|標準本錢估算|標準價格3者關系,標準本錢=標準價格*標準數量,標準本錢估算是將產品的各本錢部件〔Costcomponent,也就是本錢工程,Tcode:OKTZ〕層層滾動累加得出產品的標準價格,前者是一個立體概念,后者是一個點概念,前者告訴用戶后者是如何計算而來。2.物料分類帳配置步驟一:激活物料帳,如下列圖。使用activity-based物料價格確定〔物料主記錄中的標識2〕中的價格控制V計算移動平均價格。使用價格控制S,以標準價格評估物料和以移動平均價格計算信息。在單-/多-級物料價格確定〔物料主數據里的標識3〕中,評估價格〔標準價格〕保持不更改并且計算已關閉記帳期間的期間單位價格。此選項僅用于帶有價格控制標識S的物料的選項,而且如果除多重貨幣和/或評估外,只推舉使用單-/多-級物料價格確定。在單-/多-級物料價格確定里,期間單位價格作信息更新,但是只可以用于已關閉記帳期間的物料評估。步驟二:分配編號范圍,如下列圖。步驟三:激活價格變化,如下列圖。這個步驟是在前臺用于價格更改時候是否激活的配置〔TcodeMR21|MR22〕。步驟四:定義移動類型是否參與ML運算,如下列圖。這個步驟是定義了移動類型是否參與邏輯運算,值得注意的是,如果是新增加的移動類型此處是必須定義的。步驟五:激活物料分類賬〔前臺〕。Tcode:CKMSTART有人說物料分類帳的配置過于簡單,確實如此,因為物料分類帳是應對于中國國情開發的東西,但是配置簡單相對于前臺來說會失去好多的功能。下面我們逐一的講解。3.物料分類帳應用3.1物料主數據建立〔2066-E100〕3.2物料主數據建立4.物料分類帳問題物料分類帳是有很多問題的,要不企業不都上這個模塊了。4.1WIP不參與差異分攤其實有很多企業需要在完工產品和在產品之間分攤差異,但是在ML的標準功能里面WIP是不參與差異分攤,例如:生產A產品,標準價100元,實際價110元,那么在實際業務中如果A產品未完工,那么WIP為110。即差異全在WIP。4.2物料帳結賬錯誤影響總體結帳物料帳結賬總是會出現莫名的錯誤,如常見的物料帳在上一期間錯誤等。4.3本錢中心、內部訂單領料通過消耗結算???曾經有人問過ML能不能對本錢中心領料自動結轉差異,答復是肯定的,但是仍然需要在系統中進行相應的配置,即201MVT-02。同時對于物料帳結賬要選擇消耗4.4單層結算下的委外差異此操作會產生未分配差異。4.5跨期的物料價格變動8.SAP中如何覓找增強方法一、利用TCODE覓找增強〔第二代的增強〕執行一個程序〔源代碼后附〕,在選擇屏幕處輸入你所需要增強的程序TCODE,執行後,就會出現一個列表,那里就有關于如何增強這個的絕大局部SMOD增強。點擊進去,自己手動覓找需要的增強。這是第二代增強方法二、利用系統函數覓找MODX_FUNCTION_ACTIVE_CHECK在這個FUNCTION的代碼最后添加一個斷點。執行需要增強的TCODE,如果有增強,就會自動跳入DEBUG界面。在DEBUG界面,查看f_tab字段,這里面所顯示的Smod就是關于這個TCODE所有的增強工程的列表。這些增強都是屬于EXIT_XXXXXX_XXX這種形式。至于如何查看這個增強是屬于哪個SMOD,可以自己查閱MODSAP這個表〔SAPEnhancements〕.這是第二代增強。還有一些FUNCTION供參考:[1].DYNP_VALUES_READ[2].MODX_ALL_ACTIVE_MENUENTRIES(菜單增強)[3].MODX_FUNCTION_ACTIVE_CHECK(出口函數增強)[4].MODX_MENUENTRY_ACTIVE_CHECK(菜單增強)[5].MODX_SUBSCREEN_ACTIVE_CHECK(屏幕增強)這些的使用方法和上述的一樣,可以針對各種情況覓找增強。方法三、從程序代碼中找在需要增強的事務里面,翻開SYSTEM——?status,雙擊進入PROGRAM,查看所有的subroutines,重點觀察所有形似userexit_*******這種,由描述來確定適宜的需要增強的FORM。這里是第一代的增強。方法四、針對BADI的增強1、badi對象的信息存儲在SXS_INTER,SXC_EXIT,SXC_CLASS和SXC_ATTR這四個表中。2、sap程序都會調用cl_exithandler=>get_instance來判斷對象是否存在,并返回實例;其實get_instance就是對上述幾個表和他們的視圖〔V_EXT_IMP和V_EXT_ACT〕進行查詢和搜索。3、基于這個機理,我查用ST05來監控一個TCODE來跟蹤,然后選擇查找有關上述幾個表和視圖的操作,就可獲得相關BADI。4、se18查找接口,se19實現接口就可以實現用戶增強。附:增強查找ABAP代碼REPORTZTEST_USER_EXIT.TABLES:TSTC,"SAPTransactionCodesTADIR,"DirectoryofRepositoryObjectsMODSAPT,"SAPEnhancements-ShortTextsMODACT,"ModificationsTRDIR,"SystemtableTRDIRTFDIR,"FunctionModuleENLFDIR,"AdditionalAttributesforFunctionModulesTSTCT."TransactionCodeTextsDATA:JTABLIKETADIROCCURS0WITHHEADERLINE.DATA:FIELD1(30).DATA:V_DEVCLASSLIKETADIR-DEVCLASS.PARAMETERS:P_TCODELIKETSTC-TCODEOBLIGATORY.SELECTSINGLE*FROMTSTCWHERETCODEEQP_TCODE.IFSY-SUBRCEQ0.SELECTSINGLE*FROMTADIRWHEREPGMID='R3TR'ANDOBJECT='PROG'ANDOBJ_NAME=TSTC-PGMNA.MOVE:TADIR-DEVCLASSTOV_DEVCLASS.IFSY-SUBRCNE0.SELECTSINGLE*FROMTRDIRWHERENAME=TSTC-PGMNA.IFTRDIR-SUBCEQ'F'.SELECTSINGLE*FROMTFDIRWHEREPNAME=TSTC-PGMNA.SELECTSINGLE*FROMENLFDIRWHEREFUNCNAME=TFDIR-FUNCNAME.SELECTSINGLE*FROMTADIRWHEREPGMID='R3TR'ANDOBJECT='FUGR'ANDOBJ_NAMEEQENLFDIR-AREA.MOVE:TADIR-DEVCLASSTOV_DEVCLASS.ENDIF.ENDIF.SELECT*FROMTADIRINTOTABLEJTABWHEREPGMID='R3TR'ANDOBJECT='SMOD'ANDDEVCLASS=V_DEVCLASS.SELECTSINGLE*FROMTSTCTWHERESPRSLEQSY-LANGUANDTCODEEQP_TCODE.FORMATCOLORCOL_POSITIVEINTENSIFIEDOFF.WRITE:/(19)'TransactionCode-',20(20)P_TCODE,45(50)TSTCT-TTEXT.SKIP.IFNOTJTAB[]ISINITIAL.WRITE:/(95)SY-ULINE.FORMATCOLORCOL_HEADINGINTENSIFIEDON.WRITE:/1SY-VLINE,2'ExitName',21SY-VLINE,22'Description',95SY-VLINE.WRITE:/(95)SY-ULINE.LOOPATJTAB.SELECTSINGLE*FROMMODSAPTWHERESPRSL=SY-LANGUANDNAME=JTAB-OBJ_NAME.FORMATCOLORCOL_NORMALINTENSIFIEDOFF.WRITE:/1SY-VLINE,2JTAB-OBJ_NAMEHOTSPOTON,21SY-VLINE,22MODSAPT-MODTEXT,95SY-VLINE.ENDLOOP.WRITE:/(95)SY-ULINE.DESCRIBETABLEJTAB.SKIP.FORMATCOLORCOL_TOTALINTENSIFIEDON.WRITE:/'NoofExits:',SY-TFILL.ELSE.FORMATCOLORCOL_NEGATIVEINTENSIFIEDON.WRITE:/(95)'NoUserExitexists'.ENDIF.ELSE.FORMATCOLORCOL_NEGATIVEINTENSIFIEDON.WRITE:/(95)'TransactionCodeDoesNotExist'.ENDIF.ATLINE-SELECTION.GETCURSORFIELDFIELD1.CHECKFIELD1(4)EQ'JTAB'.SETPARAMETERID'MON'FIELDSY-LISEL+1(10).CALLTRANSACTION'SMOD'ANDSKIPFIRSTSCREEN.9.SAP分期付款設計需求:供應商開的發票過來,先付95%,剩下5%做質保險金,三個月后再付。MIRO正常業務,假設處理如下:Dr:GR/IR100元應交稅費-增值稅進項17元Cr:應付帳款-某供應商117元根據需求,希望到達如下效果:Dr:GR/IR100元應交稅費-增值稅進項17元Cr:應付帳款-某供應商117*0.95元條款:立刻支付應付質保金-某供應商117*0.05元條款:質保N月后支付利用分期付款支付條件可到達以下目的:Dr:GR/IR100元應交稅費-增值稅進項17元Cr:應付帳款-某供應商117*0.95元條款:立刻支付應付帳款-某供應商117*0.05元條款:質保N月后支付不能變換科目,除非使用科目修改增強,根據邏輯修改科目應付帳款-某供應商為應付質保金-某供應商。解決方法(Tcode:OBB8/OBB9):(1).OBB8假設建立3個支付條款,0001表示立刻支付,0002表示3個月后支付,0009表示包括支付條款0001和0002的〞母〞條款,0009需要選擇“分期付款〞標志。(2).OBB9定義如下,百分比和收付條款0001/0002。這樣就到達分期付款的目的,分期付款的參數兩個:一是百分比,二是子條款,子條款中又包括諸如付款方式,現金折扣率,付款帳齡計算的基準日期等詳細信息。如果需要,可使用增強OBBH將科目置換為應付質保金-某供應商。在SD模塊,分期付款業務也經常發生,比方客戶也會扣除質保金后續到質保期才予以支付;比方某些客戶迫于資金周轉壓力可能無法一次性交清全部貨款,討論一下后一情況在SAP中的實現。(1).銷售交貨:Dr:發出商品Cr:產成品(2).銷售實現和結轉本錢I.確定收入根據規定,分期付款銷售收入確認時間應為約定付款的時間,確定收入分錄:Dr:應收賬款-某客戶Cr:主營業務收入

應交稅費-增值稅-銷項II.結轉分期付款銷售本錢分期付款發貨先把全部本錢記入到發出商品(類中間科目),每根據合同到期確認一筆收入后,再按比例結轉相應的銷售本錢。Dr:主營業務本錢

Cr:發出商品(3).發票開具由于分期付款開具發票的方式有兩種:a.一次性全額開具增值稅發票。如果是提前一次全額開增值稅發票,那么需要按發票金額全額繳納增值稅,這比較符合稅法規定:〞發貨就需確定收入,確定收入就開發票〞,但對企業不利,需要提前繳納增值稅,還有人說:一次性開票的增值稅發票日期會造成ERP系統的銷售收入(一次)和分期銷售收入日期(屢次)不符。既然都一次全額開票,實際上在系統中也就不需要再使用什么發出商品核算,就走正常銷售,應收和收入都全部確定在當期,此時只將應收帳款的支付條件設置為分期支付就行,比方,某客戶欠款100萬,他比較賴,到期每次去催款,他還個10萬8萬的,不是分期都給生生折騰成分期了。b.分期開具增值稅發票如果企業分期開具發票,那么處理參考(1)(2)使用發出商品處理,對企業來講可延遲納稅,會計處理稍微紛雜一點。說到發出商品,在ERP系統中,由于分期付款跨了多期,而每期產品的實際價格是發生變化的,作為過渡科目的發出商品在最后結轉本錢后可能會保存有余額,這是因為發出商品是在ERP系統中,按比例從發出商品結轉到分期銷售本錢不再是從財務直接記帳,而是從后勤過帳的。已提未售和已售未提按稅法規定,商品發出,就應開具發票確定收入,如果未開票〔已提未售〕,在會計核算上不能做為收入入賬,應該計入“發出商品〞,一般企業如有發出商品發生,原那么上需要納稅申報,必要時先預交該局部增值稅,否那么屬于偷稅漏稅,說白了,分期銷售無非是商業競爭上對客戶的一種讓步,然后希望稅務也給點延遲納稅的實惠,代銷方式、賒銷和分期收款方式是增值稅收籌劃常見經典例子,不再多講。不過,本人注意到一般實施SAP的企業大都財大氣粗,NB哄哄,似乎很少見到分期的業務。還有一種已銷未提業務,比方某石油公司的油品已經售出,但客戶未提貨;某鋼鐵企業的鋼材已經銷售,客戶可能因無存放地點暫存在企業里。已提未售和寄售為了降低庫存本錢,整合供應鏈資源,越來越多的企業開始嘗試一種新型的供應鏈治理模式供應商治理庫存〔VMI〕,已提未售是吧?咱不走發出商品,走VMI流程,相當于內部移庫,庫存還是咱的庫存,不是銷售,咱的?在ERP中,好象很多企業都走的歡,不知稅務的弟兄對此如何感想?分期付款條件看SAP設計僵硬估量沒有多少人會疑心德國人設計思維的嚴謹,有人說大型治理軟件的邏輯復雜度并不亞于波音飛機的設計,某次,一個好友說他要去做治理軟件然后賣到全國各地,我回復說:我幫助你一把,我去開連鎖運輸公司。他很疑惑,我如此解釋:如果你搞治理軟件賣,肯定Bug要用卡車來運!過度的嚴謹也會導致業務實現的僵硬化,下面以幾個簡單實例來說明。業務場景一:比方,某設備摘購安裝工程按照合同約定,企業先預付20%,設備到廠并安裝完畢后付款至總貨款的90%(包括預付的20%,或者更細,比方根據施工完成程度分期付款,施工一半付總額40%,主體完工付到75%,驗收合格付到90%等),剩余10%為質保金,質保期18個月,企業在施工工程、設備摘購、裝修工程中都會出現質保金,為了核算質保金,企業在應付帳款(或其他應付)可設應付設備質保金、應付工程質保金,維修勞務質保金,裝修質保金等明細科目,那么在SAP中如何實現呢?先澄清以下幾點:(1).SAP中的科目不分級,只有一級,級別面前,科目平等,表達民主思想,對于應付,國內的財務軟件記帳是先輸入應付,然后去掛供應商核算;而SAP記帳那么是先輸入供應商,然后去帶出供應商主數據中的統馭科目(主科目),通常為應付帳款,對于同一個供應商如存在預付、應付票據或各種其他應付,那么使用特殊總帳標志區分,說白了,類似搞一個輔助核算字段標識并在憑證產生時根據配置將主科目修改,比照兩種設計思路,先輸各種應付預付其他應付科目再找供應商的設計更加靈活,不需要在使用什么標志,缺點是如果存在大量類似科目和供應商,錯選機率加大;而SAP記帳是供應商先入為主,且以一個字母標志去替代預付、應付票據或各種其他應付,記帳錯誤機率減少,缺點是,特殊總帳標志只有一個字母,在集團化的大型工程中該標志資源很快就耗盡。當然SAP還提供了一種使用備選科目的方式允許在記帳時直接修改默認的主科目。ERP設計改良建議一:在SAP的供應商主數據中,將統馭科目設置為主科目(或叫控制科目),然后可設置允許的特殊總帳標識清單,這樣在記帳時選擇該供應商只能看到和選擇允許的特殊總帳標識,效果更佳。(2).SAP的發票校驗MIRO/MIR7無法使用特殊總帳標志,也不能使用備選科目,也就是說,只能主數據中對應的主科目,假設同一供應商同時存在購置生產用料的應付帳款和購置工程物資的應付工程款,就難于直接從科目上區分。企業需求:某次,某家企業希望我能幫助他們實現MIRO發票校驗時產生如下分錄,注意貸方:Dr:GR/IR(類似材料摘購或應付暫估)100萬應交稅費-增值稅進項17萬Cr:預付帳款23.4萬(并自動和Tcode:F-48預付清帳)應付帳款81.9萬其他應付-質保金11.7萬我說:SAP默認只能做到117全進應付帳款,F-44乃供應商的應付清預付,連這功能也要在MIRO做,要求太BT太過分了!用戶揶揄道:你不是說你是傳說中的ERP神仙嗎?還有你辦不到的事?用戶的任何需求都是合理的!想想看,如果你設計發票校驗程序,如何設計才能在和后勤自動集成的情況下自動實現如上分錄?業務場景二:企業在設備安裝和裝修工程中,存在大量扣留質保金的業務,具體如下,質保期分為6、12、18、24和36個月共5個質保期限,質保比率分3%,5%,10%共3個比率,以質保期6個月質保比率3%在SAP發票校驗的實現為例,要求發票校驗的參考會計分錄如下:Dr:GR/IR100萬應交稅費-增值稅進項17萬Cr:應付帳款111.15萬(117*95%,立刻支付)其他應付-質保金5.85萬(117*5%,6個月后支付)步驟如下:(1).OBB8定義3個支付條款假設為Z001、ZB01和FQ01。Z001:對應正常應付帳款,為立刻支付,ZB01對應質保期6個月質保的其他應付-質保金,而FQ01包含此兩者,ZB01的設置如以下列圖:關于支付條款的配置項解釋請參考相關章節,不再細說,圖[3]表示60天凈到期。同樣定義好Z001和FQ01,其中FQ01表示保期6個月質保比率3%,注意選擇〞分期付款〞標志,如以下列圖:(2).OBB9定義分期付款條款FQ01包括Z001和ZB01,分別為95%和5%。也就是說要實現5個質保期(定義5個支付條款),3個質保比率,按照SAP的〞嚴謹〞設計理念,需要建立共20個支付條款(其中15個為分期類的支付條款),參考分期付款條件和保質期支付條件如下表。分期付款條件母條款質保期限質保金比率/支付條款FQ01-FQ036個月3%,5%,10%(ZB01)FQ04-FQ0612個月3%,5%,10%(ZB02)FQ07-FQ0918個月3%,5%,10%(ZB03)FQ10-FQ1224個月3%,5%,10%(ZB04)FQ13-FQ1536個月3%,5%,10%(ZB05)這種配置顯然很多人難于接受,因為假設應付帳款也分到期日,組合就更多,比方,光質保期6個月,質保比率3%又細分為:I.應付帳款15天,質保期6個月,質保比率3%。II.應付帳款30天,質保期6個月,質保比率3%。III.應付帳款45天,質保期6個月,質保比率3%。那麻煩就大了,財務參謀要沒完沒了建支付條款!(3).現在MIRO測試使用FQ01,在〞支付款項〞屏選擇付款條件,得到的分錄如以下列圖[2],117萬應付被劃分為118.15和5.85萬,如果想5.85(4).改良方案:只設置Z001/ZB01和三個分期條款FQ03(3%),FQ05(5%)和FQ10(10%),解決方法思路如下表:分期付款條件母條款質保期限質保金比率/支付條款FQ036/12/18/24/36手工填寫3%(ZB01)FQ056/12/18/24/36手工填寫5%(ZB01)FQ106/12/18/24/36手工填寫10%(ZB01)OBB9的配置如下,在配置中只區分質保金的百分比,而質保期的到期日手工在憑證中保護。質保期由FB02去修改,如以下列圖:由于默認只是將應付帳款給拆分為兩局部,3%、5%和7%的應付質保金從科目上無法區分,只能通過某字段去區分,考慮使用文本字段〔SAP雖然可以使用Tcode:OXK3定義作為輔助核算的客戶化字段,但操作非常不方便〕,如以下列圖[3],也就是說,在會計憑證生成后再去修改質保期和標志質保金類別的行文本〔SE16:V_T053定義行文本〕。在編寫查詢從BSEG根據文本內容去查找各種質保金的情況,缺陷是文本字段內容太過隨意,必須保證內容絕對一致才能查詢準確。改良方法的優點:支付條款的建立大大減少,相對靈活。改良方法的缺點:需要手工更改后續財務憑證,手工輸入質保期天數和使用不嚴肅的行工程文本區分各種質保金業務。用戶問:分期付款時〔例如5%質保金〕,5%局部金額取整到元,剩余局部用總金額減質保金為應付,能否做到?答:手工做帳人為判斷想怎么都行,系統是死的,正常情況下,設計時一般只考慮滿足大多數企業的共性需求,顯然,不大可能考慮如此細微的特定需求。ERP設計改良建議二:在發票校驗或財務記帳時,如果輸入的是分期付款,那么彈出一窗口允許用戶輸入各分支條款的名稱,比例,到期日和科目標志,可以設計如下表:這樣,將整個應付帳款通過輸入的分支條款的比例自動拆分成多行,并且通過科目標志自動帶出科目,前面的“ERP設計改良建議一〞提到過主科目,可以為主科目和預付/其他應付等設置一個字母標志,通過該標志去取得科目,就更佳了!這樣也就解決了業務場景一中提示到的在發票校驗中同時將發票金額拆分為預付帳款、應付帳款和其他應付-質保金3局部的問題。支付條款同樣適用在銷售SD模塊!最后我所需要說的是,業務場景一二提到的是分期付款的一個特例,即一次性開票付款分期,這樣對供應商的稅務籌劃有點不利,在相關章節已經討論過,比方對于供應商來說,他們做的是銷售,只要在SD模塊核算使用“發出商品〞和開票方案就能實現,對于企業這邊,發票分期來一次校驗一次,反倒更容易解決!假設企業收設備貨價值為1000萬,第一次只開票50%,在SAP中,收貨和發票參考分錄為:收貨:Dr:固定資產-機器設備1170萬〔根據分期合同上的總價格款〕CR:GR/IR1170萬企業以分期付款方式購置固定資產,應按照總價款借記“固定資產〞科目,除特殊規定的情況外(如目前稅控設備和個別試點地區如東北,固定資產允許抵扣進項稅額),進項稅都計入固定資產的本錢。發票校驗,假設本期設備商開票100萬:Dr:GR/IR100萬Cr:應付100萬在分期付款的眾多方式中,等額分期支付是實踐中最常摘用的一種,在這種付款方式下,每期歸還本金和利息總額相等,并且由于每期剩余的未歸還本金逐步減少,使得每期支付的利息逐步減少和每期支付的本金逐步增多.另外,如果企業摘用分期付款,在進行會計核算時,需要準確計算出每年應支付的本金與利息,分別記入不同的會計科目.在SAP中,需要注意的是,對于固定資產摘購,默認收貨不產生財務憑證,在發票校驗時才確定資產價值,直接產生Dr:固定資產-機器設備Cr:應付的會計憑證,在分期付款購置資產時,顯然不適宜,為了在收貨時產生憑證,需要在摘購訂單上去除“未估價的收貨“標志,如以下列圖。SAP將所有類型的摘購都集中在一個屏幕完成,對于固定資產摘購重點注意上圖的3點,[1]選種標志“A“表示固定資產摘購,[2]需要在帳戶分配屏幕選擇需購置的設備,[3]表示如果是分期付款購置固定資產,因入帳價值是總價費,一定要在收貨時將所有的價費全部計入資產,所以一定要去除“未估價的收貨“標志!如何按物料付款清帳:在某物流企業,希望按照物料去收款和付款,但是應收和應付會計科目是帶物料的,也就是說發票上有20個物料,并不會根據此20個物料將應收應付生生拆成20個同樣的行工程,只是作為輔助核算工程的物料不同?ERP設計改良建議三:比方某些物流企業確實存在按物料來劃分應收應付并根據物料清帳,如果這樣,建議將銷售訂單/摘購訂單行工程寫入應收應付,因為行工程必定和物料一一對應,而且,SAP的預收預付是可以針對銷售訂單/摘購訂單行工程,正好根據行工程去清帳,缺點是應付帳款將更加明細增加存儲量。不過,通常需要細到根據物料去做應付的,企業涉及該業務的物料通常應該不多。所以在改良建議二的彈出窗口中增加一個選況,根據摘購/銷售行工程拆分應付,不過如果在根據不同的付款期去拆分,一個應付恐怕給拆分的不成人樣了!需要到達如此的明細核算,估量只能如此!還有另外的思路,比方設計總明細帳,總帳包含有筆應收應付,明細帳那么包含帶物料的應收應付,或者,摘用輔助核算帳?這樣又亂套了!分期付款的稅務問題(1).分期付款購車,但賣車方沒有給發票原件,必須等所有款項付清才給發票原件,企業只能取得發票復印件作為入帳憑證,這樣可否計入固定資產,計提折舊?“企業的稅前扣除工程,一律要憑合法的票據憑證確認,凡不能提供合法憑證的,一律不得在稅前進行扣除〞。因此,企業在取得正式發票之前,該項資產計提的折舊不得稅前扣除。(2).根據國家稅務總局·國稅發〔1995年〕192號商業企業摘取分期付款方式購進貨物,但凡發生銷售方是先全額開具發票,購貨方再按合同約定的時間分期支付貨款的情況,其進項稅額的抵扣時間應在該項所有貨款支付完畢后,才能夠申報抵扣該貨物的進項稅額。PS:對于商業企業,銷售方全額開票,估量其銷項稅當期就全繳納了,而進貨方卻需要等全部支付完畢才可申報抵稅,莫非這就是傳說中的國家級的霸王條款?10.淺談SAP期末清帳和重分類通常企業都會制定完善的應收應付治理制度,ERP應該能提供及時登記往來款項和準確反映應收應付帳款的形成、回收、支付及增減變化情況并按月進行核對與清理的功能。1.SAP提供了強大的應收應付治理,簡單列舉幾個其應收應付功能:(1).購銷合同中明確各項條款應收應付從購銷單據開始就可明確各種條款,通常,參謀們會傾向于使用摘購/銷售文本功能來定義各種條款,這些條款被寫入摘購訂單或銷售訂單主數據,主要包括付款方式、付款日期、運輸情況、包裝方式、送貨期限甚至違約違約責任,這些條款將隨摘購訂單或銷售單據被打印或被并形成法律效應,SAP提供了OutputMessage來完成打印或功能,可以將來發生爭端時根據覓求訴訟保全。(2).雙方往來對帳一個公平競爭的市場環境下整個企業鏈應該是雙盈的,在SAP財務模塊提供了階梯式的往來通信功能,包括:信函功能(Correspondence)典型的信函有支付通知(Paymentnotifications)、對帳單(Accountstatements)、余額確定單(Balanceconfirmations)等,支付通知實際上也包括到期需要付給人家的款項,應收過大容易形成壞帳,應付過大也容易造成資不抵債高負債運營。b.自動支付〔Tcode:F110〕SAP提供了自動支付功能,可以自動找到到期的應付形成付款,當然企業可以根據其支付方案進行一定調整,按照國外習慣,到期即需付款,延期的應收和應付需要計息,而按國內實情,顯然自動付款實現不大現實。c.催款(Dunning,Tcode:F150)相對普通信函而言,催款更加正式,SAP提供了多級催款,甚至在催款時可以計算利息,當然催款也包括企業的應付帳款的催款(自催)。(3).制定鼓勵政策SAP對商業折扣,現金折扣,銷售返利等業務提供了相應處理方案。(4).評估和信用機制SAP有供應商評估和完善客戶信用控制功能。國內ERP一般管象預付沖應付、預收沖應收等業務處理叫核銷,SAP那么叫結帳/清帳,清帳包括平時手工清帳和期末自動清帳兩種方式。2.手工清帳相關Tcode:(1).F-03/FB1S:手工清G/Laccount未清項〔針對使用了未清項治理的一般總帳科目〕(2).F-44/FB1K:手工清Vendor未清項〔供應商未清項清帳,即應付預付其他應付等對清〕(3).F-32/FB1D:手工清Customer未清項〔客戶未清項清帳,既應收預收其他應收等對清〕(4).F-04:G/Laccount的帶清帳的過帳(5).F-51:Vendor的帶清帳的過帳(6).F-30:Customer的帶清帳的過帳注:F-04,F-51,F-30這些Tcode初始屏幕顯示的默認憑證類型不同而已,可以使用OBU1設置。使用這些Tcode在平時

溫馨提示

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

評論

0/150

提交評論