1D. Testat für Neues Hauptbuch und für Migration ins Neue Hauptbuch
? Gibt es ein Testat für das Neue Hauptbuch und für die Migration in das Neue Hauptbuch?
! Ja. Bitte beachten Sie den Hinweis 868278 und http://service.sap.com/certificates
1E. Certificate for new G/L and for migration to new G/L
? Is a certificate available for new G/L and migration to new G/L?
! Yes. Please see SAP Note 868278 and http://service.sap.com/certificates
2D. Migrationshandbuch Neues Hauptbuch
? Gibt es ein Handbuch für die Migration ins Neue Hauptbuch?
! Es gibt ein Handbuch für die Migration ins Neue Hauptbuch. Bitte benutzen Sie folgenden Link im
SAP Service Marktplatz:
http://service.sap.com/~sapidb/011000358700003419192006D
2E. New G/L Migration handbook
? Is a migration guide available?
! A migration guide is available. Please use the following link in SAP service market place:
http://service.sap.com/~sapidb/011000358700003419192006E
3D. Nicht unterstützte und nicht freigegebene Funktionen für das Neue Hauptbuch in ECC 5.0
? Welche Funktionen sind in ECC 5.0 nicht unterstützt und nicht freigegeben für das Neue
Hauptbuch?
! Bitte beachten Sie den Hinweis 741821, Abschnitt FI-GL-GL, Release with limitations, New General
Ledger:
“The following functions are not supported for the new general ledger and are therefore not released: …”
3E. Functions not supported and not released for the new G/L in ECC 5.0
? Which functions are not supported and not released for the new G/L in ECC 5.0?
! Please see SAP Note 741821, section FI-GL-GL, Release with limitations, New General Ledger:
“The following functions are not supported for the new general ledger and are therefore not released: …”
4D. Datenvolumen und Performance mit Neuem Hauptbuch
? Wie kann das Datenvolumen im Neuen Hauptbuch und die Auswirkungen auf das Systemverhalten
insbesondere auf die Performance abgeschätzt werden?
! Bitte beachten Sie die Hinweise 820495 und 1045430.
4E. Data volume and performance with new G/L
? How can I calculate the data volume in new G/L, and how can I evaluate the effects on system
behavior (especially on performance)?
! Please see SAP Notes 820495 and 1045430.
5D. Kompatibilität Neues Hauptbuch und FI-CA (FI – Contract Accounting)
? Ist das Neue Hauptbuch kompatibel mit FI-CA (FI – Contract Accounting)?
! Diese Frage betrifft alle Industrielösungen, die als Debitorenbuchhaltung die Komponente FI-CA
(Vertragskontokorrent) nutzen, also IS-U / IS-T / IS-M / IS-PS-CA / FS-CD und das
betriebswirtschaftlich neutrale FI-CAX.
FI-CA nutzt das Neue Hauptbuch in der Auslieferung ERP2005 weitestgehend so, wie auch das
klassische Hauptbuch genutzt wurde. Darüber hinaus unterstützt das FI-CA noch die Kontierung
'Segment', die als neue Standardkontierung im FI aufgenommen wurde
Das Neue Hauptbuch ist tendenziell nicht kompatibel mit FI-CA, wenn im Neuen Hauptbuch die
Belegaufteilung genutzt werden soll. Die Kompatibilität muss im Einzelfall abhängig von Releasestand
und eingesetzter Industrielösung geprüft werden.
FI-CA hat zu ERP2005 nicht die Möglichkeit, in einem Beleg eine Ledgergruppe zu setzen. Das
bedeutet, dass Bewertungsbuchungen, die im FI-CA (und nicht direkt im Hauptbuch) gebucht werden
1
über parallele Konten abzuwickeln sind, wenn unterschiedliche Rechnungslegungsvorschriften parallel
bedient werden sollen. Im FI-CA betrifft das in erster Linie die Fremdwährungsbewertung. In einem
künftigen ERP-Release wird FI-CA auch die Angabe von Ledgergruppen unterstützen und optional
auch bei Fremdwährungsbewertungen zulassen.
5E. Compatibility of new G/L and FI-CA (FI – Contract Accounting)
? Is new G/L compatible with FI-CA (FI – Contract Accounting)?
! This question is relevant for every Industry Solution that uses component FI-CA (contract accounting)
as accounts receivable (that is, IS-U / IS-T / IS-M / IS-PS-CA / FS-CD) plus the non-industry-specific
contract accounting FI-CAX.
FI-CA basically uses new G/L in ERP2005 in the same way it uses classic G/L. In addition, FI-CA
processes the account assignment 'Segment', which has been introduced as a new standard account
assignment in FI.
As a rule, new G/L is not compatible with FI-CA if you intend to use document split in new G/L. The
compatibility must be checked specifically depending on the release and the active industry solution.
In ERP2005, posting to a ledger group is not available for FI-CA. This means that you have to use
parallel accounts if you have to implement different accounting principles. An example for a relevant
process is foreign currency valuation posted in FI-CA (and not directly in G/L) in combination with
different accounting principles: In order to reflect different accounting principles in foreign currency
valuation in FI-CA, you have to use parallel accounts. In a future ERP release, FI-CA will be able to
process ledger groups and will allow ledger groups as an option in foreign currency valuation.
6D. Kompatibilität Neues Hauptbuch und IS-A (Industrielösung Automotive)
? Ist das neue Hauptbuch kompatibel mit IS-A (Industrielösung Automotive)?
! Bitte beachten Sie den Hinweis 927241.
6E. Compatibility of new G/L and IS-A (Industry Solution Automotive)
? Is new G/L compatible with IS-A (Industry Solution Automotive)?
! Please see SAP Note 927241.
7D. Kompatibilität Neues Hauptbuch und JVA (Joint Venture Accounting)
JVA (Joint Venture Accounting) ist aktiv.
? Welche Restriktionen müssen beachten werden, wenn Sie beabsichtigen, die Belegaufteilung im
Neuen Hauptbuch zu nutzen?
! Bitte beachten Sie die Hinweise 966000 und 985298.
7E. Compatibility new G/L and JVA (Joint Venture Accounting)
JVA (Joint Venture Accounting) is active.
? Which restrictions have to be considered when you intend to activate the document splitting
functionality of the new G/L?
! Please see SAP Notes 966000 and 985298.
8D. Kompatibilität Neues Hauptbuch und Financial Services SAP Leasing
? Ist das neue Hauptbuch kompatibel mit Financial Services SAP Leasing?
! Bitte beachten Sie den Hinweis 893906.
8E. Compatibility of new G/L and Financial Services SAP Leasing
? Is new G/L compatible with Financial Services SAP Leasing?
! Please see SAP Note 893906.
9D. Kompatibilität Neues Hauptbuch und Immobilienmanagement (RE)
? Ist das neue Hauptbuch kompatibel mit Immobilienmanagement (RE)?
! Bitte beachten Sie den Hinweis 784567.
2
9E. Compatibility of new G/L and Real Estate (RE)
? Is new G/L compatible with Real Estate (RE)?
! Please see SAP Note 784567.
10D. Neues Hauptbuch und ALE
? Was muss in einer verteilten Systemlandschaft im Hinblick auf das Neue Hauptbuch beachtet
werden?
! Basisinformationen über Neues Hauptbuch und ALE finden Sie im Hinweis 114814.
Fur weiterführende Informationen lessen Sie bitte die Hinweise 892103, 892366, 899254 und 897083.
10E. New G/L and ALE
? What has to be considered in a distributed system landscape regarding new G/L?
! For basic information regarding new G/L and ALE, see SAP Note 114814.
For additional information, please see SAP Notes 892103, 892366, 899254 and 897083.
11D. Neues Hauptbuch und Transferpreise
? Welche Restriktion gibt es bei Transferpreisen?
! Transferpreise sind im Zusammenhang mit der Nutzung des Neuen Hauptbuchs nicht freigegeben
und zwar unabhängig davon, ob im Neuen Hauptbuch die parallelen Wertansätze fortgeschrieben
werden sollen oder nicht. Beachten Sie hierzu auch den Hinweis 826357 Abschnitt 6.
11E. New G/L and transfer prices
? Which restrictions exist regarding transfer prices?
! Transfer prices are not released in combination with new G/L, irrespective of whether you use
multiple valuations or not.
Please see also SAP Note 826357, chapter 6.
12D. Neues Hauptbuch und Material Ledger
? Welcher Zusammenhang besteht zwischen Neuem Hauptbuch und Material Ledger?
! Sie können das Material Ledger kombiniert mit dem klassischen Hauptbuch und kombiniert mit dem
Neuen Hauptbuch nutzen.
Sie können das Material Ledger nicht durch das Neue Hauptbuch ablösen.
12E. New G/L and Material Ledger
? Which interdependence exists between new G/L and Material Ledger?
! You can use Material Ledger both in combination with classic G/L and in combination with new G/L.
It is not possible to replace Material Ledger with new G/L.
13D. Neues Hauptbuch und Spezielle Ledger
? Welche Speziellen Ledger können in das Neue Hauptbuch überführt werden?
! Nur Spezielle Ledger, die konform zum Hauptbuch geführt wurden, können und sollten ins Neue
Hauptbuch überführt werden.
Wenn Sie in einem Speziellen Ledger zusätzliche Währungen führen und wenn Sie dieses Spezielle
Ledger durch das neue Hauptbuch ablösen wollen, müssen Sie die Währungen prüfen, die in dem
Speziellen Ledger verwendet werden. Die Migrationsprogramme lesen die Daten im ursprünglichen
FI-Beleg. Wenn in dem Speziellen Ledger, das Sie ersetzen wollen, eine Währung verwendet wird, die
nicht im ursprünglichen FI-Beleg enthalten ist, können Sie die Daten nicht in das neue Hauptbuch
migrieren. In diesem Fall müssen Sie das entsprechende Spezielle Ledger beibehalten.
13E. New G/L and Special Ledgers
? Which Special Ledgers can be transferred to new G/L?
! Only Special Ledgers which are compliant with new G/L can and should be transferred to new G/L.
If you use additional currencies in a Special Purpose Ledger and want to replace this Special Purpose
Ledger with new G/L, you have to check the currencies used in the ledger. The migration programs
3
read the data in the original FI document. If the Special Purpose Ledger you want to replace uses a
currency that is not contained in the original FI document, you cannot migrate this data to new G/L. In
this case, you have to keep the respective special purpose ledger.
14D. Neues Hauptbuch und Profit Center Konsolidierung
? Ist die Profit Center Konsolidierung im Neuen Hauptbuch verfügbar?
! Die Profit Center Konsolidierung ist auch verfügbar, wenn das Neue Hauptbuch aktiv ist. Weitere
Informationen entnehmen Sie bitte den Hinweisen 852971 und 826357.
14E. New G/L and Profit Center Consolidation
? Is profit center consolidation available in new G/L?
! Profit Center Consolidation is also available when new G/L is active. For further information, please
see SAP Notes 852971 and 826357.
15D. Neues Hauptbuch und HR
? Was ist zu beachten, wenn neues Hauptbuch und HR genutzt werden?
! Bitte prüfen Sie, ob die Hinweise 911172 und 1006691 für Sie relevant sind.
15E. New G/L and HR
? What do I have to consider if I use HR and want to implement new G/L?
! Please check if SAP Notes 911172 and 1006691 are relevant for you.
16D. System mit mehreren produktiven Mandanten
? Was muss bei einem System mit mehreren produktiven Mandanten (= Mehrmandantensystem)
beachtet werden im Hinblick auf Konfiguration, Migration und Aktivierung des Neuen Hauptbuchs?
! Die Tabelle FAGL_ACTIVEC mit dem Feld FAGL_ACTIVE (Kennzeichen: Neue Hauptbuchhaltung
ist aktiv) ist mandantenabhängig. Alle anderen Tabellen, die relevant für das Neue Hauptbuch sind
(Tabelle mit Präfix FAGL_*) sind ebenfalls mandantenabhängig.
Wenn es keine Datenströme zwischen den produktiven Mandanten gibt, kann NewGL in den
einzelnen produktiven Mandanten unabhängig konfiguriert, migriert und aktiviert werden.
16E. System with more than one productive client
? What has to be considered in a system with more than one production client (multi-client system)
regarding configuration, migration and activation of new G/L?
! Table FAGL_ACTIVEC with indicator FAGL_ACTIVE (indicator: New General Ledger Accounting Is
Active) is client-dependent. All other tables that are relevant for new G/L (tables with prefix FAGL_*)
are also client-dependent.
If no data is exchanged between the productive clients, you can configure, migrate and activate new
G/L in each productive client independently.
17D. Upgrade auf ECC5.0 oder ECC6.0 und Migration ins Neue Hauptbuch im gleichen
Geschäftsjahr
? Ist es möglich, im gleichen Geschäftsjahr den Upgrade auf ECC5.0 oder ECC6.0 und die Migration
vom klassischen Hauptbuch ins Neue Hauptbuch durchzuführen.
! Wenn Sie beabsichtigen, die Belegaufteilung im Neuen Hauptbuch zu nutzen, sollten Sie die
Funktion „Validierung der Belegaufteilung“ in Ihrem Produktivsystem vor dem Migrationsdatum
aktivieren. Dies bedeutet, dass Sie in einem Geschäftsjahr den Upgrade auf ECC 6.0 durchführen
sollten, die Funktion „Validierung der Belegaufteilung“ vor dem Ende des Geschäftsjahres einschalten
sollten und im folgenden Geschäftsjahr ins Neue Hauptbuch migrieren sollten.
Wenn Sie nicht beabsichtigen, die Belegaufteilung im Neuen Hauptbuch zu nutzen, können Sie den
Upgrade auf ECC5.0 oder ECC6.0 und die Migration vom klassischen Hauptbuch ins Neue Hauptbuch
im gleichen Geschäftsjahr durchzuführen.
Bitte beachten Sie, dass die Funktion „Validierung der Belegaufteilung“ nicht in ECC5.0 verfügbar ist.
4
17E. Upgrade to ECC5.0 or ECC6.0 and migration to new G/L in the same fiscal year
? Is it possible to upgrade to ECC5.0 or ECC6.0 and migrate from classic G/L to new G/L in the same
fiscal year?
! If you intend to use document splitting in new G/L, the function “document split validation” should be
activated in the productive system before the migration date. This means that you should upgrade to
ECC 6.0 in one fiscal year, activate document split validation before the end of this fiscal year and
migrate to new G/L in the next fiscal year.
If you do not plan to use document splitting in new G/L, you can upgrade to ECC5.0 or ECC6.0 and
migrate to new G/L in the same fiscal year.
Please note that the function “document split validation” is not available in ECC5.0.
18D. Datenextraktion vom Neuen Hauptbuch ins BW (Business Warehouse)
? Welchen Extraktor gibt es um Daten vom Neuen Hauptbuch ins BW zu extrahieren?
! In ERP2004 and ERP2005 gibt es einen Extraktor für Summensätze vom Neuen Hauptbuch ins BW.
Die DataSource heißt 0FI_GL_10.
Wie in Hinweis 741821 erläutert gibt es momentan im Standard keinen Extraktor, um Einzelposten des
neuen Hauptbuchs (Tabelle FAGLFELXA) zu extrahieren.
18E. Extraction of data from new G/L to BW (Business Warehouse)
? Which extractor is available for data extraction from new G/L to BW?
! Extraction of totals from new G/L to BW is available in ERP2004 and ERP2005. The Data Source is
called 0FI_GL_10.
As indicated in SAP Note 741821, there are currently no standard BW extractors for reading
general ledger line items (table FAGLFELXA).
19D. Neues Hauptbuch und Hauswährungsumstellung (z.B. Euroumstellung)
? Was muss beachtet werden im Hinblick auf Migration ins Neue Hauptbuch und
Hauswährungsumstellung?
! Bezüglich der Verfügbarkeit von Werkzeugen für eine Hauswährungsumstellung im Neuen
Hauptbuch beachten Sie bitte folgendes:
ECC 5.0: Werkzeuge für eine Hauswährungsumstellung im Neuen Hauptbuch sind nicht verfügbar
ECC 6.0: Werkzeuge für eine Hauswährungsumstellung im Neuen Hauptbuch sind verfügbar.
Für die Projekte “Hauswährungsumstellung” und “Migration ins Neue Hauptbuch” beachten Sie bitte
folgendes:
Wenn Sie die Belegaufteilung im Neuen Hauptbuch aktivieren, ist es nicht möglich, die
Hauswährungsumstellung und die Migration ins Neue Hauptbuch im gleichen Geschäftsjahr
durchzuführen.
Hauswährungsumstellung und die Migration ins Neue Hauptbuch sind im gleichen Geschäftsjahr nur
in folgendem Szenario möglich:
Schritt 1: Hauswährungsumstellung im klassischen Hauptbuch
Schritt 2: Migration ins Neue Hauptbuch Hauptbuch ohne Belegaufteilung.
Alle anderen Szenarien, insbesondere wenn Sie im Neuen Hauptbuch die Belegaufteilung aktivieren,
erfordern, dass Sie die Hauswährungsumstellung und die Migration ins Neue Hauptbuch in
unterschiedlichen Geschäftsjahren durchführen.
19E. New G/L and Local Currency Changeover (e.g. Euro Changeover)
? What has to be considered regarding migration to new G/L and a local currency conversion?
! Regarding the availability of tools for local currency changeover in new G/L, please consider the
following:
ECC 5.0: No Euro changeover tools for new G/L available
ECC 6.0: Euro changeover tools are available for new G/L.
Regarding the projects “local currency conversion” and “migration to new G/L”, please consider the
following:
It is not possible to do local currency conversion and migration to new G/L in the same fiscal year if
document splitting is activated in new G/L.
If local currency conversion and migration to new G/L have to take place in the same fiscal year, there
is only one feasible scenario:
Step 1: Local currency changeover in classic G/L
Step 2: Migration to new G/L without document splitting in new G/L.
5
All other scenarios, especially the scenario involving activation of document splitting in new G/L,
require that you do local currency changeover and migration to new G/L in different fiscal years.
20D. Neues Hauptbuch und Kostenarten
? Wie können Kostenarten im Neuen Hauptbuch angezeigt werden?
! Mit ECC50 Support Package 12 und mit ECC60 Support Package 04 werden auch Kostenarten im
Neuen Hauptbuch gespeichert. Der Hinweise 908019 enthält hierzu weitere Informationen.
Für die Migration beachten Sie bitte die Hinweise 976629 und 1028743.
20E. New G/L and Cost Elements
? How can secondary postings (cost elements) be made visible in new G/L?
! For ECC50 Support Package 12 and higher and ECC60 Support Package 04 and higher, cost
element information is also stored in new G/L. For further information, please see SAP Note 908019.
Regarding migration to new G/L, please see SAP Notes 976629 und 1028743.
21D. Kontenfindung in der Anlagenbuchhaltung (FI-AA) in parallelen Ledgern
? Wie muss die Anlagenbuchhaltung (FI-AA) konfiguriert werden, damit in Subledgern die gleiche
Kontenfindung genutzt wird wie im führenden Ledger?
! Alle Bewertungsbereiche sollten die gleichen Konten verwenden wie der führende
Bewertungsbereich. Dies können Sie in der Transaktion OADB konfigurieren, indem Sie das Feld
„Abweichender Bewertungsbereich“ richtig füllen. Dieses Feld bestimmt den Bewertungsbereich für
die Kontenfindung.
Beachten Sie, dass Sie für den abgeleiteten Bewertungsbereich keine anderen Konten in der
Transaktion AO90 eintragen dürfen, da die Transaktion AO90 die allgemeine Konfiguration in der
Transaktion OADB übersteuert.
21E. Account Determination in Asset Accounting (FI_AA) with parallel ledgers
? How do I have to configure Asset Accounting (FI-AA) so that sub ledgers use the same account
determination as the leading ledger?
! All depreciation areas should use the same accounts as the leading depreciation area. To ensure
this, fill the field "Different Depreciation Area" in transaction OADB with the correct values. This field
defines the depreciation area for account determination.
Note that you must not enter different accounts for the derived area in transaction AO90 because
transaction AO90 overrides the generic setting from transaction OADB.
22D. Szenario FIN_SEGM (Segmentierung) und Szenario FIN_PCA (ProfitcenterFortschreibung)
? Kann das Szenario FIN_SEGM (Segmentierung) einem Ledger zugeordnet werden, wenn diesem
Ledger das Szenario FIN_PCA (Profitcenter-Fortschreibung) nicht zugeordnet ist?
! Die Nutzung von Segmenten ist von SAP offiziell nur in Zusammenhang mit der gleichzeitigen
Nutzung von Profitcentern freigegeben. Beachten Sie hierzu auch den Hinweis 1035140.
22E. Scenario FIN_SEGM (Segmentation) and scenario FIN_PCA (Profit Center Update)
? Is it possible to assign the scenario FIN_SEGM (Segmentation) to a ledger if this ledger does not
have the scenario FIN_PCA (Profit Center Update) assigned?
! SAP has released the use of segments only in combination with profit centers. For more information,
please see SAP Note 1035140.
23D. Systemumgebung für Testmigrationen
? Welche Systemumgebung wird für die Testmigrationen benötigt?
! Für die Testmigration(en) wird eine aktuelle Kopie des produktiven Mandanten benötigt. Datenbankund Betriebssystemumgebung des Testsystems sollten mit der Produktivumgebung vergleichbar sein.
23E. System landscape for test migrations
? Which system landscape is required for the test migrations?
! A recent copy of the productive client is required for the test migrations.
6
Database and operating system of the test system should be comparable to the productive
environment.
24D. Datenkonsistenz im klassischen Hauptbuch vor Beginn der ersten Testmigration
? Wie sollte die Datenkonsistenz im klassischen Hauptbuch vor Beginn der ersten Testmigration
geprüft werden?
! Prüfen Sie die Datenkonsistenz im klassischen Hauptbuch vor Beginn der ersten Testmigration wie
folgt:
1) Programm RFINDEX
Führen Sie das Programm RFINDEX zweimal aus.
Bei der ersten Ausführung markieren Sie im Selektionsbild den Schalter "Belege gegen Indizes".
Bei der zweiten Ausführung markieren Sie im Selektionsbild den Schalter "Indizes gegen Belege".
Weitere Informationen finden Sie in der Programmdokumentation.
Wenn Sie Differenzen feststellen, erfassen Sie eine Meldung im SAP Service Marktplatz auf der
Komponente FI-GL-GL-X.
2) Programm SAPF190
Führen Sie das Programm SAPF190 für das Geschäftsjahr vor der Migration und das Migrationsjahr
aus.
Wenn Sie Differenzen feststellen, erfassen Sie eine Meldung im SAP Service Marktplatz auf der
Komponente FI-GL-GL-X.
3) Programm RAABST02
Wenn Sie die Anlagenbuchhaltung nutzen, führen Sie das Programm RAABST02 aus.
Wenn Sie Differenzen feststellen, erfassen Sie eine Meldung im SAP Service Marktplatz auf der
Komponente FI-AA-AA-B.
4) Programm RCOPCA44
Wenn Sie die Profitcenter-Rechnung nutzen, führen Sie das Programm RCOPCA44.
Wenn Sie Differenzen feststellen, beachten Sie bitte den Hinweis 81374.
Alle Inkonsistenzen sollten bereinigt sein, bevor Sie mit der ersten Testmigration beginnen.
24E. Data consistency in classic G/L before beginning of the first test migration
? How should I check data consistency in classic G/L before the beginning of the first test migration?
! To check data consistency in classic G/L before the beginning of the first test migration, proceed as
follows:
1) Program RFINDEX
Run program RFINDEX twice:
In the first run, choose ”Documents vs. Indexes“ in the selection screen.
In the second run, choose “Indexes vs. Documents“ in the selection screen.
For more information, see the program documentation.
If the program finds any differences, create a message in SAP Service Marketplace on component FIGL-GL-X.
2) Program SAPF190
Run program SAPF190 for the fiscal year prior to the migration and for the fiscal year in which the
migration takes place.
If the program finds any differences, create a message in SAP Service Marketplace on component FIGL-GL-X.
3) Program RAABST02
If Asset Accounting is active, run program RAABST02.
If the program finds any differences, create a message in SAP Service Marketplace on component FIAA-AA-B.
4) Program RCOPCA44
If Profit Center Accounting is active, run program RCOPCA44.
If the program finds any differences, see SAP Note 81374.
All inconsistencies should be removed before you start the first test migration.
7
25D. Empfehlungen für Kontensteuerungen in Sachkonten vor Beginn der ersten Testmigration
? Welche Empfehlungen gibt es für die Kontensteuerung in Sachkonten?
! Im Sachkontenstamm sind die Felder „Salden nur in Hauswährung“, „Verwaltung offener Posten“,
„Einzelpostenanzeige“ und „Abstimmkonto für Kontoart“ bei der Einführung des Neuen Hauptbuchs
von Interesse.
Diese Felder sollten analysiert und ggf. angepasst werden, bevor Sie mit der ersten Testmigration
beginnen.
„Salden nur in Hauswährung“: Wenn der Schalter „Salden nur in Hauswährung“ ausgeschaltet ist,
werden die Summensätze des Kontos in allen Währungen fortgeschrieben. Es ist zu prüfen, ob dies
notwendig ist. Buchungen in unterschiedlichen Währungen blähen die Anzahl der Summensätze in
der Tabelle FAGLFLEXT auf.
„Verwaltung offener Posten“ (= OP-Verwaltung): Es sollte geprüft werden, bei welchen Konten eine
Verwaltung offener Posten sinnvoll ist. Welche Konten werden wirklich ausgeglichen?
Bei Nutzung paralleler Ledger im Neuen Hauptbuch dürfen Konten, die Bewertungsunterschiede (z.B.
Rückstellungskonten) haben, nicht OP geführt sein.
Konten, die mit dem Programm für die Fremdwährungsbewertung bebucht werden (Programm
SAPF100 bzw. Transaktion F.05) sollten nicht mit OP-Verwaltung geführt werden. Beachten Sie
hierzu den Hinweis 318399. Die Fremdwährungsbewertung konfigurieren Sie in der Transaktion
OBA1.
Der Report RFSEPA03 kann verwendet werden, um die OP-Verwaltung in bebuchten Konten
abzubauen. Bitte dabei den Hinweis 175960 beachten.
„Einzelpostenanzeige“: Einzelpostenanzeige ist für Konten ohne OP-Verwaltung aus technischer Sicht
nicht mehr notwendig, da im Neuen Hauptbuch zu jedem Konto Einzelposten in der Tabelle
FAGLFLEXA geführt werden. Wenn Sie vom klassischen Hauptbuch ins Neue Hauptbuch migriert
haben, ist die Abschaltung der Einzelpostenanzeige erst nach Abnahme durch den Wirtschaftsprüfer
bzw. Betriebsprüfer möglich.
„Abstimmkonto für Kontoart“: Wenn Sie die Belegaufteilung einsetzen wollen, müssen Sie prüfen,
dass Abstimmkonten für Kontoart Debitor oder Kreditor in allen Buchungskreisen gleich gesteuert
sind. D.h. wenn ein Sachkonto z.B. ein Abstimmkonto zur Kontoart Debitor ist, muss es in allen
relevanten Buchungskreisen so ausgesteuert sein, da man die Konten auf Kontenplanebene für die
Belegaufteilung klassifiziert.
25E. Recommendations for account control and account management in G/L accounts before
beginning of the first test migration
? Which recommendations exist for account control and account management in G/L accounts?
! In G/L master data, the fields”Only balances in local currency“,”Open item management“, ”Line item
display“ and ”Reconciliation account for account type“ are relevant for the implementation of new G/L.
You should analyze these fields and adapt them if necessary before beginning with the first test
migration.
„Only balances in local currency“: If the indicator”Only balances in local currency“ is switched off, totals
of the account are stored in all currencies. Check if this is necessary. Postings in different currencies
unnecessarily increase the number of totals records in table FAGLFLEXT.
„Open item management“: You should check for which accounts it is reasonable to switch on open
item management. Which accounts do you really clear?
If you intend to use parallel ledgers in new G/L, consider that accounts with different valuations (e.g.
accounts for accruals) must not be open item managed.
Accounts that take foreign currency valuation postings (program SAPF100 or transaction F.05) should
not be open item managed. See SAP Note 318399 for details. You can configure foreign currency
valuation in transaction OBA1.
You can use report RFSEPA03 to switch off open item management in active G/L accounts. See also
SAP Note 175960.
„Line item display“: From a technical point of view, ”Line item display“ is no longer necessary for
accounts which are not open item managed as new G/L stores line items for each account in table
FAGLFLEXA. After the migration to new G/L, you may not switch off line item display until your auditor
has given his approval.
„Reconciliation account for account type“: If you intend to activate document splitting in new G/L, make
sure that reconciliation accounts for customers and vendors have the same “reconciliation account for
account type“ in all company codes. If, for example, a G/L account is a reconciliation account for
customers, this must be the case in all relevant company codes because you have to classify
accounts for document splitting at chart of accounts level.
8
26D. IMG-Pfad und Anwendungsmenü für Neues Hauptbuch in einem Customizing System
oder Testsystem einblenden
? Wie kann der IMG-Pfad und das Anwendungsmenü für das Neue Hauptbuch in einem Customizing System oder Testsystem eingeblendet werden.
! Um das Menü für das neue Hauptbuch und den IMG-Pfad für die Einführung des neuen
Hauptbuches einzublenden, gehen sie folgendermaßen vor:
1. Führen Sie im Einführungsleitfaden folgenden Schritt durch:
Transaktion SPRO -> Finanzwesen -> Grundeinstellungen Finanzwesen -> Neue Hauptbuchhaltung
aktivieren. Dies ist identisch mit der Transaktion FAGL_ACTIVATION. Hierdurch wird der notwendige
Eintrag in der Tabelle FAGL_ACTIVEC erzeugt. Der Eintrag in der Tabelle FAGL_ACTIVEC
ist nicht nur das Aktivierungskennzeichen, sondern speichert auch Informationen über z.B. die
Belegaufteilung.
Das Customizing der Neuen Hauptbuchhaltung ist jetzt möglich, der Pfad im Einführungsleitfaden und
das Anwendungsmenü werden angezeigt.
2. Unmittelbar nach 1. deaktivieren Sie das Neue Hauptbuch wieder in der Transaktion
FAGL_ACTIVATION. Der notwendige Eintrag verbleibt in der Tabelle FAGL_ACTIVEC.
Wenn das Neue Hauptbuch in keinem anderen Mandant des Systems aktiv ist, verschwindet der Pfad
im Einführungsleitfaden wieder.
3. Führen Sie den Report RFAGL_SWAP_IMG_NEW aus. Danach wird der Pfad im
Einführungsleitfaden wieder angezeigt.
4. Transportieren Sie den Transportauftrag aus den Schritten 1. und 2. nicht versehentlich in das
Produktivsystem.
26E. Display IMG path and application menu for new G/L in a customizing system or test
system
? How can I make the IMG path and application menu for new G/L visible in a customizing system or
in a test system?
! In the customizing system or test system, proceed as follows in order to make the new G/L menu and
the new G/L implementation path visible.
1. Execute the following function in the IMG:
Transaction SPRO->Financial Accounting->Financial Accounting Global Settings->Activate New
General Ledger Accounting. This is equal to transaction code FAGL_ACTIVATION.
This creates the necessary entry in table FAGL_ACTIVEC. The entry in table FAGL_ACTIVEC is not
only an activation flag, but also stores other information e.g. regarding document splitting.
New G/L customizing is now enabled, IMG path and new G/L application menu appears.
2. Immediately after step 1., deactivate new G/L again in transaction code FAGL_ACTIVATION. The
necessary entry remains in table FAGL_ACTIVEC.
If new G/L is not active in any other client of this system, the IMG path vanishes again.
3. Run report RFAGL_SWAP_IMG_NEW to make the IMG path visible again.
4. Please make sure that you do not accidentally transport the transport order of step 1. or step 2. into
the productive system.
27D. Zusätzliche Felder in den Summensätzen oder Einzelposten des Neuen Hauptbuchs
? Sie überlegen, zusätzliche Felder in die die Tabelle der Summensätze (FAGLFLEXT) oder
Einzelposten (FAGLFLEXA) des Neuen Hauptbuchs aufzunehmen. Was ist hierbei zu beachten?
! Bitte beachten Sie die Hinweise 961295 und 923687.
27E. Additional fields in totals or line items of new G/L
? You think about adding additional fields to the tables of new G/L totals (FAGLFLEXT) or line items
(FAGLFLEXA). What do you have to consider?
! Please see SAP Notes 961295 and 923687.
28D. Organisation des Transportwesens
? Wie sollte das Transportwesen in einem NewGL-Projekt organisiert werden?
! Es wird davon ausgegangen, dass in der produktiven ERP-Landschaft eine KTW-Schiene
(Entwicklung, Test, Produktion) eingerichtet ist.
Reine NewGL-Einstellungen, Validierung Belegaufteilung und Aktivierungskennzeichen müssen in
getrennten Transportaufträgen gespeichert werden. Nach den Tests können reine NewGL-
9
Einstellungen bereits in die Produktivumgebung transportiert werden. Die Validierung Belegaufteilung
transportieren Sie später.
Nach der erfolgreichen Migration transportieren Sie schließlich das Aktivierungskennzeichen in das
Produktivsystem.
28E. Organization of transport management
? How shall I set up transport management in my new G/L project?
! The following recommendation assumes that the transport management in the productive ERP
landscape (development, test, production) is already set up.
Pure new G/L configurations, configuration of validation of document splitting and activation of new
G/L should be stored in different transport orders.
After completion of the testing, the transports containing pure new G/L configurations can be released
to the productive environment.
Later, you transport the transport orders for validation of document splitting.
Finally (after the successful completion of the migration), you transport the activation of new G/L to the
productive system.
29D. Customizing im Produktivsystem zum Migrationsdatum
? Welche Teile des Customizings müssen bereits zum Migrationsdatum im Produktivsystem sein?
! Wenn Sie die Belegaufteilung in ECC 6.0 nutzen, wird dringend empfohlen, die Validierung der
Belegaufteilung spätestens zum Migrationsdatum im Produktivsystem einzuschalten. Das bedeutet,
dass das Neue Hauptbuch inklusive der Belegaufteilung zum Migrationsdatum im Produktivsystem
vollständig konfiguriert sein muss und alle Schnittstellen und ALE-Szenarien entsprechend angepasst
sein müssen.
In ECC 5.0 trifft dies nicht zu, da die Validierung der Belegaufteilung in ECC 5.0 nicht vorhanden ist.
Wenn Sie die Belegaufteilung nicht nutzen werden oder in Release ECC 5.0 sind, können Sie das
Customizing des Neuen Hauptbuchs nach dem Migrationsdatum in das Produktivsystem
transportieren.
Das Kennzeichen „Neue Hauptbuchhaltung ist aktiv“ wird mit anderen Grundeinstellungen zum Neuen
Hauptbuch in der Tabelle FAGL_ACTIVEC transportiert. Achten Sie unbedingt darauf, dass das
Kennzeichen „Neue Hauptbuchhaltung ist aktiv“ in ausgeschaltetem Zustand in das Produktivsystem
transportiert wird.
29E. Customizing in productive system on migration date
? Which parts of the configuration must exist in the production system at the latest on the migration
date?
! If you plan to use document splitting in ECC 6.0, it is strongly recommended that you activate
validation of document splitting in the production system at the latest on the migration date. This
means that the new G/L configuration including document splitting in the production system must be
completed on the migration date and that all interfaces and ALE scenarios must be adapted
accordingly.
This is not applicable in ECC 5.0 because validation of document splitting is not available in ECC 5.0.
If you do not plan to use document splitting or if you are using release ECC 5.0, you can transport the
configuration of new G/L to the productive system after the migration date.
The indicator ”New General Ledger Accounting Is Active“ is transported with other basic settings of
new G/L in table FAGL_ACTIVEC. Please make absolutely sure that the flag ”New General Ledger
Accounting Is Active“ is switched off when it is transported to the production system.
30D. Projektplan bei Belegaufteilung
? Was ist im Projektplan zu berücksichtigen, wenn die Belegaufteilung genutzt werden soll?
! Es wird dringend empfohlen, die Validierung der Belegaufteilung spätestens zum Migrationsdatum
einzuschalten.
Das Neue Hauptbuch inklusive der Belegaufteilung muss vollständig und endgültig konfiguriert sein
bevor Sie die Validierung der Belegaufteilung einschalten.
30E. Project plan with document splitting
? What do I have to consider when drawing up the project plan if I plan to use document splitting?
! It is strongly recommended that you activate validation of document splitting at the latest on the
10
migration date.
New G/L including document splitting must be completely and finally configured before you activate
validation of document splitting.
31D. Kriterien für das Anlegen eines Migrationsplans
? Welche Kriterien sind maßgeblich für das Anlegen eines Migrationsplans?
! Es werden zwei grundlegende Migrationsplantypen unterschieden:
- mit Belegaufteilung
- ohne Belegaufteilung.
Die geplante Aktivierung der Belegaufteilung hat erheblichen Einfluss auf eine Migration. Jedem
Migrationsplan muss genau ein Typ zugeordnet sein, d.h. wenn Sie für einige Buchungskreise die
Belegaufteilung aktivieren wollen und für andere nicht, müssen Sie dafür zwei Migrationspläne
anlegen.
Am Migrationsplan hängt auch die Aktivierung der Validierung für die Belegaufteilung in
Migrationsphase 1.
Ein anderes Kriterium für das Anlegen mehrerer Migrationspläne sind abweichende
Geschäftsjahresvarianten. Hierbei kommt es lediglich auf den ersten Tag des Geschäftsjahres an. Die
Periodenrasterung innerhalb des Geschäftsjahres ist unerheblich.
Wenn in einem Buchungskreis das Geschäftsjahr z.B. am 1.1. beginnt und in einem anderen am 1.3.
müssen für die beiden Buchungskreise zwei Migrationspläne angelegt werden.
Wenn Buchungskreise buchungskreisübergreifend buchen und im Neuen Hauptbuch die
Belegaufteilung nutzen wollen, müssen Sie folgendes beachten. Alle Buchungskeise, die
untereinander buchungskreisübergreifend buchen, müssen dem gleichen Migrationsplan zugeordnet
werden.
31E. Criteria for the creation of a migration plan
? Which criteria are relevant for the creation of a migration plan?
! There are two basic types of migration plans:
- with document splitting
- without document splitting.
If you plan to activate document splitting, this has a major impact on the migration.
You have to assign exactly one type to each migration plan. This means that you have to create two
migration plans if some company codes will activate document split and other companies will not
activate document split.
Activation of validation of document splitting for migration phase 1 is also done in the migration plan.
Another criterion for the creation of various migration plans is different fiscal year variants. In this
respect only the first day of the fiscal year is relevant. The pattern of the periods in the fiscal year is
not relevant.
If, for example, the fiscal year begins on January 1 in one company code and on March 1 in another
company code, you have to create two migration plans for the two company codes.
If company codes do cross-company postings and want to activate document splitting in new G/L,
please be aware of the following: All company codes that post cross-company amongst each other
must be assigned to the same migration plan.
32D. Migrationsdatum
? Kann das Migrationsdatum auf ein beliebiges Datum im Geschäftsjahr gesetzt werden?
! Nein. Das Migrationsdatum muss der erste Tag des Geschäftsjahres sein. Ein anderes Datum ist
nicht möglich.
Wenn Sie die produktive Migration im Geschäftsjahr 20XY durchführen wollen, können Sie
Testmigrationen im vorherigen Geschäftsjahr durchführen, indem Sie das Migrationsdatum auf den
ersten Tag des Geschäftsjahres 20XY – 1 setzen.
32E. Migration Date
? Can any date in the fiscal year be chosen as the migration date?
! No. The migration date needs to be the first day of the fiscal year. No other date is possible.
If you want to do the productive migration in fiscal year 20XY, you can do test migrations in the
previous fiscal year after you have set the migration date to the first day of fiscal year 20XY – 1.
11
33D. Aspekte für das Aktivierungsdatum des neuen Hauptbuchs
? Welche Aspekte sollten für das Aktivierungsdatum des neuen Hauptbuchs beachtet werden?
! Eine Voraussetzung für die Migration ist, dass der Jahresabschluss für das vorherige Geschäftsjahr
durchgeführt wurde. Für die Aktivierung des Neuen Hauptbuchs gibt es kein bindendes Datum wie
z.B. der erste Tag des Monats/der Periode oder der letzte Tag des Monats/der Periode. Für die
Migration wird eine Downtime benötigt. Der Go Live kann an einem beliebigen Tag im Monat
durchgeführt werden. Es wird empfohlen, für den Go-Live ein Zeitfenster zu wählen, wenn der
Systemstillstand Ihr Unternehmen am wenigsten stört. Es bieten sich z.B. Wochenenden mit
vorhergehendem oder folgendem Feiertag an oder die Betriebsferien an.
Im Zeitfenster der Downtime werden die Migrationsprogramme ausgeführt. Nach dem erfolgreichen
Lauf der Migrationsprogramme und noch in der Downtime müssen die Zahlen vor der Migration mit
den Zahlen nach der Migration abgestimmt werden. Nach erfolgreicher Abstimmung kann das neue
Hauptbuch aktiviert werden.
Da die Abstimmung der Zahlen vor der Migration mit den Zahlen nach der Migration typischerweise
von den Personen durchgeführt wird, die auch für den Monatsabschluss zuständig sind, wird davon
abgeraten, die Aktivierung des Neuen Hauptbuchs parallel zu den Monatsabschlussarbeiten
einzuplanen.
33E. Aspects regarding the Activation Date of NewG/L
? Which aspects should be considered regarding the activation date of NewG/L
! A prerequisite for the migration is that the fiscal year closure for the previous fiscal year has been
finalized. The activation date does not have to be a special date (like the first day of a month/period or
the last day of a month/period). The migration itself requires a downtime. Go-live can be on any day in
the month. It is recommended to choose a time slot when the system outage has minimal impact on
your company’s daily business. Consequently, weekends with preceding or succeeding public holidays
or company holidays are suitable dates.
During the downtime, the migration programs are executed. After successful execution of the
migration programs (but still during the downtime), figures before migration vs. figures after migration
must be reconciled.
New G/L can then be activated afte successful completion of the reconciliation.
As reconciliation of figures before migration vs. figures after migration is usually done by the persons
who are also in charge of the month end closure, it is not recommended to schedule activation of new
G/L in parallel to month end closure.
34D. Aktivierung des Neuen Hauptbuchs auf Bukrs-Ebene
? Ist es möglich, das NewGL auf Bukrs-Ebene zu aktivieren?
! Nein. Das NewGL wird auf Mandanten-Ebene aktiviert. Hierdurch ist das NewGL für alle
Buchungskreise im Mandant gleichzeitig aktiv.
34E. Activation of New G/L at Company Code Level
? Is it possible to activate new G/L at company code level?
! No. You activate new G/L at client level. This means that new G/L is active for all company codes in
the client at a given point in time.
35D. Tabellen ACCTHD, ACCTIT und ACCTCR
? Müssen Sie etwas bezüglich der Tabellen ACCTHD, ACCTIT und ACCTCR beachten, wenn Sie in
das Neue Hauptbuch migrieren wollen?
! Bitte beachten Sie hierzu in Hinweis 48009 den Punkt 8.
35E. Tables ACCTHD, ACCTIT and ACCTCR
? Do you have to consider anything special for tables ACCTHD, ACCTIT and ACCTCR in connection
with the migration to new G/L?
! Please read chapter 8 in SAP Note 48009.
12
36D. Neuer Buchungskreis im Neuen Hauptbuch parallel zu klassischem Hauptbuch im
gleichen Mandant
Ein neuer Buchungskreis soll mit dem Neuen Hauptbuch konfiguriert werden. Die bestehenden
Buchungskreise nutzen das klassische Hauptbuch.
? Können Buchungskreise im gleichen Mandant unterschiedliche Hauptbücher (alt und neu) nutzen?
! Die Einführung eines neuen Buchungskreises und der Übergang von klassischem Hauptbuch auf
das neue Hauptbuch sind zwei unterschiedliche Projekte, die für unterschiedliche Zeiten geplant
werden müssen.
Die Migration vom klassischen Hauptbuch ins neue Hauptbuch wird mandantenweise durchgeführt
und betrifft alle Buchungskreise, die in diesem Mandant existieren.
Da die Aktivierung des Neuen Hauptbuchs auf Mandantenebene ist, wäre das Neue Hauptbuch in
allen Buchungskreisen aktiv, nicht nur für den neuen Buchungskreis. Dies würde bedeuten, dass das
Neue Hauptbuch in den alten Buchungskreisen aktiv ist und keine Migration vom klassischen
Hauptbuch ins Neue Hauptbuch durchgeführt wurde. Dies ist nicht möglich.
Zusammengefasst ist es nicht möglich mit einem neuen Buchungskreis im neuen Hauptbuch zu
beginnen während das klassische Hauptbuch noch in anderen Buchungskreisen im gleichen Mandant
aktiv ist.
Führen Sie zuerst den neuen Buchungskreis ein. Setzen Sie zweitens das Projekt für den Übergang
von klassischem Hauptbuch auf neues Hauptbuch auf.
Oder setzen Sie zuerst das Projekt für den Übergang vom klassischen Hauptbuch auf das neue
Hauptbuch auf, migrieren Sie die Daten und ins neue Hauptbuch und implementieren Sie dann den
neuen Buchungskreis.
36E. New Company Code in New G/L in Parallel to Classic G/L in the Same Client
A new company code is to be configured. It should use the new G/L, while the existing company codes
run classic G/L.
? Can company codes with different G/Ls run in parallel in the same client?
! Implementation of a new company code and transition from classic G/L to new G/L are two different
projects which must be scheduled at different times.
Migration from classic G/L to new G/L is done at client level and affects all company codes which are
in place in this client.
As activation of new G/L happens at client level, new G/L would be active for all company codes, not
only for the new company code. This would mean that new G/L is active in the old company codes, but
no migration classic G/L -> new G/L has taken place. This is not possible.
Consequently, it is not possible to start with a new company code in new G/L while classic GL is still
active in other company codes in the same client.
Either implement the new company code in classic G/L and then set up the project for transition
classic GL -> new G/L.
Or set up the project for transition classic GL -> new G/L and migrate the data to new G/L, then
implement the new company code in new G/L.
37D. Inaktive Buchungskreise
Im System sind Buchungskreise, die überhaupt keine Bewegungsdaten enthalten oder
Buchungskreise, die nur in abgeschlossenen Geschäftsjahren Bewegungsdaten enthalten und nicht
mehr genutzt werden. Diese Buchungskreise werden als inaktive Buchungskreise bezeichnet.
? Was muss bei der Migration ins Neue Hauptbuch für inaktive Buchungskreise beachtet werden?
! Inaktive Buchungskreise haben zu Beginn des laufenden Geschäftsjahres keine Offenen Posten und
keine Saldovorträge und keine FI-Belege im laufenden Jahr.
Schließen Sie inaktive Buchungskreise daher von der Migration ins Neue Hauptbuch aus.
37E. Non-Active Company Codes
The system contains company codes that either have no transaction data at all or that have
transaction data only in closed fiscal years and are no longer in use. These company codes are called
non-active company codes.
? What has to be considered regarding non-active company codes when migrating to new G/L?
! Non-active company codes do not have open items and balance carry forward at the beginning of the
current fiscal year and do not store postings in the current fiscal year.
Therefore exclude non-active company codes from the migration to new G/L.
13
38D. Zeitpunkt der Aktivierung des Neuen Hauptbuchs
? Müssen alle Buchungskreise eines Mandanten fehlerfrei migriert sein, bevor NewGL aktiv geschaltet
werden kann?
! Grundsätzlich müssen alle Belege für alle Buchungskreise vollständig und fehlerfrei migriert sein,
bevor das Neue Hauptbuch aktiviert wird.
In Ausnahmefällen kann man einige Belege auch nach der Aktivierung des Neuen Hauptbuchs
migrieren, solange man den Migrationsplan nicht auf den Status "beendet" setzt. Das Projektteam
sollte allerdings wissen, welche Auswirkungen noch fehlende Belege auf den operativen Betrieb des
Systems haben. Wenn z.B. die Belegaufteilung genutzt werden soll, können offene Verbindlichkeiten
aus dem aktuellen Geschäftsjahr erst reguliert werden, nachdem der Beleg migriert wurde.
38E. Point in Time for Activation of New G/L
? Do all documents in all company codes have to be migrated successfully before new G/L can be
activated?
! Basically all documents in all company codes must be migrated successfully before you can activate
new G/L.
In exceptional cases, you can migrate some documents after new G/L has been activated as long as
the migration plan has not been set to status “Migration ended”.
However the project team must consider the consequences of non-migrated documents for the daily
business. If, for example, document splitting is active, you cannot pay liabilities for documents from the
current fiscal year until the documents are migrated to new G/L.
39D. BAdI für den Transfer der Saldovorträge
? Gibt es einen BAdI für den Transfer der Saldovorträge aus Phase 0?
! Sie können den BAdI FAGL_UPLOAD_CF nutzen, um die neuen Kontierungsfelder (z.B. Segment)
des neuen Hauptbuchs abzuleiten. In der Ableitung können Sie alle Felder verwenden, die in der
Struktur GLU1 enthalten sind einschließlich aller Kundenfelder.
39E. BAdI for Transfer of Balance Carry Forward
? Is a BAdI available for the transfer of balance carry forward from phase 0?
! To derive the new account assignment fields (e. g. segment), you can use the BAdI
FAGL_UPLOAD_CF. For the purposes of the derivation, you can use all fields in structure GLU1
including any customer fields.
40D. Buchung mit Transaktion FBCB auf Anlagenabstimmkonten und auf Konten für Vorsteuer
und Ausgangssteuer
? Wie können Buchungen mit Transaktion FBCB auf Anlagenabstimmkonten und auf Konten für
Vorsteuer und Ausgangssteuer ermöglicht werden.
! Bauen Sie die Korrektur gemäß Hinweis 937940 ein.
40E. Posting with Transaction FBCB to Reconciliation Accounts for Assets and to VAT
Accounts
? How can I do postings to reconciliation accounts for assets and to VAT accounts using transaction
FBCB?
! Please implement SAP Note 937940.
41D. Massenverarbeitung für Transaktion FBCB
? Welche Massenverarbeitung steht für die Transaktion FBCB zur Verfügung?
! Benutzen Sie Batch Input zur Massenverarbeitung mit der Transaktion FBCB. Dies wird empfohlen,
um z.B. die Salden auf Anlagenabstimmkonten auf Profit Center bzw. Segment aufzuteilen.
41E. Mass Processing for Transaction FBCB
? How can I do mass processing for transaction FBCB?
! Please use batch input for mass processing of transaction FBCB. This is recommended e.g. if you
want to post balances of reconciliation accounts for assets to profit centers or segments.
14
42D. Belegaufteilung für offene Posten aus vorherigen Geschäftsjahren (Phase 0)
? Ist für offene Posten aus vorherigen Geschäftsjahren eine Belegaufteilung möglich?
! Nein. Das System führt keine Belegaufteilung durch wenn offene Posten aus vorherigen
Geschäftsjahren (Phase 0) ins neue Hauptbuch migriert werden.
Sie können die Kontierungsfelder für offene Posten aus vorherigen Geschäftsjahren in Form einer
singulären Kontierungsinformation anreichern. Dies bedeutet dass ein offener Posten einen Wert für
jedes Kontierungsfeld erhalten kann. Das BAdI FAGL_MIGR_SUBST stellt diese Funktionalität zur
Verfügung. Es ist nicht möglich, den Posten selbst aufzuteilen.
42E. Document Splitting for Open Items from Previous Fiscal Years (Phase 0)
? Is the splitting functionality available for open items from previous fiscal years?
! No. When migrating open items from previous years (phase 0) to the new general ledger, the system
does not split the open items.
You can supplement the account assignment for open items from previous fiscal years in the form of a
singular account assignment. This means that an open item can take one value for each account
assignment object. BAdI FAGL_MIGR_SUBST provides this functionality. It is not possible to split the
open item itself.
43D. Die Belegaufteilung stellt in die Buchungskreisverrechnungszeilen keine
Partnerkontierungen
? Wie kann erreicht werden, dass die Belegaufteilung Partnerkontierungen in die
Buchungskreisverrechnungszeilen stellt?
! Beachten Sie Hinweis 942542.
43E. Document Split Does not Set Partner Assignments in Cross-Company Code Clearing
Lines
? What do I have to do if I want the document splitting function to set partner assignments in crosscompany code clearing lines?
! Please see SAP Note 942542.
44D. Ausgleichsbelege mit Ausgleichszeilen wenn die Belegaufteilung aktiv ist
? Ist es korrekt, dass ein Ausgleichsbeleg Ausgleichszeilen hat, wenn die Belegaufteilung aktiv ist?
! Ja. Wenn die Belegaufteilung aktiv ist, haben Ausgleichsbelege immer zwei Belegzeilen in der
Erfassungssicht (Tabelle BSEG). Bitte beachten Sie Hinweis 950773.
Für Ausgleichsbelege in der Phase 1 beachten Sie bitte den Hinweis 1054674.
44E. Clearing documents with clearing lines when document split is active
? Is it correct that a clearing document has clearing lines when the document split is active?
! Yes. With active document split clearing documents will always have two lines in the entry view (table
BSEG). Please view note 950773.
Please view note 1054674 regarding clearing documents in phase 1 .
45D. Keine Meldung im Batch Input bei Validierung der Belegaufteilung
? Warum kommt trotzt entsprechend eingeschalteter Validierung der Belegaufteilung im Batch-Input
keine Fehlermeldung, wenn die Validierungsbedingung nicht erfüllt ist?
! Im View V_FAGL_SPL_PROC wurde ein Eintrag aufgenommen, der für alle oder für spezifizierte
Vorgänge im Zusammenhang mit dem Batch-Input Kennzeichen V_FAGL_SPL_PROC-BINPT gilt.
Diese Einstellung übersteuert die generelle Einstellung zur Validierung.
45E. No Message in Batch Input for Validation of Document Splitting
? Why does the batch input not send a message although the validation of document splitting is active
and configured accordingly, and the condition for the validation is false?
! You made an entry in view V_FAGL_SPL_PROC for all business transactions or for a specified
business transaction that applies in connection with a value in the batch input indicator field
15
V_FAGL_SPL_PROC-BINPT. This configuration overrides the general configuration for validation of
document splitting.
46D. Belege der Phase 1 ohne Kontierung trotz Mussfeld im Customizing der Validierung der
Belegaufteilung
? Warum haben manche Belege der Phase 1 trotz aktivierter Validierung der Belegaufteilung mit der
Aussteuerung 'Fehlermeldung' keine Kontierung in den Mussfeldern?
! In Phase 1 wurde ein Ausgleich zurückgenommen. Ausgleichsbelege werden bei der Verbuchung
nicht mit Belagaufteilungsmerkmalen versorgt, da sie die Split-Information während der Migration aus
ausgeglichenen Positionen beziehen. Durch die Ausgleichsrücknahme geht diese Beziehung verloren.
Derartige Belege müssen durch Anreicherung im BAdI oder durch das Customizing einer
Ausgleichsbeziehung speziell behandelt werden.
Zur Vermeidung dieser Situation sollte die Transaktion FBRA (Ausgleich zurücknehmen) in der Phase
1 möglichst unterbunden werden.
Desweiteren werden Stornobelege trotz aktiver Validierung der Belegaufteilung ohne Kontierung
gebucht, wenn der stornierte Beleg diese Kontierung nicht enthält.
46E. Documents in Phase 1 Without Account Assignment Although Mandatory Field in
Customizing of Document Splitting Validation
? Why are account assignments missing in required entry fields for some documents from phase 1
although validation of document splitting is active with an error message?
! You reset cleared items in phase 1. Clearing documents do not get the document splitting information
during the posting because they get the document splitting information during the migration from the
cleared items. This relation is cut by the reset of cleared items. The BAdI can generate the document
split information, or you can configure a clearing scenario in customizing for the migration of these
documents.
In order to avoid this situation it is recommended not to use transaction FBRA (Reset cleared items)
during phase 1.
Also reversal documents will be posted with empty account assignment although validation of
document splitting is active if the account assignment is empty in the document to be reversed.
47D. Belegaufteilung und Belegverdichtung
? Hat die Belegverdichtung einen Einfluss auf die Belegaufteilung?
! Belegverdichtung ist bei Nutzung der Belegaufteilung immer als kritisch zu betrachten. Zu splittende
Felder (z.B. Profitcenter, Segment) und deren Partnerfelder dürfen nie verdichtet werden.
Sie müssen prüfen, welche anderen Felder Sie während der Migration für die nachträgliche Aufteilung
der Belege aus Phase 1 benötigen. Diese Aufteilung erfolgt basierend auf den BSEG Daten. Die
entsprechenden Felder dürfen daher nicht verdichtet sein.
Nach Aktivierung des Neuen Hauptbuchs (= Phase 2) erfolgt die Belegaufteilung basierend auf der
Tabelle ACCIT und nicht mehr basierend auf der Tabelle BSEG.
Auch wenn die Belegaufteilung nicht aktiv ist, werden Phase 1 Belege in der Migration aus der BSEG
nachgebucht. Felder, die im klassischen Hauptbuch verdichtet wurden, sind nach der Migration auch
in den Tabellen FAGLFLEXA/FAGLFLEXT leer.
47E. Document Split and Document Summarization
? Does document summarization have an impact on document splitting?
! If you intend to use document splitting, document summarization must be considered as critical. It is
not allowed to summarize fields that you want to use in document splitting (e.g. profit center, segment)
and the corresponding partner fields.
You have to check which other fields you need during the migration when doing subsequent document
splitting for documents from phase 1. The document splitting is based on the data in table BSEG. You
must not summarize fields you need for document splitting of documents from phase 1.
After activation of new G/L (= phase 2), table ACCIT (and no longer table BSEG) is used as the basis
for document splitting.
Even if document splitting is not active, documents from phase 1 are migrated from table BSEG.
Fields that were summarized in classic G/L are also empty in tables FAGLFLEXA/FAGLFLEXT after
the migration.
16
48D. Belegaufteilung und Wechsel
? Welche Funktionalität steht bei aktiver Belegaufteilung für die Wechselabwicklung zur Verfügung?
! Wenn die Belegaufteilung aktiv ist, besteht folgender Zusammenhang zwischen Belegaufteilung und
Wechselabwicklung.
Die Belegaufteilung stellt die Kontierungen bei der Bildung des Wechselobligos bei Diskontierung und
Inkasso des Wechsels. Diese Funktionalität steht ab ERP 2004 Support Package 10 zur Verfügung.
In ERP 2004 und 2005 steht keine Funktionalität der Belegaufteilung für „Geplatzte Wechsel“ (=
Wechselprotest) zur Verfügung. Die neue Rechung wird unkontiert gebucht und nicht
verursachungsgerecht gemäß der ursprünglichen Rechnung.
Für „Geplatzte Wechsel“ ist ein Workaround möglich über Defaultkontierung (mit User Exit oder
Substitution). Alternativ muss die originäre Kontierung manuell mitgegeben werden.
48E. Document Splitting and Bills of Exchange
? Which functionality is available for processing bills of exchange if document splitting is active?
! If document splitting is active, the following interdependencies between document splitting and bill of
exchange processing exist:
The document splitting provides the account assignments when creating the bill liability for discounting
and collection of the bill of exchange. This functionality is available from ERP 2004 Support Package
10 onwards.
ERP 2004 and 2005 do not provide functionality for document splitting of failed bills of exchange. The
new invoice is posted without account assignments and not fair according to the input from the original
invoice.
A workaround with default account assignment (by user exit or substitution) is possible for failed bills
of exchange. Alternatively you can enter the original account assignment manually.
49D. Belegaufteilung und buchungskreisübergreifendes Buchen
? Was ist bei der Belegaufteilung zu beachten, wenn buchungskreisübergreifend gebucht wird?
! Wenn buchungskreisübergreifend gebucht wird, müssen die Einstellungen für die Belegaufteilung in
den paarweise beteiligten Buchungskreisen konsistent sein. D.h. die Belegaufteilung muss entweder
paarweise in beiden oder in keinem Buchungskreis aktiv sein.
49E. Document Splitting and Cross-Company Postings
? What has to be considered in document splitting in connection with cross-company postings?
! If you do cross-company postings, the configuration of document splitting must be consistent in all
pairs of company codes for which cross-company postings exist (or will take place in the future). This
means that document splitting must be either active or inactive in both company codes forming a pair
for cross-company postings.
50D. Verhalten der Transaktion FAGL_MIG_SIM_SPL (Simulation der Belegaufteilung)
? Warum verhält sich die Transaktion FAGL_MIG_SIM_SPL (Simulation der Belegaufteilung) anders
als die Validierung der Belegaufteilung und anderes als die Transaktion FAGL_MIG_SPLIT
(Nachbuchen der Splitinformation)?
! Die Transaktion FAGL_MIG_SIM_SPL (Simulation der Belegaufteilung) betrachtet nur den Beleg,
der aktuell prozessiert wird und keinen Belegfluss. Wenn der aktuell prozessierte Beleg Teil eines
Belegflusses ist, nimmt die Transaktion FAGL_MIG_SIM_SPL (Simulation der Belegaufteilung) an,
dass für den ursprünglichen Beleg bereits Einträge in den Tabellen erzeugt wurden, die die
Informationen der Belegaufteilung speichern.
Die Validierung der Belegaufteilung und die Transaktion FAGL_MIG_SPLIT (Nachbuchen der
Splitinformation) betrachten den gesamten Belegfluss.
50E. Behavior of Transaction FAGL_MIG_SIM_SPL (Simulation of Document Splitting)
? Why does transaction FAGL_MIG_SIM_SPL (Simulate of Document Splitting) not behave in the
same way as validation of document splitting and transaction FAGL_MIG_SPLIT (Subsequently Post
Split Information)?
! Transaction FAGL_MIG_SIM_SPL (Simulation of Document Splitting) considers only the document
that is currently being processed, but no document flow. If the document being processed is part of a
document flow, transaction FAGL_MIG_SIM_SPL assumes that the original document already has
entries in the relevant document splitting information tables.
17
The validation of document splitting and transaction FAGL_MIG_SPLIT (Subsequently Post Split
Information) both consider the whole document flow.
51D. Verhalten der Transaktion FAGL_CHECK_LINETYPE (Geschäftsvorfall für Belege prüfen)
Die Transaktion FAGL_CHECK_LINETYPE (Geschäftsvorfall für Belege prüfen) zeigt beispielsweise
Fehler bei buchungskreisübergreifenden Vorgängen im Beleg des nicht-führenden Buchungskreises.
Wenn die Belegsplitinformation aufgebaut wird und die Belege migriert werden, arbeitet die
Belegaufteilung fehlerfrei in beiden Buchungskreisen.
? Warum verhält sich die Transaktion FAGL_CHECK_LINETYPE (Geschäftsvorfall für Belege prüfen)
anders als die tatsächliche Migration?
! Die Transaktion FAGL_CHECK_LINETYPE ist nicht dafür vorgesehen, um einen kompletten
Geschäftsprozess zu simulieren. Das heißt dass z.B. ein Geschäftsprozess mit
buchungskreisübergreifenden Vorgängen, bei dem der gesamte Geschäftsprozess aus mehr als
einem FI-Beleg besteht, nicht korrekt geprüft wird. Die Belege werden dennoch später korrekt migriert
und dabei wird die Belegaufteilungsinformation korrekt aufgebaut.
Die Transaktion FAGL_CHECK_LINETYPE macht immer nur eine einfache Prüfung, ob das
Customizing korrekt ist. Die Prüfung ist fehlerhaft sobald der zu prüfende Beleg Teil eines komplexen
Geschäftsvorfalles ist.
51E. Behavior of Transaction FAGL_CHECK_LINETYPE (Check Business Transaction
Assignments for Migration Documents)
Transaction FAGL_CHECK_LINETYPE (Check Business Transaction Assignments for Migration
Documents) shows, for example, errors in cross-company code documents in the non-leading
company code. When document splitting information is built and migration of documents is performed,
the document splitting works correctly for both company codes.
? Why does transaction FAGL_CHECK_LINETYPE (Check Business Transaction Assignments for
Migration Documents) not behave like the actual migration?
! Transaction FAGL_CHECK_LINETYPE is not designed to do a complete simulation of a business
process. This means that for example a process with cross-company postings where the business
process involves more than one document will not be checked correctly. Nevertheless these
documents will be migrated correctly and passed through the document splitting functionality while reposting them to new G/L.
Transaction FAGL_CHECK_LINETYPE always does only a simple check if the customizing itself is
correct. As soon as the document that needs to be checked represents only a part of a complex
process, the check will run into an error.
52D. Wechselzahlung (Transaktion F-36) und Belegaufteilung
Sie haben die Belegaufteilung aktiviert. Sie buchen die Wechselzahlung in der Transaktion F-36. In
der Transaktion F-36 markieren Sie „Zahlungseingang“ und geben den Debitor an. In den folgenden
Dynpros geben Sie den zu regulierenden Betrag an und selektieren die zu regulierenden Belege.
Beim Buchen erhalten Sie die Fehlermeldung GLT2 201 „Bilanzierendes Feld "&1" ist in Belegzeile &2
nicht gefüllt.“ Beim Buchen kann auch das Phänomen auftreten, dass der Beleg ohne Belegaufteilung
gebucht wird.
? Was ist zu tun, damit in der Transaktion F-36 der Beleg der Wechselzahlung korrekt aufgeteilt wird?
! Ursache ist, dass bei der Buchung von Wechselzahlungen eine Belegart verwendet wird, die nicht
den Erfordernissen entsprechend konfiguriert ist.
Im Rahmen der Belegaufteilung ist es erforderlich, einen Ausgleich zu prozessieren. Aus der
Transaktion F-36 geht dieser Sachverhalt nicht hervor, daher muss dieses durch die Belegart
bestimmt werden. Bitte konfigurieren Sie für die Wechselzahlung eine Belegart, die in der
Customizing-Transaktion GSP_VZ3 dem Geschäftsvorfall 1010 Variante 0001 zugeordnet ist.
Verwenden Sie diese Belegart in der Transaktion F-36.
Anschließend können Sie in der Transaktion OBU1 die vorgeschlagene Belegart für die Transaktion F36 ändern.
52E. Bill of Exchange Payment (Transaction F-36) and Document Split
Document split is active. You post the bill of exchange payment in transaction F-36. You choose
“Incoming payment” in transaction F-36 and enter the customer ID. In the following screens, you enter
the paid amount and select the paid invoices.
18
When posting, the system sends message GLT2 201 „Balancing field "&1" in line item &2 not filled.” It
can also happen that the document is posted without document splitting.
? What has to be done to ensure that the document for the bill of exchange payment in transaction F36 is split correctly?
! The reason for this error is that you use a document type for the bill of exchange payment which is
not configured in the required way.
For the document splitting, it is necessary to process a clearing. As transaction F-36 does not process
a clearing, the document type must take care of this.
Please configure a specific document type for the bill of exchange payment which you assign to
business transaction 1010 variant 0001 in customizing transaction GSP_VZ3. Use this specific
document type in transaction F-36.
After this, use transaction OBU1 to change the default document type of transaction F-36.
53D. Belegaufteilung und Validierung
? In welchem Zusammenhang stehen Belegaufteilung und Validierung?
! Es ist zu unterscheiden zwischen Validierung vor der Belegaufteilung und Validierung nach der
Belegaufteilung. „Vor der Belegaufteilung“ bedeutet, dass die Validierung vor der Belegaufteilung
prozessiert wird. Nach der Belegaufteilung“ bedeutet, dass die Validierung nach der Belegaufteilung
prozessiert wird.
Eine Validierung vor der Belegaufteilung wird empfohlen, um zu prüfen, dass die
Eingangsvoraussetzungen für die Belegaufteilung erfüllt sind. Beispielsweise hat die Belegart im
Neuen Hauptbuch eine zentrale Steuerungsfunktion für die Belegaufteilung. Daher ist es für die
Belegaufteilung entscheidend, dass Sie in jeder Transaktion die richtige Belegart verwenden. So kann
z.B. mit einer Validierung vor der Belegaufteilung geprüft werden, dass für die Buchung von
Wechselzahlungen (Transaktion F-36) die spezifisch hierfür in der Transaktion GSP_VZ3 hinterlegte
Belegart verwendet wird. Eine Validierung vor der Belegaufteilung können Sie in der Transaktion
OB28 konfigurieren.
Eine Validierung nach der Belegaufteilung können Sie verwenden, um das Ergebnis der
Belegaufteilung zu prüfen. Hierzu können Sie den BAdI GLT0_AFTERSPLIT_VAL verwenden.
Weitere Informationen hierzu finden Sie im Hinweis 846004.
53E. Document Splitting and Validation
? What is the relation between document splitting and validation?
! You have to distinguish between validation before document splitting and validation after document
splitting. ”Before document splitting“ means that the validation is processed before the document
splitting. ”After document splitting“ means that the validation is processed after the document splitting.
The purpose of a validation before document split is to make sure that the prerequisites for document
splitting are fulfilled. For example, the document type has a central control function for document
splitting in new G/L. Hence it is vital for document splitting that you use the correct document type in
each transaction. For example, you can use a validation before document splitting for postings of bill of
exchange payments (transaction F-36) to make sure that you use the document type which is
configured for this purpose in transaction GSP_VZ3. You configure a validation before document
splitting in transaction OB28.
You can use a validation after document splitting to check the result of the document splitting. To this
purpose, you can use BAdI GLT0_AFTERSPLIT_VAL. For additional information, see SAP Note
846004.
54D. Belegstorno und Belegaufteilung
? In welchem Fall wird bei einem Belegstorno der Stornoprozess in der Belegaufteilung angestossen
und in welchem Fall werden die Belegaufteilungsregeln prozessiert?
! Die Belegaufteilung prozessiert den Stornoprozess beim FI Storno (Transaktion FB08 oder FBU8).
Dabei werden keine Regeln prozessiert, sondern es wird ein Umkehrbeleg aus den
Kontierungsinformationen des zu stornierenden Beleg erzeugt. Es wird die Geschäftsvorfallvariante
des zu stornierenden Beleges abgeleitet, da bestimmte Einstellungen in der Belegaufteilung von der
Geschäftsvorfallsvariante abhängen.
Es sind zunächst die Begriffe prozessdeterminierter (passiver) und regelbasierter Split (oft auch als
aktiver Split bezeichnet) zu unterscheiden.
19
Der prozessdeterminierte Split wird prozessiert bei bestimmten Ausgleichs- oder ausgleichsähnlichen
Prozessen. Die Steuerung erfolgt entweder über den Prozess selbst, z.B. bei Ausgleichsrücknahme
mit FBRA (nur relevant für spezielle Ledger mit Belegaufteilung) oder durch FI-Storno mit Vorgang
RFBU oder durch die Eigenschaften einzelner Belegzeilen (Ausgleichszeilen, Zeilen mit
Rechnungsbezug).
In dem Fall des FI-Stornos gilt der prozessdeterminierte Split für den jeweils kompletten Beleg. Alle
Belegzeilen 'erben' jeweils die Kontierungen der entsprechenden Belegzeilen des Ursprungsbelegs.
Im klassischen Hauptbuch werden bei Nullausgleichen reine Ausgleichsbelege erzeugt. Die
zugehörigen Belege enthalten keine Belegzeilen.
Im neuen Hauptbuch mit aktiver Belegaufteilung werden keine Nullausgleiche gebucht. Es werden
immer Belege mit Ausgleichszeilen erzeugt.
Ein Ausgleich muss aber nicht immer ein Saldo-Null-Ausgleich sein, es können auch Restposten
gebildet oder Differenzen ausbucht werden. Hier gilt nur für einen Teil des Belegs der
prozessdeterminierte Split.
Daraus folgt: Ob ein regelbasierter oder ein prozessdeterminierter Split vorliegt, gilt nicht immer für
den ganzen Beleg (das sind sogar nur die Ausnahmefälle), sondern es sind in der Regel vom
prozessdeterminierten Split nur einzelne Belegzeilen eines Beleges - unabhängig davon, welche
Geschäftsvorfallsvariante prozessiert wird - betroffen.
Regelbasierter Split gilt immer für Geschäftsvorfälle, die keinen Bezug zu einem bereits gebuchten
Beleg besitzen. Hier kann das Einbuchen einer Rechnung mit einer FI-Transaktion als Beispiel
genannt werden. Darüber hinaus wird der regelbasierte Split von Geschäftsvorfällen prozessiert, die
zwar Ausgleichs- oder ausgleichsähnliche Prozesse sein können, dieses aber nicht zwangsläufig in
jedem Fall sein müssen. Hier ist als Beispiel der Storno seitens MM mit MR8M zu nennen. Stornos,
die nicht mit dem betriebswirtschaftlichen Vorgang RFBU durchgeführt werden, prozessieren den
regelbasierten Split. Das heißt, in Abhängigkeit von der Belegart des zu stornierenden Belegs ist in
OBA7 eine Stornobelegart zugeordnet.
Zu der Stornobelegart des zu stornierenden Beleges wird aus GSP_VZ3 die Geschäftsvorfallsvariante
ermittelt. Anhand der Geschäftsvorfallsvarante dieser Stornobelegart wird das in GSP_RD hinterlegte
Customizing dieser Stornobelegart bei der Aufteilung des Stornobelegs prozessiert. Hierbei ist
wiederum zu beachten, dass auch in diesem Storno für einzelne Belegzeilen aufgrund deren
Eigenschaften der prozessdeterminierte Split prozessiert werden kann.
54E. Document Reversal and Document Splitting
? In which case does the document reversal trigger the reversal process in document splitting, and in
which case does the document reversal trigger the document split rules?
! The document splitting processes its reversal process in FI reversals (transaction FB08 and FBU8).
In this case, no document splitting rules are processed. Instead, the system creates a reverse posting
from the account assignments of the document to be reversed. The system determines the business
transaction variant of the document to be reversed because some configurations of the document
splitting depend on the business transaction variant.
You have to distinguish between “process-based (= passive) splitting” and “rule-based (= active)
splitting“.
The system processes the process-based splitting in certain clearing processes and similar processes.
This is triggered either by the process itself, e.g. in transaction FBRA (Reset Cleared Items, which is
only relevant in special purpose ledgers with document splitting) or by FI reversal with business
transaction RFBU or by the attributes of single document line items (clearing line items, line items
belonging to an invoice).
For the FI reversal, the process-based splitting is relevant for the entire document. Each document line
item 'inherits' the account assignments of the corresponding line item of the document to be reversed.
In classic G/L, the system creates mere clearing documents for zero clearing. The documents do not
contain line items.
In new G/L with active document splitting, the system does not create pure zero clearings. The system
always creates documents with clearing lines.
A clearing does not necessarily have to be a zero clearing. You can also create a residual item or post
differences. In this case, the process-based splitting is relevant only for some lines of the document.
Conclusion: The system does not always process a process-based splitting or rule-based splitting for
the entire document. In fact, process-based splitting for a complete document is rather the exception
than the rule: Process-based splitting is usually only applied to single line items of a document
(irrespective of the assigned business transaction variant).
Rule-based splitting is processed for transactions which do not refer to an existing FI document, such
as posting an invoice.
20
In addition, certain clearing transactions and certain processes similar to clearing processes involve
rule-based splitting. An example would be the reversal from MM in transaction MR8M. Reversals that
are not carried out by means of transaction RFBU process the rule-based splitting as well. The reverse
document type for each document type is stored in transaction OBA7. In transaction GSP_VZ3, the
system finds the business transaction variant based on the reverse document type. Based on the
business transaction variant, the system then finds the relevant splitting rule (as defined in transaction
GSP_RD) to be processed when splitting the reversal document. Depending on the attributes of each
line item, process-based (= passive) splitting may be processed for single line items here as well.
55D. Saldo-Null-Verrechungungskonto der Belegaufteilung
? Was muss beim Anlegen des Saldo-Null-Verrechungungskonto für die Belegaufteilung beachtet
werden?
! Beachten Sie bitte Hinweis 961937.
55E. Zero Balance Clearing Account for Document Splitting
? What has to be considered when creating the zero balance clearing account for document splitting?
! Please see SAP Note 961937.
56D. Rückbuchungen in das alte Geschäftsjahr
? Bis wann kann in das alte Geschäftsjahr gebucht werden?
! Das alte Geschäftsjahr ist das Geschäftsjahr vor dem Migrationsdatum.
Ein Rückbuchen in das alte Geschäftsjahr ist möglich, solange noch nicht mit der produktiven
Migration begonnen wurde.
Ein Rückbuchen in das Geschäftsjahr vor dem Migrationsdatum ist nicht mehr möglich, nachdem mit
der produktiven Migration begonnen wurde oder nachdem erste Objekte (z.B. Offene Posten)
produktiv migriert wurden.
Wenn das Neue Hauptbuch aktiv ist, ist ein Rückbuchen in das Geschäftsjahr vor dem
Migrationsdatum ebenfalls nicht mehr möglich.
Dies bedeutet, dass der Jahresabschluss für das Vorjahr in Phase 1, d.h. vor dem Beginn der
produktiven Migration und vor dem GoLive erfolgen muss. Alle Buchungen in das vorherige
Geschäftsjahr müssen vor Beginn der produktiven Migration durchgeführt sein, auch z.B.
Anpassungsbuchungen gemäß den Vorgaben der Wirtschaftsprüfer.
Oftmals kann die Notwendigkeit, ins alte Geschäftsjahr rückbuchen zu müssen, erst ausgeschlossen
werden, nachdem der Jahresabschluss testiert ist.
56E. Postings to Previous Fiscal Year
? Until when can I post to the previous fiscal year?
! In this context, the term “previous fiscal year“ refers to the fiscal year prior to the migration date.
You can post to the previous fiscal year as long as you have not started the productive migration.
Once you have started the productive migration or migrated any objects (e.g. open items), it is no
longer possible to post to the previous fiscal year.
Once new G/L has been activated, it is no longer possible to post to the fiscal year prior to the
migration date either.
This means that the fiscal year closure for the previous fiscal year must be done in phase 1, that is,
before starting the productive migration and before go-live.
All postings to the previous fiscal year must be stored before the beginning of the productive migration.
This includes postings according to the auditor’s instructions. In many cases, you cannot be sure that
no postings to the previous fiscal year will be required until the fiscal year closure has been testified.
57D. Migration von Anzahlungsanforderungen, geparkten Belegen, vorerfassten Belegen und
gemerkten Belegen
Das Migrationsprogramm, das die Belege aus der Phase 1 migriert, bearbeitet nur FI-Belege, die im
klassischen Hauptbuch Verkehrszahlen fortgeschrieben haben. Dieses Programm bearbeitet
Anzahlungsanforderungen, geparkte Belege, vorerfasste Belege und gemerkte Belege nicht.
? Was muss bei Anzahlungsanforderungen, geparkten Belegen, vorerfassten Belegen und gemerkten
Belegen beachtet werden?
21
! Da Anzahlungsanforderungen, geparkte Belege, vorerfasste Belege und gemerkte Belege keine
Verkehrszahlen im klassischen Hauptbuch fortgeschrieben haben, müssen
Anzahlungsanforderungen, geparkte Belege, vorerfasste Belege und gemerkte Belege nicht vom
klassischen Hauptbuch in das Neue Hauptbuch migriert werden.
Sie müssen prüfen, ob die Felder, die Sie mit dem neuen Hauptbuch neu eingeführt haben (z.B.
Funktionsbereich, Profit Center, Segment) in geparkten Belegen, vorerfassten Belegen und gemerkten
Belegen angereichert werden müssen.
57E. Migration of Down Payment Requests, Parked Documents and Noted Items
The migration program used to transfer documents from phase 1 processes only FI documents that
have updated totals in classic G/L. This program does not cover down payment requests, parked
documents and noted items.
? What has to be considered regarding down payment requests, parked documents and noted items?
! As down payment requests, parked documents and noted items did not update totals in classic G/L,
there is no need to migrate down payment requests, parked documents and noted items from classic
G/L to new G/L.
You have to check if you need to add values for the new fields you have introduced with new G/L (e.g.
functional area, profit center, segment) in parked documents and noted items.
58D. Übernahme Plandaten von CO-OM (Controlling - Gemeinkostenrechnung) in das Neue
Hauptbuch
? Wie können Plandaten von CO-OM (Controlling - Gemeinkostenrechnung) in das Neue Hauptbuch
übernommen werden?
! Sie können wie folgt Plandaten aus CO-OM (Controlling - Gemeinkostenrechnung) ins Neue
Hauptbuch übernehmen.
Zunächst müssen Sie das Customizing für Planung im Neuen Hauptbuch entsprechend den Schritten
im Einführungsleitfaden konfigurieren.
Danach können Sie die bestehenden Plandaten von CO-OM (Plandaten auf Kostenstellen und
Innenaufträgen) ins Neue Hauptbuch zu übernehmen. Wählen Sie hierzu folgenden Pfad im
Einführungsleitfaden:
-> Hauptbuchhaltung (neu)
-> Planung
-> Plandaten aus CO-OM übernehmen.
58E. Transfer of Planning Data from CO-OM (Controlling – Overhead Management) to New G/L
? How can I transfer planning data from CO-OM (Controlling – Overhead Management) to new G/L?
! Please proceed as follows to transfer planning data from CO-OM (Controlling – Overhead
Management) to new G/L:
First do the configuration for planning in new G/L as described in the implementation guide.
Then transfer existing planning data from CO-OM (planning data stored on cost centers and internal
orders) to new G/L. Choose the following path in the implementation guide:
-> General Ledger Accounting (New)
-> Planning
-> Transfer Planning Data from CO-OM.
59D. Übernahme Plandaten von klassischem EC-PCA (Unternehmenscontrolling – Profit Center
Rechnung) oder von klassischem Hauptbuch in das Neue Hauptbuch
? Wie können Plandaten aus der klassischen Profit Center Rechnung (EC-PCA) oder aus dem
klassischen Hauptbuch in das Neue Hauptbuch übernommen werden?
! Sie können wie folgt Plandaten aus der klassischen Profit Center Rechnung (EC-PCA) oder aus dem
klassischen Hauptbuch ins Neue Hauptbuch übernehmen.
Zunächst müssen Sie das Customizing für Planung im Neuen Hauptbuch entsprechend den Schritten
im Einführungsleitfaden konfigurieren.
Für die Übernahme von Plandaten aus der klassischen Profit Center Rechnung (EC-PCA) oder aus
dem klassischen Hauptbuch in das Neue Hauptbuch existieren keine spezifischen Funktionen.
Als Workaround gibt es zwei Möglichkeiten. Sie können erstens hierfür die Transaktion GP52
verwenden. Zweitens können Sie mit einem Roll-Up die Summen der Planung ins Neue Hauptbuch
übernehmen. Für letzteres müssen Sie hart in zwei Customizing-Tabellen die Roll-Up-Funktionalität
22
für die NewGL Ledger zulassen. Die zweite Möglichkeit dürfen Sie nur durchführen, wenn Sie über
ausreichende technische Kenntnisse verfügen.
Da es sich in beiden Fällen um einen Workaround handelt, müssen Sie ausgiebig testen.
Wenn Sie in der klassischen Profitcenter-Rechnung nicht lokal geplant haben, sondern die Plandaten
im klassischen EC-PCA ausschließlich durch die Planintegration mit CO-OM entstanden sind, sollten
Sie anstatt der EC-PCA-Plandaten die CO-OM-Plandaten ins Neue Hauptbuch übernehmen.
59E. Transfer of Planning Data From Classic EC-PCA (Enterprise Controlling – Profit Center
Accounting) or From Classic G/L to newG/L
? How can I transfer planning data from classic EC-PCA (Enterprise Controlling – Profit Center
Accounting) or from classic G/L to new G/L?
! Please proceed as follows to transfer planning data from classic EC-PCA (Enterprise Controlling –
Profit Center Accounting) or from classic G/L to new G/L:
First do the configuration for planning in new G/L as described in the implementation guide.
No specific functions are available for the transfer of planning data from classic EC-PCA (Enterprise
Controlling – Profit Center Accounting) or from classic G/L to new G/L.
There are two possible workarounds. You can either use transaction GP52 or a roll-up to transfer the
totals of the planning data to new G/L. For the latter alternative, you have to allow roll-up for the new
G/L ledger by making the required changed directly in two customizing tables. You are only allowed to
implement the second alternative if you have sufficient technical know-how.
As both alternatives are workarounds, you have to test intensively.
If you have not planned locally in classic EC-PCA and EC-PCA planning data was created exclusively
by planning integration with CO-OM, you should transfer CO-OM planning data to new G/L instead of
transferring EC-PCA planning data to new G/L.
60D. Echtzeitintegration CO -> FI aktiv und Standard-UKV-Ledger 0F aktiv
? Was muss beachtet werden, wenn die Echtzeitintegration CO -> FI eingeschaltet ist und das
Standard-UKV-Ledger 0F genutzt wird?
! Es ist zu unterscheiden zwischen Phase 1 (Migrationdatum bis Aktivierungsdatum) und Phase 2 (ab
Aktivierungsdatum).
Phase 1: Klassisches Hauptbuch aktiv, Echtzeitintegration CO -> FI aktiv und Standard-UKV-Ledger
0F aktiv.
Da die Echtzeitintegration aktiv ist, werden in Phase 1 keine FI-Buchungen mehr aus dem
Abstimmledger erzeugt. Die FI-Belege aus der Echtzeitintegration (EZI) müssen in Phase 1 nicht nur
im klassischen Hauptbuch, sondern auch im Ledger 0F fortgeschrieben werden.
Dazu muss beim Einschalten der Echtzeitintegration CO -> FI, d.h. spätestens zum Migrationsdatum,
der Vorgang COFI dem Ledger 0F manuell zugeordnet werden. Benutzen Sie die Transaktion GCL2,
um dem Ledger 0F den Vorgang COFI zuzuordnen.
Phase 2: Neues Hauptbuch aktiv, Echtzeitintegration CO -> FI aktiv und Standard-UKV-Ledger 0F
aktiv.
Wenn das Standard-UKV-Ledger 0F parallel zum aktiven Neuen Hauptbuch weiter genutzt werden
soll, ist folgendes zu beachten.
Da die Echtzeitintegration aktiv ist, werden keine FI-Buchungen mehr aus dem Abstimmledger
erzeugt. Die FI-Belege aus der Echtzeitintegration (EZI) müssen nicht nur im Neuen Hauptbuch,
sondern auch im Ledger 0F fortgeschrieben werden.
Dazu muss beim Einschalten der Echtzeitintegration CO -> FI dem Ledger 0F der Vorgang COFI
manuell zugeordnet werden. Benutzen Sie die Transaktion GCL2, um dem Ledger 0F den Vorgang
COFI zuzuordnen.
Wenn die Variante der Echtzeitintegration (EZI) im Customizing so eingestellt ist, dass die EZI-Belege
mit einer Ledgergruppe gebucht werden, muss in der Transaktion GCL2 im Ledger 0F zusätzlich das
Feld „Referenz Ledger“ mit dem führenden Ledger des NewGL (z.B. 0L) gefüllt werden. Das Ledger
0F wird dann nur mit solchen FI-Belegen fortgeschrieben, die in das entsprechende NewGL Ledger
(z.B. 0L) gebucht werden.
60E. Real-Time Integration CO -> FI Active and Standard COS Ledger 0F Active
? What has to be considered if real time integration CO -> FI is active and standard COS Ledger 0F is
active?
! You must distinguish between phase 1 (from migration date to activation date) and phase 2 (from
activation date onwards).
23
Phase 1: Classic G/L is active, real-time integration CO -> FI is active, and standard COS ledger 0F is
active.
As real time integration is active in phase 1, the reconciliation ledger will not create FI postings in
phase 1. This is why in phase 1 the FI documents from real-time integration CO -> FI must not only be
posted to classic G/L, but also to ledger 0F. When activating real-time integration CO -> FI, you have
to assign activity COFI to ledger 0F. Use transaction GCL2 to assign activity COFI to ledger 0F.
Phase 2: New GL is active, real-time integration CO -> FI is active and standard COS ledger 0F is
active.
If you want to continue using standard COS ledger 0F in parallel to new G/L, please consider the
following.
As real-time integration is active, the reconciliation ledger will not create FI postings. This is why the FI
documents from real-time integration CO -> FI must not only be posted to new G/L, but also to ledger
0F. When activating real-time integration CO -> FI, you have to assign activity COFI to ledger 0F. Use
transaction GCL2 to assign activity COFI to ledger 0F.
If the applicable variant for real-time integration specifies that the documents from real-time integration
are posted in a ledger group, you have to fill the field “reference ledger” in transaction GCL2 in ledger
0F with the leading ledger of new G/L (for example 0L). Ledger 0F will then only be updated with FI
documents that were posted to the corresponding new G/L Ledger (for example 0L).
61D. Zeitpunkt für Aktivierung Echtzeitintegration CO -> FI
In der Variante für Echtzeitintegration CO -> FI tragen Sie den „Stichtag: Aktiv ab“ ein und schalten
den Schalter „Echtzeitint. aktiv“ ein. Hierdurch ist die Echtzeitintegration CO -> FI ab dem definierten
Datum aktiv.
? Welcher Zeitpunkt wird empfohlen zur Aktivierung der Echtzeitintegration CO -> FI?
! Grundsätzlich wird empfohlen, die Echtzeitintegration CO -> FI entweder vor oder nach der
Aktivierung des Neuen Hauptbuchs einzuschalten. Hierdurch wird die Anzahl der Aktivitäten zum
Aktivierungszeitpunkt des Neuen Hauptbuchs während der Downtime reduziert wird
Wenn Sie im Neuen Hauptbuch Kostenarten auswerten wollen, wird empfohlen, die
Echtzeitintegration CO -> FI nach der Aktivierung des Neuen Hauptbuchs einzuschalten. Der Grund
ist, dass das Feld „Kostenart“ in der Migration nicht gefüllt wird in Belegen, die im klassischen
Hauptbuch aus der Echtzeitintegration erzeugt wurden. Beachten Sie hierzu auch den Hinweis
1028743. Sinnvolle Zeitpunkte zur Aktivierung der Echtzeitintegration CO -> FI sind z.B. der Beginn
der Periode, des Quartals oder des Geschäftsjahres, das auf dieAktivierung des Neuen Hauptbuchs
folgt.
Wenn Sie im Neuen Hauptbuch keine Kostenarten auswerten wollen, wird empfohlen, die
Echtzeitintegration CO -> FI zum Migrationsdatum einzuschalten mit Stichtag = Migrationsdatum. Das
Customizing der Echtzeitintegration muss also spätestens am letzten Tag des alten Geschäftsjahres
im Produktivsystem sein.
Durch die Aktivierung der Echtzeitintegration CO -> FI zum Migrationsdatum ergibt sich eine klare
Trennung. Im alten Geschäftsjahr wird das Abstimmledger für Reporting und FI-Buchungen genutzt.
Im neuen Geschäftsjahr wird das NewGL für Reporting genutzt und die Echtzeitintegration erzeugt die
FI-Buchungen.
Ein weiterer Vorteil ist, dass mit dieser Vorgehensweise das Nachbuchen mit dem Report
FAGL_COFI_TRANSFER_CODOCS entfällt.
61E. Point In Time for Activation of Real-Time Integration CO -> FI
In the variant for real time integration CO -> FI, you enter the ”Key Date: Active from“ and switch on
the indicator “R-Time Integ:Active“. This activates real-time integration CO -> FI beginning on the
given date.
? Which point in time is recommended for the activation of real-time integration CO -> FI?
! A basic recommendation is to activate real-time integration CO -> FI either before or after activation
of new G/L. This approach reduces the number of activities related to the activation of new G/L during
the downtime.
We recommend activating real-time integration CO -> FI after activation of new G/L if you want to
report cost elements from new G/L.
The reason is that for documents created in classic G/L by real time integration CO -> FI the field ”cost
element” is not filled during the migration. Please see also SAP Note 1028743. Reasonable points in
24
time for activating real-time integration CO -> FI are, for example, the beginning of the period, the
quarter or the fiscal year that follows the activation of new G/L.
If you do not want to report cost elements from new G/L, we recommend activating real-time
integration CO -> FI before activation of new G/L with ”Key Date: Active from“ = migration date. In this
case, the configuration of real-time integration CO -> FI must be available in the productive system at
the latest on the last day of the old fiscal year.
The activation of real-time integration CO -> FI at the migration date constitutes a clear separation: In
the old fiscal year, you use the reconciliation ledger for reporting and postings. In the new fiscal year,
you use new G/L for reporting and real-time integration CO -> FI creates the postings.
Another advantage of this approach is that you do not have to post retrospectively with report
FAGL_COFI_TRANSFER_CODOCS.
62D. Profitcenter-übergreifende CO-interne Verrechnungen ins FI buchen
? Wie können Profitcenter übergreifende CO-interne Verrechnungen in das FI gebucht werden?
! Markieren Sie in der Variante für Echtzeitintegration CO -> FI den Schalter „PrCtr-übergreifend“.
Analoges gilt für das Durchbuchen ins FI von CO-internen Verrechnungen bei Buchungskreis-,
Geschäftsbereichs-, Funktionsbereichs-, Segment- oder Fondswechsel.
62E. Post cross-profit center CO-internal allocations to FI
? How can I post cross-profit center CO-internal allocations to FI?
! In the variant for real time integration CO -> FI, switch on the indicator “Cross-Profit-Center”. The
same applies if you want to post CO-internal allocations that cause a change in company code,
business area, functional area, segment or grant to FI.
63D. Interne CO-Belege aus Phase 1
Das Migrationsprogramm, das die Belege aus Phase 1 migriert, bearbeitet nur FI-Belege. Das
Programm bearbeitet keine internen CO-Belege (z.B. aus Umlagen), die in Phase 1 erzeugt wurden.
Diese Belege benötigen Sie im Neuen Hauptbuch, da Sie z.B. die klassische Profit Center Rechnung
durch das Neue Hauptbuch ablösen oder weil Sie Kostenarten im Neuen Hauptbuch auswerten.
? Wie können interne CO-Belege aus Phase 1 in das Neue Hauptbuch migriert werden?
! Nach der Aktivierung der “Echtzeitintegration CO -> FI" können Sie das Programm "CO-Belege ins
externe Rechnungswesen überleiten" (= Programm FAGL_COFI_TRANSFER_CODOCS) benutzen.
Dieses Programm selektiert alle CO-Belege mit Buchungsdatum (BUDAT) > “Stichtag: Aktiv ab” in der
Variante der Echtzeitintegration CO -> FI, die nicht in Echtzeit vom CO ins FI gebucht wurden.
Möglicherweise müssen Sie für diese Aktivität geschlossene Perioden wieder öffnen.
63E. Internal CO Documents From Phase 1
The migration program used to transfer documents from phase 1 processes only FI documents. It
does not cover internal CO documents (e.g. from assessment in CO) that were created in phase 1.
You need these documents in new G/L, for example, because you want to replace classic Profit
Center Accounting with new G/L or because you report cost elements in new G/L.
? How can I migrate internal CO documents from phase 1 to new G/L?
! After activation of "Real-time integration CO -> FI", you can use "Transfer CO Documents
Retrospectively" (= program FAGL_COFI_TRANSFER_CODOCS). This program finds all CO
documents whose posting date (BUDAT) is lower than the “active from” date in the variant for real time
integration CO -> FI and that have not been posted in real-time mode from CO into FI.
You may have to reopen closed periods for this activity.
64D. Interne EC-PCA-Belege aus Phase 1
Das Migrationsprogramm, das die Belege aus Phase 1 migriert, bearbeitet nur FI-Belege. Das
Programm bearbeitet keine internen EC-PCA-Belege (z.B. aus Verteilungen), die in Phase 1 erzeugt
wurden.
? Wie können interne EC-PCA-Belege (z.B. aus Verteilungen) aus Phase 1 in das Neue Hauptbuch
migriert werden?
25
! Es ist nicht möglich, interne EC-PCA-Belege aus Phase 1 in das Neue Hauptbuch zu migrieren.
Wenn die internen EC-PCA-Belege aus Allokationen (z.B. Verteilungen) erzeugt wurden, können Sie
im Neuen Hauptbuch neue Zyklen anlegen und die Zyklen für die Perioden der Phase 1 nachträglich
ausführen.
64E. Internal EC-PCA Documents From Phase 1
The migration program used to transfer documents from phase 1 processes only FI documents. It
does not cover internal EC-PCA documents (e.g. from distribution in EC-PCA) that were created in
phase 1.
? How can I migrate internal EC-PCA documents (for example from distribution) from phase 1 to new
G/L?
! It is not possible to migrate internal EC-PCA documents to new G/L. If the internal EC-PCA
documents result from allocations in EC-PCA (e.g. from distribution), you can create new cycles in
new G/L and rerun the cycles in new G/L subsequently for the periods of phase 1.
65D. Ableitung des Funktionsbereichs
Der Hinweis 740519 beschreibt die Ableitung des Funktionsbereichs.
? Ist es möglich, im Neuen Hauptbuch weiterhin die alte Ableitung des Funktionsbereichs zum
Zeitpunkt 0005 (= gefüllt nach Erfassungssicht des Beleges) zu benutzen anstatt zum Zeitpunkt 0006?
! Sie können weiterhin die alte Ableitung des Funktionsbereichs zum Zeitpunkt 0005 nutzen. Es gibt
einen Schalter im Customizing, der es ermöglicht, den Zeitpunkt 0005 im neuen Hauptbuch zu nutzen.
Benutzen Sie den folgenden Pfad im Einführungsleitfaden: -> Finanzwesen (neu) ->
Grundeinstellungen Finanzwesen (neu) -> Werkzeuge -> Kundenerweiterungen -> Ermittlung des
Funktionsbereichs erweitern.
Schalten Sie in der Customizing Transaktion den Schalter „FunktBer. auf Erfassungsbild ermitteln”
aus. Detaillierte Informationen finden Sie in der F1-Hilfe zu diesem Feld.
65E. Derivation of Functional Area
SAP Note 740519 describes the derivation of the functional area.
? When new G/L is active, can I still use the old functional area derivation according to event 0005 (=
populated after the document entry view) instead of using event 0006?
! You can continue to use the old derivation of functional area according to event = 0005.
There is a switch in customizing that makes it possible to use event 0005 in new G/L.
In the Implementation Guide, use the following path: -> Financial Accounting (New) -> Financial
Accounting Basic Settings (New) -> Tools -> Customer Enhancements -> Enhance Determination of
Functional Area.
In this customizing transaction, switch off the indicator "Determine FArea on Entry Screen". For
detailed information, read the F1 help for this field.
66D. Funktionsbereich und Segment im Modul CO (Controlling)
? Was muss im Modul CO (Controlling) für den Funktionsbereich und das Segment beachtet werden?
! Bitte lesen Sie die Hinweise 764485 und 981184.
66E. Functional Area and Segment in Module CO (Controlling)
? What has to be considered in module CO (Controlling) regarding functional area and segment?
! Please see SAP Notes 764485 and 981184.
67D. Fortschreiben des Funktionsbereichs und des Segments in den CO Summensätzen
? Wie können Funktionsbereich und Segment in den CO Summensätzen fortgeschrieben werden?
! Die Fortschreibung von Funktionsbereich und Segment in den Summensätzen des CO wird mit der
folgenden Aktivität im Einführungsleitfaden eingeschaltet:
ECC 5.0: Controlling -> Controlling Allgemein -> Merkmale in CO-Summensätze aufnehmen.
ECC 6.0: Controlling -> Controlling Allgemein -> Merkmale in CO-Summensätze aufnehmen.
Für weitere Informationen beachten Sie bitte den Hinweis 764485.
26
67E. Update of Functional Area and Segment in CO Totals Records
? How can I update the functional area and segment in CO totals records?
! You switch on the update of the functional area and segment the CO totals tables by executing the
following step in the implementation guide:
ECC 5.0: Controlling -> General Controlling -> Add characteristics to CO totals records.
ECC 6.0: Controlling -> General Controlling -> Include characteristics in CO totals records.
For additional information, please see SAP Note 764485.
68D. Einträge im produktiven Mandant in Tabelle T8G10
? Welche Einträge warden im produktiven Mandant in Tabelle T8G10 benötigt?
! Die Tabelle T8G10 hat die Auslieferungsklasse C (= Customizing). Aus diesem Grund werden
während des Upgrades auf mySAP ERP neue Einträge nur im Mandant 000 in die Tabelle T8G10
eingefügt. Bitte transportieren Sie nach dem Upgrade die folgenden Einträge der Tabelle T8G10 vom
Mandant 000 in Ihren produktiven Mandant:
TCODE
PROCESS
VARIANT
FB1D
1010
0001
FB1K
1010
0001
FB1S
1010
0001
FBRA
1020
0001
68E. Entries in Productive Client in Table T8G10
? Which entries are needed in the productive client in table T8G10?
! Table T8G10 belongs to delivery class C (= Customizing). For this reason, during upgrade to mySAP
ERP new entries in table T8G10 are inserted only in client 000. After the upgrade, please transport the
following entries of table T8G10 from client 000 to your productive client:
TCODE
PROCESS
VARIANT
FB1D
1010
0001
FB1K
1010
0001
FB1S
1010
0001
FBRA
1020
0001
69D. Arbeitsvorrat für Nachkontierung der FI-Belege löschen
Der Arbeitsvorrat zur Nachkontierung der FI-Belege kann mit der Transaktion FAGL_MIG_FICHAN
erzeugt werden.
? Wie kann der Arbeitsvorrat zur Nachkontierung der FI-Belege gelöscht werden?
! Dafür steht keine Funktion zur Verfügung.
69E. Delete Work List for Supplementing FI Documents
You can create the work list for supplementing FI documents in transaction FAGL_MIG_FICHAN.
? How can I delete the work list for supplementing FI documents?
! This function is not availbale.
70D. Nicht alle Belege erfolgreich verarbeitet nach der Ausführung des Programms
FAGL_MIG_RPITEMS_CRESPLIT (Belegsplitinformation erzeugen für zu migrierende Belege)
Es kann vorkommen, dass nach dem ersten Lauf des Programms FAGL_MIG_RPITEMS_CRESPLIT
(Belegsplitinformation erzeugen für zu migrierende Belege) nicht alle Belege erfolgreich verarbeitet
wurden.
? Was ist zu tun?.
! Es ist wahrscheinlich, dass der beschriebene Effekt auftritt, wenn Sie buchungskreisübergreifende
Buchungen haben. Ein Grund hierfür ist die Sortier- und Bearbeitungsfolge, die das Programm intern
anwendet.
Die wiederholte Ausführung des Programs FAGL_MIG_RPITEMS_CRESPLIT (Belegsplitinformation
erzeugen für zu migrierende Belege) behebt das Problem.
27
70E. Not All Documents Successfully Processed After Execution of Program
FAGL_MIG_RPITEMS_CRESPLIT (Generate Document Splitting Information for the Documents
to Be Migrated)
In the first run of program FAGL_MIG_RPITEMS_CRESPLIT (Generate document splitting information
for the documents to be migrated), it can happen that not all documents are processed successfully.
? What has to be done?
! This issue is most likely to occur if you have cross-company code postings+ One reason can be the
way the program internally sorts and processes the documents.
To resolve the problem, simple start program FAGL_MIG_RPITEMS_CRESPLIT (Generate document
splitting information for the documents to be migrated) once again.
71D. Laufzeit und Performance „Nachkontierung der FI-Belege erstellen“ (Programm
FAGL_MIG_FICHAN)
? Was ist bei einem Massenlauf des Programms FAGL_MIG_FICHAN bzgl. Laufzeit/Performance zu
beachten?
! Es kann zu einer langen Laufzeit des Programms FAGL_MIG_FICHAN kommen, wenn das
Programm in einem Lauf eine größere Menge an Belegen abarbeiten soll. Hintergrund sind die
technischen Eigenschaften der Spoolverwaltung.
In einem Programmlauf sollen z.B. 100.000 Belege mit 1.000.000 BSEG-Zeilen abgearbeitet werden.
Das Programm FAGL_MIG_FICHAN wird im Hintergrund gestartet. Zunächst arbeitet das Programm
die Belegzeilen ab. Dann wird die Ausgabeliste vorbereitet. Hierbei wird versucht, eine Liste mit
1.000.000 Zeilen in der Spool zu speichern. Der Versuch die Liste zu speichern kann sehr lange
dauern. Bei einem Kunden dauerte die Abarbeitung von 3.000.000 Belegzeilen drei Stunden, die
Spoolerstellung war nach drei Tagen noch nicht beendet.
Lösungen:
- Das Programm nur mit kleineren Mengen an Belegen auf einmal laufen lassen. Das Datenvolumen
kann durch die Eingabe geeigneter Belegnummerintervalle im Selektionsbildschirm portioniert werden.
- Bei einem großen Belegvolumen im Selektionsbildschirm den Schalter "Nur Fehler anzeigen" setzen.
71E. Runtime and Performance of ”Supplementing FI documents“ (Program
FAGL_MIG_FICHAN)
? What has to be considered in a mass run of program FAGL_MIG_FICHAN with regard to runtime
and performance?
! The runtime of a mass run of program FAGL_MIG_FICHAN may be very long if a large amount of
documents needs to be processed. The reason for this lies in the technical characteristics of the spool
controller.
For instance, one program run is meant to process 100,000 documents with 1,000,000 lines in table
BSEG.
Program FAGL_MIG_FICHAN is started in the background. The program first processes the document
line items. After that, the program prepares the spool list. The program tries to store a list with
1,000,000 lines in spool. The attempt to save the list can take very long. At one customer, the
processing of 3,000,000 document line items took three hours, while the creation of the spool request
was not yet finished after three days.
Solutions:
- Execute the program for only a few documents at a time. You can adapt the data volume by entering
intervals for the document numbers in the selection screen.
- When processing a high volume of documents, choose “Display errors only” in the selection screen.
72D. Laufzeit und Performance des Programms FAGL_MIG_SUBSEQ_POST (= Fortschreiben
der Belege des laufenden Jahres in die Neue Hauptbuchhaltung)
? Wie kann die Performance des Programms FAGL_MIG_SUBSEQ_POST (= Fortschreiben der
Belege des laufenden Jahres in die Neue Hauptbuchhaltung) verbessert werden?
! Bitte führen Sie folgende Maßnahmen durch, um die Performance des Programms
FAGL_MIG_SUBSEQ_POST (= Fortschreiben der Belege des laufenden Jahres in die Neue
Hauptbuchhaltung) zu verbessern:
1) Datenbankstatistiken für Tabelle FAGLFLEXA aktualisieren
Die Datenbanktabelle FAGLFLEXA ist vor der Migration leer. Durch das sequentielle Abarbeiten der
einzelnen Arbeitschritte wird die Tabelle schrittweise mit Daten gefüllt. Bei der Übernahme der Belege
28
des laufenden Jahres in das Neue Hauptbuch prüft das Programm bei jedem Beleg, ob er bereits in
der Tabelle FAGLFLEXA existiert. Der Cost-Based Optimizer (CBO) hat während der Migration
allerdings noch nicht die notwendigen Informationen, um für den Zugriff auf die Datenbanktabellen
den richtigen Index zu wählen.
Gehen Sie zur Behebung des Problems wie folgt vor. Sobald die ersten Daten in die Tabellen des
neuen Hauptbuchsgeschrieben wurden (z.B. nach Übernahme der Offenen Posten und vor der
Übernahme der Belege des laufenden Jahres) sollten Sie den CBO ausführen oder die
Tabellenstatistik aufbauen.
Danach sollten die Programme den richtigen Index für den Datenbankzugriff verwenden und die
Laufzeit erheblich optimiert werden.
Im Detail können Sie wie folgt vorgehen. Schalten Sie in der Transaktion ST05 den Trace ein. Starten
Sie dann das Programm FAGL_MIG_SUBSEQ_POST für z.B. einen Beleg. Schalten Sie den Trace
wieder aus und zeigen Sie den Trace an.
Positionieren Sie auf "FAGLFLEXA" und drücken Sie die Drucktaste "Explain". Hier können Sie sehen,
wann die Statistiksätze zuletzt aufgebaut wurden und welcher Index im Zugriff ist. Von hier aus kann
man dann auch den Neuaufbau anstarten.
2) "Parallelisierung" im Selektionsbild des Programms FAGL_MIG_SUBSEQ_POST
Es wird empfohlen, die "Parallelisierung" im Selektionsbild des Programms
FAGL_MIG_SUBSEQ_POST einzuschalten, um die Laufzeit zu reduzieren.
Wenn Sie die "Parallelisierung" nutzen, müssen Sie zwei R/3 Parameter wie folgt einstellen:
rdisp/bufrefmode
sendon,exeauto
rdisp/bufreftime
auf den kleinsten möglichen Wert setzen
Weitere Informationen hierzu finden Sie in Hinweis 384167 und 36283 sowie deren verwandte
Hinweise.
Durch das entsprechende Setzen der R/3 Parameter vermeiden Sie auch die Fehlermeldung GI 754
bei parallelisierter Ausführung des Programms FAGL_MIG_SUBSEQ_POST.
72E. Runtime and Performance of program FAGL_MIG_SUBSEQ_POST (= Update Documents
from Current Year to New General Ledger Accounting)
? How can I improve the performance of program FAGL_MIG_SUBSEQ_POST (= Update Documents
from Current Year to New General Ledger Accounting) ?
! Please do the following in order to improve the performance of
program FAGL_MIG_SUBSEQ_POST (= Update Documents from Current Year to New General
Ledger Accounting):
1) Update database statistics for table FAGLFLEXA
Before the migration, table FAGLFLEXA is empty. The processing of the program steps gradually fills
table FAGLFLEXA with data. When transferring documents from the current year to new G/L, program
FAGL_MIG_SUBSEQ_POST checks for every document whether it exists in table FAGLFLEXA.
During the migration, the Cost-Based Optimizer (CBO) does not yet have the necessary information to
select the right index when accessing the database tables.
Please proceed as follows: Having migrated some data to the new G/L tables (e.g. after migration of
open items and before migration of documents from the current year) you should run CBO or update
database statistics.
After this, the program should select the right database index, and the runtime should be reduced
drastically.
In more detail, you can proceed as follows. Activate the trace in transaction ST05. Run program
FAGL_MIG_SUBSEQ_POST e.g. for one document. Deactivate the trace and display the trace.
Put the cursor on "FAGLFLEXA" and press button "Explain". You can see when statistics were created
for the last time and which index is being used. Here you can also start the update of the statistics.
2) "Execute with Para.Proc." in the selection screen of program FAGL_MIG_SUBSEQ_POST
It is recommended to switch on "Execute with Para.Proc." in the selection screen of program
FAGL_MIG_SUBSEQ_POST in order to reduce the runtime.
When you switch on "Execute with Para.Proc.", you have to set two R/3 parameters as follows:
rdisp/bufrefmode
sendon,exeauto
rdisp/bufreftime
set this parameter to the lowest possible value
For more information, please see SAP Notes 384167 and 36283 as well as related Notes.
If you set the parameters accordingly, you will avoid error message GI 754 during parallel processing
of program FAGL_MIG_SUBSEQ_POST.
29
73D. Parallelisierung des Programms FAGL_MIG_OPITEMS_CRESPLIT
Das Programm FAGL_MIG_OPITEMS_CRESPLIT erzeugt die Informationen für die Belegaufteilung
für offene Posten.
? Kann das Programm FAGL_MIG_OPITEMS_CRESPLIT parallelisiert warden?
! Es ist nicht möglich, das Programm FAGL_MIG_OPITEMS_CRESPLIT gleichzeitig mehrfach parallel
auszuführen. Dies gilt auch dann, wenn sich die Selektion auf unterschiedliche Migrationspläne
bezieht.
Wenn Sie versuchen, das Program FAGL_MIG_OPITEMS_CRESPLIT ein zweites Mal parallel zu
starten, erhalten Sie die Meldung MC 601 ' Das angeforderte Objekt ist momentan gesperrt durch
User ...' .
Die Ursache ist das Design des Programms und das Design der Migration.
73E. Parallelization of Program FAGL_MIG_OPITEMS_CRESPLIT
Program FAGL_MIG_OPITEMS_CRESPLIT generates the document splitting information for open
items.
? Is it possible to parallelize the program FAGL_MIG_OPITEMS_CRESPLIT?
! It is not possible to run program FAGL_MIG_OPITEMS_CRESPLIT more than once at a time. This
applies even if the selection refers to different migration plans.
If you try to start program FAGL_MIG_OPITEMS_CRESPLIT in parallel mode, message MC 601 'the
requested object is currently locked by user ...' is displayed.
The reason for this is the design of the program and the design of the migration itself.
74D. Parallelisierung des Programms FAGL_MIG_RPITEMS_CRESPLIT
Das Programm FAGL_MIG_RPITEMS_CRESPLIT erzeugt die Informationen für die Belegaufteilung
für die Belege des laufenden Jahres.
? Kann das Programm FAGL_MIG_RPITEMS_CRESPLIT parallelisiert werden?
! Es ist nicht möglich, das Programm FAGL_MIG_RPITEMS_CRESPLIT gleichzeitig mehrfach parallel
auszuführen. Dies gilt auch dann, wenn sich die Selektion auf unterschiedliche Migrationspläne
bezieht.
Das Programm setzt ein LOCK auf einige Datenbanktabellen der Migration. Dies ist notwendig, um die
Konsistenz der Migration sicherzustellen.
74E. Parallelization of Program FAGL_MIG_RPITEMS_CRESPLIT
Program FAGL_MIG_RPITEMS_CRESPLIT generates the document splitting information for
documents of the current year.
? Is it possible to parallelize the program FAGL_MIG_RPITEMS_CRESPLIT?
! It is not possible to run program FAGL_MIG_RPITEMS_CRESPLIT more than once at a time. This
applies even if the selection refers to different migration plans.
The program sets a LOCK on some of the database tables for the migration to ensure data
consistency.
75D. Datenbank
? Was sollte im Hinblick auf die Datenbank vor der produktiven Migration beachtet werden?
! Es gibt zwei zentrale Aspekte. Erstens wird ein full backup benötigt bevor Sie die produktive
Migration starten. Zweitens sollte das Logging der Datenbank abgeschaltet warden bevor Sie die
produktive Migration starten.
75E. Database
? What has to be considered regarding the database before the productive migration?
! There are two major aspects. First, a full backup must be made before the productive migration is
started. Second, database logging should be switched off before the start of the productive migration.
76D. Vorgehensweise zur Minimierung der Downtime für die produktive Migration
? Welche Vorgehensweise gibt es, um die Downtime der produktiven Migration zu minimieren?
! Als Voraussetzungen für den Beginn der produktiven Migration muss der Jahresabschluss des
30
Vorjahres durchgeführt und testiert sein, es muss sichergestellt sein, dass es in der Zukunft nicht
notwendig wird, in das Vorjahr zu buchen und das Neue Hauptbuch muss endgültig konfiguriert sein.
Ein inkrementeller Ansatz ermöglicht es, die notwendige Downtime der produktiven Migration zu
minimieren. Das zentrale Element des inkrementellen Ansatzes ist es, die Mehrheit der Daten
während des produktiven Betriebs zu migrieren.
Im Einzelnen migrieren Sie im inkrementellen Ansatz Salden und offene Posten in einer ersten Welle
vor der Downtime während des normalen R/3-Betriebs. In einer zweiten Welle migrieren Sie die
Belege des laufenden Jahres ebenfalls während des normalen R/3-Betriebs. Während der Downtime
migrieren Sie die restlichen Belege des laufenden Jahres in einer dritten Welle.
In der ersten Welle können Sie in der Phase 1 Salden und offene Posten ohne Systemausfall parallel
zum normalen R/3-Produktivbetrieb migrieren. Falls Probleme bei der Migration der Salden und
offenen Posten auftreten, können Sie im laufenden Produktivbetrieb die Migration mit der Transaktion
FAGL_MIG_RESTORE_ALL zurücksetzen.
In der zweiten Welle migrieren Sie die Belege des laufenden Jahres in das Neue Hauptbuch parallel
zum normalen R/3-Betrieb. Mit der zweiten Welle können Sie z.B. zwei Wochen vor der Downtime
beginnen. Führen Sie die Programme „Arbeitsvorrat für Belege erstellen“, (Programm
FAGL_MIG_RPITEMS_FILL), "Belegaufteilungsinformation für die zu übertragenden Belege
aufbauen" (Programm FAGL_MIG_RPITEMS_CRESPLIT) und "Fortschreiben der Belege in die neue
Hauptbuchhaltung" (Programm FAGL_MIG_SUBSEQ_POST) aus.
Nach der erstmaligen Migration der Belege des laufenden Jahres können Sie dies täglich
wiederholen, indem Sie die Jobs z.B. wiederholend einmal in der Nacht einplanen.
Jedesmal wenn Sie die Programme ausführen, werden die Belege, die seit dem letzten Programmlauf
gebucht wurden, in das Neue Hauptbuch migriert. Setzen Sie nach der erstmaligen Migration der
Belege des laufenden Jahres immer das Kennzeichen “komplett nachlesen“ im Selektionsbild des
Programms „Arbeitsvorrat für Belege erstellen“ (Programm FAGL_MIG_RPITEMS_FILL).
In der dritten Welle während der Downtime werden die restlichen Belege des laufenden Jahres, die
nach der zweiten Welle gebucht wurden, migriert. Während der Systemausfallzeit bauen Sie ein
letztes Mal den Arbeitsvorrat für Belege des laufenden Jahres auf und führen ein letztes Mal das
Programm aus, das die Belegaufteilungsinformation aufbaut. Dann migrieren Sie die restlichen Belege
des laufenden Geschäftsjahres. Das heißt, dass Sie noch einmal die Programme „Arbeitsvorrat für
Belege erstellen“, (Programm FAGL_MIG_RPITEMS_FILL), "Belegaufteilungsinformation für die zu
übertragenden Belege aufbauen" (Programm FAGL_MIG_RPITEMS_CRESPLIT) und "Fortschreiben
der Belege in die neue Hauptbuchhaltung" (Programm FAGL_MIG_SUBSEQ_POST) ausführen.
Beachten Sie in der dritten Welle bitte zwei Aspekte. Setzen Sie erstens das Kennzeichen “komplett
nachlesen“ im Selektionsbild des Programms „Arbeitsvorrat für Belege erstellen“ (Programm
FAGL_MIG_RPITEMS_FILL). Schalten Sie zweitens im Selektionsbild des Programms "Fortschreiben
der Belege in die neue Hauptbuchhaltung" (Programm FAGL_MIG_SUBSEQ_POST) das
Kennzeichen „Parallelisiert ausführen“ aus.
Nach erfolgreicher Abstimmung der Daten des klassischen Hauptbuchs mit den Daten des Neuen
Hauptbuchs aktivieren Sie während der Downtime das Neue Hauptbuch.
Zusammenfassend werden im inkrementellen Ansatz nur die Aktivitäten, die als dritte Welle
bezeichnet sind, in der Downtime durchgeführt. Alles andere kann vorher parallel zum normalen R/3Betrieb durchgeführt werden.
76E. Approach for Minimizing Downtime of Productive Migration
? What can I do in order to minimize the downtime for productive migration?
! Prerequisites for beginning the productive migration are that the fiscal year closure for the previous
fiscal year has been finalized and approved by your auditor, that there is no more need for postings to
the previous fiscal year and that the customizing of new G/L is finalized.
The incremental approach minimizes the downtime required for the productive migration. The
cornerstone of the incremental approach is to migrate most of the data whilst the system is up and
running.
In detail, in the incremental approach means that you migrate balances and open items in a first wave
before the downtime whilst the system is up. In a second wave, you migrate documents of the current
fiscal year - also whilst the system is up. During the downtime, the remaining documents of the current
fiscal year are migrated in a third wave.
In the first wave during phase 1, you can transfer balances and open items without any system
downtime in parallel to day-to-day business. If the migration of balances and open items fails, you can
reset the migration using transaction FAGL_MIG_RESTORE_ALL whilst the productive system is
open for users.
In the second wave, you transfer documents from the current year to new G/L in parallel to day-to-day
business. You can start the second wave, for example, two weeks before the downtime. Run
31
programs "Create worklist for documents" (program FAGL_MIG_RPITEMS_FILL), "Build document
splitting information" (program FAGL_MIG_RPITEMS_CRESPLIT) and "Transfer documents to New
General Ledger Accounting" (program FAGL_MIG_SUBSEQ_POST).
After this initial migration of documents from the current year, you can repeat this process every day
by scheduling recurring jobs (for example once a day at night time). Every time you run the jobs, the
documents that have been posted since the last program run are migrated to new G/L. After the initial
migration of documents from the current year, always flag "Read completely" in the selection screen of
"Create worklist for documents" (program FAGL_MIG_RPITEMS_FILL).
In the third wave during the downtime, the remaining documents that were posted in the current year
since the second wave are migrated. During the system downtime, you create a last worklist for
documents and run the program that generates the document splitting information. Then you transfer
the remaining documents from the current fiscal year by once again running programs "Create worklist
for documents" (program FAGL_MIG_RPITEMS_FILL), "Build document splitting information"
(program FAGL_MIG_RPITEMS_CRESPLIT) and "Transfer documents to New General Ledger
Accounting" (program FAGL_MIG_SUBSEQ_POST).
In the third wave, consider the following two aspects. First, set the "Read completely" indicator in the
selection screen of program "Create worklist for documents" (FAGL_MIG_RPITEMS_FILL). Second,
deselect "Execute with Para. Proc." in the selection screen of program "Transfer documents to New
General Ledger Accounting" (FAGL_MIG_SUBSEQ_POST) do not flag.
You activate new G/L during the downtime after successful reconciliation of the data in classic G/L and
new G/L.
To summarize, the incremental approach means that only the activities for the third wave are
performed during the downtime. Everything else can be done before in parallel to normal business
whilst the productive system is open for users.
77D. Deaktivierung der klassischen Profit Center Rechnung (EC-PCA)
? Wie kann nach Aktivierung des Neuen Hauptbuchs die klassische Profit Center Rechnung (EC-PCA)
deaktivieren?
! Der Hinweis 702854 erläutert, wie die klassische Profit Center Rechnung deaktiviert werden kann.
Wenn Sie in ERP2004 die Belegaufteilung für Profit Center nutzen, löschen Sie bitte zusätzlich das
Dummy Profit Center aus der Tabelle TKA01. Der Hinweis 702854 stellt hierfür das Programm
Z30PCA23 zur Verfügung. Bitte verwenden Sie das Programm Z30PCA23 um das Dummy Profit
Center der klassischen Profit Center Rechnung im Kostenrechnungskreis zu löschen.
77E. Deactivation of Classic Profit Center Accounting (EC-PCA)
? How can I deactivate classic Profit Center Accounting (EC-PCA) after activation of new G/L?
! SAP Note 702854 explains how to deactivate classic Profit Center Accounting.
If you use document splitting for profit centers in ERP2004, please delete additionally the dummy profit
center from table TKA01. Please use program Z30PCA23, which is provided with SAP Note 702854,
to delete the dummy profit center of classic Profit Center Accounting in the controlling area.
78D. Löschen der Tabellen FAGL_MIG* nach der produktiven Migration
Die Tabellen der Migration (Tabellen FAGL_MIG*) belegen viel Speicherplatz (z.B. 350 MB).
? Ist es erlaubt, die Tabellen FAGL_MIG* nach der produktiven Migration zu löschen?
! Nein. Der Inhalt der Tabellen FAGL_MIG* muss in der Datenbank bleiben. Die Daten der Tabellen
FAGL_MIG* werden benötigt, um die Migration zu verifizieren und für Kontrollen und Prüfungen.
78E. Deletion of Tables FAGL_MIG* After Productive Migration
The tables that are needed for the migration (tables FAGL_MIG*) take up a lot of disk space (e.g. 350
MB).
? Is it allowed to delete the FAGL_MIG* tables after the productive migration?
! No. The content of the FAGL_MIG* tables must remain in the database. The data from the
FAGL_MIG* tables is needed for verification of the migration and for controls and checks.
32
79D. Änderungen im Customizing bei produktivem Neuem Hauptbuch
? Sind Änderungen im Customizing des Neuen Hauptbuchs möglich, wenn das Neue Hauptbuch
bereits produktiv genutzt wird?
! Beachten Sie hierzu den Hinweis 891144.
79E. Changes in Customizing When NewG/L Is Active
? Is it possible to change the configuration of new G/L when new G/L is active and has been used in
production?
! Please see SAP Note 891144.
80D. Abstimmung Belege – Verkehrszahlen – Indices im Neuen Hauptbuch
? Können die aus dem klassischen Hauptbuch bekannten Reports RFINDEX und SAPF190 zur
Abstimmung Belege – Verkehrszahlen – Indizes auch im Neuen Hauptbuch genutzt werden?
! Im Neuen Hauptbuch übernimmt der Report TFC_COMPARE_VZ (= Transaktion FAGLF03) die
Abstimmung zwischen den Summensätzen (Tabelle FAGLFLEXT), Einzelposten (Tabelle
FAGLFLEXA) und FI-Belegen (Tabellen BKPF und BSEG). Beachten Sie hierzu auch die Hinweise
862523 und 946596.
80E. Reconciliation of Documents – Totals – Indexes in NewG/L
? Can I continue to to use reports RFINDEX and SAPF190 (from classic G/L) for reconciliation of
documents – totals – indexes in new G/L?
! In new G/L, please use report TFC_COMPARE_VZ (= transaction FAGLF03) to reconcile totals
(table FAGLFLEXT), line items (table FAGLFLEXA) and FI documents (tables BKPF and BSEG).
Please see also SAP Notes 862523 and 946596.
81D. Abstimmung Neues Hauptbuch und Anlagenbuchhaltung (FI-AA)
? Im klassischen Hauptbuch gibt es die Reports RAABST01 und RAABST02, um das Hauptbuch mit
der Anlagebuchhaltung (FI-AA) abzustimmen. Welche Reports gibt es, um das Neue Hauptbuch mit
der Anlagenbuchhaltung (FI-AA) abzustimmen?
! Sie können den Report RAABST01 nutzen, um das Neue Hauptbuch mit der Anlagenbuchhaltung
abzustimmen. Voraussetzung ist ECC 5.0 Support Package 01 oder der Einbau des Hinweises
752329.
Sie können den Report RAABST02 nutzen, um das Neue Hauptbuch mit der Anlagenbuchhaltung
abzustimmen. Voraussetzung ist ECC 5.0 Support Package 14 oder ECC 6.0 Support Package 7. Ein
Downgrade dieser Funktionalität ist nicht möglich. Bitte beachten Sie den Hinweis 897388.
Eine Abstimmung Neues Hauptbuch und Anlagenbuchhaltung unterhalb der Ebene Buchungskreis /
Konto (z.B. auf Profit Center oder Segment) wird z.Zt. nicht unterstützt.
Allgemeine Informationen zur Abstimmung Hauptbuch und Anlagenbuchhaltung (FI-AA) finden Sie in
Hinweis 543151.
81E. Reconciliation of NewG/L and Asset Accounting (FI-AA)
? In classic G/L, reports RAABST01 and RAABST02 are available to reconcile G/L and Asset
Accounting (FI-AA). Which reports are available to reconcile new G/L and Asset Accounting (FI-AA)?
! You can use report RAABST01 to reconcile new G/L and FI-AA. Prerequisite: ECC 5.0 Support
Package 01 or implementation of SAP Note 752329.
You can also use report RAABST02 to reconcile new G/L and FI-AA. Prerequisite: ECC 5.0 Support
Package 14 or ECC 6.0 Support Package 7. It is not possible to downgrade this functionality. See also
SAP Note 897388.
The reconciliation of new G/L and FI-AA on a level below company code and account (e.g profit center
or segment) is presently not supported.
For general information on reconciliation of G/L and Asset Accounting (FI-AA), please see SAP Note
543151.
82D. Abstimmung Neues Hauptbuch und Controlling (CO)
Die CO-Echtzeitintegration und das Neue Hauptbuch sind aktiv.
? Wie können die Daten des Neuen Hauptbuchs mit dem Controlling (CO) abgestimmt werden?
33
! Die Abstimmung kann mit Hilfe der Transaktion FAGLCORC durchgeführt werden. Weitere
Informationen finden Sie in Hinweis 908019.
82E. Reconciliation of New G/L and Controlling (CO)
CO-FI real-time integration and new G/L are active.
? How can I reconcile data in new G/L and data in Controlling (CO)?
! Please use transaction FAGLCORC for the reconciliation. For more information, see SAP Note
908019.
83D. Analyse von Inkonsistenzen im Neuen Hauptbuch
Im neuen Hauptbuch stimmen die Einzelposten nicht mit den zugehörigen Summensätzen überein
oder die Summensätze werden nicht richtig fortgeschrieben.
? Welches Werkzeug ist für die Analyse dieser Inkonsistenzen vorhanden?
! Bitte beachten Sie den Hinweis 940668.
83E. Analysis of Inconsistencies in New G/L
In new G/L, line items do not correspond to the corresponding totals records, or the totals records are
not updated correctly.
? Which tool is available for the analysis of these inconsistencies?
! See SAP Note 940668.
84D. Allokationen für Bilanz- und Abstimmkonten im Neuen Hauptbuch
? Was ist zu beachten bei Allokationen für Bilanz- und Abstimmkonten im Neuen Hauptbuch?
! Bitte lesen Sie die Hinweise 830556 und 900962.
84E. Allocations for Balance Sheet Accounts and Reconciliation Accounts in New G/L
? What has to be considered for allocations for balance sheet accounts and reconciliation accounts in
new G/L?
! See SAP Notes 830556 and 900962.
85D. Report RCOPCA02 (Profit Center: Isteinzelposten)
? Welcher Report in der Neuen Hauptbuchhaltung hat die gleiche Funktionalität wie der Report
RCOPCA02 (Profit Center: Ist-Einzelposten) in der klassischen Profit Center Rechnung?
! Die Transaktion FAGLL03 in der Neuen Hauptbuchhaltung hat die gleiche Funktionalität wie der
Report RCOPCA02 (Profit Center: Ist-Einzelposten) bzw. die Transaktion KE5Z in der klassischen
Profit Center Rechnung.
85E. Report RCOPCA02 (Profit Center: Actual Line Items)
? Which report in new general ledger accounting has the same features as report RCOPCA02 (Profit
Center: Actual Line Items) in classic Profit Center Accounting?
! Transaction FAGLL03, which is available in new general ledger accounting, has the same features
as report RCOPCA02 (Profit Center: Actual Line Items) or transaction KE5Z in classic Profit Center
Accounting.
86D. Selektion von kundenspezifischen Feldern in der Einzelpostenanzeige des Neuen
Hauptbuchs
? Ist es möglich, in der Einzelpostenanzeige des neuen Hauptbuchs (= Transaktion FAGLL03) nach
kundenspezifischen Feldern zu selektieren?
! Der Hinweis 945932 erläutert, wie Sie in der Einzelpostenanzeige des neuen Hauptbuchs (=
Transaktion FAGLL03) nach kundenspezifischen Feldern selektieren können.
86E. Selection of Customer-Specific Fields in Line Item Display in New G/L
? Is it possible to select customer-specific fields in the line item display in new G/L (= transaction
FAGLL03)?
34
! SAP Note 945932 explains how to select customer-specific fields in the selection screen of line item
display for new general ledger accounting (transaction FAGLL03).
87D. Anzeige, Sortierung und Summenbildung von kundenspezifischen Feldern in der
Einzelpostenanzeige des Neuen Hauptbuchs
? Ist es möglich, in der Einzelpostenanzeige des neuen Hauptbuchs (= Transaktion FAGLL03)
kundenspezifische Felder anzuzeigen und nach kundenspezifischen Feldern zu sortieren und zu
summieren?
! Der Hinweis 984305 erläutert, wie Sie in der Einzelpostenanzeige des neuen Hauptbuchs (=
Transaktion FAGLL03) kundenspezifische Felder anzeigen und nach kundenspezifischen Feldern
sortieren und summieren können.
87E. Display, Sorting and Summarization of Customer-Specific Fields in Line-Item Display in
New G/L
? Is it possible to display, sort and summarize customer-specific fields in the line item display (=
transaction FAGLL03) in new G/L?
! SAP Note 984305 explains how to display, sort and summarize customer-specific fields in the line
item display for new general ledger accounting (= transaction FAGLL03).
88D. Gegenkonto in Einzelpostenanzeige
? Wie kann das Gegenkonto in der Einzelpostenanzeige angezeigt werden?
! Der Hinweis 112312 beschreibt, wie Sie im klassischen Hauptbuch das Gegenkonto in der
Einzelpostenanzeige anzeigen können.
Der Hinweis 1034354 beschreibt, wie Sie im Neuen Hauptbuch das Gegenkonto in der
Einzelpostenanzeige anzeigen können.
88E. Offsetting Account (= Contra Account) in Line Item Display
? How can I display the offsetting account (= contra account) in line item display?
! SAP Note 112312 describes how you can display the offsetting account (= contra account) in line
item display in classic G/L.
SAP Note 1034354 describes how you can display the offsetting account (= contra account) in line
item display in new G/L.
89D. Feld „Alternative Kontonummer“ im Reporting des Neuen Hauptbuchs
? Was kann die Ursache dafür sein, dass die "Alternative Kontonummer" im Reporting des Neuen
Hauptbuchs nicht angezeigt wird?
! Gehen Sie bitte wie folgt vor, damit das Feld "Alternative Kontonummer" im Reporting des Neuen
Hauptbuchs angezeigt wird.
1) Bitte bauen Sie die Hinweise 895609 und 939649 ein.
2) Damit das Feld "Alternative Kontonummer" in der Zeilenaufbauvariante angezeigt wird, gehen Sie
bitte wie folgt vor:
- Rufen Sie die Transaktion o7r3 auf und fügen Sie BSEG-LOKKT als Sonderfeld
hinzu.
- Ändern Sie dann die Zeilenaufbauvariante. Das Feld "Alternative Kontonummer" wird
angezeigt.
3) In der Einzelpostenanzeige im klassischen Hauptbuch (Transaktion FBL3N) konnten Sie gemäß
Hinweis 310886 die freien Abgrenzungen in der Transaktion SE36 erweitern. Im neuen Hauptbuch
gibt es verschiedene Teilbereiche für die freien Abgrenzungen in der Transaktion FAGLL03. Jeder
Teilbereich entspricht einer Struktur:
Sachkontenstamm
SKA1_FS
Sachkonto Buchungskreis
SKB1_FS
Sachkonto Einzelposten BSIS_FS
Da das Feld "Alternative Kontonummer" in der Standardauslieferung nicht in der Struktur SKB1_FS
enthalten ist, führen Sie bitte die Erweiterung durch, die in Hinweis 945932 beschrieben ist. Um
weitere Felder in die freien Abgrenzungen der Transaktion FAGLL03 aufzunehmen, können Sie die
Strukturen mit einem APPEND erweitern.
35
89E. Field „Alternative Account Number“ in New G/L Reporting
? Why is the "Alternative account number" not displayed in new G/L reporting in some cases?
! To display the field "Alternative account number" in new G/L reporting, please proceed as follows:
1) Implement SAP Notes 895609 and 939649.
2) To display “alternative account number” in the layout, please do the following:
- Run transaction o7r3 and add BSEG-LOKKT as special field.
- Then use the change layout function to display field "alternative account
no.".
3) In G/L account line item display in classic G/L (transaction FBL3N), you could enhance the 'dynamic
selections' in transaction SE36 as described in SAP Note 310886. In new G/L, however, the custom
selection in transaction FAGLL03 has different 'sub-areas'. Each of these areas corresponds to a
structure:
G/L account master record
SKA1_FS
G/L account company code
SKB1_FS
G/L account line item
BSIS_FS
As the "Alternative account number" is not included in the standard configuration of SKB1_FS, please
implement the enhancement as described in SAP Note 945932. To include more fields in the custom
selections of transaction FAGLL03, you can enhance the structures using an APPEND.
90D. Segment Reorganisation
Segment Reorganisation ist der Begriff für die Möglichkeit, in einem Profit Center das Segment zu
ändern wenn auf diesem bereits Bewegungsdaten gespeichert sind.
? Ist es möglich, das Segment in einem Profit Center zu ändern, wenn auf diesem bereits
Bewegungsdaten gespeichert sind?
! Nein. Der Hinweis 940721 beschreibt den momentanen Status im Standard R/3.
SAP hat in der Planung für künftige R/3-Releases keine Funktionen für Segment Reorganisation
vorgehesen. Es kann nicht vorhergesagt werden, ob bzw. wann SAP Funktionen für Segment
Reorganisation im R/3 Standard anbieten wird.
Ein praktikabler Ansatz für Segment Reorganisation kann in einer kundenspezifischen Lösung
bestehen.
Kurzfristig können Sie den folgenden Ansatz verfolgen, der allerdings nur eine technische Lösung
betrachtet. Entfernen Sie die Hinweise 940440, 1037986 und 940629 aus Ihrem System. Danach
definieren Sie das „Segment“ als zeitabhängiges Feld in der Transaktion 0KE7. Jetzt können Sie das
Segment in den Profit Center Stammdaten auch ändern wenn Bewegungsdaten gespeichert sind.
Bitte beachten Sie, dass diese Lösung die Datenintegrität nicht sicherstellt. Z.B. müssen Sie zusätzlich
manuell die Salden des Profit Centers vom alten Segment in das neue Segment umbuchen.
90E. Segment Realignment
Segment realignment is the term for the possibility to change a segment in a profit center when
transaction data are already stored.
? Is it possible to change a segment in a profit center when transaction data are already stored?
! No. Note 940721 describes the current status in standard R/3.
In the current SAP release planning, SAP has not included any functions for segment realignment in
the standard of future R/3 releases. It is not predictable whether or when SAP will offer functionality for
segment realignment in R/3 standard.
The feasible approach for segment realignment will be a customer specific solution.
On short term basis, you can use the following approach which considers only a technical solution.
Undo notes 940440, 1037986 and 940629 in your system. After this, set “segment” as time based
field in transaction 0KE7. Then you can change the segment in profit center master data although
transaction data exist. Please take into account that this solution does not assure data integrity. E.g.
reposting of the profit center balances from the old segment to the new segment must be done in
addition manually.
91D. Änderung Profit Center in Kostenstelle mit Anlagenbuchhaltung
Das neue Hauptbuch ist aktiv. Das Szenario „Profitcenter-Fortschreibung“ ist dem Ledger zugeordnet.
In den Anlagenstammsätzen sind Kostenstellen gespeichert. Sie ändern das Profit Center in einer
36
Kostenstelle, die in Anlagenstammsätzen gespeichert ist.
? Wie werden die zugehörigen Salden pro Profit Center z.B. für Anschaffungs- und Herstellkosten in
der neuen Hauptbuchhaltung umgebucht?
! Es gibt keinen Automatismus, der die Salden pro Profit Center im neuen Hauptbuch umbucht
nachdem das Profit Center in einer Kostenstelle geändert wurde, wenn die Kostenstelle in
Anlagenstammsätzen verwendet wird. Als Workaround können Sie eine manuelle Korrekturbuchung
durchführen.
Gehen Sie wie folgt vor.
1) Ermitteln Sie die Werte, die Sie umbuchen müssen. Hierfür können Sie den Report RABEST01
verwenden. Füllen Sie das Feld „Kostenstelle“ im Selektionsbild des Reports RABEST01 mit der
Kostenstelle, die einem anderen Profit Center zugeordnet wurde.
2) Setzen Sie den Status auf “1” in den Buchungskreisen, in denen Sie Korrekturbuchungen erfassen
müssen. Wählen Sie hierfür im Einführungsleitfaden den Pfad
Finanzwesen -> Anlagenbuchhaltung -> Produktionsvorbereitung -> Produktivstart -> Buchungskreis
produktiv setzen.
3) Verwenden Sie die Transaktion OASV um Anpassungsbuchungen von Profit Center / an Profit
Center auf Abstimmkonten der Anlagenbuchhaltung zu erfassen.
4) Setzen Sie danach den Status der Buchungskreise zurück auf "0".
91E. Change of Profit Center in Cost Center and Asset Accounting
New G/L is active. The scenario “Profit Center Update” is assigned to the ledger. Cost centers are
stored in asset account master data. You change the profit center in a cost center which is used in
asset account master data.
? How are balances by profit center (e.g for acquisition and production costs) reposted in new G/L?
! There is no automatism that changes balances by profit center in new G/L after the profit center has
been changed in a cost center that is used in asset master data. As a workaround, you can do a
manual correction posting.
Proceed as follows.
1) Identify the values you have to repost, for example by using report RABEST01. Fill field "Cost
center" in the selection screen of report RABEST01 with the cost center that has been assigned to a
different profit center.
2) Set the status to "1" in the company codes that require adjustment postings. To do so, use the
following path in the implementation guide: Financial Accounting -> Asset Accounting -> Preparing for
Production Startup -> Production Startup -> Activate Company Code.
3) Use transaction OASV to do adjustment postings credit / debit profit center on reconciliation
accounts in asset accounting.
4) Afterwards, set the status of the company codes back to "0".
92D. Migrationscockpit
? Was ist das Migrationscockpit?
! Das Migration Cockpit ist das von SAP empfohlene Migrationswerkzeug. Das Migrationscockpit stellt
zu einem gewissen Grad vorkonfigurierte Migrationspakete zur Verfügung, die geladen werden
können, um vom klassischen Hauptbuch ins Neue Hauptbuch zu migrieren.
Abhängig vom Migrationsszenario können Sie das passende Migrationspaket laden, das die
Migrationsschritte in einer Ablaufstruktur enthält,
Der Hinweis 1019774 enthält die Anleitung zur Installation des Migrationscockpits.
92E. Migration Cockpit
? What is the migration cockpit?
! The migration cockpit is the migration tool recommended by SAP. The migration cockpit includes
migration packages that are preconfigured to some exent and can be loaded for the migratation from
classic general ledger to new general ledger accounting.
Depending on the migration scenario, you can load the required migration package, which includes
the migration steps in sequence in the form of a process tree.
Instructions for installing the migration cockpit are provided in SAP Note 1019774.
37
93D. SAP Migrationsservice neues Hauptbuch
? Wo erhalte ich Informationen zum SAP Migrationsservice neues Hauptbuch?
! Bitte lesen Sie den Hinweis 812919.
93E. FI document display and new general ledger active? Where can I find information about SAP
General Ledger Migration service?
! Please see SAP Note 812919.
94D. FI-Beleganzeige und Neues Hauptbuch aktiv
? Warum gibt es bei aktivem neuem Hauptbuch Belege, die in der FI-Beleganzeige (Transaktion
FB03) nur die Erfassungssicht und keine Hauptbuchsicht haben?
! Aus dem Buchungsstoff der Geschäftsjahre vor dem Migrationsdatum werden nur offene Posten und
Salden in das neue Hauptbuch migriert. FI-Belege mit einem Buchungsdatum, das vor dem
Migrationsdatum liegt, werden nicht in das Neue Hauptbuch migriert. Daher wird zu diesen Belegen
keine Hauptbuchsicht erzeugt.
Somit ist es ein korrektes Systemverhalten, dass FI-Belege, deren Buchungsdatum vor dem
Migrationsdatum liegen, in der FI-Beleganzeige (Transaktion FB03) nur eine Erfassungssicht und
keine Hauptbuchsicht haben.
94E. FI document display and new general ledger active
? When new G/L is active why do documents exist which in FI document display (transaction FB03)
have a data entry view but no general ledger view?
! From the posting data in fiscal years prior to the migration date, only open items and balances are
migrated to new G/L. FI documents with a posting date prior to the migration date are not migrated to
new G/L. Hence no general ledger view is created for these documents.
Hence it is correct system behavior that FI documents with posting date prior to the migration date in
FI document display (transaction FB03) have a data entry view but no general ledger view.
38