New General Ledger Migration(FI-CO)

1. Is a certificate available for the new General Ledger and migration to new General Ledger?
Yes. For information, see Note 868278 and http://service.sap.com/certificates.
! Is a g"ide available for migration to the new General Ledger# migration g"ide is available!
Use the followin lin! on "#$ "ervice %ar!etplace: http://service.sap.com/&sapid'/(11((()*87(((()+1,1,2((6-
). $ow can I calc"late the data vol"me in the new General Ledger (before the migration)% and how can I eval"ate
the effects on s&stem behavior (es'eciall& on 'erformance)?
For information, see Notes 82(+,* and 1(+*+)(.
+. (hat restrictions are there d"ring a new G)L migration regarding *#+ CFM (,reas"r&) and)or *#+ CML
(Loans).f /o0 have selected miration scenario + or *, /o0 m0st contact "#$ "0pport 'efore the miration to the new
1eneral 2eder 3prefera'l/ as part of the 'l0eprint4. 5his is 'eca0se the miration scenario + or * with "#$ 6F% and/or
"#$ 6%2 is not a standard miration, '0t a pro7ect8'ased miration.
For more information on "#$ miration scenarios, refer to these F#9 and "#$ "ervice %ar!etplace at:
www.service.sap.com/12%.1.

*. (hich restrictions m"st I consider if I intend to activate the doc"ment s'litting f"nction in the new General
Ledger?
For information, see Notes ,66((( and ,8*2,8.
.n this conte:t, see also the F#9 ;.s there an/thin to 'ear in mind d0rin the miration if doc0ment splittin is to 'e
0sed<; in this note.

6. (hich *'ecial Ledgers can be transferred to the new General Ledger?
=nl/ "pecial 2eders that are compliant with the new 1eneral 2eder can and sho0ld 'e transferred to the new 1eneral
2eder.
.f /o0 0se additional c0rrencies in a "pecial $0rpose 2eder and want to replace this "pecial $0rpose 2eder with the
new 1eneral 2eder, /o0 have to chec! the c0rrencies 0sed in the "pecial $0rpose 2eder. 5he miration prorams
read the data in the oriinal F. doc0ment. .f the "pecial $0rpose 2eder /o0 want to replace 0ses a c0rrenc/ that is not
contained in the oriinal F. doc0ment, /o0 cannot mirate this data to the new 1eneral 2eder. .n this case, /o0 m0st
!eep the relevant "pecial $0rpose 2eder.

7. (hat m"st I consider in a s&stem with more than one 'rod"ction client (m"lti-client s&stem) regarding
config"ring% migrating and activating the new General Ledger?
5he ta'le F#12>#65.?@6 with the field F#12>#65.?@ 3indicator: ABNew 1eneral 2eder #cco0ntin .s #ctiveAB4 is client8
specific. #ll other ta'les that are relevant for the new 1eneral 2eder 3ta'les with prefi: F#12>C4 are also client8
dependent.
.f no data is e:chaned 'etween the prod0ctive clients, /o0 can confi0re, mirate and activate the new 1eneral 2eder
in each prod0ctive client independentl/.

8. Is it 'ossible to "'grade to -CC.!/ or -CC0!/ and migrate from the classic General Ledger to the new General
Ledger in the same fiscal &ear?
.f /o0 intend to 0se doc0ment splittin in the new 1eneral 2eder, activate the f0nction for validatin the doc0ment
splittin in /o0r prod0ctive s/stem 'efore the miration date. 5his means that /o0 sho0ld 0prade to @66 6.( in one fiscal
/ear, activate doc0ment split validation 'efore the end of that fiscal /ear and mirate to the new 1eneral 2eder in the
ne:t fiscal /ear.
.f /o0 do not plan to 0se doc0ment splittin in the new 1eneral 2eder, /o0 can 0prade to @66*.( or @666.( and
mirate to the new 1eneral 2eder in the same fiscal /ear.
Deep in mind that the f0nction for validatin doc0ment splittin is not availa'le in @66*.(.
,. (hat m"st I consider regarding migration to the new General Ledger and a local c"rrenc& changeover (for
e1am'le% changeover to the e"ro)?
Eeardin the availa'ilit/ of tools for a local c0rrenc/ chaneover in the new 1eneral 2eder, consider the followin:
@66 *.( and 6.(: 2ocal c0rrenc/ chaneover tools are availa'le in the new 1eneral 2eder.
Eeardin the pro7ects for local c0rrenc/ conversion and miration to the new 1eneral 2eder, consider the followin:
.f doc0ment splittin is activated in the new 1eneral 2eder, it is not possi'le to perform local c0rrenc/ conversion and
miration to the new 1eneral 2eder in the same fiscal /ear.
.f local c0rrenc/ conversion and miration to the new 1eneral 2eder m0st ta!e place in the same fiscal /ear, there is
onl/ one possi'le scenario:
"tep 1: 2ocal c0rrenc/ chaneover in the classic 1eneral 2eder
"tep 2: %iration to the new 1eneral 2eder witho0t doc0ment splittin
#ll other scenarios, especiall/ active doc0ment splittin in the new 1eneral 2eder, reF0ire that /o0 perform local
c0rrenc/ chaneover and miration to the new 1eneral 2eder in different fiscal /ears.
1(. (hich s&stem landsca'e is re2"ired for the test migrations?
For test mirations, /o0 reF0ire a c0rrent cop/ of the prod0ctive client. 5he data'ase and operatin s/stem of the test
s/stem m0st 'e compara'le to the prod0ctive environment.
11. $ow sho"ld I chec3 data consistenc& in the classic General Ledger before the beginning of the first test
migration?
5o chec! data consistenc/ in the classic 1eneral 2eder 'efore the 'einnin of the first test miration, proceed as
follows:
14 $roram EF.N-@G
@:ec0te the proram EF.N-@G twice.
.n the first r0n, choose ;-oc0ments vs .nde:es; in the selection screen.
.n the second r0n, choose ;.nde:es vs -oc0ments; in the selection screen.
For more information, see the proram doc0mentation.
.f the proram finds an/ differences, create a messae on "#$ "ervice %ar!etplace 0nder the component F.8128128G.
24 $roram "#$F1,(
E0n proram "#$F1,( for the fiscal /ear prior to the miration and for the fiscal /ear in which the miration ta!es place.
.f the proram finds an/ differences, create a messae on "#$ "ervice %ar!etplace 0nder the component F.8128128G.
)4 $roram E##H"5(2
.f /o0 0se #sset #cco0ntin, r0n proram E##H"5(2.
.f the proram finds an/ differences, create a messae on "#$ "ervice %ar!etplace 0nder the component F.8##8##8H.
+4 $roram E6=$6#++
.f /o0 0se $rofit 6enter #cco0ntin, r0n proram E6=$6#++.
.f the proram finds an/ differences, see "#$ Note 81)7+.
Eemove all inconsistencies 'efore /o0 start the first test miration.
12. #re there an& recommendations for acco"nt control in G)L acco"nts before the start of the first te1t
migration?
.n 1/2 master data, the fields ;=nl/ 'alances in local crc/;, ;=pen item manaement;, ;-ispla/ line items; and
;Eeconciliation acco0nt for acco0nt t/pe; are relevant for the implementation of the new 1eneral 2eder.
#nal/Ie these fields and ad70st them if necessar/ 'efore startin the first test miration.
;=nl/ 'alances in local crc/;: .f the indicator ;=nl/ 'alances in local crc/; is not active, totals records of the acco0nt are
0pdated to all c0rrencies. 6hec! if this is necessar/. $ostins in different c0rrencies inflate the n0m'er of totals records
in the ta'le F#12F2@G5.
;=pen item manaement; 3=. manaement4: 6hec! for which acco0nts it is 0sef0l to manae open items. Jhich
acco0nts do /o0 act0all/ clear<
.f 0se parallel leders in the new 1eneral 2eder, !eep in mind that acco0nts with different val0ations 3for e:ample,
provision acco0nts4 m0st not 'e manaed on an open item 'asis.
.f /o0 0se the forein c0rrenc/ val0ation proram to post to acco0nts 3proram "#$F1(( or transaction F.(*4, /o0 sho0ld
not manae these acco0nts on an open item 'asis. For more information, see "#$ Note )18),,. Yo0 can confi0re
forein c0rrenc/ val0ation in transaction =H#1.
Yo0 can 0se the report EF"@$#() to switch off open item manaement in acco0nts that have 'een posted to. For more
information, see Note 17*,6(.
;-ispla/ line items;: From a technical point of view, ;-ispla/ line items; is no loner reF0ired for acco0nts that are not
manaed on an open item 'asis 'eca0se the new 1eneral 2eder manaes line items for each acco0nt in the ta'le
F#12F2@G#. #fter the miration from the classic 1eneral 2eder to the new 1eneral 2eder, /o0 cannot switch off line
item displa/ 0ntil the e:ternal a0ditor has iven approval.
;Eeconciliation acco0nt for acco0nt t/pe;: .f /o0 intend to activate doc0ment splittin, ma!e s0re that the reconciliation
acco0nts for c0stomers and vendors are controlled in the same wa/ in all compan/ codes. .f, for e:ample, a 1/2 acco0nt
is a reconciliation acco0nt for c0stomers, this m0st 'e the case in all relevant compan/ codes 'eca0se /o0 have to
classif/ acco0nts for doc0ment splittin at chart of acco0nts level.

1). $ow can I dis'la& the IMG 'ath and a''lication men" for the new General Ledger in a C"stomi4ing s&stem or
in a test s&stem for the migration?
5o displa/ the men0 for the new 1eneral 2eder and the .%1 path for implementin the new 1eneral 2eder, proceed as
follows.
14 @:ec0te the followin step in the .%1 3.mplementation 10ide4:
5ransaction "$E= 8K Financial #cco0ntin 8K Financial #cco0ntin 1lo'al "ettins 8K #ctivate New 1eneral 2eder
#cco0ntin.
"et the activation fla, and save the chane in the s0'seF0ent 60stomiIin order.
H/ settin 3and savin4 the activation fla, an entr/ is created in the F#12>#65.?@6 ta'le, which also contains other
important information, for e:ample reardin doc0ment splittin, 125( 0pdate, derivin the f0nctional area in the entr/
view, and more.
#fter callin transaction "$E=, 60stomiIin is possi'le in the new 1eneral 2eder 3in this s/stem4, and the new paths
are displa/ed in the .mplementation 10ide and in the application men0.
24 .mmediatel/ after step 14, deactivate the new 1eneral 2eder aain in the same 60stomiIin step, and save the
chane in the 60stomiIin order from "tep 14. Lowever, the necessar/ entr/ remains in the ta'le F#12>#65.?@6.
.mportant: .f the new 1eneral 2eder is not active in an/ other client of this s/stem, the .%1 path disappears aain.
)4 5herefore, r0n the report EF#12>"J#$>.%1>N@J. 5he .%1 path will then 'e displa/ed aain even tho0h the new
1/2 is not active. Yo0 can now confi0re the new 1/2 in the test s/stem witho0t the new 1/2 'ein active, allowin /o0 to
start /o0r first test miration.
+4 Lowever, in order to create a miration plan in the live s/stem later 3for e:ample, to activate the doc0ment splittin
validation in ood time4, transport the 60stomiIin order from "teps 14 and 24 to /o0r live s/stem.
1+. I want to add additional fields to the total record table (F#GLFL-5,) or line item table (F#GLFL-5#)! (hat
m"st I consider?
For information, see Notes ,612,* and ,2)687.
1*. $ow sho"ld I set "' m& trans'ort s&stem in m& new General Ledger 'ro6ect?
5he followin recommendation ass0mes that the transport manaement 3wor!'ench oraniIer and transport s/stem:
development, test, prod0ction4 is set 0p in the prod0ctive @E$ landscape.
Yo0 m0st store p0re new 1eneral 2eder confi0rations, confi0ration of validation of doc0ment splittin and activation of
the new 1eneral 2eder in different transport orders. #fter completin the test, /o0 can transport p0re new 1eneral
2eder settins to the prod0ctive environment. 5ransport the doc0ment splittin validation at a later stae.
Finall/ 3after completin the miration4, transport the activation indicator to the prod0ctive s/stem.
16. (hich 'arts of C"stomi4ing m"st alread& e1ist in the 'rod"ction s&stem on the migration date?
.f /o0 0se doc0ment splittin in @66 6.(, we recommend that /o0 activate the validation of doc0ment splittin in the
prod0ction s/stem at the latest on the miration date. 5his means that the new 1eneral 2eder incl0din doc0ment
splittin m0st 'e completel/ confi0red in the prod0ction s/stem on the miration date and that all interfaces and #2@
scenarios m0st 'e ad70sted accordinl/.
5his does not appl/ to @66 *.( 'eca0se the validation of doc0ment splittin is not availa'le in @66 *.(.
.f /o0 do not intend to 0se doc0ment splittin or if /o0 0se Eelease @66 *.(, /o0 can transport 60stomiIin of the new
1eneral 2eder to the prod0ctive s/stem after the miration date.
5he indicator ;New 1eneral 2eder #cco0ntin .s #ctive; is transported with other 'asic settins of the new 1eneral
2eder in ta'le F#12>#65.?@6. @ns0re that the indictor ;New 1eneral 2eder #cco0ntin .s #ctive; is not set when /o0
transport it to the prod0ction s/stem.
17. (hen drawing "' the 'ro6ect 'lan% what m"st I consider if I want to "se doc"ment s'litting?
Je recommend that /o0 activate doc0ment splittin validation at the latest on the miration date.
5he new 1eneral 2eder incl0din doc0ment splittin m0st 'e completel/ and finall/ confi0red 'efore /o0 activate
doc0ment splittin validation.
18. (hich are the criteria for creating a migration 'lan?
5here are two 'asic t/pes of miration plans:
8 Jith doc0ment splittin
8 Jitho0t doc0ment splittin.
.f /o0 plan to activate doc0ment splittin, this has a ma7or impact on the miration. Yo0 have to assin e:actl/ one t/pe
to each miration plan. 5herefore, if /o0 want to activate doc0ment splittin for some compan/ codes and not for others,
/o0 m0st create two miration plans.
#ctivation of validation of doc0ment splittin is also done in the miration plan in miration phase 1.
5o create several miration plans, /o0 also reF0ire different fiscal /ear variants. .n this respect, onl/ the first da/ of the
fiscal /ear is relevant. 5he period sorted list in the fiscal /ear is not relevant.
.f, for e:ample, the fiscal /ear 'eins on Man0ar/ 1 in one compan/ code and on %arch 1 in another compan/ code, /o0
m0st create two miration plans for the two compan/ codes.
.f compan/ codes post across compan/ codes and /o0 want to activate doc0ment splittin in the new 1eneral 2eder,
note the followin: Yo0 m0st assin all compan/ codes that post across compan/ codes amonst each other to the same
miration plan.
1,. Can an& date in the fiscal &ear be chosen as the migration date?
No. 5he miration date m0st 'e the first da/ of the fiscal /ear. No other date is possi'le.
.f /o0 want to perform the prod0ctive miration in fiscal /ear 2(GY, /o0 can perform test mirations in the previo0s fiscal
/ear '/ settin the miration date to the first da/ of fiscal /ear 2(GY N 1.
2(. (hich as'ects m"st I consider regarding the activation date of the new General Ledger?
# prereF0isite for the miration is that /ear8end closin has 'een performed for the previo0s fiscal /ear. 5he activation
date does not have to 'e a partic0lar date 3for e:ample, the first da/ of the month/period or the last da/ of the
month/period4. 5he miration reF0ires downtime. 5he s/stem can o live on an/ da/ in the month. Je recommend that
/o0 choose a time slot for oin live when the s/stem standstill has minimal impact on /o0r compan/. 6onseF0entl/,
wee!ends after or precedin p0'lic holida/s are s0ita'le dates, as are compan/ holida/s.
-0rin the downtime, the miration prorams are r0n. #fter s0ccessf0ll/ r0nnin the miration prorams 3'0t still d0rin
the downtime4, fi0res 'efore miration m0st 'e reconciled with fi0res after miration. #fter s0ccessf0ll/ completin the
reconciliation, /o0 can activate the new 1eneral 2eder.
Heca0se the reconciliation of fi0res 'efore and after miration is 0s0all/ done '/ the persons who are also in chare of
the month8end closin, we recommended that /o0 do not sched0le activation of the new 1eneral 2eder at the same time
as the month8end closin.
21. Is it 'ossible to activate the new General Ledger at com'an& code level?
No. Yo0 activate the new 1eneral 2eder at client level. 5his means that the new 1eneral 2eder is active for all
compan/ codes in the client at the same time.
22. M"st I consider an&thing s'ecial for the tables #CC,$7% #CC,I, and #CC,C8 in connection with the
migration to the new General Ledger?
For more information, see Note +8((,, section 8.
2). 9o" want to config"re a new com'an& code with the new General Ledger! ,he e1isting com'an& codes "se
the classic General Ledger! Can com'an& codes "se different general ledgers (classic and new) in the same
client?
5he implementation of a new compan/ code and the transition from the classic 1eneral 2eder to the new 1eneral
2eder are two different pro7ects which /o0 m0st sched0le at different times.
Yo0 perform the miration from the classic 1eneral 2eder to the new 1eneral 2eder at client level and it affects all
compan/ codes in this client.
Heca0se the new 1eneral 2eder is activated at client level, the new 1eneral 2eder wo0ld 'e active for all compan/
codes, not onl/ for the new compan/ code. 5his wo0ld mean that the new 1eneral 2eder is active in the old compan/
codes, '0t there was no miration from the classic 1eneral 2eder to the new 1eneral 2eder. 5his is not possi'le.
5herefore, it is not possi'le to start with a new compan/ code in the new 1eneral 2eder while the classic 1eneral 2eder
is still active in other compan/ codes in the same client.
First implement the new compan/ code. 5hen set 0p the pro7ect for the transition from the classic 1eneral 2eder to the
new 1eneral 2eder.
#lternativel/: First set 0p the pro7ect for the transition from the classic 1eneral 2eder to the new 1eneral 2eder and
mirate the data to the new 1eneral 2eder, then implement the new compan/ code.
2+. ,he s&stem contains com'an& codes that have no transaction data at all or com'an& codes that have
transaction data onl& in closed fiscal &ears and are no longer in "se! ,hese com'an& codes are called inactive
com'an& codes! (hat m"st I consider regarding inactive com'an& codes when migrating to the new General
Ledger?
#t the 'einnin of the c0rrent fiscal /ear, inactive compan/ codes do not have open items, 'alance carr/forwards or F.
doc0ments.
5herefore, e:cl0de inactive compan/ codes from the miration to the new 1eneral 2eder.
2*. M"st all com'an& codes be migrated s"ccessf"ll& before the new General Ledger can be activated?
Hasicall/, all doc0ments in all compan/ codes m0st 'e mirated completel/ and witho0t errors 'efore /o0 can activate the
new 1eneral 2eder.
.n e:ceptional cases, /o0 can mirate some doc0ments after activatin the new 1eneral 2eder as lon as the stat0s of
the miration plan has not 'een set to stat0s ;%iration ended;. Lowever, the pro7ect team m0st 'e aware of the
conseF0ences of missin doc0ments for s/stem operations. .f, for e:ample, /o0 want to 0se doc0ment splittin, /o0
cannot pa/ open pa/a'les from the c0rrent fiscal /ear 0ntil the doc0ment was mirated.
26. Is there a :#dI for transferring the balance carr&forward from 'hase /?
5o derive the new acco0nt assinment fields 3for e:ample, "ement4, /o0 can 0se the H#d. F#12>U$2=#->6F. Jhen
derivin fields, /o0 can 0se all fields in the str0ct0re 12U1 incl0din an/ c0stomer fields.
27. $ow can I "se transaction F:C: 'ost data to reconciliation acco"nts for assets and to acco"nts for in'"t ta1
o"t'"t ta1?
.mplement the corrections accordin to Note ,)7,+(.
28. (hat mass 'rocessing o'tion is available for transaction F:C:?
Use 'atch inp0t for mass processin of transaction FH6H. Je recommend this, for e:ample, if /o0 want to split the
'alances of reconciliation acco0nts for assets to profit centers or sements.
2,. Is the doc"ment s'litting available for o'en items from 'revio"s fiscal &ears ('hase /)?
No. Jhen miratin open items from previo0s /ears 3phase (4 to the new 1eneral 2eder, the s/stem does not split
doc0ments.
Yo0 can s0pplement the acco0nt assinment fields for open items from previo0s fiscal /ears in the form of a sin0lar
acco0nt assinment. 5his means that an open item can receive one val0e for each acco0nt assinment field. 5he H#d.
F#12>%.1E>"UH"5 provides this f0nction..t is not possi'le to split the open item itself. .t is not possi'le to split the open
item itself.
)(. (hat m"st I do if I want the doc"ment s'litting f"nction to set 'artner assignments in com'an& code clearing
lines?
"ee Note ,+2*+2.
)1. Is it correct that a clearing doc"ment has clearing items when the doc"ment s'lit is active?
Yes. .f doc0ment splittin is active, clearin doc0ments will alwa/s have two line items in the entr/ view 3ta'le
H"@14. "ee Note ,*(77).
For information a'o0t clearin doc0ments in phase 1, see Note 1(*+67+.
)2. (h& does the batch in'"t not iss"e an error message altho"gh the validation of doc"ment s'litting is active
and config"red accordingl&% and the condition for the validation is not met?
5he view ?>F#12>"$2>$E=6 contains an entr/ that applies tor all '0siness transactions or for a specified '0siness
transaction in connection with the 'atch inp0t indicator ?>F#12>"$2>$E=68H.N$5. 5his confi0ration overrides the
eneral settin for validation.
)). (h& are acco"nt assignments missing from re2"ired entr& fields for some doc"ments from 'hase ; even
tho"gh validation of doc"ment s'litting is active with an error message?Yo0 reset cleared items in phase 1.
6learin doc0ments do not receive the doc0ment splittin characteristics d0rin postin 'eca0se the/ receive the
doc0ment splittin information from the cleared items d0rin the miration. 5his relationship is lost d0e to the clearin
reset. 5he H#d. can enrich the doc0ments, or /o0 can c0stomiIe a clearin relationship for these doc0ments in partic0lar.
5o avoid this sit0ation, we recommend that /o0 do not 0se transaction FHE# 3Eeset 6leared .tems4 d0rin phase 1.
.n addition, if the doc0ment to 'e reversed does not contain this acco0nt assinment, reversal doc0ments will 'e posted
witho0t acco0nt assinments even tho0h doc0ment splittin validation is active.
)+. 7oes doc"ment s"mmari4ation affect doc"ment s'litting?
.f /o0 intend to 0se doc0ment splittin, /o0 m0st consider doc0ment s0mmariIation as critical. Yo0 can never s0mmariIe
fields that /o0 want to 0se in doc0ment splittin 3for e:ample, profit center, sement4 and the relevant partner fields.
Yo0 m0st chec! which other fields /o0 reF0ire for s0'seF0ent doc0ment splittin from phase 1 d0rin the miration. 5he
splittin is 'ased on the data in the ta'le H"@1. 5herefore, /o0 cannot s0mmariIe the relevant fields.
#fter /o0 activate the new 1eneral 2eder 3phase 24, the s/stem 0ses the ta'le #66.5 3and no loner ta'le H"@14 as the
'asis for doc0ment splittin.
@ven if doc0ment splittin is not active, doc0ments from phase 1 are s0'seF0entl/ posted from the ta'le H"@1. Fields
that were s0mmariIed in the classic 1eneral 2eder are also empt/ in the ta'les F#12F2@G#/F#12F2@G5 after the
miration.
)*. If doc"ment s'litting is active% which f"nctions are available for 'rocessing bills of e1change?
.f doc0ment splittin is active, the followin relationship e:ists 'etween doc0ment splittin and 'ill of e:chane
processin:
5he doc0ment splittin provides the acco0nt assinments when creatin the 'ill of e:chane lia'ilit/ for disco0ntin and
collection of the 'ill of e:chane. 5his f0nction is availa'le as of @E$ 2((+ "0pport $ac!ae 1(.
@E$ 2((+ and 2((* do not provide an/ f0nctions for doc0ment splittin of ;'o0nced 'ills of e:chane; 3'ill of e:chane
protest4. 5he new invoice is posted witho0t acco0nt assinments and not 'ased on the inp0t from the oriinal invoice.
# wor!aro0nd with defa0lt acco0nt assinment 3'/ 0ser e:it or s0'stit0tion4 is possi'le for 'o0nced 'ills of e:chane.
#lternativel/, /o0 can enter the oriinal acco0nt assinment man0all/.
)6. 7"ring doc"ment s'litting% what m"st I consider in connection with cross-com'an& 'ostings?
.f /o0 post across compan/ codes, the settins for doc0ment splittin m0st 'e consistent in all pairs of relevant compan/
codes. 5his means that doc0ment splittin m0st 'e either active or inactive in 'oth compan/ codes formin a pair for
cross8compan/ postins.
)7. (h& does transaction F#GL<MIG<*IM<*+L (*im"lation of 7oc"ment *'litting) not behave in the same wa& as
validation of doc"ment s'litting and transaction F#GL<MIG<*+LI, (*"bse2"entl& +ost *'lit Information)?
5ransaction F#12>%.1>".%>"$2 3"im0lation of -oc0ment "plittin4 ta!es into acco0nt onl/ the doc0ment that is
c0rrentl/ 'ein processed, '0t no doc0ment flow. .f the doc0ment 'ein processed is part of a doc0ment flow, transaction
F#12>%.1>".%>"$2 ass0mes that the oriinal doc0ment alread/ has entries in the ta'les that store doc0ment splittin
information.
5he validation of doc0ment splittin and transaction F#12>%.1>"$2.5 3"0'seF0entl/ $ost "plit .nformation4 'oth ta!e
into acco0nt the whole doc0ment flow.
)8. ,ransaction F#GL<C$-C=<LIN-,9+- (Chec3 :"siness ,ransaction for 7oc"ments) shows% for e1am'le%
errors in cross-com'an& code transactions in the doc"ment of the non-leading com'an& code! (hen doc"ment
s'litting information is b"ilt and the doc"ments are migrated% the doc"ment s'litting wor3s correctl& for both
com'an& codes! (h& does transaction F#GL<C$-C=<LIN-,9+- (Chec3 :"siness ,ransaction for 7oc"ments)
not behave li3e the act"al migration?
5ransaction F#12>6L@6D>2.N@5Y$@ is not desined to sim0late a complete '0siness process. 5his means that, for
e:ample, a '0siness process with cross8compan/ code transactions for which the '0siness process involves more than
one doc0ment will not 'e chec!ed correctl/. Nevertheless these doc0ments will 'e mirated correctl/ at a later stae and,
as a res0lt, the doc0ment splittin information will 'e '0ilt correctl/.
5ransaction F#12>6L@6D>2.N@5Y$@ alwa/s performs onl/ a simple chec! to determine if 60stomiIin is correct. 5he
chec! will r0n into an error if the doc0ment that needs to 'e chec!ed represents part of a comple: '0siness transaction.
),. 9o" activated doc"ment s'litting! 9o" 'ost the bill of e1change 'a&ment in transaction F->0! In transaction F-
>0 &o" choose ?Incoming 'a&ment? and enter the c"stomer! In the following screens% &o" enter the amo"nt to be
'aid and select the invoices to be 'aid! (hen 'osting% the s&stem iss"es message GL, /; ?:alancing field
?@;? in line item @ not filled?! (hen 'osting% it is also 'ossible that the doc"ment is 'osted witho"t doc"ment
s'litting! (hat m"st I do to ens"re that the doc"ment for the bill of e1change 'a&ment is s'lit correctl& in
transaction F->0?
5he reason for this error is that /o0 0se a doc0ment t/pe for the 'ill of e:chane pa/ment that is not confi0red accordin
to reF0irements.
For the doc0ment splittin, /o0 m0st process a clearin. Yo0 cannot process clearin from transaction F8)6, therefore the
doc0ment t/pe m0st determine this. 6onfi0re a specific doc0ment t/pe for the 'ill of e:chane pa/ment and 0se
60stomiIin transaction 1"$>?O) to assin this doc0ment t/pe to '0siness transaction 1(1( variant (((1. Use this
doc0ment t/pe in transaction F8)6.
5hen 0se transaction =HU1 to chane the defa0lt doc0ment t/pe for transaction F8)6.
+(. (hat is the relationshi' between doc"ment s'litting and validation?
Yo0 m0st distin0ish 'etween validation 'efore doc0ment splittin and validation after doc0ment splittin. ;Hefore
doc0ment splittin; means that the validation is processed 'efore doc0ment splittin. ;#fter doc0ment splittin; means
that the validation is processed after the doc0ment splittin.
5he p0rpose of validation 'efore doc0ment splittin is to chec! that the prereF0isites for doc0ment splittin are f0lfilled.
For e:ample, the doc0ment t/pe has a central control f0nction for doc0ment splittin in the new 1eneral 2eder.
5herefore it is vital for doc0ment splittin that /o0 0se the correct doc0ment t/pe in each transaction. For e:ample, /o0
can 0se validation 'efore doc0ment splittin for postins of 'ill of e:chane pa/ments 3transaction F8)64 to ma!e s0re
that /o0 0se the doc0ment t/pe which is confi0red for this p0rpose in transaction 1"$>?O). 5o confi0re a validation
'efore doc0ment splittin, 0se transaction =H28.
Yo0 can 0se a validation after doc0ment splittin to chec! the res0lt of the doc0ment splittin. For this p0rpose, /o0 can
0se the H#d. 125(>#F5@E"$2.5>?#2. For additional information, see Note 8+6((+.
+1. In which case does the doc"ment reversal trigger the reversal 'rocess in doc"ment s'litting% and in which
case are the doc"ment s'litting r"les 'rocessed?
5he doc0ment splittin processes the reversal process for F. reversals 3transaction FH(8 and FHU84. .n this case, no
doc0ment splittin r0les are processed. .nstead, the s/stem creates a reversed doc0ment from the acco0nt assinment
information of the doc0ment to 'e reversed. 5he s/stem determines the '0siness transaction variant of the doc0ment to
'e reversed 'eca0se some doc0ment splittin settins depend on the '0siness transaction variant.
Yo0 m0st distin0ish 'etween process8'ased 3passive4 splittin and r0le8'ased 3active4 splittin.
5he s/stem processes the process8'ased splittin in certain clearin processes and similar processes. 5his is triered
either '/ the process itself, for e:ample in transaction FHE# 3Eeset 6leared .tems, which is relevant onl/ in special
p0rpose leders with doc0ment splittin4 or '/ F. reversal 0sin '0siness transaction EFHU or '/ the attri'0tes of sinle
doc0ment line items 3clearin line items, line items 'elonin to an invoice4.
For the F. reversal, the process8'ased splittin is relevant for the entire doc0ment. @ach doc0ment line item ;inherits; the
acco0nt assinments of the relevant line item of the so0rce doc0ment.
.n the classic 1eneral 2eder, the s/stem creates p0re clearin doc0ments for Iero clearin. 5he relevant doc0ments do
not contain line items.
.n the new 1eneral 2eder with active doc0ment splittin, the s/stem does not create an/ Iero clearins. 5he s/stem
alwa/s creates doc0ments with clearin lines.
Lowever, a clearin does not necessaril/ alwa/s have to 'e a Iero clearin. Yo0 can also create a resid0al item or post
differences. .n this case, the process8'ased splittin is relevant onl/ for some lines of the doc0ment.
6oncl0sion: .f there is a r0le8'ased or a process8determined split, it does not alwa/s appl/ to the entire doc0ment 3that is
onl/ in e:ceptional cases4. Us0all/,
onl/ individ0al line items of a doc0ment are affected '/ the process8determined split 8 irrespective of which '0siness
transaction variant is processed.
# r0le8'ased split alwa/s applies to '0siness transactions that have no reference to a doc0ment that is alread/ posted. .n
this case, one e:ample is postin an invoice 0sin an F. transaction. .n addition, the r0le8'ased split is processed '/
'0siness transactions, which can 'e clearin processes or processes similar to clearin this is not necessar/ in ever/
case. .n this case, one e:ample if the reversal '/ %% 0sin %E8%. Eeversals that are not e:ec0ted 0sin '0siness
transaction EFHU process the r0le8'ased split. 5hat is, dependin on the doc0ment t/pe of the doc0ment to 'e reversed,
a reversal doc0ment t/pe is assined in =H#7.
.n transaction 1"$>?O), the s/stem finds the '0siness transaction variant for the reversal doc0ment t/pe of the
doc0ment to 'e reversed. Usin the '0siness transaction variant of this reversal doc0ment t/pe, the 60stomiIin of this
reversal doc0ment t/pe 3defined in 1"$>E-4 is processed d0rin the reversal doc0ment split. Deep in mind: -ependin
on the attri'0tes of each line item, process8'ased 3passive4 splittin ma/ 'e processed for sinle line items in this reversal
as well.
+2. (hat m"st I consider when creating the 4ero balance clearing acco"nt for doc"ment s'litting?
"ee Note ,61,)7.
+). Antil when can I 'ost to the 'revio"s fiscal &ear?
.n this conte:t, the ;previo0s fiscal /ear; refers to the fiscal /ear prior to the miration date.
Yo0 can post to the previo0s fiscal /ear as lon as /o0 have not started the prod0ctive miration.
=nce /o0 have started the prod0ctive miration or mirated an/ o'7ects 3for e:ample, open items4, it is no loner possi'le
to post to the previo0s fiscal /ear.
=nce the new 1eneral 2eder has 'een activated, it is no loner possi'le to post to the fiscal /ear prior to the miration
date either.
5his means that the fiscal /ear clos0re for the previo0s fiscal /ear m0st 'e done in phase 1, that is, 'efore startin the
prod0ctive miration and 'efore oin live. #ll postins to the previo0s fiscal /ear m0st 'e stored 'efore startin the
prod0ctive miration. 5his incl0des postins accordin to the a0ditorNs instr0ctions.
.n man/ cases, /o0 cannot 'e s0re that no postins to the previo0s fiscal /ear will 'e reF0ired 0ntil the fiscal /ear clos0re
has 'een certified.
++. (hat m"st I consider regarding down 'a&ment re2"ests% 'ar3ed doc"ments and held doc"ments?
5he miration proram that mirates the doc0ments from phase 1 processes onl/ F. doc0ments that 0pdate transaction
fi0res to the classic 1eneral 2eder. 5his proram does not process down pa/ment reF0ests, par!ed doc0ments and
noted items.
Yo0 m0st chec! if /o0 have to add val0es for the new fields /o0 have introd0ced with the new 1eneral 2eder 3for
e:ample, f0nctional area, profit center, sement4 in par!ed doc0ments and noted items.
+*. $ow can I transfer 'lanning data from CO-OM (Controlling B Overhead Management) to the new General
Ledger?
$roceed as follows to transfer plannin data from 6=8=% 36ontrollin N =verhead %anaement4 to the new 1eneral
2eder:
First, confi0re 60stomiIin for plannin in the new 1eneral 2eder accordin to the steps in the implementation 0ide.
5hen transfer e:istin plannin data from 6=8=% 3plannin data on cost centers and internal orders4 to the new 1eneral
2eder. 6hoose the followin path in the implementation 0ide:
8K 1eneral 2eder #cco0ntin 3new4
8K $lannin
8K 5ransfer $lannin -ata from 6=8=%
+6. $ow can I transfer 'lanning data from classic +rofit Center #cco"nting (-C-+C#) or from the classic General
Ledger to the new General Ledger?
5o transfer plannin data from classic $rofit 6enter #cco0ntin 3@68$6#4 or from the classic 1eneral 2eder to the new
1eneral 2eder, proceed as follows:
First, confi0re 60stomiIin for plannin in the new 1eneral 2eder accordin to the steps in the implementation 0ide.
No specific f0nctions are availa'le for transferrin plannin data from classic $rofit 6enter #cco0ntin 3@68$6#4 or from
the classic 1eneral 2eder to the new 1eneral 2eder.
5here are two possi'le wor!aro0nds. Yo0 can 0se transaction 1$*2. #lternativel/, /o0 can 0se a roll0p to transfer the
plannin totals to the new 1eneral 2eder. For the latter, /o0 m0st allow roll0p for the new 1eneral 2eder '/ ma!in the
reF0ired chanes directl/ in two c0stomiIin ta'les. Yo0 can implement the second alternative onl/ if /o0 have s0fficient
technical !nowlede.
"ince 'oth alternatives are wor!aro0nds, /o0 m0st perform e:tensive tests.
.f /o0 have not planned locall/ in classic $rofit 6enter #cco0ntin and plannin data was created e:cl0sivel/ in classic
@68$6# as a res0lt of plannin interation with 6=8=%, transfer 6=8=% plannin data to the new 1eneral 2eder
instead of transferrin @68$6# plannin data.
+7. (hat m"st I consider if the real time integration from CO to FI is active and standard C*# (cost of sales
acco"nting) ledger /F is active?
Yo0 m0st distin0ish 'etween phase 1 3from miration date to activation date4 and phase 2 3from activation date
onwards4.
+hase ;C 5he classic 1eneral 2eder is active, the real8time interation 6= 8K F. is active, and the standard 6"# leder
(F is active.
"ince real time interation is active, the reconciliation leder will not create an/ more F. postins in phase 1. .n phase 1,
the F. doc0ments from real8time interation m0st not 'e posted to the classic 1eneral 2eder onl/, '0t also to the leder
(F.
Jhen activatin real8time interation 6= 8K F., /o0 m0st assin activit/ 6=F. to leder (F man0all/ '/ the miration date
at the latest. Use transaction 1622 to assin activit/ 6=F. to leder (F.
+hase C 5he new 1eneral 2eder is active, the real8time interation 6= 8K F. is active, and the standard 6"# leder (F
is active.
.f /o0 want to contin0e 0sin the standard 6"# leder (F in parallel to the active new 1eneral 2eder, consider the
followin:
"ince real time interation is active, the reconciliation leder will not create an/ more F. postins. 5he F. doc0ments from
real8time interation m0st not 'e posted to classic 1eneral 2eder onl/, '0t also to the leder (F.
Jhen activatin real8time interation 6= 8K F., /o0 m0st assin activit/ 6=F. to leder (F man0all/. Use transaction
1622 to assin activit/ 6=F. to leder (F.
.f the 60stomiIin settins for the variant for real8time interation specif/ that the real8time interation doc0ments are
posted with a leder ro0p, /o0 m0st 0se transaction 1622 to fill the ;Eeference 2eder; field in leder (F with the
leadin leder of the new 1eneral 2eder 3for e:ample, (24. 2eder (F will then 'e 0pdated onl/ with F. doc0ments that
were posted to the relevant leder of the new 1eneral 2eder 3for e:ample (24.
+8. In the variant for real time integration CO -D FI% enter the ?=e& 7ateC #ctive from? and activate the indicator
?8!-,ime IntegC#ctive?! ,his activates real-time integration CO -D FI beginning on the s'ecified date! (hich 'oint
in time is recommended for activating the real-time integration CO -D FI?
# 'asic recommendation is to activate real8time interation 6= 8K F. either 'efore or after activatin the new 1eneral
2eder. 5his approach red0ces the n0m'er of activities related to the activation of the new 1eneral 2eder d0rin the
downtime.
.f /o0 want to anal/Ie cost elements in the new 1eneral 2eder we recommend that /o0 activate real8time interation 6=
8K F. after activatin of the new 1eneral 2eder. 5he reason is that the ;6ost element; field in the miration is filled onl/
for doc0ments created in the classic 1eneral 2eder '/ real time interation 3see "#$ Note 1()17(6 and 1()62+84.
"ee also Note 1(287+). Eeasona'le points in time for activatin real8time interation 6= 8K F. are, for e:ample, the
'einnin of the period, the F0arter or the fiscal /ear that follows the activation of the new 1eneral 2eder.
.f /o0 do not want to anal/Ie cost elements in the new 1eneral 2eder we recommend that /o0 activate real8time
interation 6= 8K F. after on the miration date 3where the !e/ date is the miration date4. .n this case, 60stomiIin of
real8time interation m0st 'e availa'le in the prod0ctive s/stem at the latest on the last da/ of the old fiscal /ear.
5he activation of real8time interation 6= 8K F. on the miration date represents a clear separation: .n the old fiscal /ear,
/o0 0se the reconciliation leder for reportin and F. postins. .n the new fiscal /ear, /o0 0se the new 1eneral 2eder for
reportin and real8time interation creates the F. postins.
#nother advantae of this approach is that /o0 do not have to perform s0'seF0ent postin 0sin report
F#12>6=F.>5E#N"F@E>6=-=6".
+,. $ow can I 'ost cross-'rofit center% CO-internal allocations to FI?
.n the variant for real time interation 6= 8K F., activate the indicator ;6ross8$rofit86enter;. 5he same applies if /o0 want
to post 6=8internal allocations to F. that ca0se a chane in compan/ code, '0siness area, f0nctional area, sement or
rant.
*(. ,he migration 'rogram "sed to transfer doc"ments from 'hase ; 'rocesses onl& FI doc"ments! It does not
'rocess internal CO doc"ments (for e1am'le% from assessments) that were created in 'hase ;! 9o" re2"ire these
doc"ments in the new General Ledger% for e1am'le% beca"se &o" want to re'lace classic +rofit Center
#cco"nting with the new General Ledger or beca"se &o" eval"ate cost elements in the new General Ledger! $ow
can I migrate internal CO doc"ments from 'hase ; to the new General Ledger?
#fter activatin the ;Eeal8time interation 6= 8K F.;, /o0 can 0se the proram ;5ransfer 6= -oc0ments into @:ternal
#cco0ntin; 3F#12>6=F.>5E#N"F@E>6=-=6"4. 5his proram finds all 6= doc0ments with a postin date 3HU-#54
that is later than the ;De/ -ate: #ctive from; date in the variant for real time interation 6= 8K F. and that have not 'een
posted in real8time mode from 6= into F..
Yo0 ma/ have to reopen closed periods for this activit/.

*1. ,he migration 'rogram "sed to transfer doc"ments from 'hase ; 'rocesses onl& FI doc"ments! It does not
'rocess internal -C-+C# doc"ments (for e1am'le% from distrib"tions) that were created in 'hase ;! $ow can I
migrate internal -C-+C# doc"ments (for e1am'le% from distrib"tions) from 'hase ; to the new General Ledger?
.t is not possi'le to mirate internal @68$6# doc0ments from phase 1 to the new 1eneral 2eder. .f the internal @68$6#
doc0ments res0lt from allocations 3for e:ample, from distri'0tions4, /o0 can create new c/cles in the new 1eneral 2eder
and rer0n the c/cles in the new 1eneral 2eder s0'seF0entl/ for the periods of phase 1.
*2. Note EF/.;G describes the derivation of the f"nctional area!
(hen the new General Ledger is active% can I still "se the old f"nctional area derivation for event ///. (filled after
the doc"ment entr& view) instead of "sing event ///0?
Yo0 can contin0e to 0se the old derivation of f0nctional area accordin to event (((*. 5here is a switch in 60stomiIin
that ma!es it possi'le to 0se event (((* in the new 1eneral 2eder.
6hoose the followin path in the implementation 0ide: Financial #cco0ntin 3New4 8K Financial #cco0ntin Hasic
"ettins 3New4 8K 5ools 8K 60stomer @nhancements 8K @nhance -etermination of F0nctional #rea
.n this 60stomiIin transaction, deactivate the indicator ;-etermine F#rea on @ntr/ "creen;. For detailed information, see
the field help 3F14 for this field.
*). (hat m"st I consider in mod"le CO (Controlling) regarding f"nctional area and segment?
For information, see Notes 76++8* and ,8118+.
*+. $ow can I "'date the f"nctional area and segment in CO totals records?
5o activate the 0pdate of the f0nctional area and sement in the 6= totals ta'les, perform the followin step in the
implementation 0ide:
@66 *.(: 6ontrollin 8K 1eneral 6ontrollin 8K .ncl0de 6haracteristics in 6= 5otals Eecords
@66 6.(: 6ontrollin 8K 1eneral 6ontrollin 8K .ncl0de 6haracteristics in 6= 5otals Eecords
For more information, see Note 76++8*.
**. (hich entries are re2"ired in the 'rod"ctive client in the table ,HG;/?
5he ta'le 5811( 'elons to deliver/ class 6 360stomiIin4. For this reason, d0rin the 0prade to "#$ @E$, new entries
are inserted onl/ in client ((( in ta'le 5811(. #fter the 0prade, transport the followin entries of the ta'le 5811( from
client ((( to /o0r prod0ctive client:
56=-@ $E=6@"" ?#E.#N5
FH1- 1(1( (((1
FH1D 1(1( (((1
FH1" 1(1( (((1
FHE# 1(2( (((1
*6. In the first r"n of the 'rogram F#GL<MIG<8+I,-M*<C8-*+LI, (:"ild 7oc"ment *'litting Information for
7oc"ments ,o :e ,ransferred)% the s&stem ma& not 'rocess all doc"ments s"ccessf"ll&! (hat can I do?
5his iss0e is most li!el/ to occ0r if /o0 have cross8compan/ code postins. =ne reason can 'e the wa/ the proram
internall/ sorts and processes the doc0ments.
5o resolve the pro'lem, simpl/ start the proram F#12>%.1>E$.5@%">6E@"$2.5 3H0ild -oc0ment "plittin
.nformation for -oc0ments 5o He 5ransferred4 aain.
*7. (hat m"st I consider in a mass r"n of the 'rogram F#GL<MIG<FIC$#N (*"''lement FI 7oc"mentsC Create
(or3list) with regard to r"ntime and 'erformance?
5he r0ntime of the proram F#12>%.1>F.6L#N ma/ 'e ver/ lon if a lare amo0nt of doc0ments m0st 'e processed.
5his is d0e to the technical characteristics of spool administration.
For instance: .n one proram r0n, /o0 want to process 1((,((( doc0ments with 1,(((,((( lines in the ta'le H"@1. Yo0
start the proram F#12>%.1>F.6L#N in the 'ac!ro0nd. 5he proram first processes the doc0ment line items. 5he
proram then prepares the spool list. 5he proram tries to save a list with 1,(((,((( lines in the spool. 5he attempt to
save the list ma/ ta!e ver/ lon. For one c0stomer, the processin of ),(((,((( doc0ment line items too! three ho0rs,
while the creation of the spool reF0est was not /et finished after three da/s.
"ol0tions:
8 @:ec0te the proram for onl/ a few doc0ments at a time. Yo0 can adapt the data vol0me '/ enterin intervals for the
doc0ment n0m'ers in the selection screen.
8 Jhen processin a hih vol0me of doc0ments, choose ;-ispla/ @rrors =nl/; in the selection screen.
*8. $ow can I im'rove the 'erformance of the 'rogram F#GL<MIG<*A:*-I<+O*, (A'date 7oc"ments to New
General Ledger #cco"nting)?
5o improve the performance of the proram F#12>%.1>"UH"@9>$="5 3Update -oc0ments to New 1eneral 2eder
#cco0ntin4, perform the followin steps:
a4 Update data'ase statistics for the ta'le F#12F2@G#.
Hefore the miration, the ta'le F#12F2@G# is empt/. 5he seF0ential processin of the proram steps rad0all/ fills the
ta'le F#12F2@G# with data. Jhen transferrin doc0ments from the c0rrent /ear to the new 1eneral 2eder, the proram
F#12>%.1>"UH"@9>$="5 whether each doc0ment e:ists in the ta'le F#12F2@G#. Lowever, d0rin the miration, the
6ost8Hased =ptimiIer 36H=4 does not /et have the reF0ired information to select the riht inde: for accessin the
data'ase ta'les.
5o solve the pro'lem, proceed as follows: #s soon as /o0 have mirated some data to the new 1eneral 2eder ta'les 3for
e:ample, after miratin open items and 'efore miratin doc0ments from the c0rrent /ear4, /o0 sho0ld r0n the 6H= or
0pdate ta'le statistics.
5he prorams sho0ld then 0se the correct inde: for the data'ase access and this sho0ld considera'l/ red0ce the r0ntime.
.n more detail, proceed as follows: #ctivate the trace in transaction "5(*. "tart the proram
F#12>%.1>"UH"@9>$="5, for e:ample, for one doc0ment. -eactivate the trace and displa/ the trace.
$osition the c0rsor on ;F#12F2@G#; and choose ;@:plain;. Yo0 can see when statistics were created for the last time
and which inde: is 'ein 0sed. Yo0 can also start the 0pdate of the statistics from here.
'4 ;@:ec0te with $ara.$roc.; in the selection screen of proram F#12>%.1>"UH"@9>$="5
Je recommend that /o0 activate ;@:ec0te with $ara.$roc.; in the selection screen of the proram
F#12>%.1>"UH"@9>$="5, to red0ce the r0ntime.
Jhen /o0 activate ;@:ec0te with $ara.$roc.;, /o0 m0st set two E/) parameters as follows:
rdisp/'0frefmode sendon,e:ea0to
rdisp/'0freftime set this parameter to the lowest possi'le val0e
For more information, see Notes )8+167 and )628) as well as the related.
.f /o0 set the E/) parameters accordinl/, /o0 will avoid error messae 1. 7*+ d0rin parallel processin of the proram
F#12>%.1>"UH"@9>$="5.
*,. ,he 'rogram F#GL<MIG<O+I,-M*<C8-*+LI, generates the doc"ment s'litting information for o'en items!
Is it 'ossible to 'aralleli4e the 'rogram F#GL<MIG<O+I,-M*<C8-*+LI,?
.t is not possi'le to r0n the proram F#12>%.1>=$.5@%">6E@"$2.5 more than once at a time. 5his applies even if the
selection refers to different miration plans.
.f /o0 tr/ to start the proram F#12>%.1>=$.5@%">6E@"$2.5 for a second time in parallel mode, the s/stem iss0es
messae %6 6(1 ;='7ect reF0ested is c0rrentl/ loc!ed '/ 0ser P; . .
5his is d0e to the desin of the proram and the desin of the miration.
6(. ,he 'rogram F#GL<MIG<8+I,-M*<C8-*+LI, generates the doc"ment s'litting information for doc"ments of
the c"rrent &ear! Is it 'ossible to 'aralleli4e the 'rogram F#GL<MIG<8+I,-M*<C8-*+LI,?
.t is not possi'le to r0n the proram F#12>%.1>E$.5@%">6E@"$2.5 more than once at a time. 5his applies even if the
selection refers to different miration plans.
5he proram sets a 2=6D on some of the data'ase ta'les for the miration. 5his is to ens0re the consistenc/ of the
miration.
61. (hat m"st I consider regarding the database before the 'rod"ctive migration?
5here are two ma7or aspects. First, perform a f0ll 'ac!0p 'efore the prod0ctive miration is started. "econd, deactivate
data'ase loin 'efore startin the prod0ctive miration.
62. (hat can I do in order to minimi4e the downtime for 'rod"ctive migration?
$rereF0isites for 'einnin the prod0ctive miration are that the fiscal /ear clos0re for the previo0s fiscal /ear has 'een
finaliIed and approved '/ /o0r a0ditor, that there is no f0rther need for postins to the previo0s fiscal /ear and that the
new 1eneral 2eder is finall/ confi0red.
5he incremental approach minimiIes the downtime reF0ired for the prod0ctive miration. 5he cornerstone of the
incremental approach is to mirate most of the data whilst the s/stem is 0p and r0nnin.
.n detail, in the incremental approach means that /o0 mirate 'alances and open items in a first wave 'efore the
downtime while the E/) s/stem is r0nnin as normal. .n a second wave, /o0 mirate doc0ments of the c0rrent fiscal /ear 8
also while the s/stem r0ns normall/. -0rin the downtime, mirate the remainin doc0ments of the c0rrent fiscal in a third
wave.
.n the first wave, /o0 can transfer 'alances and open items d0rin phase 1 witho0t an/ s/stem downtime in parallel to
normal prod0ction operation. .f the miration of 'alances and open items fails, /o0 can reset the miration d0rin
prod0ction operation 0sin transaction F#12>%.1>E@"5=E@>#22.
.n a second wave, /o0 mirate doc0ments of the c0rrent fiscal /ear to the new 1eneral 2eder d0rin normal operation.
Yo0 can start the second wave, for e:ample, two wee!s 'efore the downtime. E0n the prorams ;6reate Jor!list for
-oc0ments; 3F#12>%.1>E$.5@%">F.224, ;H0ild -oc0ment "plittin .nformation for -oc0ments 5o He 5ransferred;
3F#12>%.1>E$.5@%">6E@"$2.54 and ;Update -oc0ments to New 1eneral 2eder #cco0ntin;
3F#12>%.1>"UH"@9>$="54.
#fter this initial miration of doc0ments from the c0rrent /ear, /o0 can repeat this process ever/ da/ '/ sched0lin
rec0rrin 7o's 3for e:ample once a da/ at niht time4.
@ach time /o0 r0n the prorams, the doc0ments that have 'een posted since the last proram r0n are mirated to the
new 1eneral 2eder. #fter the initial miration of doc0ments from the c0rrent /ear, alwa/s set the ;Eead 6ompletel/;
indicator in the selection screen of the proram ;6reate Jor!list for -oc0ments; 3F#12>%.1>E$.5@%">F.224.
.n the third wave d0rin the downtime, the s/stem mirates the remainin doc0ments from the c0rrent /ear that were
posted since the second wave. -0rin the s/stem downtime, create a last wor!list for doc0ments of the c0rrent /ear and,
for the last time, r0n the proram that enerates the doc0ment splittin information. 5hen transfer the remainin
doc0ments from the c0rrent fiscal /ear. 5o do this, once aain r0n the prorams ;6reate Jor!list for -oc0ments;
3F#12>%.1>E$.5@%">F.224, ;-oc0ment "plittin .nformation for -oc0ments 5o He 5ransferred;
3F#12>%.1>E$.5@%">6E@"$2.54 and ;Update -oc0ments to New 1eneral 2eder #cco0ntin;
3F#12>%.1>"UH"@9>$="54.
.n the third wave, consider the followin two aspects: First, set the ;Eead 6ompletel/; indicator in the selection screen of
the proram ;6reate Jor!list for -oc0ments; 3F#12>%.1>E$.5@%">F.224. "econd, deselect the indicator ;@:ec0te with
$ara. $roc.; in the selection screen of the proram ;Update -oc0ments to New 1eneral 2eder #cco0ntin;
3F#12>%.1>"UH"@9>$="54.
#fter s0ccessf0ll/ reconcilin the data of the classic 1eneral 2eder and the new 1eneral 2eder, activate the new
1eneral 2eder d0rin the downtime.
5o s0mmariIe, the incremental approach means that onl/ the activities for the third wave are performed d0rin the
downtime. @ver/thin else can 'e done 'efore the downtime d0rin normal E/) operation.
6). $ow can I deactivate classic +rofit Center #cco"nting (-C-+C#) after activating the new General Ledger?
Note 7(28*+ e:plains how to deactivate classic $rofit 6enter #cco0ntin.
.f /o0 0se doc0ment splittin for profit centers in @E$2((+, delete the d0mm/ profit center from the ta'le 5D#(1 also. For
this p0rpose, Note 7(28*+ provides the proram O)($6#2). Use the proram O)($6#2) to delete the d0mm/ profit
center of classic $rofit 6enter #cco0ntin in the controllin area.
6+. ,he tables that are re2"ired for the migration (tables F#GL<MIGJ) ta3e "' a lot of dis3 s'ace (for e1am'le% >./
M:)! Can I delete the tables F#GL<MIGJ after the 'rod"ctive migration?
No. 5he content of the ta'les F#12>%.1C m0st remain in the data'ase. 5he data from the ta'les F#12>%.1C is reF0ired
for controls and chec!s and to verif/ the miration.
6*. Is it 'ossible to change C"stomi4ing of the new General Ledger if the new General Ledger has been "sed
'rod"ctivel&?
"ee Note 8,11++.
66. Can I contin"e to "se the re'orts 8FIN7-5 and *#+F;G/ (from the classic General Ledger) to reconcile
doc"ments B transaction fig"res B inde1es in the new General Ledger?
.n the new 1eneral 2eder, 0se report 5F6>6=%$#E@>?O 3transaction F#12F()4 to reconcile totals records 35 ta'les,
s0ch as ta'le F#12F2@G54, line items 3# ta'les, s0ch as ta'le F#12F2@G#4, secondar/ inde:es 3s0ch as ta'les H"."
and H"#"4, and F. doc0ments 3ta'les HD$F and H"@1/H"@1>#--4. Eefer also to the report doc0mentation and Notes
862*2) and ,+6*,6.
67. ,he classic General Ledger contains the re'orts 8##:*,/; and 8##:*,/ to reconcile the general ledger
and #sset #cco"nting (FI-##)! (hich re'orts are available to reconcile the new General Ledger and #sset
#cco"nting (FI-##)?
Yo0 can 0se report E##H"5(1 to reconcile the new 1eneral 2eder and #sset #cco0ntin. #s a prereF0isite /o0 reF0ire
@66 *.( "0pport $ac!ae (1 or Note 7*2)2,.
Yo0 can 0se report E##H"5(2 to reconcile the new 1eneral 2eder and #sset #cco0ntin. #s a prereF0isite /o0 reF0ire
@66 *.( "0pport $ac!ae (1 or @66 6.( "0pport $ac!ae 7. .t is not possi'le to downrade this f0nction. "ee Note
8,7)88.
5he reconciliation of the new 1eneral 2eder and #sset #cco0ntin at a level 'elow compan/ code and acco0nt 3for
e:ample, profit center or sement4 is c0rrentl/ not s0pported.
For eneral information a'o0t reconcilin of the eneral leder and #sset #cco0ntin 3F.8##4, see Note *+)1*1.
68. CO-FI real-time integration and the new General Ledger are active! $ow can I reconcile data in the new
General Ledger with data in Controlling (CO)?
Use transaction F#126=E6 for the reconciliation. For f0rther information, see Note ,(8(1,.
6,. In the new General Ledger% line items do not match the relevant totals records% or the totals records are not
"'dated correctl&! (hich tool is available to anal&4e these inconsistencies?
"ee Note ,+(668.
7(. (hat m"st I consider for allocations for balance sheet acco"nts and reconciliation acco"nts in the new
General Ledger?
For information, see Notes 8)(**6 and ,((,62.
71. (hich re'ort in new General Ledger acco"nting has the same feat"res as the re'ort 8CO+C#/ (+rofit
CenterC #ct"al Line Items) in classic +rofit Center #cco"nting?
5ransaction F#122() in new 1eneral 2eder acco0ntin has the same feat0res as the report E6=$6#(2 3$rofit 6enter:
#ct0al 2ine .tems4 or transaction D@*O in classic $rofit 6enter #cco0ntin.
72. Is it 'ossible to select c"stomer-s'ecific fields in the line item dis'la& of the new General Ledger (transaction
F#GLL/>)?
Note ,+*,)2 e:plains how to select c0stomer8specific fields in the line item displa/ of the new 1eneral 2eder
3transaction F#122()4.
7). Is it 'ossible to dis'la&% sort and s"mmari4e c"stomer-s'ecific fields in the line item dis'la& (transaction
F#GLL/>) in the new General Ledger?
"ee Note ,8+)(*.
7+. $ow can I dis'la& the offsetting acco"nt in the line item dis'la&?
"#$ Note 112)12 descri'es how /o0 can displa/ the offsettin acco0nt in the line item displa/ in the classic 1eneral
2eder.
"#$ Note 1()+)*+ descri'es how /o0 can displa/ the offsettin acco0nt in the line item displa/ in the new 1eneral
2eder.
7*. (h& is the ?#lternative #cco"nt N"mber? field not dis'la&ed in re'orting of the new General Ledger?
5o displa/ the ;#lternative #cco0nt N0m'er; field in report of the new 1eneral 2eder, please proceed as follows:
14 .mplement Note 8,*6(, and ,),6+,.
24 5o displa/ N#lternative #cco0nt N0m'erN in the line la/o0t variant, proceed as follows:
8 6all transaction =7E) and add H"@182=DD5 as special field.
8 5hen chane the line la/o0t variant. 5he s/stem now displa/s the ;#lternative #cco0nt N0m'er; field.
)4 .n the line item displa/ in the classic 1eneral 2eder 3transaction FH2)N4, /o0 co0ld enhance the c0stom selections in
transaction "@)6 as descri'ed in Note )1(886. Lowever, in the new 1eneral 2eder, the c0stom selection in transaction
F#122() has different s0'8areas. @ach of these areas corresponds to a str0ct0re:
1/2 acco0nt master record "D#1>F"
1/2 acco0nt compan/ code "DH1>F"
1/2 acco0nt line item H".">F"
"ince the ;#lternative #cco0nt N0m'er; is not incl0ded in the str0ct0re "DH1>F" in the standard deliver/, please
implement the enhancement as descri'ed in Note ,+*,)2. 5o incl0de more fields in the c0stom selections of transaction
F#122(), /o0 can enhance the str0ct0res 0sin an #$$@N-.
76. *egment reorgani4ation is the term for the o'tion of changing the segment in a 'rofit center when transaction
data is alread& stored! Is it 'ossible to change the segment in a 'rofit center when transaction data is alread&
stored?
No. Note ,+(721 descri'es the c0rrent stat0s in the standard E/) s/stem.
.n the c0rrent "#$ release plannin, we have not incl0ded an/ f0nctions for sement reoraniIation for f0t0re E/)
releases. .t is not possi'le to sa/ whether or when "#$ will offer f0nctions for sement reoraniIation in the E/) standard
s/stem.
5he feasi'le approach for sement reoraniIation will 'e a c0stomer specific sol0tion.
.n the short term, /o0 can 0se the followin approach, which considers onl/ a technical sol0tion. -eimplement notes
,+(++(, 1()7,86 and ,+(62, from /o0r s/stem. #fter this, define the ;"ement; field as a time8'ased field in transaction
(D@7. 5hen /o0 can chane the sement in the profit center master data even if transaction data e:ists.
5a!e into acco0nt that this sol0tion does not 0arantee data interit/. For e:ample, /o0 m0st also
man0all/ repost the profit center 'alances from the old sement to the new sement.

77. ,he new General Ledger is active! ,he ?+rofit Center A'date? scenario is assigned to the ledger! Cost centers
are stored in the asset acco"nt master data! 9o" change the 'rofit center in a cost center that is "sed in the asset
acco"nt master data! $ow are the relevant balances for each 'rofit center (for e1am'le% for ac2"isition and
'rod"ction costs) re'osted in the new General Ledger?
5here is no a0tomatic process that chanes 'alances for each profit center in the new 1eneral 2eder after the profit
center has 'een chaned in a cost center that is 0sed in asset master records. #s a wor!aro0nd, /o0 can perform a
man0al correction postin.
$roceed as follows:
14 .dentif/ the val0es that /o0 m0st repost. For this p0rpose, /o0 can 0se the report E#H@"5(1. Fill the field ;6ost center;
in the selection screen of the report E#H@"5(1 with the cost center that has 'een assined to a different profit center.
24 "et the stat0s to ;1; in the compan/ codes that reF0ire ad70stment postins. 5o do so, 0se the followin path in the
implementation 0ide:
Financial #cco0ntin 8K #sset #cco0ntin 8K $reparin for $rod0ction "tart0p 8K $rod0ction "tart0p 8K #ctivate 6ompan/
6ode.
)4 Use transaction =#"? to perform ad70stment postins to de'it or credit the profit center on reconciliation acco0nts in
asset acco0ntin.
+4 #fterwards, reset the stat0s of the compan/ codes to ;(;.
78. (hat is the migration coc3'it?
5he miration coc!pit is the miration tool recommended '/ "#$. 5he miration coc!pit incl0des miration pac!aes that
are preconfi0red to some e:tent. Yo0 can load these pac!aes for the miration from the classic 1eneral 2eder to the
new 1eneral 2eder.
-ependin on the miration scenario, /o0 can load the reF0ired miration pac!ae, which incl0des the miration steps in
the form of a process tree.
Note 1(+1(66 provides instr0ctions for installin the miration coc!pit.
7,. (here can I find information abo"t the *#+ Migration *ervice?
"ee Note 812,1,.
8(. (hen the new General Ledger is active% wh& do doc"ments e1ist which have a data entr& view b"t no general
ledger view in the FI doc"ment dis'la& (transaction F:/>)?
From the postin data for the fiscal /ears prior to the miration date, onl/ open items and 'alances are mirated to the
new 1eneral 2eder. F. doc0ments with a postin date prior to the miration date are not mirated to the new 1eneral
2eder. 5herefore, no eneral leder view is created for these doc0ments.
.t is correct s/stem 'ehavior for F. doc0ments with a postin date prior to the miration date to have a data entr/ view '0t
no eneral leder view in the F. doc0ment displa/ 3transaction FH()4.
81. (hat m"st I consider for the c"rrenc& settings for the new General Ledger?
#s 'efore, the leadin leder 0s0all/ manaes the doc0ment c0rrenc/ and the first local c0rrenc/. 5here is also the option
of manain two additional, parallel c0rrencies. Non8leadin leders can manae onl/ 3a selection of4 the c0rrencies that
are defined for the leadin leder.
Jhen replacin the classic $rofit 6enter #cco0ntin, chec! that the previo0s profit center acco0ntin c0rrenc/ is
manaed as the local c0rrenc/ or parallel c0rrenc/ in F. since 'efore the miration date. .f this is not the case, see Note
),,1, for information a'o0t s0'seF0entl/ implementin a parallel c0rrenc/ in F.. Yo0 cannot perform the reF0ired data
enrichment for phase ( and phase 1 immediatel/ 'efore or d0rin the miration.
82. 7o &o" re2"ire a Anicode s&stem for *#+ General Ledger Migration?
No, a Unicode s/stem is not reF0ired.
8). Is there a migration scenario that re'resents 'arallel acco"nting "sing non-leading ledgers?
Usin miration scenarios + and *, miration can ta!e place from the acco0nts approach to the non8leadin leder
approach in the conte:t of parallel acco0ntin.
Lowever, the new implementation of parallel acco0ntin is not intertwined with the miration and 'asicall/ represents a
pro7ect of its own. Yo0 can interate this into the miration pro7ect, '0t is not, however, part of the "#$ 1eneral 2eder
%iration "ervice. #ll aspects for the implementation of parallel acco0ntin, relatin also to interation into the miration
pro7ect, m0st 'e covered '/ additional cons0ltation.
8+. #re there recommendations for when the doc"ment s'litting sho"ld be introd"ced?
Us0all/, the splittin is worthwhile if the c0stomer wants to 0se Financial statement and $rofit and 2oss "tatement 3fields4
in an additional entit/. .n the new 1eneral 2eder, this is alwa/s possi'le for the profit center and the sement.
.nd0stries in partic0lar reF0ire separate entities for reportin p0rposes. $65E and "ement are predefined standard
fields. Yo0 can incl0de additional fields in the ta'les 0sin a standard mechanism 3transaction F#12>1.N"4.
8*. Is there an&thing to bear in mind d"ring the migration if doc"ment s'litting is to be "sed?
.f /o0 want to 0se the doc0ment splittin 3immediatel/4 after miration from the classic 1eneral 2eder to the new 1eneral
2eder, 3onl/4 miration scenarios ) and * are availa'le for this. Hoth of these miration scenarios 3or ;miration
pac!aes;4 are alread/ 'ased on active doc0ment splittin within the miration from classic to new 1eneral 2eder
#cco0ntin.
Ca"tionC#s of 2((8, miration pac!ae 6 3QK "0'seF0ent implementation of doc0ment splittin4 also provides the option
of activatin the doc0ment splittin s0'seF0entl/, if the new 1eneral 2eder is active witho0t doc0ment splittin.
%ore information a'o0t all delivered miration scenarios or miration pac!aes is availa'le on "#$ "ervice %ar!etplace
0nder: www.service.sap.com/12%.1, for e:ample, in the $-F file ;=verview $resentation: "#$ 1eneral 2eder
%iration;.
86. $ow is the r"ntime affected when &o" "se the doc"ment s'litting? (hat has been e1'erienced?
5here is c0rrentl/ no research on this s0'7ect relatin to what c0stomers have e:perienced. Lowever, there are iss0es
and concerns from time to time. .n ,,R of cases, these are 0nfo0nded. Eefer to the followin notes for additional
information:
82(+,* New12: -ata vol0me, performance and parallel leders
1(+*+)( 6alc0lation of the n0m'er of totals records
Usin 'oth notes, /o0 sho0ld et an assessment of how the c0stomer s/stems are performin 0nder the iven
circ0mstances.
87. 9o" are alread& "sing classic +rofit Center #cco"nting and want to introd"ce s"bse2"ent segments! Can
&o" "se 'rofit center mass maintenance for initial assignment of the 'rofit center to segments% or to change
assignments for 'rofit centers not 'osted to &et?
Note 11(1*61 manaes the chane options for the sement in profit center mass maintenance 3transaction D@**4 in the
same wa/ as in profit center individ0al maintenance 3transaction D@*24 0sin the view ?>F#12>"@1%>$E65. .f new
1eneral 2eder #cco0ntin is not /et active in /o0r s/stem, the %aintain "ement indicator m0st also 'e set in the view
?>F#12>"@1%>6U"5 so that /o0 can maintain the assinments.
5he difference to D@*2 is that the chec! for e:istence of transaction data 3which ma/ 'e ver/ time8cons0min4 in mass
maintenance cannot ta!e place 0ntil /o0 save. .t is not a pro'lem if the sement was initial 'eforehand, in other words,
the profit center was not assined to an/ sement. .f a sement was assined 'efore, the chane ma/ 'e ABre7ectedAB 3with
the relevant error messae4. .n mass maintenance, it is not possi'le to perform prior chec!s and then set the sement
field for a profit center to 6an 'e chaned, and set to 6annot 'e chaned for the ne:t one.
88. Migration and the (-h+>) KLclearing s'ecific to ledger gro"'sKL f"nction! (hat m"st I ta3e into acco"nt?
#s of @h$) 3"#$ @E$ 6.(4, the clearin specific to leder ro0ps f0nction will 'e availa'le when /o0 0se the new eneral
leder.
5he followin aplies to the miration from the classical to the new eneral leder: .t is not technicall/ possi'le for /o0 to
convert the acco0nt master records to ABclearin specific to leder ro0psAB 'efore or d0rin the miration, that is, /o0
cannot implement this toether with the miration.
5herefore, /o0 m0st convert the acco0nt master records in a separate step after the miration with an active new 1/2.
5his separate step is not part of the "#$ 1eneral 2eder %iration service.
5his f0nction is also not ta!en into acco0nt in the miration coc!pit for mirations within the new 1eneral 2eder
#cco0ntin where @h$) is also in 0se.
.f /o0 are an @h$) c0stomer and /o0 are plannin a miration 0sin the "#$ 1eneral 2eder %iration service, inform
the 1eneral 2eder %iration Hac! =ffice
8,. $ow or where do &o" install the migration coc3'it in the s&stem (NMI<CON, #dd-On)?
Note the followin relevant points:
14 .nstall the coc!pit in all of the s/stems in which the miration is to occ0r.
24 5he N%.>6=N5 add8on is an official "#$ add8on and is handled as s0ch. 5he wa/ in which the c0stomer performs the
installation depends mainl/ on c0stomer8specific internal processes.
)4 "ee Notes ,762( and ,7621 for eneral information a'o0t installin add8ons 356ode "#.N54 and "0pport $ac!aes
356ode "$#%4.
+4 Yo0 m0st attend 6o0rse #6212 for detailed information a'o0t handlin the coc!pit.
.f /o0 enco0nter technical pro'lems, contact "0pport. .f /o0 have other, eneral F0estions a'o0t installation and
distri'0tion within the s/stem landscape, contact Eemote 6ons0ltin.
,(. If &o" want to carr& o"t com'arative re'orting after the migration% how do &o" transfer the totals records of
the 'revio"s fiscal &ear from classical General Ledger #cco"nting% the classical +rofit Center #cco"nting% or
from an *L ledger to new General Ledger #cco"nting?
"ee Note 8,)2(6 for information a'o0t cross8fiscal /ear reportin.
,1. (hich doc"ments are transferred to new General Ledger #cco"nting?
5he content of the wor!list is 0sed to constr0ct the new totals ta'les 3F#12F2@G54 and the line item ta'les 3F#12F2@G#4
from the doc0ments of the c0rrent fiscal /ear for all 1/2 acco0nts '/ period. .n the simplest case, /o0 merel/ enter a
miration plan that contains the compan/ codes to 'e mirated.
=nl/ open items are transferred from the previo0s fiscal /ears.
,2. (hat o'tions does *#+ offer for ma''ing 'arallel acco"nting and which o'tions are s"''orted b& standard
migration scenarios?
5he followin sol0tions/options are availa'le for mappin parallel acco0ntin in an "#$ s/stem:
14 #cco0nt sol0tion
QK possi'le in the classic 1eneral 2eder and the new 1eneral 2eder.
24 2eder approach in F.8"2 3"pecial $0rpose 2eders 3of the component F.8"24 are 0pdated '/ assinin acco0ntin
principles4
QK possi'le 3onl/4 with the classic 1eneral 2eder
)4 6ompan/ code sol0tion
QK possi'le onl/ in the classic 1eneral 2eder
+4 2eder approach in the new 1eneral 2eder
QK possi'le onl/ in the new 1eneral 2eder
*4 "pecial c0stomer sol0tion
"tandard miration scenarios s0pport onl/ 3contin0ation of4 the acco0nts approach or the replacement of the acco0nts
approach '/ the leder approach in the new 1eneral 2eder.
.f /o0 0se mappin options 2, ) or * in the classic 1eneral 2eder, and /o0 want to switch to the acco0nt approach or
leder approach within the miration, this is alwa/s a c0stomer specific miration. 5hat is, this t/pe of miration cannot 'e
mapped completel/ with an/ of the availa'le standard scenarios. %irations s0ch as this are often e:ec0ted as c0stomer8
specific pro7ects 'ased on scenario 2 or ). Jhether or not this is possi'le, or whether other alternatives e:ist, varies from
c0stomer to c0stomer.
.t is not possi'le to contin0e to 0se or to implement options 2, ) or * in a miration to the new 1eneral 2eder.
,). (h& can I not s'ecif& a ta1 code in transaction F:/;L (ledger-s'ecific 'osting) even tho"gh the acco"nt is
ta1-relevant?
Je are not aware of an/ '0siness transactions in which leder8specific postins reF0ire a ta: !e/. 5herefore, this field
does not e:ist and is also not chec!ed 0nli!e in transaction FH(1. "ales ta:8relevant postins are alwa/s posted in all
leders.
5his ma/ res0lt in certain inconsistencies 'eca0se 30nli!e postin with transaction FH(124 when /o0 0se periodic #$6
postin with transaction #"DHN, the ta: code is set for leder8specific postin. 5his is d0e to the attri'0tes of the 1/2
acco0nt. "ince #sset #cco0ntin alwa/s posts net, /o0 sho0ld alwa/s set the ;$ostin witho0t ta: allowed; indicator for
the relevant 1/2 acco0nts.
,+. (hat m"st I consider when adding a new "ser field (MD "ser field was not 'revio"sl& "sed) in a migration
witho"t doc"ment s'litting?
8 .f /o0 want to fill the field for at least the miration of doc0ments in phase 1 and save the field in the totals ta'le, it m0st
'e availa'le at codin 'loc! level 3QK 6.>6=H24 as of the miration date, and a derivation loic m0st 'e implemented 3'/
the c0stomer4.
8 For the 'alance carr/forward of 1/2 acco0nts not manaed on an open item 'asis in phase (, /o0 can 0se the standard
H#d. to s0'seF0entl/ add a new 0ser field 3with implementation '/ the c0stomer4.
8 For open items in phase (, there is no standard option 3for e:ample, H#d. or proram4 as of Man0ar/ 2((8 to
s0'seF0entl/ add the 0ser field.
,*. Can I 'erform a chart of acco"nts conversion when the new General Ledger is active? *ee also the ne1t F#I!
Yes, this is 0s0all/ possi'le. "#$ 3QK "/stem 2andscape =ptimiIation 3"2=4 department4 provides the ;6hart of
#cco0nts 6onversion; service. For more information a'o0t the chart of acco0nts conversion, see
http://service.sap.com/slo.
,6. Can I 'erform a chart of acco"nts conversion in the same fiscal &ear as the migration?
5his is 0s0all/ possi'le. Lowever, /o0 m0st ma!e clear differentations and several 3eneral4 points m0st 'e considered:
5his concerns two independent pro7ects. Lowever, these pro7ects ma/ have dependencies and sho0ld therefore 'e
reconciled with each other. @ns0re that /o0 !eep this in mind when plannin 'oth pro7ects. Yo0 m0st inform the relevant
"#$ contact person a'o0t the planned pro7ects.
8egarding the se2"ence of both 'ro6ects% &o" m"st also consider the followingC
MD For migration scenarios ; and C Yo0 can alwa/s perform the chart of acco0nts conversion 'efore and after the
prod0ctive miration 8 there are 0s0all/ no pro'lems in this reard.
MD For migration scenario > (MD with doc"ment s'litting)C Yo0 sho0ld perform the chart of acco0nts conversion
before the miration.
Eeason: -0rin a chart of acco0nts conversion, several acco0nts are 0s0all/ mered. .n other words, there are 0s0all/
fewer acco0nts after the chart of acco0nts conversion than 'efore the conversion. .f, for e:ample, /o0 mere three
acco0nts 3which are assined three item cateories in new 1eneral 2eder 60stomiIin4 into one acco0nt, then this
acco0nt will also have onl/ one item cateor/. 5his ma/ mean that some processes can no loner 'e
displa/ed/posted/entered with the specified doc0ment splittin r0les, and the s/stem ma/ enerate an error d0rin
postin. #s a res0lt, /o0 m0st ad70st the doc0ment splittin r0les accordinl/ 3if possi'le4.
5he a'ovementioned chanes and conversion tests are easier to perform in miration phase 1 3that is, 'efore prod0ctive
miration in the classic 1eneral 2eder4 than at a later stae when the new 1eneral 2eder is active 3after the miration4.
"ee also Note 8,11++ for information a'o0t confi0ration chanes after activatin the new 1eneral 2eder.
MD For migration scenario FC #ain, the time is not important here. Lowever, the acco0nts approach ;concept; %U"5 'e
retained after the chart of acco0nts conversion.
5his means: #cco0nts that mirror different acco0ntin principles for an acco0nts approach. For e:ample, even tho0h
acco0nt 1+711 and acco0nt ,+711 can 'e converted 3'/ "2=4 3for e:ample, to acco0nts 112)+ and ,12)+4, the/ cannot
'e deleted or mered into one acco0nt 3for e:ample, acco0nt +7114.
Eeason: .f /o0 do this, the s/stem displa/s onl/ one amo0nt 3and this amo0nt is incorrect4 when the new acco0nt 3QK
+7114 is val0ated.
@:ample 3QK chart of acco0nts conversion 'efore miration4:
Halance 3international4 acco0nt 1+711: 2(( @0ro
Halance 3local4 acco0nt ,+711: )(( @0ro
QK #ss0min the acco0nts are now mered into acco0nt +711:
5here is onl/ one amo0nt 3QK *(( @0ro4, and it is not clear whether this is the local or the international approach.
=ften an incorrect ass0mption 3QK for chart of acco0nts conversion after miration4: -0rin the miration, the acco0nts
are mered. For e:ample, as e:plained a'ove, acco0nts 1+711 and ,+711 are mered into one acco0nt +711.
.t is correct that this occ0rs in the miration '/ transfer postins, and /o0 can then val0ate this one acco0nt for different
leders 3QK different acco0ntin principles4. #fter this /o0 can delete the oriinal acco0nts 31+711 and ,+7114, for
e:ample 0sin the "2= service, 'eca0se these acco0nts are no loner reF0ired. @ven tho0h the acco0nts are no loner
reF0ired in the f0t0re, if acco0nt +711 is val0ated 'efore the miration date, onl/ one amo0nt is displa/ed 3and this
amo0nt is incorrect4 8 see a'ove.
5herefore: @ven after miration, the chart of acco0nts conversion m0st ta!e into acco0nt the acco0nts approach
loic/concept to ens0re that data can 'e correctl/ eval0ated 'efore the miration date.
MD For migration scenario .C 5he a'ove e:ec0tions for miration scenario ) and + m0st 'e o'served.
,7. Migration into the new General Ledger and introd"ction of a shortened fiscal &ear at the same time! (hat
m"st I consider?
.f /o0 introd0ce a shortened fiscal /ear, this chanes the fiscal /ear end and ma/ also affect the planned miration date
3for e:ample, 'efore the shortened fiscal /ear is introd0ced, the fiscal /ear end is -ecem'er 12S after the shortened fiscal
/ear is introd0ced, the fiscal /ear end chanes to "eptem'er )(4. Yo0 m0st ta!e this into consideration when plannin the
miration to the new 1eneral 2eder. For more information a'o0t shortened fiscal /ears, see Note 6722**.
,8. $ow do the migration date and the date of the live migration (new G)L Go-Live) relate to each other?
5he miration date m"st 'e the first da/ of a fiscal /ear.
-1am'le and ass"m'tionsC Yo0 are 0sin the F. fiscal /ear variant D+ 312 periods T + special periods and a calendar
/ear Q a fiscal /ear4. 5his means the miration date is alwa/s Man0ar/ 1. .t is still ass0med that the c0rrent date is M0ne 7,
2((8.
#ss0min that the miration will 'e implemented in 2((, 3for e:ample an #pril or %a/ wee!end4, vario0s confi0rations
will alread/ 'e reF0ired in 2((8, incl0din in the live s/stem. For precise details on these confi0rations, see "#$
"tandard 5rainin #6212.
.n the miration coc!pit 3"#$ tool for miratin F. data from the classic 1/2 to the new 1/2 8 for more information, see the
F#9 ;Jhat is a miration coc!pit<; in this note4, the miration date is still set for Man0ar/ 1, 2((,.
#s alread/ e:plained, the act0al live miration / o8live for the new 1/2 will 'e carried o0t in "prin 2((,.
.f it not possi'le to avoid shiftin the o8live, ma!e s0re that the live miration of /o0r data planned for Man0ar/ 1, 2((, is
still mirated in 2((,. It is not 'ossible to shift the go-live to /;/ if the migration date has alread& been set for
Nan"ar& ;% //G! 5his wo0ld constit0te a ;cross8fiscal /ear miration;.
Lowever, if the iven circ0mstances force a live miration in 2(1(, /o0 will have to create a new pro7ect 3miration
pac!ae4 with the miration date set for Man0ar/ 1, 2(1( 'eca0se cross8fiscal /ear mirations are not s0pported '/ "#$.
,,. #re there an& restrictions that I sho"ld bear in mind d"ring a new G)L migration when "sing the Lease
#cco"nting -ngine (L#-)?
No, if /o0 0se the 2#@ with version ()/2((8, there are no limitations when 0sin it with a new 1/2.
.mportant: Lowever, if /o0 0se the complete the "#$ 2easin $rocess with F.86#, and the correspondin doc0ment
s0mmariIation, the restrictions in this note still appl/ 8 see the F#9 ;.s the new 1eneral 2eder compati'le with F.86# 3F.
N 6ontract #cco0ntin4<; "ee also Note 8,),(6.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
#''endi1C 90estions that do not directl/ appl/ to a new 1/2 miration, '0t which ma/ 'e of interest in a miration pro7ect,
incl0de:
1. In -CC .!/% which f"nctions are not s"''orted and not released for the new General Ledger?
For information, see Note 7+1821, section F.812812, Eelease with limitations, New 1eneral 2eder:
;5he followin f0nctions are not s0pported for the new eneral leder and are therefore not released:...;
2. Is the new General Ledger com'atible with FI-C# (FI B Contract #cco"nting)?
5his F0estion is relevant for each .nd0str/ "ol0tion that 0ses component F.86# 36ontract #cco0ntin4 as acco0nts
receiva'le acco0ntin 3."8U, ."85, ."8%, ."8$"86#, F"86-4 and the non8ind0str/8specific contract acco0ntin F.86#G.
#s far as possi'le, F.86# 0ses the new 1eneral 2eder in @E$2((* in the same wa/ it 0ses the classic 1eneral
2eder. F0rthermore, F.86# s0pports the acco0nt assinment ;"ement;, which was introd0ced as a new standard
acco0nt assinment in F..
#s a r0le, the new 1eneral 2eder is not compati'le with F.86# if /o0 intend to 0se doc0ment splittin in the new 1eneral
2eder. Yo0 m0st chec! the compata'ilit/ in each case dependin on the release and the active ind0str/ sol0tion 0sed.
.n @E$2((*, it is not possi'le to post to a leder ro0p in F.86#. 5herefore, if /o0 have to implement different acco0ntin
principles in parallel, /o0 m0st 0se parallel acco0nts to process val0ation postins that were posted in F.86# 3not directl/
in the eneral leder4. .n F.86#, this primaril/ affects forein c0rrenc/ val0ation. .n a f0t0re @E$ release, F.86# will
s0pport leder ro0ps and will allow leder ro0ps as an option in forein c0rrenc/ val0ation.
). Is the new General Ledger #cco"nting com'atible with I*-# (Ind"str& *ol"tion #"tomotive)?
"ee Note ,272+1.
+. Is the new General Ledger com'atible with Financial *ervices *#+ Leasing?
"ee Note 8,),(6.
Is the new General Ledger com'atible with 8eal -state (8-)?
"ee Note 78+*67.
*. (hat m"st I consider in a distrib"ted s&stem landsca'e regarding the new General Ledger (#L-)?
For 'asic information a'o0t the new 1eneral 2eder and #2@, see Note 11+81+.
For f0rther information, see Notes 8,21(), 8,2)66, 8,,2*+ and 8,7(8).
6. #re there an& restrictions when "sing transfer 'rices in the new G)L?
"ee the section AB5ransfer pricesAB in Note 826)*7.
7. (hat is the relationshi' between the new General Ledger and Material Ledger?
Yo0 can 0se the %aterial 2eder in com'ination with the classic 1eneral 2eder and in com'ination with the new 1eneral
2eder.
.t is not possi'le to replace the %aterial 2eder with the new 1eneral 2eder.
8. Is 'rofit center consolidation available in the new General Ledger?
$rofit 6enter 6onsolidation is also availa'le when the new 1eneral 2eder is active. For more information, see Notes
8*2,71 and 826)*7.
,. (hich e1tractors are available to e1tract data from the new General Ledger to :I (:"siness (areho"se)?
.n @66 *.( 3QK "#$ @E$ 2((+4 and @66 6.( 3QK "#$ @E$ 6.(4, there is an e:tractor for e:tractin totals records from
the new 1eneral 2eder to H.: (F.>12>1(.
Im'ortantC #s of @nhancement $ac! ) 3QK @h$)4 / H0siness F0nction F.N>12>6.>1 3QK New 1eneral 2eder
#cco0ntin4, /o0 can also 0se the line item e:tractor (F.>12>1+ 3QK -ata"o0rce: HJH65>-">(F.>12>1+4. 5his also
allows /o0 to e:tract sinle doc0ments of the leadin leder for H. reportin.
Yo0 can also enerate e:tractors for non8leadin leders 3QK transaction code F#12HJ()4. 5he enerated e:tractors are
called )F.>12>GG>"., where GG is the name of the leder.
For f0rther information, see 3for e:ample4 the "#$ 2i'rar/ 0nder ;1eneral 2eder 3New4: 2ine .tems of 2eadin 2eder; or
the doc0mentation for the F.N>12>6.>1 H0siness F0nction 3QK transaction code "FJ*4.
1(. (hat do I have to consider if I "se the new General Ledger and $8?
6hec! whether Notes ,11172 and 1((66,1 are relevant for /o0.
11. $ow m"st I config"re #sset #cco"nting (FI-##) so that s"bledgers ('arallel ledgers) "se the same acco"nt
determination as the leading ledger?
#ll depreciation areas sho0ld 0se the same acco0nts as the leadin depreciation area. 5o ens0re this, fill the field
;-ifferent -epreciation #rea; in transaction =#-H with the correct val0es. 5his field defines the depreciation area for
acco0nt determination.
Deep in mind that /o0 m0st not enter different acco0nts for the derived depreciation area in transaction #=,( 'eca0se
transaction #=,( overrides the eneric settin from transaction =#-H.
12. Is it 'ossible to assign the scenario FIN<*-GM (*egmentation) to a ledger if this ledger does not have the
scenario FIN<+C# (+rofit Center A'date) assigned?
5he 0se of sements has 'een officiall/ released '/ "#$ in com'ination with the 0sae of profit centers onl/. For more
information, see also Note 1()*1+(.
1). (hen I carr& o"t an FI-## 'osting wh& does the error message GA FFF 3still4 occ"r?
"ee Note 1(,+6)( first.
.n certain circ0mstances, the error messae 1U +++ can still occ0r in asset acco0ntin. 5his happens when a leder
ro0p assined to a depreciation area contains e:actl/ one leder, and this leder is not 0sed for the compan/ code
c0rrentl/ 'ein 0sed. Lowever, if there are leder ro0ps with more than one leder, and one of these leders is not 0sed
in a compan/ code, /o0 can still ma!e a postin.
Eeason: .f asset acco0ntin permitted this confi0ration, val0es and line items wo0ld still occ0r in the relevant
depreciation areas in F.8##, '0t val0es wo0ld not 'e 0pdated in the correspondin acco0nt / leder. 5his means that the
E##H"5(2 report wo0ld alwa/s show differences, even tho0h there are none.
"ol0tion:
8 New c0stomers / new implementation: -istri'0te the compan/ codes across different val0ation plans
8 @:istin c0stomers: #ll compan/ codes of a val0ation plan 0se the same leder
-1am'leC
;!
2eder 6ompan/ 6ode
L1 1(((
L1 2(((
L2 1(((
2eder 2eder 1ro0p F.8## -epreciation #rea
L1 L1 (1
L2 L2 6(
QK @rror messae 1U +++ is iss0ed for compan/ code 2(((
!
2eder 6ompan/ 6ode
.1 1(((
.1 2(((
L1 1(((
L1 2(((
L5C 1((( CL5 Q -ail/ leder
2eder 2eder 1ro0p F.8## -epreciation #rea
.1 .1 (1
L1 L1 6(
L5 L1 6(
QK @rror messae 1U +++ is not iss0ed for compan/ code 2((( 'eca0se postins are possi'le in leder L1.