/image%2F1473637%2F20170207%2Fob_adae32_profilbild.png)
co
ALE Verteilung von CO Innenaufträgen mit Z-Feldern
Die Verteilung von CO Innenaufträgen per ALE mithilfe des Nachrichtentyps INTERNAL_ORDER funktioniert im Prinzip problemlos und ist auch schnell konfiguriert. Komplizierter wird's da schon, wenn Kundenerweiterungen in Form von Z-Feldern im Spiel sind. Mein Kollege Markus Läller hat sich dieser Problematik im Rahmen eines Kundenprojektes annehmen müssen und hat seine Erkenntnisse dankenswerterweise in Form einer Schritt-für-Schritt-Anleitung aufgeschrieben. Das komplette Dokument findet ihr hier:
/https%3A%2F%2Flh6.googleusercontent.com%2FZdrrUZ1IdX2aNgHtJmy8mBXmKFMaGhOPvhZkmwWuviqVZBdlldLmIw%3Dw1200-h630-p)
Nach dem Studium des o.g. Dokuments sagt sich der ein oder andere vielleicht: "hmm - möglicherweise doch keine gute Idee, Z-Felder in verteilten Systemen zu verwenden...".
Muss vielleicht auch nicht sein. Im Auftragsstammsatz (Tab. AUFK) gibt es diverse vordefinierte Userfelder verschiedener Datentypen, die kundenspezifische Informationen beherbergen können:
- USER0 CHAR 20
- USER1 CHAR 20
- USER2 CHAR 20
- USER3 CHAR 20
- USER4 CURR 11 (Betrag)
- USER5 DATS 8
- USER6 CHAR 15
- USER7 DATS 8
- USER8 DATS 8
- USER9 CHAR 1 (Ankreuzfeld)
Die Felder sind in der SAP-Auslieferung schon mit Bezeichnungen versehen (z,B. USER0 = 'Antragsteller'), die auf den ersten Blick den Eindruck erwecken, dass es sich um Standard-Felder mit fester interner Verwendung handelt, ist aber nicht so. Details hierzu finden sich im Customizing unter Controlling - Innenaufträge - Auftragsstammdaten - Bildschirmgestaltung - Individuelle Stammdatenfelder ändern.
Anders als in der o.g. Customizing-Doku beschrieben, würde ich in verteilten Systemen davon abraten, den User-Feldern eigene/abweichende Datenelemente zuzuordnen, da diese sonst von denen in den korrespondierenden IDoc-Strukturen abweichen. Natürlich könnte man auch die anpassen, aber ob das dann noch alles kompatibel ist...? Am Ende muss man sich dann womöglich doch durch die oben verlinkte Anleitung kämpfen.
Einfacher hat man es da natürlich, wenn man mit den oben aufgelisteten Feldern/Datentypen auskommen kann. Die Bezeichnungen lassen sich modifikationsfrei mithilfe der "globalen Erweiterungen" kundenspezifisch anpassen (Transaktion CMOD, Menü: Springen - Glob. Erweiterungen - Schlüsselworte - Ändern...)
Um bspw. die Bezeichnung zum Feld USER0 zu ändern, wählt man das zugehörige Datenelement AUFUSER0 aus und ändert mithilfe der vorgenannten Funktion die Bezeichnung "Antragsteller" auf einen eigenen Wert ab.
Diese Felder werden in der Standard-ALE-Verteilung mit INTERNAL_ORDER ohne weiteres Zutun bereits berücksichtigt.
Massenlöschung von Kostenstellen
Mithilfe der KS04 lassen sich Kostenstellen löschen. Blöd nur, dass dabei immer nur eine spezifiziert werden kann und man aber z.B. 100 fehlerhaft angelegt (noch nicht bebuchte!) KST löschen will.
Anbei ein kleines Programm, welches sich des BAPIs BAPI_COSTCENTER_DELETEMULTIPLE bedient. Der Baustein durchläuft dabei die gleichen Prüfungen, die auch beim Löschen im Dialog (KS04) ausgeführt werden. Entsprechend lange wird die Laufzeit sein.
REPORT Z_KS04_MEHR_ALS_EINE.
* Löschen von mehreren Kostenstellen
TABLES: CSKS.
DATA: LT_CLIST TYPE TABLE OF BAPI0012_CCDELLIST.
DATA: LT_RETURN TYPE BAPIRET2_TAB.
PARAMETERS: pa_kokrs like csks-kokrs obligatory.
SELECT-OPTIONS: so_kostl for csks-kostl.
* hier ggf. noch weitere Selektionskriterien einfügen...
START-OF-SELECTION.
SELECT * FROM CSKS INTO CORRESPONDING FIELDS OF TABLE LT_CLIST
WHERE kokrs = pa_kokrs
AND kostl in so_kostl.
CALL FUNCTION 'BAPI_COSTCENTER_DELETEMULTIPLE'
EXPORTING
controllingarea = pa_kokrs
testrun = 'X' "TESTLAUF-Kz. raus, wenn's ernst wird
TABLES
COSTCENTERLIST = lt_clist
return = lt_return
EXCEPTIONS
error_message = 1.
IF SY-SUBRC <> 0.
MESSAGE 'Mind. eine KST muckt auf, Details s. Protokoll'.
ENDIF.
* Ausgabe Meldungen
CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
TABLES
i_bapiret2_tab = lt_return.
CO-Kontierungen im SD Auftragskopf
Bestimmte CO-Objekte (wie z.B. Innenaufträge) lassen sich im SD Auftrag im SAP Standard nur auf Positionsebene kontieren, was natürlich nervt, wenn bei allen Positionen das gleiche CO-Objekt eingetragen werden soll.
Kann man aber mithilfe der einschlägigen Userexits im Include MV45AFZB was machen:
1. Schritt:
Gewünschtes CO-Objekt "aufmachen" (Im Standard ist nur PSP-Element im Auftragskopf kontierbar).
z.B. Innenauftrag:
FORM USEREXIT_COBL_SEND_HEADER. * This example shows how to select fields that are shown in the * account assignment block * INT_COBLF-FDNAM = zzfield1. "hier: 'AUFNR' * INT_COBLF-OUTPUT = '1'. * IF T180-TRTYP NE CHARA AND * VBAP-KZVBR NE KZVBR_P. * INT_COBLF-INPUT = '1'. * INT_COBLF-REQUIRED = '1'. "nur wenn Mussfeld!!!! * ENDIF. * INT_COBLF-ACTIVE = '1'. * APPEND INT_COBLF. ENDFORM.
2. Schritt:
Auftragsnummer in Auftragskopf (VBAK) speichern:
FORM USEREXIT_COBL_RECEIVE_VBAK. * VBAK-zzfield = COBL-zzfield2. "hier: vbak-aufnr = cobl-aufnr. ENDFORM.
3. Schritt
Objekt in die Auftragspositionen "vererben":
FORM USEREXIT_MOVE_FIELD_TO_COBL USING US_VBAK STRUCTURE VBAK US_VBAP STRUCTURE VBAP CHANGING CH_COBL STRUCTURE COBL. * Examples * CH_COBL-zzfield = US_VBAK-zzfield2. * CH_COBL-zzfield = US_VBAP-zzfield2. "hier: ch_cobl-aufnr = us_vbak-aufnr. ENDFORM.
Sofern die Anforderung besteht, zusätzliche CO-Objekte in den Auftragspositionen aufzumachen, ist das Vorgehen ähnlich.
Im Include MV45AFZB, Routine USEREXIT_COBL_SEND_ITEM wird das gewünschte Objekt in den Kontierungsblock aufgenommen.
FORM USEREXIT_COBL_SEND_ITEM.
* This example shows how to select fields that are shown in the
* account assignment block
* INT_COBLF-FDNAM = zzfield1. "z.B. Kostenstelle 'KOSTL'
* INT_COBLF-OUTPUT = '1'.
* IF T180-TRTYP NE CHARA AND
* VBAP-KZVBR NE KZVBR_P.
* INT_COBLF-INPUT = '1'.
* INT_COBLF-REQUIRED = '1'. "nur bei Mussfeld
* ENDIF.
* INT_COBLF-ACTIVE = '1'.
* APPEND INT_COBLF.
ENDFORM.
In der Routine USEREXIT_COBL_RECEIVE_VBAP wird die CO-Kontierung in das entsprechende Feld in der Auftragsposition übernommen.
FORM USEREXIT_COBL_RECEIVE_VBAP.
* VBAP-zzfield = COBL-zzfield2.
"z.B. VBAP-KOSTL = COBL-KOSTL.
ENDFORM.
Ein etwaig bereits in der Auftragsposition vorhandenes CO-Objekt soll natürlich in den Kontierungsblock übernommen werden (Routine USEREXIT_MOVE_FIELD_TO_COBL)
FORM USEREXIT_MOVE_FIELD_TO_COBL USING US_VBAK STRUCTURE VBAK
US_VBAP STRUCTURE VBAP
CHANGING CH_COBL STRUCTURE COBL.
* Examples
* z.B. CH_COBL-KOSTL = US_VBAP-KOSTL. "Bsp. Kostenstelle
* CH_COBL-zzfield = US_VBAK-zzfield2.
* CH_COBL-zzfield = US_VBAP-zzfield2.
ENDFORM.
Leistungsverrechnung buchen mittels BAPI
Für die maschinelle Verbuchung von CO-Buchungen stehen neben der Übernahmetransaktion BATCHMAN (vgl. Artikel Übernahme von externen Umbuchungen und statistischen Kennzahlen ins CO ) auch div. BAPIs zur Verfügung. Nachfolgend ein Beispiel für die Verwendung des BAPIs BAPI_ACC_ACTIVITY_ALLOC_POST, mit dem Leistungsverrechnungen (KB21N) gebucht werden können:
*&---------------------------------------------------------------------*
*& Report ZTEST_KB21N_BAPI
*&
*&---------------------------------------------------------------------*
*& Demo-Programm BAPI-Aufruf BAPI_ACC_ACTIVITY_ALLOC_POST
*& Leistungsverrechnung (KB21N)
*&---------------------------------------------------------------------*
REPORT ztest_kb21n_bapi.
DATA: ls_doc_header TYPE bapidochdrp.
DATA: lt_doc_items TYPE TABLE OF bapiaaitm,
ls_doc_item TYPE bapiaaitm,
lt_return TYPE TABLE OF bapiret2.
DATA: ls_docno TYPE bapidochdrp-doc_no.
* Belegkopf
ls_doc_header-co_area = '1000'. "Kostenrechnungskreis
ls_doc_header-docdate = sy-datum. "Belegdatum
ls_doc_header-postgdate = sy-datum. "Buchungsdatum
ls_doc_header-doc_hdr_tx = 'Demo'. "Belegkopftext
ls_doc_header-username = sy-uname. "User-Name
* Positionen aufbauen
* Pos. 1
ls_doc_item-send_cctr = '0000002047'. "Sender-Kostenstelle
ls_doc_item-acttype = '8'. "Leistungsart
ls_doc_item-actvty_qty = 3. "Menge
ls_doc_item-rec_cctr = '0000002013'. "Empfänger-KST
APPEND ls_doc_item TO lt_doc_items.
* Pos. 2
ls_doc_item-send_cctr = '0000002047'.
ls_doc_item-acttype = '8'.
ls_doc_item-actvty_qty = 10.
ls_doc_item-rec_cctr = '0000002004'.
APPEND ls_doc_item TO lt_doc_items.
* BAPI rufen
CALL FUNCTION 'BAPI_ACC_ACTIVITY_ALLOC_POST'
EXPORTING
doc_header = ls_doc_header
* IGNORE_WARNINGS = ' '
IMPORTING
doc_no = ls_docno
TABLES
doc_items = lt_doc_items
return = lt_return
* CRITERIA =
* CUSTOMER_FIELDS =
.
* COMMIT nicht vergessen!
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'.
* Meldungen ausgeben
IF lt_return[] IS NOT INITIAL.
CALL FUNCTION 'C14ALD_BAPIRET2_SHOW'
TABLES
i_bapiret2_tab = lt_return.
ENDIF.
Übernahme von externen Umbuchungen und statistischen Kennzahlen ins CO
Nachfolgend eine Anleitung, wie zum einen Primärkostenumbuchungen und zum anderen statistische Kennzahlen mithilfe von Standard-Werkzeugen ins CO übernommen werden können. Grundlage hierfür bilden entsprechend vorformatierte Excel-Dateien. Die Übernahme selbst erfolgt jeweils mit der CO-spezifischen Datenübernahmetransaktion BATCHMAN.
Details zum Vorgehen befinden sich im Dokument https://docs.google.com/file/d/0B1_CTm8mzZEQamdDMW5Xa3BzSWc/edit
Das hier beschriebene Verfahren fusst auf der Standard-Auslieferung von SAP für das hinter dem BATCHMAN verankerte BadI. Eine eigene, gepimpte Version steht hier zur Verfügung
Merkmals- und Wertfeldauswahl im CO-PA
Ein Artikel aus der Serie: 'Ihr sollt es im Leben mal besser haben, als ich...':
Symptom:
Es wurden im CO-PA neue Wertfelder (oder Merkmale) angelegt. Diese sollen nun dem Ergebnisbereich hinzugefügt werden. Die neuen Wertfelder lassen sich nicht auswählen, obwohl sie aktiviert sind.
Ursache:
In der Routine set_rky_tab_pick im Include MKCGGF81 wird das Kennzeichen 'Pick' in der Tabelle rky_tab gesetzt, welches steuert, ob ein Wertfeld auswählbar ist oder nicht. Im ersten Coding-Abschnitt werden alle die Wertfelder auf 'nicht auswählbar' gesetzt, die bereits dem Ergebnisbereich zugeordnet sind... (das ist ja auch soweit nachvollziehbar!).
Im nachfolgenden Coding-Abschnitt wird aber eine zusätzliche, perfide, nicht weiter dokumentierte Prüfung vorgenommen:
if cgg_par-ffgrp eq kcdb_false and
ikcge-eq_txt_allowed eq kcdb_false.
loop at kyf_tab into kyf_wa
where txt_m eq rky_wa-txt_m
or txt_s eq rky_wa-txt_s.
exit.
endloop.
if sy-subrc eq 0.
clear rky_wa-pick.
endif.
endif.
Hier wird der Mittel- und Kurztext der Wertfelder im Vorrat mit denen der bereits im Ergebnisbereich vorhandenen Wertfelder (Tab. kyf_tab) abgeglichen. Stimmt einer der Texte überein, wird das Feld PICK auf space gesetzt.
D.h. es können keine zwei Wertfelder mit gleichen (Kurz-)texten im Ergebnisbereich verwendet werden.
Der im Coding abgefragte Paramter 'eq_txt_allowed' ist immer hart auf SPACE gesetzt - die (nicht im Customizing beeinflussbare) Initialisierung erfolgt in der Routine init_ikcge_ke im Include FKCGNF20.
Ich hab's nicht überprüft, aber ich gehe davon aus, dass das Gesagte analog auch für Merkmale gilt.
Hat mich einige Mühe gekostet, dass herauszufinden, deshalb die Info an Euch, falls Ihr mal vor dem gleichen Phänomen steht.
Automatisierte Anlage von Abrechnungsvorschriften zu Innenaufträgen
Um eine Abrechnungsvorschrift zu einem Innenauftrag automatisiert anzulegen, sollte in neueren Releases die Standardfunktionalität "automatische Generierung von Abrechnungsvorschriften" verwendet werden. Hierüber steht ein umfassendes Framework zur Verfügung, mit dem die meisten Use-Cases abgedeckt sein sollten. Details hierzu finden sich im Customizing-Leitfaden unter Controlling - Innenaufträge - Istbuchungen - Abrechnung - Automatische Generierung von Abrechnungsvorschriften ...
Für Datenübernahmen von Innenaufträgen, d.h. Übernahme der Stammdaten inkl. Abrechnungsvorschrift kann der BAPI BAPI_INTERNALORDER_CREATE verwendet werden.
Sollte es in Ausnahmefällen jedoch nötig sein, per Programm Abrechnungsvorschriften zu bestehenden Innenauftragen zu generieren, steht der Funktionsbaustein: K_ORDER_SRULE_ADD zur Verfügung, der allerdings einen großen Nachteil hat: er wurde von SAP in neueren Releases deaktiviert, d.h. im Coding ist ein sofortiger Rücksprung zur rufenden Anwendung implementiert, der jegliche Ausführung unterbindet:
************************************************************
************************************************************
RETURN. "fm will be deleted within the next releases ...
************************************************************
************************************************************
D.h., um ihn zu verwenden, muss entweder der oben stehende Befehl per Modifikation ausgebaut oder eine Kopie des Funktionsbausteins im Kundennamensraum angelegt werden.
Schade eigentlich, denn der Funktionsbaustein werkelt gut.
Der FuBa kann wie folgt gerufen werden:
*&---------------------------------------------------------------------*
*& Report YDEMO_ORDER_SRULE_ADD
*&
*&---------------------------------------------------------------------*
*& maschinelles Anlegen einer Abrechnungsvorschrift zu CO-Innenaufträgen
*&---------------------------------------------------------------------*
REPORT ydemo_order_srule_add.
* Schnittstelle f. BAPI
DATA: l_objnr LIKE aufk-objnr. "Objektnummer
DATA:
* Tabelle mit Abrechnungsvorschriften
lt_srules TYPE TABLE OF srules_ext,
* Tabelle f. Übergabe CO-PA Felder bei Abrechnung ins Ergebnis
* Angabe der Tabelle ist Pflicht, auch wenn nicht ins CO-PA
* abgerechnet werden soll...
lt_criteria TYPE TABLE OF bapi_copa_data,
l_rule_inserted LIKE sy-batch.
DATA: ls_srule TYPE srules_ext.
* Objektnummer zusammenbauen oder für einen gegebenen Innenauftrag
* einfach aus der Tab. AUFK nachlesen (Feld AUFK-OBJNR)
* Zusammenbauen ist aber auch recht einfach:
* Format Objektnummer f. CO-Aufträge: XX999999999999
* XX = Objektart OR
* 999999999999 = 12-stellige Innenauftragsnummer
l_objnr(2) = 'OR'.
l_objnr+2(12) = '000000400000'.
* Abrechnungsvorschrift zusammenbasteln...
* Abrechnungsart (engl. Festwerte)
* z.B. FUL = Gesamtabrechnung
* PER = periodische Abrechnung
ls_srule-settl_type = 'PER'.
* ls_srule-SOURCE "opt: Ursprungszuordnung
* Aufteilung
ls_srule-percentage = 100. "prozentuale Aufteilung ODER
*ls_srule-equiv_number "Äquivalenzziffer ODER
*ls_srule-amount "Betrag f. Betragsabrechnung
* Das Abrechungsempfängerobjekt ergibt sich aus der selektiven
* Befüllung der folgenden Felder:
*ls_srule-bus_area "Geschäftsbereich
*ls_srule-comp_code "Buchungskreis
*ls_srule-gl_account "Sachkonto
*ls_srule-profit_ctr "Profitcenter
ls_srule-costcenter = '0000002001'. "Kostenstelle
*ls_srule-orderid "Innenaauftrag
*ls_srule-wbs_element "PSP-Element
*ls_srule-asset_no "Anlage
* ...
APPEND ls_srule TO lt_srules.
CALL FUNCTION 'K_ORDER_SRULE_ADD'
EXPORTING
object_no = l_objnr
IMPORTING
flg_rule_inserted = l_rule_inserted
TABLES
srules = lt_srules
criteria = lt_criteria
EXCEPTIONS
wrong_input = 1
error_occurred = 2
object_not_found = 3
activity_not_allowed = 4
OTHERS = 5.
IF sy-subrc <> 0.
WRITE: / 'Fehler', sy-subrc, 'beim Anlegen der Abrechnungsvorschrift'.
ELSE.
IF l_rule_inserted = 'X'.
WRITE: 'Abrechnungsvorschrift hinzugefügt'.
COMMIT WORK.
ELSE.
WRITE: 'Abrechnungsvorschrift nicht hinzugefügt'.
ENDIF.
ENDIF.
Fremddatenübernahme ins CO-PA
Im nachfolgenden Link ist eine ausführliche Anleitung enthalten, wie Fremddaten ohne Entwicklungsaufwand ins CO-PA geladen werden können:
https://drive.google.com/file/d/0B1_CTm8mzZEQTkowLXRwSDRhYVU/edit?usp=sharing
Viel Erfolg!
Fakturaschnittstelle ins FI / FI-Beleg unterbinden, CO-PA bleibt
Bei einem Projekt gab es die Anforderung, die eingelesen Abverkaufsdaten vom POS ins SAP zu laden, aber bei den daraus entstehenden (POS-)Fakturen keinen FI-Beleg zu erzeugen. Allerdings sollte die Fortschreibung ins CO-PA nicht unterbunden werden.
Hierzu wurde folgendes Coding in der SAP-Erweiterung SDVFX008 (Funktionsexit EXIT_SAPLV60B_008, Include ZXVVFU08) implementiert (CMOD):
...
data: l_tabix type sytabix,
ls_accit like line of xaccit.
* Kill FI, long live CO-PA!!!
* Table XACCIT contains lines for FI and CO-PA document
* --> Remove lines for FI-doc only!
* Caution: for certain cases only
check ... <> ... AND ...
loop at xaccit into ls_accit.
l_tabix = sy-tabix.
if ls_accit-kstat = space. "line of FI doc
* delete line in item table
delete xaccit index l_tabix.
* delete corresponding entry in amount table
delete xacccr index l_tabix.
endif.
endloop.
Diese Aktion darf natürlich nur in den relevanten Konstellationen durchgeführt werden, d.h. es ist auf eine hinreichend scharfe Abgrenzung zum übrigen Belegaufkommen zu achten!
CO-PA Berichte zwischen Ergebnisbereichen kopieren
Mit dem nachfolgenden Report können Sie Recherche-Berichte (inkl. Formulare) von einem Ergebnisbereich in einen anderen kopieren, wobei diese natürlich strukturell kompatibel sein müssen. So ganz ausgereift ist die Sache noch nicht (siehe Abschnitt 'Einschränkungen' im Report-Header) aber besser als nix.
*&---------------------------------------------------------------------*
*& Report YRKE_COPY_REPORT
*& Version 0.1
*&---------------------------------------------------------------------*
*& Kopieren von Reports zwischen verschiedenen Ergebnisbereichen
*& Achtung: Ergebnisbereiche dürfen sich natürlich nur vom Namen her
*& unterscheiden. Wenn die Strukturen nicht kompatibel sind, macht die
*& Nummer hier absolut keinen Sinn!!!!
*&
*& Einschränkungen Version 0.1:
*& ----------------------------
*& - Formulartexte werden nicht mitkopiert --> manuell nachpflegen
*& - Formelprioritäten müssen im Formular manuell nachbearb. werden
*&---------------------------------------------------------------------*
REPORT yrke_copy_report.
TABLES: tkeb1, tka01.
DATA: i_tkeb1 TYPE TABLE OF tkeb1 WITH HEADER LINE.
DATA: l_tabname_wild LIKE tkeb1-tabname,
l_tabname LIKE tkeb1-tabname.
PARAMETERS: pa_serkr LIKE tka01-erkrs OBLIGATORY,
pa_terkr LIKE tka01-erkrs OBLIGATORY.
SELECT-OPTIONS: so_repid FOR tkeb1-repid.
PARAMETERS: pa_test AS CHECKBOX DEFAULT 'X'.
AT SELECTION-SCREEN.
IF pa_serkr = pa_terkr.
MESSAGE e600(fr) WITH 'Bitte Quell- und Zielergebnisbereich'
'unterschiedlich wählen'.
ENDIF.
START-OF-SELECTION.
* Selektion aller Berichte im Quell-Ergebnisbereich
CONCATENATE '___' pa_serkr INTO l_tabname_wild.
SELECT * FROM tkeb1 INTO TABLE i_tkeb1
WHERE applclass = 'KE'
AND subclass = '01'
AND tabname LIKE l_tabname_wild
AND repid IN so_repid.
LOOP AT i_tkeb1.
WRITE: / i_tkeb1-applclass,
i_tkeb1-subclass,
i_tkeb1-tabname,
i_tkeb1-repid,
i_tkeb1-form.
l_tabname = i_tkeb1-tabname.
* Zieltabellenname setzen
CALL FUNCTION 'RKE_COPY_CHANGE_TABNAME'
EXPORTING
i_tabname = l_tabname
i_source_erkrs = pa_serkr
i_target_erkrs = pa_terkr
IMPORTING
e_tabname = l_tabname
EXCEPTIONS
no_erkrs_in_tabname = 1
OTHERS = 2.
IF sy-subrc <> 0.
MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
ENDIF.
* Im Echtlauf Kopierfunktion starten
IF pa_test IS INITIAL.
* Ggf. zuerst Formular kopieren
IF NOT i_tkeb1-form IS INITIAL.
CALL FUNCTION 'RKD_FORM_COPY'
EXPORTING
i_applclass = 'KE'
i_subclass = '01'
i_tabname = i_tkeb1-tabname
i_form = i_tkeb1-form
* I_AKTMDT = 'X'
i_tabname_new = l_tabname
* EXCEPTIONS
* FORM_EXISTS_ALREADY = 1
* FORM_IMPORT_IMPOSSIBLE = 2
* FORM_NOT_FOUND = 3
* OTHERS = 4
.
IF sy-subrc <> 0.
EXIT.
ENDIF.
ENDIF.
* Bericht kopieren
CALL FUNCTION 'RKE_REPORT_COPY'
EXPORTING
repid = i_tkeb1-repid
erkrs = pa_serkr
applclass = i_tkeb1-applclass
subclass = i_tkeb1-subclass
tabname = i_tkeb1-tabname
dest_tabname = l_tabname
EXCEPTIONS
report_not_found = 1
unknown_error = 2
list_elements_not_copied = 3
old_report_version = 4.
CASE sy-subrc.
WHEN 0 OR 3.
MESSAGE i126(ke0c) WITH i_tkeb1-repid i_tkeb1-tabname.
* Bericht &1 (Tabelle &2) wurde kopiert
PERFORM write_msg_prot(sapmkecp) USING
'KE0C' 'I' '126'
i_tkeb1-repid i_tkeb1-tabname
space space.
WHEN 2.
PERFORM write_msg_prot(sapmkecp) USING
'KE/NC' 'E' '000'
i_tkeb1-repid 'SY-SUBRC' sy-subrc
space.
WHEN 4.
IF 0 = 1.
MESSAGE w129(ke0c) WITH i_tkeb1-repid i_tkeb1-tabname.
ENDIF.
* Bericht &1 (Tabelle &2) muss umgesetzt werden
PERFORM write_msg_prot(sapmkecp) USING
'KE0C' 'W' '129'
i_tkeb1-repid i_tkeb1-tabname
space space.
ENDCASE.
ENDIF.
ENDLOOP.
