CO-06 period-end closing

1.Period End Closing
	CO和FI一樣有每期結帳的問題,需結完后才可以出管理報表 期末結帳順序可以分為accrual cost/輸入skf(為了reposting用的)/reposting/cost allocation/period lock
2. accrual cost
	要先將相關費用暫估,這樣后續的動作中才可以分攤分配到正確的費用收集單位
3.skf
	因為費用后續要歸到正確的費用收集單位,有可能會用到skf,所以要先建立skf
4. reposting
	這邊的reposting是指periodic reposting,和先前在actual posting下說的reposting有些差異,這邊指的是先收集到某個cost object,月底決定分攤基礎后,再做reposting,和前面說的reposting,比較偏向修正過帳到錯誤的費用收集單位
5. cost allocation
	這邊就是指費用的分攤分配,要轉到合理成本收集單位
6. period lock
	做完所有動作后,就是要將期間關結

CO-04 Account Assignment

1.acct. assignment
	Acct. assignment可以是controlling area level(即default acct. assignment,從cost element主檔中指定,代入交易中)或是img level(即auto acct. assignment,從img中指定代入交易中) Img level的設定會高於 controlling area level
	無論系統是用哪一種acct. assignment,都可以於交易時再修改 一般而言無論是default acct assignment或是automatic acct. assignement,都是為了做到自動過帳時針對價差/量差/匯差/折扣...等等的元素指定cost element
5.validation & substrution
	此部份邏輯相同於fi,可於交易時,將相關acct. assignment做一檢查或是變更 Validation的效力會高於subtitution,即這二個若有相沖會以Validation為準
6. adjustment posting
	adjustment posting可以分為二類,一類為manual posting(有點像是重分類),一類為reposting line item(有點像是修正錯誤,所以必需參考到原本的fi文件) manual posting為直接從co做一筆交易修正從fi來的錯誤acct, assignment或是直接做一筆交易過到某個co object下, 這類的posting 系統不會先去check是否有之前要回的或是要修正的過帳存在 repost line item 則會是需要指定到fi文件 若fi 文件的后續co文件,有被repost,此時若需要回轉fi文件,則需先回轉相關co文件后,才可回轉fi文件

CO-05 Adjustment Posting

1. adjustment posting
	adjustment posting可以分為manual及auto manual又可以分為 manual reposting cost/ manual reposting revenue/repost line item/activity allocation/ activity allocation reposting
1.1 manual reposting cost & revenue
	主要是針對從fi來的primary cost element 做reposting 若fi有on 和co整合的話,此reposting亦會產生fi doc 此類reposting不會做sender check也就是說,他不會參考到任何文件及可能產生cost center 會有負數的金額 執行tx:kb11n/kb14n, 回轉tx:kb41n/kb44n
1.2 reposting line item
	主要是針對從fi來的primary cost element 做reposting,但是最主要他會ref回原始的fi資料,即若原始的fi過1000元,要repost也會卡住上限只能是1000元 執行tx:kb61n, 回轉tx:kb4n 若fi 文件的后續co文件,有被repost,此時若需要回轉fi文件,則需先回轉相關co文件后,才可回轉fi文件
1.3 activity allocation
	亦可稱為direct activity allocation direct activity allocation其主要是要將企業組織內的活動轉成數值過帳到系統中,做此動作之前要先讓activity type 和cost center間的關係link起來(tx:kp26) 主要是針對source cost center所提供確定的act. type利用secondary cost element 過到target cost center 這個act. type 的cate. 值是1,secondary cost element 的cate. 值是43 執行tx:kb21n, 回轉tx:kb24n
1.4 activity allocation reposting
	主要是針對direct activity allocation所過帳的文件,再reposting 一次,所以其一定會參考到原始的co 文件 可以和原本文件做到不同月份,但是一定要同一年度 執行tx:kb65, 回轉tx:kb67 Repost 的文件可以是從co直接立的/或是從pp來的(報工文件)/或是time sheet
1.6 direct activity allocation & indirect activity allocation	Direct是指過帳時同時輸入receiving object的資訊,所以可以做到過帳時同步allocation;而indirect是指先過帳到某個cost object上,然后月底再轉到真正的cost objet 身上

CO-03 CO posting

1.doc no range
	CO的no range 是指派到controlling area Co的no range是和年度無關的 Actual 和 plan的posting 最好用不同的no range
2. real & statistical post
	Acct. assignment object會判斷此post要過的oobject是real 或是statistical的object,也就是說Acct. assignment不是real object 就是statistical object, Real就是指會不會影响到財務帳面數,若會就是real posting 一個過帳文件只會存在一個real object,但是可以存在多個statistical object(如IO/profit center...) Profit center 一定是statictical post,但是coster center 則有可能是real或是statistical
3. reposting & allocation
	Reporting是指過錯帳的回轉,allocation是指先過帳到某個虛的成本中心,然后再結轉到實際的成本中心;所以reposting 時會將sender的debit 方迴掉,allocation 則是sender的debit方不變,但會增加sender的credit方,然后會將credit方加的量轉到接收方的debit Co的primary posting 文件(即過帳到primary cost element )可以從fi來或是其他前端如hr/mm/pp....等等,從其他系統來時,是直接從端系統到co,而非是先到fi再自動觸發到co
4.report setting
	Tcode:rpc0 針對執行co report時,可以設定的一些預設值,相似於fi的fb00
	可以設定一些預設值,加快執行效率 每個report亦可設定variant,將常用的參數設定進variant中
5. report ttl values and line item
	SAP將line item及total record會分二個tables 存放,而不是放一齊 Total record一般是用report painter/writer做出來的,而line item是用ALV做出來的
6. overhead cost controlling
	費用管理通常可以分為planning/allocation/control/monitoring 這四大類
7.acct. assignment
Default acct. assignment(KA01)
	可以在cost element主檔中指定cost object
Auto acct. assignment(OKB9)
	IMG也可以設定acct. assignment,而且其效力會大於主檔的 在img 上設定的只能針對primary cost element
Vaildation & substitution
	Vaildation & substitution亦可以協助決定 cost object,且Vaildation 會大於substitution,而且substitution執行后不會有任何訊息

FI-GR/IR暫估科目月底結清

1.GR/IR
	SAP在GR時會 借 原物料 貸 暫估應付帳款,而IR時會 借 暫估應付帳款 貸 AP(供應商),所以會有暫估這個過渡科目,但有時因為價差或是匯差或是其他差異,導致暫估科目沒有結清,此時就需要人為結清他
2.自動結清
	可用F.13或是F13E
	輸入相關條件(記得要先TEST RUN)
	系統會根據ASSIGNMENT配對,將GR和IR所產生的對應暫估一齊做結清 系統會依不同的ASSIGNMENT 產生不同的會計文件,所以會有多筆會計文件的狀況
	取消TEST RUN后,會產生DOC NO
	基本上就是暫估科目一借一貸沖掉
3.手動結清
	手動的方式可以用POST WITH CLEARING方式,自已去沖掉,想沖的部份,這個好處是會只產生一筆會計文件 TX:F-04/FB05

CO-CKMLCP的執行log查詢

1.ckmlcp
	執行完ckmlcp后 產生的log,並不能在ckmlcp 中查到(只能查到最后的log),所以要透過另一個log 去查發生過啥問題
	Tx: CKMPROTDIS 查出你要查的log number

CO-02 MASTER DATA

CO-02 master data
1. master data
	Co 的master data為cost center/cost element/activity type/SKF,這些主檔資料以cost center 為核心,其中activity type是指cost center所提供的服務或是作業,而這些服務或是作業是可以用skf分配到有使用到這些服務或是作業的目地cost center,而分配的媒界叫做cost element,所以activity type主檔中會去指定cost element 這四個主要的master data都有他們自己的cate. 除了skf以外其他三個master data都是和時間有相關性的,即要做任何主檔資料變更時都要指定時間,而哪些欄位是和時間有相依性的是由img設定的
Master data group
	Cost center/cost element/skf/act.type這四個主檔資料都有data group, 但是所有的data group 都沒有時間概念,最明顯的就是standard hierarchy,也就是說hierarchy都是即時的狀態,,若要保留某成本中心位於某組織下的狀況,可以用copy 功能將當時的狀況copy出來,則日后跑報表,就可以反應當時的狀況
2. cost center
	主要是拿來收集相關cost 資訊,可以做大量變更,且在controlling area 下的cost center一定會被指派到一個standard hierarchy(standard hierarchy是在controlling area下指定的) Cost center 會組成一個standard hierarchy,而每一個standard hierarchy的node 或level都是放cost center group,即cost center group為standard hierarchy的level或是node 可以在standard hierarchy中建立cost center 不過一開始的狀態是inactive, 需要active后才可以收集資料;standard hierarchy 可以有多個 Cost center 指派到standard hierarchy 這和時間沒有關係,即若改變standard hierarchy,則這個cost center 以往的交易都會到現在這個standard hierarchy下
	若要修正cost center 的organizational unit的資料,會有如下的限制 1.新舊company code要有相同的幣別 2.只能有paln的資料過到cost center不能有actual的資料 3.這個cost center不能assign到FA/HR MASTER RECORD/WORK CENTER
2.1 cost center category
	cost center category是cost center的分類,也就是說可以用可以提供的activity type來做cost center的分類依據,這樣可以避免生產類的cost center去提供管理類的activity type 其也提供一些屬性的預設值func area
3. activity type
	activity type是activity 的分類,而activity是指公司內部的cost center 所能提供服務或是活動,所以需針對cost center去定義他能提供哪類的activity type 及對應的金額(kp26) 其需要計劃值,這樣就可以比對和實際值的差異 Price indicator是指定計算金額的邏輯 一個activity type可以對應多個cost center
	activity type cate. 是將activity type的操作行為及如何allocated做一分類 price indicator可以指定是否由系統算或是人工輸入,若是人工輸入要選3
	將cost center 和activity type做一link,並將單位金額或是計量單位填入
3.1 Activity-Based Costing( BUSINESS PROCESS)
	所謂的Business process是指一連串的activity 的集合,亦可以視為Activity-Based Costing,其就是針對每一個activity 給一個計劃值,然后再去收集實際值,去比較這個activity 是否有改善的空間;如針對key po這個activity 給定1min要key完,但若是key 2min 就是要被檢討或是分析原因
4. Statistical Key Figure (SKF)
	SKF是指由cost center 提供服務或是activity 的計量值,其主要是為了期末時reposting或allocation用的,可想成是計算的基底 Skf可分為固定值及ttl values,固定值是指手動於需要的時間給值,所以年度總值是年度平均值的加總;而ttl values是指每期給定一個總值,所以年度總值是所有ttl values的加總 如果skf的值是加總有意義的才設定ttl,如公里數/電話分鐘數,其他的就設固定值 其為計算的基底,如要將IT部門的費用轉分到各部門去,其計算基礎若是依PC數,則PC數就是SKF 可以做大量變更 分攤的基礎如人數/坪數/pc數
5. cost element
	Cost element 可分為primary 及secondary Primary cost elements are like materail costs, personnel costs, energy costs... where a corresponding GL account exists in FI. Secondary cost elements are like production costs, material overheads, production overheads, they can be created and administered in only CO. These are used in internal cost allocation, overhead calculation, settlement transactions., it does not flow to FI. 大量變更只能做display及delete
	Primary cost element 主要是為了和fi做資料串接,可以視為外部來的,即從fi過帳而來的.可以視為交易,也就是說不同的primary cost element代表不同的交易行為 Secondary cost elemnt 只有在co 在用,不是從外面模組來的,單純在模組內要重新分配用的,其同上亦可視為一個交易,只是這個交易主要是for co內部重新分攤/分配用的 Revenue element主要是在co上做revenue analyze,其亦為primary cost element,因為他也有是有對應的會科承接 Cost element cate. 是去分類哪些交易可以給該類的cost element 用,所以每一個cost element 一定要指派到cost element cate.
5.1 default value
	Primary cost element因為可以在建G/L acct.時自動產生,所以需要設定一些default value
6.大量變更
Selection variant
	針對下參數的畫面,也可以是動態的決定值,如建一個selection variant是含所有cost center的ba屬性為9900 Cost center/act. type/cost element 都有selection variant selection variant是在img中設定的
List variant
	是指大量變更的程式,進入要改資料的晝面時,其畫面的layout要如何決定 這個是在img設定

FI-信用額度設定邏輯

FI-信用額度設定邏輯
1.想法
	若是結帳日25號月結60天,即代表每月25日(含)以前的發票,會從下個月一號開始起算60天(即月底)為到期日;若是25號以后的發票則是下下個月的一號開始起算60天(即月底)為到期日 對sap而言,要先設定day limit即上述的25號(即結帳日),然后再去設定baseline date(即上述條件的一號),然后再推算出due date(即上述條件的月底
2.1 day limit
	Day limit可想成為結帳日,即每月過25日后,算下個月,所以你必需設定成二個一個是25,一個是31,這代表25前是一個區段,25-31是一個區段,當然也可以把31改成0當做每月的第一天 就sap的語言,這個叫做版本,如上所述,左圖P003這個pym term會存在25及31這二個版本
2.2 baseline date
	決定day limit后,再來就是決定baseline date, baseline date的算法可以用posting date/document date/entry date...等等,因為我們計算的邏輯是只要是當月收的發票就是從下個月一號開始起算,所以左圖紅框的上半部就是讓我們設定加一個月,並月固定從1號開始起算 要設定posting date/document date為基礎日,則可以考量如下狀況,現在為四月,而公司的付款是依過帳日,而不是依對方的發票日(如一月的發票)來計算的話,就可以用post date
	若是你是day limit 31的版本,那個月份就要變加2,因為他是從下下個月一號開始起算
2.3 due date
	有了baseline date后,就可以推算出due date,因為是月結60天,而我們的baseline date 都是從每月的1號開始,所以他就佔了30天了,因此我們的due date 只要再加一個月,並且固定都是月底到期,這樣就是符合月結60天的定義了
3.實務做法
	實務上due date 到了,但是和企業的付款日(出帳日),若還是有落差,一般還是會依出帳日為主,即若due date 為22日,但是企業的出帳日是每月15/30,則這筆款項還是會等到30日才收到,一般這種做法都是用在付款方式電滙的case上