Bestellung über Batch Input anlegen ME21
14 Beiträge
•
Seite 1 von 1
14 Beiträge
Seite 1 von 1
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hallo,
Leider bin ich im Bereich Batch Input sehr frisch und bin nun auf ein Problem gestoßen, wo ich leider im Moment nicht mehr weiterkomme.
und zwar möchte ich über Batch Input mit der Transaktion ME21 eine Bestellung anlegen.
Die Daten werden über ein .txt - file eingelesen.
Folgende Daten werden über das .txt-file eingelesen:
Materialnummer, Werk, Bestellmenge, Nettopreis, Preiseinheit, Bestellpreismengeneinheit
In meinem Report werden die jeweiligen Daten in die i_daten eingelesen, ... danach wie gehabt in die Mappe (i_bdctab) über die jeweiligen forms eingelesen.
...hier ist ein Teil des Codes zu sehen:
Über BDC_INSERT werden die Daten an die Mappe übergeben:
form insert_bdctab:
Das Problem ist jedoch nun, dass die Daten zwar angelegt werden, jedoch wird der Nettopreis (EKPO-NETPR), die Preiseinheit (EKPO-PEINH) und die Bestellpreismengeneinheit (EKPO-BPRME) überschrieben (nicht die jeweiligen Daten aus dem .txt-file), sobald bereits ein Infosatz besteht!
D.h. er nimmt dann die Daten die über den Infosatz bereits gespeichert wurden und die einzulesenden Daten aus dem .txt-file werden ignoriert bzw. nicht in die ME21 geschrieben/angelegt.
Ich wollte mit Aufruf eines weiteren Dynpros (z.B. 0111, Detail Position) oder des Dynpros der Positionskonditionen (9000) die Sache umgehen, bzw. dass der Nettopreis, die Preiseinheit und die Bestellpreismengeneinheit über dieses Dynpro geschrieben wird,
allerdings ist es mir mit Aufruf d. sm35 (Mappenabspielung) danach nicht gestattet, da er dann jammert, dass die Daten des Dynpros 0120 nicht gefunden werden. (siehe im Codeteil, das sind die auskommentierten Teile...).
Über's debuggen habe ich jedoch gesehen, dass die Daten aus der i_daten jedoch erfolgreich an die Mappe übergeben wird, ALLERDINGS schreibt er die daten aus dem .txt danach nicht in die Transaktion, SOBALD ein Infosatz zu dem jeweiligen Material besteht.
--> Wie kann man das umgehen??
( mit zuweisen, überschreiben, etc. .. habe ich alles schon versucht, ...
- d.h. es muss eine andere Lösung dafür geben. )
Kann man über Batch Input ein ganzes Dynpro überspringen??
- weil wenn die ME21 aufgerufen wird, dann springt er natürlich sofort in die 0120 Maske, und leider NICHT auf die die 0111 oder auf die 9000 ...
... offensichtlich funktioniert das nicht, oder?
Wie kann das anders lösen, dass die Daten aus dem .txt-file korrekt in die Transaktion me21 übergeben werden??
wollte das auch schon mit Call Transaction lösen, ... führte jedoch leider auch nicht zum Erfolg.
Bitte um Hilfe!
Danke!
mlG
Leider bin ich im Bereich Batch Input sehr frisch und bin nun auf ein Problem gestoßen, wo ich leider im Moment nicht mehr weiterkomme.
und zwar möchte ich über Batch Input mit der Transaktion ME21 eine Bestellung anlegen.
Die Daten werden über ein .txt - file eingelesen.
Folgende Daten werden über das .txt-file eingelesen:
Materialnummer, Werk, Bestellmenge, Nettopreis, Preiseinheit, Bestellpreismengeneinheit
In meinem Report werden die jeweiligen Daten in die i_daten eingelesen, ... danach wie gehabt in die Mappe (i_bdctab) über die jeweiligen forms eingelesen.
...hier ist ein Teil des Codes zu sehen:
Code: Alles auswählen.
PERFORM bdc_dynpro USING 'SAPMM06E' '0100'.
PERFORM bdc_field USING 'RM06E-BSART' 'NB'.
PERFORM bdc_field USING 'EKKO-LIFNR' p_lifnr.
PERFORM bdc_field USING 'EKKO-EKORG' 'BUAU'.
PERFORM bdc_field USING 'EKKO-EKGRP' p_ekgrp.
PERFORM bdc_field USING 'BDC_OKCODE' '/00'.
zline = 1.
*overview by index - choose item
PERFORM bdc_dynpro USING 'SAPMM06E' '0120'.
PERFORM bdc_fieldi USING zline 'EKPO-EMATN' i_daten-matnr.
PERFORM bdc_fieldi USING zline 'EKPO-MENGE' i_daten-brgew.
PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
PERFORM bdc_fieldi USING zline 'EKPO-WERKS' i_daten-werks.
PERFORM bdc_fieldi USING zline 'RM06E-EEIND' zw_eeind.
PERFORM bdc_dynpro USING 'SAPLV69A' '9000'.
** PERFORM bdc_fieldi USING zline 'KONP-KBETR' i_daten-netpr.
PERFORM bdc_fieldi USING zline 'KONP-KPEIN' i_daten-kpein.
PERFORM bdc_fieldi USING zline 'KONP-KMEIN' i_daten-kmein.
** PERFORM bdc_dynpro USING 'SAPMM06E' '0111'.
** PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
** PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
** PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
PERFORM bdc_field USING 'BDC_OKCODE' '/00'.
*endif.
*org tab
ELSE.
ADD 1 TO zline.
* zline = 1.
*overview by index - choose item
PERFORM bdc_dynpro USING 'SAPMM06E' '0120'.
PERFORM bdc_fieldi USING zline 'EKPO-EMATN' i_daten-matnr.
PERFORM bdc_fieldi USING zline 'EKPO-MENGE' i_daten-brgew.
PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
PERFORM bdc_fieldi USING zline 'EKPO-WERKS' i_daten-werks.
PERFORM bdc_fieldi USING zline 'RM06E-EEIND' zw_eeind.
PERFORM bdc_dynpro USING 'SAPLV69A' '9000'.
** PERFORM bdc_fieldi USING zline 'KONP-KBETR' i_daten-netpr.
PERFORM bdc_fieldi USING zline 'KONP-KPEIN' i_daten-kpein.
PERFORM bdc_fieldi USING zline 'KONP-KMEIN' i_daten-kmein.
** PERFORM bdc_dynpro USING 'SAPMM06E' '0111'.
** PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
** PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
** PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
* if zline gt 13.
PERFORM bdc_field USING 'BDC_OKCODE' '=NP'.
zline = '1'.
* else.
* PERFORM bdc_field USING 'BDC_OKCODE' '/00'.
ENDIF.
ENDLOOP.
Code: Alles auswählen.
PERFORM insert_bdctab USING 'ME21'.Code: Alles auswählen.
FORM insert_bdctab USING transaktion.
CALL FUNCTION 'BDC_INSERT'
EXPORTING
tcode = transaktion
* POST_LOCAL = NOVBLOCAL
* PRINTING = NOPRINT
TABLES
dynprotab = i_bdctab
EXCEPTIONS
internal_error = 1
not_open = 2
queue_error = 3
tcode_invalid = 4
printing_invalid = 5
posting_invalid = 6
OTHERS = 7
.
IF sy-subrc <> 0.
WRITE: / 'BDC_INSERT nicht möglich. Fehlernummer:', sy-subrc.
ENDIF.
REFRESH i_bdctab. "löscht Itab-Einträge
CLEAR i_bdctab. "löscht Kopfzeile
ENDFORM. "insert_bdctab
D.h. er nimmt dann die Daten die über den Infosatz bereits gespeichert wurden und die einzulesenden Daten aus dem .txt-file werden ignoriert bzw. nicht in die ME21 geschrieben/angelegt.
Ich wollte mit Aufruf eines weiteren Dynpros (z.B. 0111, Detail Position) oder des Dynpros der Positionskonditionen (9000) die Sache umgehen, bzw. dass der Nettopreis, die Preiseinheit und die Bestellpreismengeneinheit über dieses Dynpro geschrieben wird,
allerdings ist es mir mit Aufruf d. sm35 (Mappenabspielung) danach nicht gestattet, da er dann jammert, dass die Daten des Dynpros 0120 nicht gefunden werden. (siehe im Codeteil, das sind die auskommentierten Teile...).
Über's debuggen habe ich jedoch gesehen, dass die Daten aus der i_daten jedoch erfolgreich an die Mappe übergeben wird, ALLERDINGS schreibt er die daten aus dem .txt danach nicht in die Transaktion, SOBALD ein Infosatz zu dem jeweiligen Material besteht.
--> Wie kann man das umgehen??
( mit zuweisen, überschreiben, etc. .. habe ich alles schon versucht, ...
- d.h. es muss eine andere Lösung dafür geben. ) Kann man über Batch Input ein ganzes Dynpro überspringen??
- weil wenn die ME21 aufgerufen wird, dann springt er natürlich sofort in die 0120 Maske, und leider NICHT auf die die 0111 oder auf die 9000 ...
... offensichtlich funktioniert das nicht, oder?
Wie kann das anders lösen, dass die Daten aus dem .txt-file korrekt in die Transaktion me21 übergeben werden??
wollte das auch schon mit Call Transaction lösen, ... führte jedoch leider auch nicht zum Erfolg.
Bitte um Hilfe!
Danke!
mlG
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
beschäftige dich besser mit den dazugehörigen Funktionsbausteinen kuck in die SE37
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
<:: XING-Gruppe Tricktresor::>
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hallo,
Vielen Dank für den Fkt.baustein.
In diesem Fall muss ich jedoch dann die Feldzuweisungen der Batch Input - Mappe umschreiben, da die ME21N auf andere Dynpros führt als die ME21 (siehe code):
oder ist dann mit Aufruf des Funktionsbaustein BAPI_PO_CREATE1 keine vorige Feldzuweisung mehr notwendig?
Da ich ohnedies die Fehlermeldung bei Ausführung der Mappe in der sm35 "Batchinput Daten für Dynpro SAPLMEGUI 0014 sind nicht vorhanden" bekomme, was in dem Fall nicht stimmt, da ich die Felder des Dynpros 0014 versorge!? (siehe oberen Code)
und wenn ich andere Dynpros nehme, dann schreit er dass die jeweiligen Felder nicht vorhanden sind.
Daher die Frage:
Sind die Feldzuweisungen bei Aufruf der BAPI_PO_CREATE1 denn in dem Fall noch überhaupt notwendig? - ich denke schon, oder?
Und wenn ja, wie? - weil so wie es jetzt ist, gefällt es ihm, aus welchen Gründen auch immer, nicht!??
Den Funktionsbaustein würde ich folgendermaßen aufrufen:
---> allerdings kommt dann danach ein Dump, in dem mitgeteilt wird, dass es einen Typkonflikt mit poheader gibt.
(siehe screenshot)
Bitte um Hilfe des richtigen Aufrufs!
Danke!
mlG,
Vielen Dank für den Fkt.baustein.
In diesem Fall muss ich jedoch dann die Feldzuweisungen der Batch Input - Mappe umschreiben, da die ME21N auf andere Dynpros führt als die ME21 (siehe code):
Code: Alles auswählen.
PERFORM bdc_dynpro USING 'SAPLMEGUI' '0014'.
* PERFORM bdc_dynpro USING 'SAPLMEGUI' '1105'.
PERFORM bdc_fieldh USING 'MEPO_TOPLINE-BSART' 'NB'.
PERFORM bdc_fieldh USING 'MEPO_TOPLINE-SUPERFIELD' p_lifnr.
PERFORM bdc_dynpro USING 'SAPLMEGUI' '1221'.
PERFORM bdc_fieldh USING 'MEPO1222-EKORG' 'BUAU'.
PERFORM bdc_fieldh USING 'MEPO1222-EKGRP' p_ekgrp.
PERFORM bdc_field USING 'BDC_OKCODE' '/00'.
** poheader-comp_code = '1000'.
** poheader-doc_type = 'NEBP'.
*** POHEADER-VENDOR = I_EKKO-LIFNR.
** poheader-vendor = p_lifnr.
** poheader-purch_org = '200'.
** poheader-pur_group = '910'.
zline = 1.
*overview by index - choose item
** PERFORM bdc_dynpro USING 'SAPMM06E' '0120'.
** PERFORM bdc_fieldi USING zline 'EKPO-EMATN' i_daten-matnr.
** PERFORM bdc_fieldi USING zline 'EKPO-MENGE' i_daten-brgew.
** PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
** PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
** PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
** PERFORM bdc_fieldi USING zline 'EKPO-WERKS' i_daten-werks.
** PERFORM bdc_fieldi USING zline 'RM06E-EEIND' zw_eeind.
* PERFORM bdc_dynpro USING 'SAPLMEGUI' '1211'.
PERFORM bdc_dynpro USING 'SAPLMEGUI' '0014'.
PERFORM bdc_fieldi USING zline 'MEPO1211-EMATN' i_daten-matnr.
PERFORM bdc_fieldi USING zline 'MEPO1211-MENGE' i_daten-brgew.
PERFORM bdc_fieldi USING zline 'MEPO1211-NETPR' i_daten-netpr.
PERFORM bdc_fieldi USING zline 'MEPO1211-PEINH' i_daten-peinh.
PERFORM bdc_fieldi USING zline 'MEPO1211-BPRME' i_daten-bprme.
PERFORM bdc_fieldi USING zline 'MEPO1211-NAME1' i_daten-werks.
PERFORM bdc_fieldi USING zline 'MEPO1211-EEIND' zw_eeind.
** PERFORM bdc_dynpro USING 'SAPLV69A' '9000'.
*** PERFORM bdc_fieldi USING zline 'KONP-KBETR' i_daten-netpr.
** PERFORM bdc_fieldi USING zline 'KONP-KPEIN' i_daten-kpein.
** PERFORM bdc_fieldi USING zline 'KONP-KMEIN' i_daten-kmein.
* PERFORM bdc_dynpro USING 'SAPMM06E' '0111'.
* PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
* PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
* PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
PERFORM bdc_field USING 'BDC_OKCODE' '/00'.
*endif.
*org tab
ELSE.
ADD 1 TO zline.
* zline = 1.
*overview by index - choose item
** PERFORM bdc_dynpro USING 'SAPMM06E' '0120'.
** PERFORM bdc_fieldi USING zline 'EKPO-EMATN' i_daten-matnr.
** PERFORM bdc_fieldi USING zline 'EKPO-MENGE' i_daten-brgew.
** PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
** PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
** PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
** PERFORM bdc_fieldi USING zline 'EKPO-WERKS' i_daten-werks.
** PERFORM bdc_fieldi USING zline 'RM06E-EEIND' zw_eeind.
* PERFORM bdc_dynpro USING 'SAPLMEGUI' '1211'.
PERFORM bdc_dynpro USING 'SAPLMEGUI' '0014'.
PERFORM bdc_fieldi USING zline 'MEPO1211-EMATN' i_daten-matnr.
PERFORM bdc_fieldi USING zline 'MEPO1211-MENGE' i_daten-brgew.
PERFORM bdc_fieldi USING zline 'MEPO1211-NETPR' i_daten-netpr.
PERFORM bdc_fieldi USING zline 'MEPO1211-PEINH' i_daten-peinh.
PERFORM bdc_fieldi USING zline 'MEPO1211-BPRME' i_daten-bprme.
PERFORM bdc_fieldi USING zline 'MEPO1211-NAME1' i_daten-werks.
PERFORM bdc_fieldi USING zline 'MEPO1211-EEIND' zw_eeind.
** PERFORM bdc_dynpro USING 'SAPLV69A' '9000'.
*** PERFORM bdc_fieldi USING zline 'KONP-KBETR' i_daten-netpr.
** PERFORM bdc_fieldi USING zline 'KONP-KPEIN' i_daten-kpein.
** PERFORM bdc_fieldi USING zline 'KONP-KMEIN' i_daten-kmein.
* PERFORM bdc_dynpro USING 'SAPMM06E' '0111'.
* PERFORM bdc_fieldi USING zline 'EKPO-NETPR' i_daten-netpr.
* PERFORM bdc_fieldi USING zline 'EKPO-PEINH' i_daten-peinh.
* PERFORM bdc_fieldi USING zline 'EKPO-BPRME' i_daten-bprme.
* if zline gt 13.
PERFORM bdc_field USING 'BDC_OKCODE' '=NP'.
zline = '1'.
* else.
* PERFORM bdc_field USING 'BDC_OKCODE' '/00'.
ENDIF.
ENDLOOP.
PERFORM bdc_field USING 'BDC_OKCODE' '/11'.
PERFORM bdc_dynpro USING 'SAPLSPO1' '0300'.
PERFORM bdc_field USING 'BDC_OKCODE' '=YES'.Da ich ohnedies die Fehlermeldung bei Ausführung der Mappe in der sm35 "Batchinput Daten für Dynpro SAPLMEGUI 0014 sind nicht vorhanden" bekomme, was in dem Fall nicht stimmt, da ich die Felder des Dynpros 0014 versorge!? (siehe oberen Code)
und wenn ich andere Dynpros nehme, dann schreit er dass die jeweiligen Felder nicht vorhanden sind.
Daher die Frage:
Sind die Feldzuweisungen bei Aufruf der BAPI_PO_CREATE1 denn in dem Fall noch überhaupt notwendig? - ich denke schon, oder?
Und wenn ja, wie? - weil so wie es jetzt ist, gefällt es ihm, aus welchen Gründen auch immer, nicht!??
Den Funktionsbaustein würde ich folgendermaßen aufrufen:
Code: Alles auswählen.
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
poheader = i_bdctab_header
** POHEADERX =
** POADDRVENDOR =
** TESTRUN =
** MEMORY_UNCOMPLETE =
** MEMORY_COMPLETE =
** POEXPIMPHEADER =
** POEXPIMPHEADERX =
** VERSIONS =
** NO_MESSAGING =
** NO_MESSAGE_REQ =
** NO_AUTHORITY =
** NO_PRICE_FROM_PO =
** PARK_COMPLETE =
** PARK_UNCOMPLETE =
** IMPORTING
** EXPPURCHASEORDER =
** EXPHEADER =
** EXPPOEXPIMPHEADER =
TABLES
return = t_return
poitem = i_bdctab
** POITEMX =
** POADDRDELIVERY =
** POSCHEDULE =
** POSCHEDULEX =
** POACCOUNT =
** POACCOUNTPROFITSEGMENT =
** POACCOUNTX =
** POCONDHEADER =
** POCONDHEADERX =
** POCOND =
** POCONDX =
** POLIMITS =
** POCONTRACTLIMITS =
** POSERVICES =
** POSRVACCESSVALUES =
** POSERVICESTEXT =
** EXTENSIONIN =
** EXTENSIONOUT =
** POEXPIMPITEM =
** POEXPIMPITEMX =
** POTEXTHEADER =
** POTEXTITEM =
** ALLVERSIONS =
** POPARTNER =
** POCOMPONENTS =
** POCOMPONENTSX =
** POSHIPPING =
** POSHIPPINGX =
** POSHIPPINGEXP =
** SERIALNUMBER =
** SERIALNUMBERX =
** INVPLANHEADER =
** INVPLANHEADERX =
** INVPLANITEM =
** INVPLANITEMX =
.(siehe screenshot)
Bitte um Hilfe des richtigen Aufrufs!
Danke!
mlG,
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
servus Fritzi_SAP,
du hast mit BAPI Bausteinen noch nicht gearbeitet so wie ich das sehe. den ganzen Dynpro BDC Kram kannst du getrost vergessen wenn du mit diesem BAPI arbeitest.
1. .txt holen Beispiel, in i_ekko stehen dann die Daten:
2. BAPI mindestanforderung was der braucht glaub ich 
:
3. Beispiel Tabellen füllen für BAPI:
Einfacher wäre jetzt nur noch wenn ich dir ein fertiges programm poste. 
hoffe du kannst damit etwas anfangen.
gruss
ratsnus
du hast mit BAPI Bausteinen noch nicht gearbeitet so wie ich das sehe. den ganzen Dynpro BDC Kram kannst du getrost vergessen wenn du mit diesem BAPI arbeitest.
1. .txt holen Beispiel, in i_ekko stehen dann die Daten:
Code: Alles auswählen.
types: BEGIN OF TY_EKKO,
EBELN TYPE EKKO-EBELN,
BUKRS TYPE EKKO-BUKRS,
LIFNR TYPE EKKO-LIFNR,
EKGRP TYPE EKKO-EKGRP,
WAERS TYPE EKKO-WAERS,
name(100) type c,
create(8) type c,
END OF TY_EKKO.
data: i_ekko type table of ty_ekko with header line.
data: wa_ekko like line of i_ekko.
DATA: w_filename TYPE string,
SELECTION-SCREEN BEGIN OF BLOCK bl_001 WITH FRAME TITLE text-001.
PARAMETERS:
* Pfad der Inputdatei
p_path TYPE rlgrap-filename DEFAULT 'C:\Bestellungen\' .
SELECTION-SCREEN END OF BLOCK bl_001.
* EKKO
refresh i_EKKO.
CONCATENATE p_path 'ekko.txt' INTO w_filename.
open dataset w_filename for input in text mode encoding utf-8 IGNORING CONVERSION ERRORS.
do.
read dataset w_filename into str.
if sy-subrc <> 0.
exit.
endif.
split str at cl_abap_char_utilities=>horizontal_tab
into
wa_ekko-ebeln
wa_ekko-bukrs
wa_ekko-lifnr
wa_ekko-ekgrp
wa_ekko-waers
wa_ekko-name
wa_ekko-create.
append wa_ekko to i_ekko.
enddo.
Code: Alles auswählen.
data: pohead type bapimepoheader.
data: poheadx type bapimepoheaderx.
data: poitem type table of bapimepoitem with header line.
data: poitemx type table of bapimepoitemx with header line.
data: exp_head type bapimepoheader.
data: return type table of bapiret2 with header line.
data: ex_po_number type bapimepoheader-po_number.
data: testrun type bapiflag-bapiflag.
*** hier musst du jetzt natürlich vor dem Aufruf die pohead, poheadx, poitem und poitemx füllen.
call function 'BAPI_PO_CREATE1'
EXPORTING
poheader = pohead
poheaderx = poheadx
testrun = testrun
NO_MESSAGING = 'X'
NO_MESSAGE_REQ = 'X'
NO_AUTHORITY = 'X'
NO_PRICE_FROM_PO = 'X'
IMPORTING
exppurchaseorder = ex_po_number
expheader = exp_head
TABLES
return = return
poitem = poitem
poitemx = poitemx.
commit work and wait.
loop at return.
write: return-message.
endloop.Code: Alles auswählen.
constants : c_x value 'X'.
data: l_count like ekpo-ebelp.
* Header Level Data
pohead-comp_code = '4500'.
pohead-doc_type = 'NB' .
pohead-creat_date = sy-datum.
pohead-vendor = '0000200003'.
pohead-purch_org = '4500'.
pohead-pur_group = '499'.
pohead-langu = sy-langu.
pohead-doc_date = date.
pohead-OUR_REF = 'CN Bestellungen'.
pohead-CURRENCY = 'CNY'.
pohead-LANGU = 'EN'.
* Head Level BAPI X
poheadx-comp_code = c_x.
poheadx-doc_type = c_x.
poheadx-creat_date = c_x.
poheadx-vendor = c_x.
poheadx-langu = c_x.
poheadx-purch_org = c_x.
poheadx-pur_group = c_x.
poheadx-doc_date = c_x.
poheadx-OUR_REF = c_x.
poheadx-CURRENCY = c_x.
poheadx-LANGU = c_x.
* Item Level
loop at i_daten.
add 1 to l_count.
poitem-po_item = l_count.
poitem-material = i_daten-matnr.
poitem-plant = '4500'.
poitem-stge_loc = '4500'.
poitem-quantity = i_daten-mng02.
poitem-PO_UNIT = i_daten-meins.
poitem-net_price = i_daten-verpr.
poitem-price_unit = i_daten-peinh.
poitem-NO_MORE_GR = ' '.
poitem-FINAL_INV = 'X'.
poitem-NO_ROUNDING = 'X'.
poitem-PO_PRICE = '1'.
append poitem.
* Item level BAPI X
poitemx-po_item = l_count.
poitemx-po_itemx = c_x.
poitemx-material = c_x.
poitemx-plant = c_x .
poitemx-stge_loc = c_x .
poitemx-quantity = c_x .
poitemx-PO_UNIT = c_x.
poitemx-net_price = c_x.
poitemx-price_unit = c_x.
poitemx-NO_MORE_GR = c_x.
poitemx-FINAL_INV = c_x.
poitemx-NO_ROUNDING = c_x.
poitemx-PO_PRICE = c_x.
append poitemx.
endloop.gruss
ratsnus
<:: XING-Gruppe Tricktresor::>
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hallo Ratsnus,
Danke für dein weiteres posting.
"du hast mit BAPI Bausteinen noch nicht gearbeitet so wie ich das sehe" --> richtig
"den ganzen Dynpro BDC Kram kannst du getrost vergessen wenn du mit diesem BAPI arbeitest." --> sehr gut
o.k., danke - ich werd' das Ganze mal dementsprechend ändern!
lG
Danke für dein weiteres posting.
"du hast mit BAPI Bausteinen noch nicht gearbeitet so wie ich das sehe" --> richtig
"den ganzen Dynpro BDC Kram kannst du getrost vergessen wenn du mit diesem BAPI arbeitest." --> sehr gut
o.k., danke - ich werd' das Ganze mal dementsprechend ändern!
lG
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hello,
Danke für deine Hilfe des Bausteins.
Ich habe das Ganze nun dementsprechend geändert, ... -
Vom return des Bausteins werden mir nun Meldungen geliefert, die mir unklar sind, siehe screenshot "fehlermeldungen _ z_create_po.JPG", vor allem folgende 3 Punkte:
1) "Das Bestelldatum liegt in der Vergangenheit"
--> ??? Wie kann das sein? Abgesehen davon liefere ich alles mit sy-datum
2) "Die Bestellmengenpreiseinheit TO kann nicht verwendet werden"
--> ??? also das ist definitiv ein Schwachsinn! Ich kann die Bestellmengenpreiseinheit sehr wohl auf Tonnen ändern, wieso sollte das über den Baustein nicht funktionieren?
3) 2x "Für Geschäftjahrevariante K4 ist zum . . kein Periode definiert"
--> ???
Den jeweiligen Code dazu habe ich folgendermassen geändert:
für das .txt holen habe ich mein Altes gelassen, ich möchte die Daten in die ekpo (positionsdaten) geschrieben haben, so wie sie im .txt-file (siehe attached file.txt) geschrieben wurden.
das ist das Unterprogramm wo die Positionsdaten aus dem txt-file (i_daten) befüllt werden:
Und deine Hilfe mit der Befüllung der Tabellen für's BAPI create1 habe ich meinen Bedürfnissen dementsprechend angepasst:
- mir wäre jetzt nichts bewusst was an den Positionsdaten fehlerhaft sein sollte? (Meldung: "Die Bestellung enthält noch fehlerhafte Positionen")
Habe ich was Wichtiges vergessen?
Oder weshalb wird mit solchen Meldungen gemotzt?
Danke!
lG
Danke für deine Hilfe des Bausteins.
Ich habe das Ganze nun dementsprechend geändert, ... -
Vom return des Bausteins werden mir nun Meldungen geliefert, die mir unklar sind, siehe screenshot "fehlermeldungen _ z_create_po.JPG", vor allem folgende 3 Punkte:
1) "Das Bestelldatum liegt in der Vergangenheit"
--> ??? Wie kann das sein? Abgesehen davon liefere ich alles mit sy-datum
2) "Die Bestellmengenpreiseinheit TO kann nicht verwendet werden"
--> ??? also das ist definitiv ein Schwachsinn! Ich kann die Bestellmengenpreiseinheit sehr wohl auf Tonnen ändern, wieso sollte das über den Baustein nicht funktionieren?
3) 2x "Für Geschäftjahrevariante K4 ist zum . . kein Periode definiert"
--> ???
Den jeweiligen Code dazu habe ich folgendermassen geändert:
für das .txt holen habe ich mein Altes gelassen, ich möchte die Daten in die ekpo (positionsdaten) geschrieben haben, so wie sie im .txt-file (siehe attached file.txt) geschrieben wurden.
Code: Alles auswählen.
* Kopfdaten
TYPES: BEGIN OF ty_ekko,
ebeln TYPE ekko-ebeln,
bukrs TYPE ekko-bukrs,
lifnr TYPE ekko-lifnr,
ekgrp TYPE ekko-ekgrp,
waers TYPE ekko-waers,
name(100) TYPE c,
create(8) TYPE c,
END OF ty_ekko.
* Positionsdaten
TYPES: BEGIN OF i_fics, " occurs 0,
matnr LIKE ekpo-matnr,
werks LIKE ekpo-werks,
brgew LIKE ekpo-brgew,
** menge LIKE ekpo-menge,
netpr(9),
peinh LIKE ekpo-peinh,
bprme LIKE ekpo-bprme,
eeind LIKE sy-datum, "YYYYMMDD
END OF i_fics.
DATA: BEGIN OF i_daten OCCURS 0,
matnr LIKE ekpo-matnr,
werks LIKE ekpo-werks,
lgort LIKE ekpo-lgort,
brgew(17),
** menge(17),
netpr(14),
meins LIKE ekpo-meins,
peinh LIKE ekpo-peinh,
bprme LIKE ekpo-bprme,
eeind LIKE sy-datum, "YYYYMMDD
END OF i_daten.
Code: Alles auswählen.
* Kopfdaten
DATA: i_ekko TYPE TABLE OF ty_ekko WITH HEADER LINE.
DATA: wa_ekko LIKE LINE OF i_ekko.
* Positionsdaten (aus dem txt-file)
DATA: gt_import TYPE TABLE OF i_fics.
FIELD-SYMBOLS: <gw_import> LIKE LINE OF gt_import.
Code: Alles auswählen.
PARAMETERS: p_name LIKE apqi-groupid DEFAULT 'BUAU_PO' OBLIGATORY,
p_file(128) TYPE c DEFAULT 'C:\xxxxxxxx.txt' OBLIGATORY LOWER CASE,
p_lifnr LIKE ekko-lifnr OBLIGATORY,
p_ekgrp LIKE ekko-ekgrp OBLIGATORY.
DATA zfile TYPE string.
AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_file.
CALL METHOD cl_gui_frontend_services=>file_open_dialog
EXPORTING
default_extension = 'txt'
file_filter = '*.txt'
multiselection = abap_false
CHANGING
file_table = retfiletable
rc = retrc
user_action = retuseraction.
READ TABLE retfiletable INTO p_file INDEX 1.
START-OF-SELECTION.
* Unicode / Releasewechsel AJ/03.01.2005
zfile = p_file.
CALL METHOD cl_gui_frontend_services=>gui_upload
EXPORTING
filename = zfile
has_field_separator = abap_true
CHANGING
data_tab = gt_import.
CHECK gt_import IS NOT INITIAL.
Code: Alles auswählen.
PERFORM i_daten_aufbauen.
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Form i_daten_aufbauen
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
* --> p1 text
* <-- p2 text
*----------------------------------------------------------------------*
FORM i_daten_aufbauen.
LOOP AT gt_import ASSIGNING <gw_import>.
IF <gw_import>-matnr CO ' 0123456789'.
UNPACK <gw_import>-matnr TO <gw_import>-matnr.
ENDIF.
IF <gw_import>-matnr IS INITIAL OR
<gw_import>-matnr CN '0123456789'.
CONTINUE.
ENDIF.
TRANSLATE <gw_import>-netpr USING '$ '.
TRANSLATE <gw_import>-netpr USING ',.'.
WRITE <gw_import>-netpr TO i_daten-netpr.
WRITE <gw_import>-brgew TO i_daten-brgew.
MOVE-CORRESPONDING <gw_import> TO i_daten.
APPEND i_daten.
CLEAR i_daten.
ENDLOOP.
ENDFORM. " i_daten_aufbauenCode: Alles auswählen.
* Header Level Data
pohead-comp_code = '6101'.
pohead-doc_type = 'NB' .
pohead-creat_date = sy-datum.
** pohead-vendor = '0000200003'.
pohead-vendor = p_lifnr.
** pohead-purch_org = '4500'.
pohead-purch_org = 'BUAU'.
** pohead-pur_group = '499'.
pohead-pur_group = p_ekgrp.
pohead-langu = sy-langu.
** pohead-doc_date = date.
pohead-doc_date = i_ekko-create.
pohead-currency = 'AUD'.
pohead-langu = 'EN'.
* Head Level BAPI X
poheadx-comp_code = c_x.
poheadx-doc_type = c_x.
poheadx-creat_date = c_x.
poheadx-vendor = c_x.
poheadx-langu = c_x.
poheadx-purch_org = c_x.
poheadx-pur_group = c_x.
poheadx-doc_date = c_x.
poheadx-currency = c_x.
poheadx-langu = c_x.
* Item Level
LOOP AT i_daten.
ADD 1 TO l_count.
poitem-po_item = l_count.
poitem-material = i_daten-matnr.
** poitem-plant = '4500'.
poitem-plant = i_daten-werks.
poitem-stge_loc = 'BRI'.
poitem-quantity = i_daten-brgew.
** poitem-po_unit = i_daten-meins. "Bestellmengeneinheit
poitem-po_unit = i_daten-bprme. "Bestellpreismengeneinheit
poitem-net_price = i_daten-netpr.
poitem-price_unit = i_daten-peinh.
poitem-no_more_gr = ' '.
poitem-final_inv = 'X'.
poitem-no_rounding = 'X'.
poitem-po_price = '1'.
APPEND poitem.
* Item level BAPI X
poitemx-po_item = l_count.
poitemx-po_itemx = c_x.
poitemx-material = c_x.
poitemx-plant = c_x .
poitemx-stge_loc = c_x .
poitemx-quantity = c_x .
poitemx-po_unit = c_x.
poitemx-net_price = c_x.
poitemx-price_unit = c_x.
poitemx-no_more_gr = c_x.
poitemx-final_inv = c_x.
poitemx-no_rounding = c_x.
poitemx-po_price = c_x.
APPEND poitemx.
ENDLOOP.
Habe ich was Wichtiges vergessen?
Oder weshalb wird mit solchen Meldungen gemotzt?
Danke!
lG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Na sieht doch schonmal nicht schlecht aus . 
ok die Meldungen die du da bekommst, mal einzeln abarbeiten:
bei den Header daten, ist noch ein zweites datum zu füllen, ist i_ekko-create wirklich gefüllt ?
Bestellmengeneinheit, nimm erstmal KG was das System dir anscheinend ja abnimmt. Danach kann man immer noch schauen wie er TO haben will.
bei der Perioden meldung, sind deine Buchungsperioden offen im Testsystem ?
kann aber auch sein das es mit dem Datum im header teil zu tun hat, welches wenn es fehlt die Meldung verursacht,
da er keine periode ableiten kann.
bei der ersten Meldung CI_EKPODB , habt ihr Kundeneigene Felder in der EKPO die gefüllt werden müssen ?
lässt du die Sache im Testmode laufen ? dann kommt die Instanzmledung glaub ich immer.
gruss
ratsnus
ok die Meldungen die du da bekommst, mal einzeln abarbeiten:bei den Header daten, ist noch ein zweites datum zu füllen, ist i_ekko-create wirklich gefüllt ?
Code: Alles auswählen.
* Header Level Data
pohead-comp_code = '6101'.
pohead-doc_type = 'NB' .
pohead-creat_date = sy-datum.
** pohead-vendor = '0000200003'.
pohead-vendor = p_lifnr.
** pohead-purch_org = '4500'.
pohead-purch_org = 'BUAU'.
** pohead-pur_group = '499'.
pohead-pur_group = p_ekgrp.
pohead-langu = sy-langu.
** pohead-doc_date = date.
********************************************************
pohead-doc_date = i_ekko-create.
********************************************************
pohead-currency = 'AUD'.
pohead-langu = 'EN'.
* Head Level BAPI Xbei der Perioden meldung, sind deine Buchungsperioden offen im Testsystem ?
kann aber auch sein das es mit dem Datum im header teil zu tun hat, welches wenn es fehlt die Meldung verursacht,
da er keine periode ableiten kann.
bei der ersten Meldung CI_EKPODB , habt ihr Kundeneigene Felder in der EKPO die gefüllt werden müssen ?
lässt du die Sache im Testmode laufen ? dann kommt die Instanzmledung glaub ich immer.
gruss
ratsnus
<:: XING-Gruppe Tricktresor::>
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hello Ratsnus,
Danke!
- ja, du hattest recht - -> i_ekko-create war leer, aus dem Grund hatte er kein zweites Datum und somit kamen auch die ganzen Meldungen, die sind nun alle beseitigt, nachdem ich ihm ein zweites Datum mitgegeben habe.
Nun kann er auch erfolgreich die jeweilige Bestellung anlegen - über me23n erfolgreich getestet, ob die Bestellung über das .txt-file auch wirklich angelegt wird, dem ist auch so.
Die beiden Meldungen:
"Fehler bei der Übernahme der ExtensionIn Daten für Erweiterung CI_EKPODB"
und
"Fehler bei der Übernahme der ExtensionIn Daten für Erweiterung CI_EKKODB"
sind nach wie vor vorhanden!?? - mir ist jedoch nichts bewusst, dass wir kundeneigene Felder in der EKPO haben die gefüllt werden müssen!? - die Bestellung wird auch, lt. me23n offensichtlich erfolgreich angelegt, ...
d.h. laut Debug (siehe attached "debug _ return.jpg" ) dürten die beiden Meldungen auch nur Warnungen sein!!
- kann man das umgehen, dass die einfach nicht ausgegeben werden!?!
Was noch immer sehr merkwürdig ist, ist dass Tonnen (TO, und auch alle weitere Mengeneinheiten, ... - ich probierte auch schon Weitere) einfach nicht genommen werden! - er gibt die meldung aus, und in der ME23N legt er KG dazu an.
Das heißt es werden IMMER NUR KG akzeptiert, egal was für eine Mengeneinheit ich eingebe.
---> das kann ja auch nicht sein, oder??
weil manuell kann ich auch andere Mengeneinheiten eingeben, da muss es doch über den BAPI auch funkt. , oder?
Vor allem weil im debug TO angelegt werden, aber in der Transaktion dann nicht mehr, ...
Woran kann das liegen??
Danke!
lG
Danke!
- ja, du hattest recht - -> i_ekko-create war leer, aus dem Grund hatte er kein zweites Datum und somit kamen auch die ganzen Meldungen, die sind nun alle beseitigt, nachdem ich ihm ein zweites Datum mitgegeben habe.
Nun kann er auch erfolgreich die jeweilige Bestellung anlegen - über me23n erfolgreich getestet, ob die Bestellung über das .txt-file auch wirklich angelegt wird, dem ist auch so.
Die beiden Meldungen:
"Fehler bei der Übernahme der ExtensionIn Daten für Erweiterung CI_EKPODB"
und
"Fehler bei der Übernahme der ExtensionIn Daten für Erweiterung CI_EKKODB"
sind nach wie vor vorhanden!?? - mir ist jedoch nichts bewusst, dass wir kundeneigene Felder in der EKPO haben die gefüllt werden müssen!? - die Bestellung wird auch, lt. me23n offensichtlich erfolgreich angelegt, ...
d.h. laut Debug (siehe attached "debug _ return.jpg" ) dürten die beiden Meldungen auch nur Warnungen sein!!
- kann man das umgehen, dass die einfach nicht ausgegeben werden!?!
Was noch immer sehr merkwürdig ist, ist dass Tonnen (TO, und auch alle weitere Mengeneinheiten, ... - ich probierte auch schon Weitere) einfach nicht genommen werden! - er gibt die meldung aus, und in der ME23N legt er KG dazu an.
Das heißt es werden IMMER NUR KG akzeptiert, egal was für eine Mengeneinheit ich eingebe.
---> das kann ja auch nicht sein, oder??
weil manuell kann ich auch andere Mengeneinheiten eingeben, da muss es doch über den BAPI auch funkt. , oder?
Vor allem weil im debug TO angelegt werden, aber in der Transaktion dann nicht mehr, ...
Woran kann das liegen??
Danke!
lG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
OK, also das
"Fehler bei der Übernahme der ExtensionIn Daten für Erweiterung CI_EKPODB"
würde ich mal ignorieren. ist ja nur eine Warnung. das mit den Tonnen ist allerdings etwas komisch.
versuch mal bei poitem dieses feld auch zu füllen: aber nicht vergessen, auch in der poitemx das feld mit einem X zu versorgen.
gruss
ratsnus
"Fehler bei der Übernahme der ExtensionIn Daten für Erweiterung CI_EKPODB"
würde ich mal ignorieren. ist ja nur eine Warnung. das mit den Tonnen ist allerdings etwas komisch.
versuch mal bei poitem dieses feld auch zu füllen: aber nicht vergessen, auch in der poitemx das feld mit einem X zu versorgen.
gruss
ratsnus
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
<:: XING-Gruppe Tricktresor::>
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hallo Ratsnus,
Danke für deine Hilfe.
Ja, mit dem Vorschlag des anderen Feldes hat er nun auch TO in der ME23N erfolgreich angelegt.
Nach Anlage in der Bestellpreismengeneinheit einer TO kam dann eine neue Warnung (lt. Debug auch eine Warnung, siehe screenshots, dass ich "Mengeneinheit und Umrechnungsfaktor prüfen" soll, obwohl es d. selbe Datenelement besitzt wie BPRME) , aber - wie gesagt - im ME23N offensichtlich erfolgreich angelegt.
Ich habe aus diesem Grund jetzt vor der Ausgabe der return-message eine IF-Bedingung eingebaut, dass er keine Warnungen ausgibt (siehe dritter screenshot) , somit kommt dann nur die Info, dass die Bestellung angelegt wurde.
- ich weiß, das ist zwar "geschummelt" :-/ , aber nachdem die Bestellung lt. ME23N offensichtlich erfolgreich angelegt wird!?! ... - verwirren solche Warnungen ja den Kunden nur unnötig, und er glaubt dann vermutlich, dass es ein Fehler ist, ...
Danke vorab mal,
lG
Danke für deine Hilfe.
Ja, mit dem Vorschlag des anderen Feldes hat er nun auch TO in der ME23N erfolgreich angelegt.
Nach Anlage in der Bestellpreismengeneinheit einer TO kam dann eine neue Warnung (lt. Debug auch eine Warnung, siehe screenshots, dass ich "Mengeneinheit und Umrechnungsfaktor prüfen" soll, obwohl es d. selbe Datenelement besitzt wie BPRME) , aber - wie gesagt - im ME23N offensichtlich erfolgreich angelegt.
Ich habe aus diesem Grund jetzt vor der Ausgabe der return-message eine IF-Bedingung eingebaut, dass er keine Warnungen ausgibt (siehe dritter screenshot) , somit kommt dann nur die Info, dass die Bestellung angelegt wurde.
- ich weiß, das ist zwar "geschummelt" :-/ , aber nachdem die Bestellung lt. ME23N offensichtlich erfolgreich angelegt wird!?! ... - verwirren solche Warnungen ja den Kunden nur unnötig, und er glaubt dann vermutlich, dass es ein Fehler ist, ...
Danke vorab mal,
lG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Hello Ratsnus,
... ich hatte was vergessen - und habe daher das Lieferdatum, das ja auch im txt-file mitgegeben wird, nachträglich über die bapi-Tabelle poschedule (weil im poitem gibt es kein delivery date) im code hinzugefügt:
Es wird auch richtig, mit dem richtigen Lieferdatum aus dem txt-file in der ME23N angelegt,
das Problem ist leider jetzt nur dieses, dass die Bestellmenge doppelt (x 2) angelegt wird, AUCH wenn ich in der poitem die Quantity gar nicht mitgebe!! - und in der Tabelle poschedule ist quantity ein Pflichtfeld, sonst kann er die Bestellung nicht anlegen.
laut debug habe ich gesehen, dass er bis zum ENDLOOP (i_daten) die Quantity richtig ausfüllt,
jedoch nach Ausführung des BAPI:
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
poheader = pohead
poheaderx = poheadx
testrun = testrun
no_messaging = 'X'
no_message_req = 'X'
no_authority = 'X'
no_price_from_po = 'X'
IMPORTING
exppurchaseorder = ex_po_number
expheader = exp_head
TABLES
return = return
poitem = poitem
poitemx = poitemx
poschedule = poschedule
poschedulex = poschedulex.
ist lt. debug die quantity im poitem doppelt drinnen (mal zwei gerechnet, eben einmal für poitem und einmal für poschedule )
(siehe die beiden screenshots einmal davor , einmal danach...
Kann man das umgehen??
das ist nämlich schon sehr blöd sonst :-/
Danke!
lG
... ich hatte was vergessen - und habe daher das Lieferdatum, das ja auch im txt-file mitgegeben wird, nachträglich über die bapi-Tabelle poschedule (weil im poitem gibt es kein delivery date) im code hinzugefügt:
Code: Alles auswählen.
* Item Level
LOOP AT i_daten.
ADD 1 TO l_count.
SELECT SINGLE datfm FROM usr01 INTO l_datfm
WHERE bname = sy-uname.
CASE l_datfm.
WHEN '1'.
CONCATENATE i_daten-eeind+6(2) i_daten-eeind+4(2) i_daten-eeind(4)
INTO zw_eeind SEPARATED BY '.'.
WHEN '2'.
CONCATENATE i_daten-eeind+4(2) i_daten-eeind+6(2) i_daten-eeind(4)
INTO zw_eeind SEPARATED BY '/'.
WHEN '3'.
CONCATENATE i_daten-eeind+4(2) i_daten-eeind+6(2) i_daten-eeind(4)
INTO zw_eeind SEPARATED BY '.'.
WHEN '4'.
CONCATENATE i_daten-eeind(4) i_daten-eeind+4(2) i_daten-eeind+6(2)
INTO zw_eeind SEPARATED BY '.'.
WHEN '5'.
CONCATENATE i_daten-eeind(4) i_daten-eeind+4(2) i_daten-eeind+6(2)
INTO zw_eeind SEPARATED BY '/'.
WHEN '6'.
CONCATENATE i_daten-eeind(4) i_daten-eeind+4(2) i_daten-eeind+6(2)
INTO zw_eeind SEPARATED BY '-'.
WHEN OTHERS.
ENDCASE.
poitem-po_item = l_count.
poitem-material = i_daten-matnr.
poitem-plant = i_daten-werks.
poitem-stge_loc = 'BRI'.
poitem-quantity = i_daten-menge. "Bestellmenge
** poitem-quantity = i_daten-brgew. "Bruttogewicht
poitem-orderpr_un = i_daten-bprme. "Bestellpreismengeneinheit
poitem-net_price = i_daten-netpr.
poitem-price_unit = i_daten-peinh.
poitem-no_more_gr = ' '.
poitem-final_inv = 'X'.
poitem-no_rounding = 'X'.
poitem-po_price = '1'.
APPEND poitem.
* Item level BAPI X
poitemx-po_item = l_count.
poitemx-po_itemx = c_x.
poitemx-material = c_x.
poitemx-plant = c_x .
poitemx-stge_loc = c_x .
poitemx-quantity = c_x .
poitemx-orderpr_un = c_x.
poitemx-net_price = c_x.
poitemx-price_unit = c_x.
poitemx-no_more_gr = c_x.
poitemx-final_inv = c_x.
poitemx-no_rounding = c_x.
poitemx-po_price = c_x.
APPEND poitemx.
poschedule-po_item = l_count.
poschedule-del_datcat_ext = 'T'.
poschedule-delivery_date = zw_eeind.
** poschedule-quantity = i_daten-menge.
poschedule-quantity = poitem-quantity.
APPEND poschedule.
* Item level BAPI X
poschedulex-po_item = l_count.
poschedulex-po_itemx = c_x.
poschedulex-del_datcat_ext = c_x.
poschedulex-delivery_date = c_x.
poschedulex-quantity = c_x.
APPEND poschedulex.
ENDLOOP.das Problem ist leider jetzt nur dieses, dass die Bestellmenge doppelt (x 2) angelegt wird, AUCH wenn ich in der poitem die Quantity gar nicht mitgebe!! - und in der Tabelle poschedule ist quantity ein Pflichtfeld, sonst kann er die Bestellung nicht anlegen.
laut debug habe ich gesehen, dass er bis zum ENDLOOP (i_daten) die Quantity richtig ausfüllt,
jedoch nach Ausführung des BAPI:
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
poheader = pohead
poheaderx = poheadx
testrun = testrun
no_messaging = 'X'
no_message_req = 'X'
no_authority = 'X'
no_price_from_po = 'X'
IMPORTING
exppurchaseorder = ex_po_number
expheader = exp_head
TABLES
return = return
poitem = poitem
poitemx = poitemx
poschedule = poschedule
poschedulex = poschedulex.
ist lt. debug die quantity im poitem doppelt drinnen (mal zwei gerechnet, eben einmal für poitem und einmal für poschedule )
(siehe die beiden screenshots einmal davor , einmal danach...
Kann man das umgehen??
das ist nämlich schon sehr blöd sonst :-/
Danke!
lG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
komisch, da stimmt irgendetwas nicht. nimm mal anstatt der i_daten-menge, einfach eine Zahl aslo einen fixen Wert:
er sollte dir unabhängig von der Bestellmenge in der Bestellung eine Einteilung zum Lieferdatum mit 10 anlegen.
Code: Alles auswählen.
** poschedule-quantity = i_daten-menge.
poschedule-quantity = '10'.
APPEND poschedule.
<:: XING-Gruppe Tricktresor::>
Beitrag
von Fritzi_SAP (ForumUser / 8 / 0 /
0
)
»
Danke!
- jedoch kann man ihn leider so nicht "austricksen" , irgendwas ist da falsch!?
Weil nachdem ich bei poschedule-quantity den fixen Wert 10 eingegeben habe, hat er mit bei JEDER der angelegten Datensätze die Bestellmenge 20 in die ME23N geschrieben!?!
(einmal 10 für poitem-quantity und einmal 10 für poschedule-quantity)
Nachdem ich statt 10 den Wert 0 eingegeben habe (poschedule-quantity = '0'.) wird das natürlich so gesehen, als hätte ich keine Bestellmenge eingegeben, da kommt dann die Meldung: "Bitte eine Bestellmenge eingeben" und legt mir natürlich auch keine Bestellung an.
Nachdem ich bei der Bestellmenge bei poschedule wieder i_daten-menge eingegeben habe (poschedule-quantity = i_daten-menge.)
und dafür bei poitem die Zuweisung i_daten-menge (poitem-quantity = i_daten-menge.) auskommentiert habe (weil bei poitem is' kein Pflichtfeld, bei poschedule ist es ein Pflichtfeld), ...siehe code:
...das Ganze befindet sich natürlich im loop der i_daten, klar,...
Dann legt er die Bestellmenge in der ME23N TROTZDEM DOPPELT an!!!??? (siehe file.txt - 27x2 = 54, 15x2 = 30 und 30x2 = 60 (Ergebnis = die angezeigte Bestellmenge in der ME23N)
das kann doch nicht sein, bitte??
Das ist ein ganz blöder Fehler!
Dann bin ich draufgekommen weshalb die Menge im ME23N doppelt angedruckt wird -
und zwar habe ich im debug auch noch gesehen, dass er mir eine Zeile im poschedule jeweils doppelt anlegt, nach Ausführung des BAPI_PO_CREATE1 --> siehe screenshot "doppelte Anlage der Zeilen im poschedule.jpg"
--> und daran wird's vermutlich liegen :-/ , weil mit refresh poschedule löscht er natürlich die Einträge der poschedule, danach wird die Menge korrekt einmal in der ME23N angedruckt,
allerdings legt er dann klarerweise den Liefertermin in der ME23N auch nicht mehr korrekt aus dem txt-file an, da ich ja davor mit refresh die Zeilen der Tabelle gelöscht habe :-S
fehlt irgendwo ein clear oder refresh oder sonst was dergleichen!?? - bzw. man kann doch im refresh (?) jede zweite Zeile rauslöschen, bzw. dass er nur eine Zeile anlegt, oder?
... soviel ich weiß gibt es so einen Befehl, dass man jede zweite Zeile, die den gleichen Eintrag hat (doppelt angelegt wurde!), rauslöschen kann, oder?
Mein derzeitiger Code dazu sieht folgendermaßen aus:
Kann man das alles anders austricksen? so dass er die Bestellmenge nur einmal, mit dem richtigen Wert aus dem .txt-file in der ME23N andruckt?
- eben wie z.B., dass er nach dem Ausführen d. BAPI_PO_CREATE1 jede Zeile nur einmal ausgibt und nicht doppelt, so wie vor Ausführen des BAPI?
Gibt's da einen Befehl wo aus der poschedule jeder doppelte Eintrag rausgelöscht wird?
Danke!
lG
- jedoch kann man ihn leider so nicht "austricksen"
, irgendwas ist da falsch!? Weil nachdem ich bei poschedule-quantity den fixen Wert 10 eingegeben habe, hat er mit bei JEDER der angelegten Datensätze die Bestellmenge 20 in die ME23N geschrieben!?!
(einmal 10 für poitem-quantity und einmal 10 für poschedule-quantity)
Nachdem ich statt 10 den Wert 0 eingegeben habe (poschedule-quantity = '0'.) wird das natürlich so gesehen, als hätte ich keine Bestellmenge eingegeben, da kommt dann die Meldung: "Bitte eine Bestellmenge eingeben" und legt mir natürlich auch keine Bestellung an.
Nachdem ich bei der Bestellmenge bei poschedule wieder i_daten-menge eingegeben habe (poschedule-quantity = i_daten-menge.)
und dafür bei poitem die Zuweisung i_daten-menge (poitem-quantity = i_daten-menge.) auskommentiert habe (weil bei poitem is' kein Pflichtfeld, bei poschedule ist es ein Pflichtfeld), ...siehe code:
Code: Alles auswählen.
loop at i_daten.
poitem-po_item = l_count.
poitem-material = i_daten-matnr.
poitem-plant = i_daten-werks.
poitem-stge_loc = 'BRI'.
** poitem-quantity = i_daten-menge. "Bestellmenge
poitem-orderpr_un = i_daten-bprme. "Bestellpreismengeneinheit
poitem-net_price = i_daten-netpr.
poitem-price_unit = i_daten-peinh.
poitem-no_more_gr = ' '.
poitem-final_inv = 'X'.
poitem-no_rounding = 'X'.
poitem-po_price = '1'.
APPEND poitem.
* Item level BAPI X
poitemx-po_item = l_count.
poitemx-po_itemx = c_x.
poitemx-material = c_x.
poitemx-plant = c_x .
poitemx-stge_loc = c_x .
** poitemx-quantity = c_x .
poitemx-orderpr_un = c_x.
poitemx-net_price = c_x.
poitemx-price_unit = c_x.
poitemx-no_more_gr = c_x.
poitemx-final_inv = c_x.
poitemx-no_rounding = c_x.
poitemx-po_price = c_x.
APPEND poitemx.
poschedule-po_item = l_count.
poschedule-del_datcat_ext = 'T'.
poschedule-delivery_date = zw_eeind.
poschedule-quantity = i_daten-menge.
** poschedule-quantity = '0'.
** poschedule-quantity = poitem-quantity.
APPEND poschedule.
* Item level BAPI X
poschedulex-po_item = l_count.
poschedulex-po_itemx = c_x.
poschedulex-del_datcat_ext = c_x.
poschedulex-delivery_date = c_x.
poschedulex-quantity = c_x.
APPEND poschedulex.
endloop.Dann legt er die Bestellmenge in der ME23N TROTZDEM DOPPELT an!!!??? (siehe file.txt - 27x2 = 54, 15x2 = 30 und 30x2 = 60 (Ergebnis = die angezeigte Bestellmenge in der ME23N)
das kann doch nicht sein, bitte??
Das ist ein ganz blöder Fehler!
Dann bin ich draufgekommen weshalb die Menge im ME23N doppelt angedruckt wird -
und zwar habe ich im debug auch noch gesehen, dass er mir eine Zeile im poschedule jeweils doppelt anlegt, nach Ausführung des BAPI_PO_CREATE1 --> siehe screenshot "doppelte Anlage der Zeilen im poschedule.jpg"
--> und daran wird's vermutlich liegen :-/ , weil mit refresh poschedule löscht er natürlich die Einträge der poschedule, danach wird die Menge korrekt einmal in der ME23N angedruckt,
allerdings legt er dann klarerweise den Liefertermin in der ME23N auch nicht mehr korrekt aus dem txt-file an, da ich ja davor mit refresh die Zeilen der Tabelle gelöscht habe :-S
fehlt irgendwo ein clear oder refresh oder sonst was dergleichen!?? - bzw. man kann doch im refresh (?) jede zweite Zeile rauslöschen, bzw. dass er nur eine Zeile anlegt, oder?
... soviel ich weiß gibt es so einen Befehl, dass man jede zweite Zeile, die den gleichen Eintrag hat (doppelt angelegt wurde!), rauslöschen kann, oder?
Mein derzeitiger Code dazu sieht folgendermaßen aus:
Code: Alles auswählen.
...
* Item Level
LOOP AT i_daten.
ADD 1 TO l_count.
poitem-po_item = l_count.
poitem-material = i_daten-matnr.
poitem-plant = i_daten-werks.
poitem-stge_loc = 'BRI'.
poitem-quantity = i_daten-menge. "Bestellmenge
poitem-orderpr_un = i_daten-bprme. "Bestellpreismengeneinheit
poitem-net_price = i_daten-netpr.
poitem-price_unit = i_daten-peinh.
poitem-no_more_gr = ' '.
poitem-final_inv = 'X'.
poitem-no_rounding = 'X'.
poitem-po_price = '1'.
APPEND poitem.
* Item level BAPI X
poitemx-po_item = l_count.
poitemx-po_itemx = c_x.
poitemx-material = c_x.
poitemx-plant = c_x .
poitemx-stge_loc = c_x .
poitemx-quantity = c_x .
** poitemx-po_unit = c_x.
poitemx-orderpr_un = c_x.
poitemx-net_price = c_x.
poitemx-price_unit = c_x.
poitemx-no_more_gr = c_x.
poitemx-final_inv = c_x.
poitemx-no_rounding = c_x.
poitemx-po_price = c_x.
APPEND poitemx.
* poschedule-po_item = l_count.
* poschedule-del_datcat_ext = 'T'.
* poschedule-delivery_date = zw_eeind.
* poschedule-quantity = i_daten-menge.
*** poschedule-quantity = '0'.
*** poschedule-quantity = poitem-quantity.
* APPEND poschedule.
** Item level BAPI X
* poschedulex-po_item = l_count.
* poschedulex-po_itemx = c_x.
* poschedulex-del_datcat_ext = c_x.
* poschedulex-delivery_date = c_x.
* poschedulex-quantity = c_x.
* APPEND poschedulex.
* poitem-quantity = poitem-quantity - poschedule-quantity.
* APPEND poitem.
** CLEAR poschedule.
CLEAR poitem.
ENDLOOP.
** REFRESH poschedule.
clear l_count.
LOOP AT i_daten.
** LOOP AT poitem.
ADD 1 TO l_count.
SELECT SINGLE datfm FROM usr01 INTO l_datfm
WHERE bname = sy-uname.
CASE l_datfm.
WHEN '1'.
CONCATENATE i_daten-eeind+6(2) i_daten-eeind+4(2) i_daten-eeind(4)
INTO zw_eeind SEPARATED BY '.'.
WHEN '2'.
CONCATENATE i_daten-eeind+4(2) i_daten-eeind+6(2) i_daten-eeind(4)
INTO zw_eeind SEPARATED BY '/'.
WHEN '3'.
CONCATENATE i_daten-eeind+4(2) i_daten-eeind+6(2) i_daten-eeind(4)
INTO zw_eeind SEPARATED BY '.'.
WHEN '4'.
CONCATENATE i_daten-eeind(4) i_daten-eeind+4(2) i_daten-eeind+6(2)
INTO zw_eeind SEPARATED BY '.'.
WHEN '5'.
CONCATENATE i_daten-eeind(4) i_daten-eeind+4(2) i_daten-eeind+6(2)
INTO zw_eeind SEPARATED BY '/'.
WHEN '6'.
CONCATENATE i_daten-eeind(4) i_daten-eeind+4(2) i_daten-eeind+6(2)
INTO zw_eeind SEPARATED BY '-'.
WHEN OTHERS.
ENDCASE.
poschedule-po_item = l_count. "poitem-po_item.
poschedule-del_datcat_ext = 'T'.
poschedule-delivery_date = zw_eeind.
poschedule-quantity = i_daten-menge.
** poschedule-quantity = '0'.
** poschedule-quantity = poitem-quantity.
APPEND poschedule.
* Item level BAPI X
poschedulex-po_item = l_count.
poschedulex-po_itemx = c_x.
poschedulex-del_datcat_ext = c_x.
poschedulex-delivery_date = c_x.
poschedulex-quantity = c_x.
APPEND poschedulex.
CLEAR poschedule.
ENDLOOP.
CALL FUNCTION 'BAPI_PO_CREATE1'
EXPORTING
poheader = pohead
poheaderx = poheadx
testrun = testrun
no_messaging = 'X'
no_message_req = 'X'
no_authority = 'X'
no_price_from_po = 'X'
IMPORTING
exppurchaseorder = ex_po_number
expheader = exp_head
TABLES
return = return
poitem = poitem
poitemx = poitemx
poschedule = poschedule
poschedulex = poschedulex.
COMMIT WORK AND WAIT.
... - eben wie z.B., dass er nach dem Ausführen d. BAPI_PO_CREATE1 jede Zeile nur einmal ausgibt und nicht doppelt, so wie vor Ausführen des BAPI?
Gibt's da einen Befehl wo aus der poschedule jeder doppelte Eintrag rausgelöscht wird?
Danke!
lG
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Fehlermeldung Übernahme Extension liegt daran, dass Strukturen CI_EKKO bzw. CI_EKPO auch nicht-character Felder enthalten.
Normale Menschen wundern sich, warum in der Welt so viel schief läuft.
Programmierer wundern sich, warum alles so gut funktioniert.
Programmierer wundern sich, warum alles so gut funktioniert.
Seite 1 von 1
Vergleichbare Themen
1
Antw.
Antw.
1315
Views
Views
Bestellung ( ME21) mit Batch / Kontierungssubscreen
von Kleenmex » 14.06.2007 17:40 • Verfasst in Material Management & Produktionsplanung
von Kleenmex » 14.06.2007 17:40 • Verfasst in Material Management & Produktionsplanung
4
Antw.
Antw.
2630
Views
Views
Batch Input / ME21 - Problem bei Kontierung auf Anlage
von Anchi » 21.06.2007 11:44 • Verfasst in Material Management & Produktionsplanung
von Anchi » 21.06.2007 11:44 • Verfasst in Material Management & Produktionsplanung
6
Antw.
Antw.
3052
Views
Views
3
Antw.
Antw.
3302
Views
Views
Batch-Input: Kunde anlegen / ändern
von 4sunshine » 19.11.2007 12:33 • Verfasst in ABAP® für Anfänger
von 4sunshine » 19.11.2007 12:33 • Verfasst in ABAP® für Anfänger
12
Antw.
Antw.
5346
Views
Views
über Batch Input Ansprechpartner zu Lieferanten anlegen
von SAPlerin » 13.04.2011 16:02 • Verfasst in ABAP® Core
von SAPlerin » 13.04.2011 16:02 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.