Extending Plants thru IDOC
Hi,
I have created Material using transaction MM01 manually and then going to WE19 and trying to create/extend to plants using the IDOC. It's showing the success status 53 if look at status in WE02 but views are not being created.
This is being done using a customized FM which is a modification to 'IDOC_INPUT_MATMAS01'.
Plz reply ASAP if somebody is aware of the issue.
Rgds,
Srini
Finally got it figured out. Steps I used to generate the new customer BAPI-IDOC interface:
1. Created custom structure with data elements desired
2. Copied the BAPI_BATCH_REPLICATE and BAPI_BATCH_SAVE_REPLICA function modules to custom function modules
3. Add parameter for custom segment to BAPI_BATCH_SAVE_REPLICA
4. Extend BAPI object with custom segment
5. Generate the ALE interface (this was where I got stuck originally)
6. Assign function module to generate message type (BD60)
7. Assigned additional change pointer field to message type (BD52)
Similar Messages
-
IDOC: Material master (Extend Plants)
I used LSMW IDOC option to migrate material master data (MATMAS):
- Basic views
- Description
- Costing
- Plant Stock
I want to extend the plant view (Plant Stock). What change do I do to original LSMW to extend plant?
How do I specify that I am extending?
Is it that function code at the beginning of IDOC?You can do this by writing a program:
REPORT zdmmm_mm_multiplant NO STANDARD PAGE HEADING
MESSAGE-ID zdmmm
LINE-SIZE 255.
TABLE DECLARATION *
TABLES: mara, "General Material Data
mard, "Storage location data
mdma, "MRP data for material
marc. "Plant Data for Material
include zdmmmr_dev00160_mm_multi_top.
include zdmmmr_dev00160_mm_multi_f00.
AT SELECTION-SCREEN *
AT SELECTION-SCREEN.
IF NOT s_matnr[] IS INITIAL.
*Subroutine to perform the Material Number validation
PERFORM sub_validate_matnr.
ELSEIF p_ersda IS INITIAL.
MESSAGE e003 .
ENDIF.
IF NOT s_werks[] IS INITIAL.
Subroutine to perform the plant validation
PERFORM sub_validate_plant.
ENDIF.
START-OF-SELECTION
START-OF-SELECTION.
*To retrive all possible material numbers that have to be
*extended.
PERFORM sub_get_mara.
*To retrieve all possible plants to which the material needs
*to be extended.
IF s_werks IS INITIAL.
PERFORM sub_get_werks.
ENDIF.
*For retrieving Procurement status data from T134.
PERFORM sub_get_pstat.
*To determine the plants to which the Materials have
*already been extended.
PERFORM sub_get_marc.
*To determine all Storage Locations for individual Plants.
PERFORM sub_get_t001l.
*To retrieve company code
PERFORM sub_get_t001k.
*To determine the storage locations and plants to which the Material
*has already extended.
PERFORM sub_get_mard.
*To determine the MRP Areas to which the materials need to be extended.
PERFORM sub_get_mdlv.
*To determine the MRP Areas to which the materials already been extended.
PERFORM sub_get_mdma.
*To retrieve the MRP Area related data from customized table.
PERFORM sub_get_zdmmm_mrp_area.
*TO retrieve the Scalabilty info
PERFORM sub_get_scalability.
*For extending Material to Plant, all possible Storage Location and corresponding MRP Area .
PERFORM sub_mat_extn.
*For creating success and error log.
PERFORM sub_create_log.
*Text elements
001 Material/Plant Selection
002 No data found for given Selection.
003 Reference material is not maintained
004 Material is already extended to the plant
006 Material extended for MRP Area
007 Successfully extended
008 Already extended
009 Not a seviceable storage location,cannot be extended to MRP Area
*Selection texts
P_ERSDA Date
S_MATNR Material Number
S_WERKS Extend to Plant
*Messages
Message class: ZDMMM
*000 & & & &
*001 The material no. does not exist
*002 The plant does not exists.
*003 Enter either material no. or Creation date
*& Include ZDMMMR_MM_MULTI_TOP *
Types
*Type declaration to hold material no.
TYPES: BEGIN OF ty_matnr,
matnr TYPE matnr, "Material Number
mtart TYPE mtart, "Material Type
ersda TYPE ersda, "Creation date
mbrsh TYPE mbrsh, "Industry Sector
vkorg TYPE vkorg, "Sales Organization
vtweg TYPE vtweg, "Distribution Channel
mtartz TYPE zmtart, "Material Type (Customized)
END OF ty_matnr.
*Type declaration to hold plant.
TYPES: BEGIN OF ty_plant,
werks TYPE werks_d, "Plant
bwkey TYPE bwkey, "Valuation area
END OF ty_plant.
*Type declaration to hold data from marc.
TYPES: BEGIN OF ty_marc,
matnr TYPE matnr, "Material Number
werks TYPE werks_d, "Plant
bwkey TYPE bwkey,
END OF ty_marc.
*Type declaration to hold data from mard.
TYPES: BEGIN OF ty_mard,
matnr TYPE matnr, "Material Number
werks TYPE werks_d, "Plant
lgort TYPE lgort_d, "Storage Location
mtart TYPE mtart, "Material Type
END OF ty_mard.
*Type declaration to hold data from t001l.
TYPES: BEGIN OF ty_sloc,
werks TYPE werks_d, "Plant
lgort TYPE lgort_d, "Storage Location
END OF ty_sloc.
*Type declaration to hold data from mdlv.
TYPES: BEGIN OF ty_mdlv,
berid TYPE berid, "MRP Area
werzg TYPE werks_d, "Plant
ortzg TYPE lgort_d, "Storage Location
END OF ty_mdlv.
*Type declaration to hold data from custom table ZDMMM_MRP_AREA.
TYPES: BEGIN OF ty_refmdma,
zmtart TYPE zdmmm_mrp_area-zmtart, "Material Type (Customized)
zwerks TYPE zdmmm_mrp_area-zwerks, "Plant
zberid TYPE zdmmm_mrp_area-zberid, "MRP Area
zdismm TYPE zdmmm_mrp_area-zdismm, "MRP Type
zeisbe TYPE zdmmm_mrp_area-zeisbe, "Safety Stock
zdisls TYPE zdmmm_mrp_area-zdisls, "Lot Size
zdispo TYPE zdmmm_mrp_area-zdispo, "MRP Controller
zfxhor TYPE zdmmm_mrp_area-zfxhor, "Plant Delivery Time (In days)
END OF ty_refmdma.
*Type declaration to hold data for success log.
TYPES: BEGIN OF ty_succ,
mat(18) TYPE c, "Material
plant(8) TYPE c, "Plant
sloc(15) TYPE c, "Storage Location
comm(150) TYPE c, "Comments
END OF ty_succ.
*Type declaration to hold data for error log.
TYPES: BEGIN OF ty_error,
mat(18) TYPE c, "Material
plant(8) TYPE c, "Plant
sloc(15) TYPE c, "Storage Location
comm(150) TYPE c, "Comments
END OF ty_error.
*Type declaration for holding data from mvke
TYPES: BEGIN OF ty_mvke,
matnr TYPE matnr, "Material Number
vkorg TYPE vkorg, "Sales Org
vtweg TYPE vtweg, "Distribution Channel
END OF ty_mvke.
*Type declaration for holding data from qmat
TYPES: BEGIN OF ty_qmat,
matnr type matnr,
werks type werks_d,
art TYPE qmat-art,
ppl TYPE qmat-ppl,
spezueber TYPE qmat-spezueber,
conf TYPE qmat-conf,
tls TYPE qmat-tls,
app TYPE qmat-app,
mer TYPE qmat-mer,
insmk TYPE qmat-insmk,
ave TYPE qmat-ave,
stichprver TYPE qmat-stichprver,
dynregel TYPE qmat-dynregel,
sproz TYPE qmat-sproz,
hpz TYPE qmat-hpz,
dyn TYPE qmat-dyn,
mpb TYPE qmat-mpb,
mst TYPE qmat-mst,
ein TYPE qmat-ein,
mpdau TYPE qmat-mpdau,
chg TYPE qmat-chg,
qkzverf TYPE qmat-qkzverf,
qpmat TYPE qmat-qpmat,
kzprfkost TYPE qmat-kzprfkost,
aufnr_co TYPE qmat-aufnr_co,
aktiv TYPE qmat-aktiv,
apa TYPE qmat-apa,
afr TYPE qmat-afr,
mma TYPE qmat-mma,
feh TYPE qmat-feh,
prfrq TYPE qmat-prfrq,
nkmpr TYPE qmat-nkmpr,
END OF ty_qmat.
*Type declaration for MARA and MARC data for reference material
TYPES: BEGIN OF ty_ref_data,
matnr TYPE matnr, "Material Number
ladgr TYPE ladgr, "Loading Group
bklas TYPE bklas, "Valuation class
peinh TYPE peinh, "Price unit
losgr TYPE losgr, "Costing Lot Size
hkmat TYPE hkmat, "Material Origin
herkl TYPE herkl, "Country Of Origin
dismm TYPE dismm, "MRP Type
dispo TYPE dispo, "MRP Controller
fxhor TYPE fxhor, "Planned delivery time (In days)
disls TYPE disls, "Lot size
fhori TYPE fhori, "Scheduling Margin Key for Floats
magrv TYPE magrv,
vhart TYPE vhart,
ergew TYPE ergew,
ervol TYPE ervol,
fuelg TYPE fuelg,
stfak TYPE stfak,
gewto TYPE gewto,
volto TYPE volto,
prctr TYPE prctr,
kzgvh TYPE kzgvh,
stawn TYPE stawn,
mtver TYPE mtver,
casnr TYPE casnr,
gpnum TYPE gpnum,
steuc TYPE steuc,
herkr TYPE herkr,
mownr TYPE mownr,
mogru TYPE mogru,
prenc TYPE prenc,
preno TYPE preno,
prend TYPE prend,
itark TYPE itark,
bstme TYPE bstme,
vabme TYPE vabme,
nrfhg TYPE nrfhg,
mfrgr TYPE mfrgr,
ekwsl TYPE ekwsl,
webaz TYPE webaz,
insmk TYPE insmk,
kzkri TYPE kzkri,
usequ TYPE usequ,
kordb TYPE kordb,
mprof TYPE mprof,
ekgrp TYPE ekgrp,
disgr TYPE disgr,
maabc TYPE maabc,
minbe TYPE minbe,
lfrhy TYPE lfrhy,
bstmi TYPE bstmi,
bstma TYPE bstma,
bstfe TYPE bstfe,
mabst TYPE mabst,
losfx TYPE losfx,
lagpr TYPE lagpr,
ausss TYPE ausss,
takzt TYPE takzt,
rdprf TYPE rdprf,
bstrf TYPE bstrf,
megru TYPE megru,
sobsl TYPE sobsl,
kzech TYPE kzech,
lgpro TYPE lgpro,
vspvb TYPE vspvb,
rgekz TYPE rgekz,
lgfsb TYPE lgfsb,
fabkz TYPE fabkz,
eprio TYPE eprio,
schgt TYPE schgt,
plifz TYPE plifz,
mrppp TYPE mrppp,
eisbe TYPE eisbe,
lgrad TYPE lgrad,
eislo TYPE eislo,
rwpro TYPE rwpro,
shflg TYPE shflg,
shzet TYPE shzet,
shpro TYPE shpro,
periv TYPE periv,
auftl TYPE auftl,
strgr TYPE strgr,
vrmod TYPE vrmod,
vint2 TYPE vint2,
umref TYPE umref,
prgrp TYPE prgrp,
vint1 TYPE vint1,
miskz TYPE miskz,
prwrk TYPE prwrk,
mtvfp TYPE mtvfp,
wzeit TYPE wzeit,
kzpsp TYPE kzpsp,
stdpd TYPE stdpd,
perkz TYPE perkz,
altsl TYPE altsl,
kausf TYPE kausf,
sbdkz TYPE sbdkz,
kzbed TYPE kzbed,
ahdis TYPE ahdis,
kzaus TYPE kzaus,
ausdt TYPE ausdt,
nfmat TYPE nfmat,
sauft TYPE sauft,
sfepr TYPE sfepr,
mdach TYPE mdach,
dplfs TYPE dplfs,
dplpu TYPE dplpu,
dplho TYPE dplho,
tempb TYPE tempb,
raube TYPE raube,
behvo TYPE behvo,
stoff TYPE stoff,
abcin TYPE abcin,
ccfix TYPE ccfix,
wesch TYPE wesch,
etiar TYPE etiar,
etifo TYPE etifo,
xgchp TYPE xgchp,
maxlz TYPE maxlz,
lzeih TYPE lzeih,
mhdrz TYPE mhdrz,
mhdhb TYPE mhdhb,
iprkz TYPE dattp,
rdmhd TYPE rdmhd,
mhdlp TYPE mhdlp,
brgew TYPE brgew,
ntgew TYPE ntgew,
volum TYPE volum,
voleh TYPE voleh,
groes TYPE groes,
xmcng TYPE xmcng,
loggr TYPE loggr,
sernp TYPE serail,
serlv TYPE serlv,
fprfm TYPE fprfm,
ausme TYPE ausme,
qmata TYPE qmatauth,
kzdkz TYPE kzdkz,
prfrq TYPE prfrq,
rbnrm TYPE rbnr,
qmpur TYPE qmpur,
ssqss TYPE ssqss,
qzgtp TYPE qzgtyp,
qssys TYPE qssys,
bwtty TYPE bwtty,
eklas TYPE eklas,
qklas TYPE qklas,
verpr TYPE verpr,
stprs TYPE stprs,
zkprs TYPE dzkprs,
zkdat TYPE dzkdat,
bwprs TYPE bwprs,
bwprh TYPE bwprh,
bwps1 TYPE bwps1,
bwph1 TYPE bwph1,
vjbws TYPE vjbws,
vjbwh TYPE vjbwh,
abwkz TYPE abwkz,
bwpei TYPE bwpei,
xlifo TYPE xlifo,
mypol TYPE mypool,
ncost TYPE ck_no_costing,
ekalr TYPE ck_ekalrel,
hrkft TYPE hrkft,
kosgr TYPE ck_kosgr,
awsls TYPE awsls,
mmsta TYPE mmsta,
mmstd TYPE mmstd,
stlal TYPE stlal,
stlan TYPE stlan,
plnnr TYPE plnnr,
aplal TYPE plnal,
plnty TYPE plnty,
sobsk TYPE ck_sobsl,
zplpr TYPE dzplpr,
zplp1 TYPE dzplp1,
zpld1 TYPE dzpld1,
zplp2 TYPE dzplp2,
zpld2 TYPE dzpld2,
zplp3 TYPE dzplp3,
zpld3 TYPE dzpld3,
lvolg TYPE lvolg,
diskz TYPE diskz,
lsobs TYPE lsobs,
lminb TYPE lminb,
lbstf TYPE lbstf,
lgpbe TYPE lgpbe,
END OF ty_ref_data.
*Type declaration for holding data from mdma
TYPES: BEGIN OF ty_mdma,
matnr TYPE mdma-matnr, "Material Number
berid TYPE mdma-berid, "MRP Area
werks TYPE mdma-werks, "Plant
END OF ty_mdma.
*Type declaration for holding Company code data
TYPES: BEGIN OF ty_bukrs,
bwkey TYPE bwkey, "Valuation Area
bukrs TYPE bukrs, "Company code
END OF ty_bukrs.
*Type declaration for holding T001w Data
TYPES: BEGIN OF ty_t001w,
werks TYPE werks_d, "Plant
bwkey TYPE bwkey, "Valuation Area
END OF ty_t001w.
*Type declaration for holding T134 Data
TYPES: BEGIN OF ty_t134,
mtart TYPE mtart, " Material type
pstat TYPE pstat, "Condensed status display
END OF ty_t134.
Type declaration for Holding TWLAD data
TYPES: BEGIN OF ty_twlad,
werks TYPE werks_d,
lgort TYPE lgort_d,
adrnr TYPE adrnr,
END OF ty_twlad.
*Type declaration for holding ADRC data
TYPES: BEGIN OF ty_adrc,
adrnr TYPE adrnr, "Address number
sort2 TYPE ad_sort2, "Search Term
END OF ty_adrc.
TYPES: BEGIN OF ty_dev00160,
pkey TYPE zkey, "parameter key
item TYPE zitem, "Item No
value TYPE zvalue,
END OF ty_dev00160.
Constants
CONSTANTS: c_header(1) TYPE c VALUE 'H', "Header
c_true(1) TYPE c VALUE 'X', "value = x
c_v(1) TYPE c VALUE 'V', "Sales View
c_e(1) TYPE c VALUE 'E', "Purchasing View
c_d(1) TYPE c VALUE 'D', "MRP View
c_p(1) TYPE c VALUE 'P', "Forecasting View
c_a(1) TYPE c VALUE 'A', "Work Scheduling view
c_l(1) TYPE c VALUE 'L', "Storage View
c_q(1) TYPE c VALUE 'Q', "Quality View
c_b(1) TYPE c VALUE 'B', "Accounting
c_g(1) TYPE c VALUE 'G', "Costing View
c_f(1) TYPE c VALUE 'F', "PRT View
c_k(1) TYPE c VALUE 'K'. "Basic View
Internal tables
*Internal table to hold material no and material type
DATA: i_matnr TYPE STANDARD TABLE OF ty_matnr INITIAL SIZE 0.
*Internal table to hold plant
DATA: i_plant TYPE STANDARD TABLE OF ty_plant INITIAL SIZE 0.
*Internal table to hold marc data
DATA: i_marc TYPE STANDARD TABLE OF ty_marc INITIAL SIZE 0.
*Internal table to hold marc data
DATA: i_tmarc TYPE STANDARD TABLE OF ty_marc INITIAL SIZE 0.
*Internal table to hold mard data
DATA: i_mard TYPE STANDARD TABLE OF ty_mard INITIAL SIZE 0.
*Internal table to hold t001l data
DATA: i_sloc TYPE STANDARD TABLE OF ty_sloc INITIAL SIZE 0.
*Internal table to hold MRP Area
DATA: i_mdlv TYPE STANDARD TABLE OF ty_mdlv INITIAL SIZE 0.
*Internal table to hold already extended MRP Area
DATA: i_mdma TYPE STANDARD TABLE OF ty_mdma INITIAL SIZE 0.
*Internal table to hold MRP Area data from customized table
DATA: i_refmdma TYPE STANDARD TABLE OF ty_refmdma INITIAL SIZE 0.
*Internal table to hold success messages
DATA: i_succ TYPE STANDARD TABLE OF ty_succ INITIAL SIZE 0.
*Internal table to hold error messages
DATA: i_error TYPE STANDARD TABLE OF ty_error INITIAL SIZE 0.
*Internal table to hold mvke data
DATA: i_mvke TYPE STANDARD TABLE OF ty_mvke INITIAL SIZE 0.
*Internal table for company code data
DATA: i_bukrs TYPE STANDARD TABLE OF ty_bukrs INITIAL SIZE 0.
*Internal table for T001W data
DATA: i_t001w TYPE STANDARD TABLE OF ty_t001w INITIAL SIZE 0.
*Internal table for T134 data
DATA: i_t134 TYPE STANDARD TABLE OF ty_t134 INITIAL SIZE 0.
*Internal table for TWLAD data
DATA: i_twlad TYPE STANDARD TABLE OF ty_twlad INITIAL SIZE 0.
*Internal table for ADRC data
DATA: i_adrc TYPE STANDARD TABLE OF ty_adrc INITIAL SIZE 0.
*Internal table for dev00160 data
DATA: i_dev00160 TYPE STANDARD TABLE OF ty_dev00160 INITIAL SIZE 0.
*Internal table for qmat data
DATA: i_qmat TYPE STANDARD TABLE OF ty_qmat INITIAL SIZE 0.
Work areas
*Work Area for Internal table i_mara
DATA: wa_matnr TYPE ty_matnr.
*Work Area for Internal table i_werks
DATA: wa_plant TYPE ty_plant.
*Work Area for Internal table i_marc
DATA: wa_marc TYPE ty_marc.
*Work Area for Internal table i_t001l
DATA: wa_sloc TYPE ty_sloc.
*Work Area for Internal table i_mdlv
DATA: wa_mdlv TYPE ty_mdlv.
*Work Area for Internal table i_bukrs
DATA: wa_bukrs TYPE ty_bukrs.
*Work Area for Internal table i_refmdma.
DATA: wa_refmdma TYPE ty_refmdma.
*Work Area for Internal table i_succ
DATA: wa_succ TYPE ty_succ.
*Work Area for Internal table i_error
DATA: wa_error TYPE ty_error.
*Work Area for Internal table i_selfields
DATA: wa_selfields TYPE sdibe_massfields.
*Work Area for Internal table i_mvke
DATA: wa_mvke TYPE ty_mvke.
*Work Area for Internal table i_ref_data
DATA: wa_ref_data TYPE ty_ref_data.
*Work Area for internal table I_t001w
DATA: wa_t001w TYPE ty_t001w.
*Work Area for internal table I_t001w
DATA: wa_twlad TYPE ty_twlad.
*Work Area for internal table I_t134
DATA: wa_t134 TYPE ty_t134.
WOrk Area for ADRC Table
DATA: wa_adrc TYPE ty_adrc.
WOrk Area for MARD Table
DATA: wa_mard TYPE ty_mard.
*Work Area for Internal table i_mvke
DATA: wa_dev00160 TYPE ty_dev00160.
*Work Area for Internal table i_mvke
DATA: wa_qmat TYPE ty_qmat.
SELECTION SCREEN *
SELECTION-SCREEN : BEGIN OF BLOCK b_001
WITH FRAME
TITLE text-001 . "Start of selection-screen
SELECT-OPTIONS: s_matnr FOR mara-matnr. "Material Number
PARAMETERS : p_ersda LIKE mara-ersda. "Creation Data
SELECT-OPTIONS: s_werks FOR marc-werks NO INTERVALS. "Plant
SELECTION-SCREEN : END OF BLOCK b_001 . "End of Selection-screen
*& Include ZDMMMR_MM_MULTI_F00 *
*& Form sub_validate_matnr
Subroutine for validating material number
FORM sub_validate_matnr .
SELECT matnr "Material Number
mtart "Material Type
ersda "Creation date
mbrsh "Industry Sector
FROM mara "Table for General Material Data
INTO TABLE i_matnr
WHERE matnr IN s_matnr.
*If no material is found an error message is given
IF sy-subrc <> 0.
MESSAGE e001.
ENDIF.
ENDFORM. " sub_validate_matnr
*& Form sub_validate_plant
Subroutine to validate Plant
FORM sub_validate_plant .
SELECT werks "Plant
bwkey "Valuation area
FROM t001w "Table for Plants/Branches
INTO TABLE i_plant
WHERE werks IN s_werks.
*If no plant is found an error message is given
IF sy-subrc NE 0.
MESSAGE e002.
ENDIF.
ENDFORM. " sub_validate_plant
*& Form sub_get_mara
*Determine all the materials that need to be extended to new plants,
*storage locations and MRP areas
FORM sub_get_mara .
IF NOT s_matnr[] IS INITIAL.
SORT i_matnr BY matnr.
IF p_ersda IS NOT INITIAL.
DELETE i_matnr WHERE ersda NE p_ersda.
ENDIF.
ELSE.
*If only Creation Date is given
SELECT matnr "Material No.
mtart "Material Type
ersda "Creation date
mbrsh "Industry Sector
FROM mara "Table for General Material Data
INTO TABLE i_matnr
WHERE ersda EQ p_ersda.
IF sy-subrc EQ 0.
SORT i_matnr BY matnr.
ELSE.
MESSAGE i000 WITH 'No data found for given Selection.'(002).
LEAVE LIST-PROCESSING.
ENDIF.
ENDIF.
Subroutine to get data from mvke.
PERFORM sub_get_mvke.
LOOP AT i_matnr INTO wa_matnr.
CLEAR wa_mvke.
READ TABLE i_mvke INTO wa_mvke WITH KEY matnr = wa_matnr-matnr
BINARY SEARCH.
IF sy-subrc EQ 0.
wa_matnr-vkorg = wa_mvke-vkorg.
wa_matnr-vtweg = wa_mvke-vtweg.
ENDIF.
IF wa_matnr-mtart = 'AD01'.
wa_matnr-mtartz = 'AD01'.
ELSE.
wa_matnr-mtartz = 'NAD01'.
ENDIF.
MODIFY i_matnr FROM wa_matnr TRANSPORTING vkorg vtweg mtartz.
ENDLOOP.
ENDFORM. " sub_get_mara
*& Form sub_get_werks
*Determine all the plants to which the Materials need to be extended
FORM sub_get_werks .
SELECT werks "Plant
bwkey "Valuation Area
FROM t001w "Check table for Plants/Branches
INTO TABLE i_plant.
IF sy-subrc EQ 0.
SORT i_plant BY werks.
ENDIF.
ENDFORM. " sub_get_werks
*& Form sub_get_marc
*Determine the status of the materials with respect to which plants
*they have already been extended to
FORM sub_get_marc .
CHECK i_matnr[] IS NOT INITIAL.
SELECT m~matnr "Material Number
m~werks "Plant
t~bwkey
INTO TABLE i_marc
FROM marc AS m "Table for Plant Data for Material
INNER JOIN t001w AS t
ON mwerks = twerks
FOR ALL ENTRIES IN i_matnr
WHERE matnr EQ i_matnr-matnr.
IF sy-subrc EQ 0.
*Append the plants that have been extended to
to the list of plants to which they have to be extended
only when no plants are given in the selection screen
IF s_werks IS INITIAL.
LOOP AT i_marc INTO wa_marc.
wa_plant-werks = wa_marc-werks.
wa_plant-bwkey = wa_marc-bwkey.
APPEND wa_plant TO i_plant.
CLEAR wa_plant.
ENDLOOP.
SORT i_plant BY werks bwkey.
DELETE ADJACENT DUPLICATES FROM i_plant
COMPARING werks bwkey.
ENDIF.
SORT i_marc BY matnr werks.
*Retrieve the Valutaion Area for the plants to which the material
*has already been extended.
SELECT werks "Plant
bwkey "Valuation area
INTO TABLE i_t001w
FROM t001w "Table for Plants/Branches
FOR ALL ENTRIES IN i_marc
WHERE werks = i_marc-werks.
*If selection succeed.
IF sy-subrc EQ 0.
Sort by Plant
SORT i_t001w BY werks.
ENDIF.
ENDIF.
*Copy the content of MARC into a temporary internal table
i_tmarc[] = i_marc[].
DELETE ADJACENT DUPLICATES FROM i_tmarc
COMPARING matnr.
*Retrieving Inspection type - material parameters (QMAT)
*data
SELECT matnr "Material Number
werks "Plant
art "Inspection Type
ppl "Inspection with Task List
spezueber "Inspect with Material Specification
conf "Inspection Specifications from
" Configuration
tls "Inspection Specifications from Batch
" Determination
app "Automatic Specification Assignment
mer "nspect by Characteristics
insmk "Post to Inspection Stock
ave "Automatic Usage Decision Planned
stichprver "Sampling Procedure
dynregel "Dynamic Modification Rule
sproz "Inspection Percentage
hpz "100% Inspection
dyn "Skips Allowed
mpb "Enter the Sample Manually
mst "Trigger Sample Calculation Manually
ein "Serial Number Management Possible
mpdau "Average Inspection Duration
chg "Control of Inspection Lot Creation (Lot
"Summary)
qkzverf "Procedure for Calculating Quality Score
qpmat "Allowed Share of Scrap (Percent) in
"Inspection Lot
kzprfkost "Record Appraisal Costs in Individual QM
"Order
aufnr_co "Order Number for Recording Appraisal
"Costs
aktiv "Inspection Type - Material Combination is
"Active
apa "Preferred Inspection Type
afr "Inspection for Handling Unit
mma "Field Not Used as of 3.0 Field
"Reserved for SAP
feh "Field Not Used as of 3.0 Field
"Reserved for SAP
prfrq "Field Not Used as of 3.0 Field
"Reserved for SAP
nkmpr "Field Not Used as of 3.0 Field
"Reserved for SAP
INTO TABLE i_qmat
FROM qmat "Table of "Inspection type - material
"parameters"
FOR ALL ENTRIES IN i_tmarc
WHERE matnr = i_tmarc-matnr "Material no. of temporary internal
"table
AND werks = i_tmarc-werks. "Plant of temporary internal table
*If selection succeed
IF sy-subrc EQ 0.
SORT i_qmat BY matnr.
ENDIF.
ENDFORM. " sub_get_marc
*& Form sub_get_mard
Determine the storage locations for the Plants i_plant.
FORM sub_get_mard .
CHECK i_marc[] IS NOT INITIAL.
SELECT matnr "Material Number
werks "Plant
lgort "Storage Location
FROM mard "Table for Storage Location Data for Material
INTO TABLE i_mard
FOR ALL ENTRIES IN i_marc
WHERE matnr EQ i_marc-matnr
AND werks EQ i_marc-werks.
*If selection succeed
IF sy-subrc EQ 0.
*Sort internal table by Material no , Plant and Storage Location
SORT i_mard BY matnr werks lgort .
ENDIF.
ENDFORM. " sub_get_mard
*& Form sub_get_t001l
Determine the storage locations for the Plants i_plant.
FORM sub_get_t001l .
CHECK i_plant[] IS NOT INITIAL.
SELECT werks "Plant
lgort "Storage Location
FROM t001l "Check table for Storage Location
INTO TABLE i_sloc
FOR ALL ENTRIES IN i_plant
WHERE werks EQ i_plant-werks.
*If selection succeed
IF sy-subrc EQ 0.
*Sort by Plant and Storage Location
SORT i_sloc BY werks lgort.
For all the storage location get the Storage Location Address
*Number
SELECT werks "Plant
lgort "Storage Location
adrnr "Address Number
FROM twlad "Table of 'Determination of Address from Plant and
"Storage Location'
INTO TABLE i_twlad
FOR ALL ENTRIES IN i_sloc
WHERE werks = i_sloc-werks
AND lgort = i_sloc-lgort.
*If selection succeed
IF sy-subrc EQ 0.
*Sort by Plant, Storage Location and Address number
SORT i_twlad BY werks lgort adrnr.
For all address numbers retrieved get the search term
SELECT addrnumber "Address number
sort2 "Search Term 2
INTO TABLE i_adrc
FROM adrc "Table of 'Addresses (Business Address
"Services)'
FOR ALL ENTRIES IN i_twlad
WHERE addrnumber = i_twlad-adrnr.
IF sy-subrc EQ 0.
SORT i_adrc BY adrnr.
ENDIF.
ENDIF.
ENDIF.
ENDFORM. " sub_get_t001l
*& Form sub_get_mdlv
Determine the MRP Areas to which the materials need to be extended.
FORM sub_get_mdlv .
CHECK i_sloc[] IS NOT INITIAL.
SELECT berid "MRP Area
werzg "Plant
ortzg "Receiving Storage Location
FROM mdlv "Table for Customizing MRP Area
INTO TABLE i_mdlv
FOR ALL ENTRIES IN i_sloc
WHERE werzg EQ i_sloc-werks
AND ortzg EQ i_sloc-lgort.
*If selection succeed.
IF sy-subrc EQ 0.
*Sort by Plant and Storage Location
SORT i_mard BY werks lgort.
ENDIF.
ENDFORM. " sub_get_mdlv
*& Form sub_get_zdmmm_mrp_area
Determine required fields w.r.t Plant and MRP Area from customized
*table
FORM sub_get_zdmmm_mrp_area .
CHECK i_mdlv[] IS NOT INITIAL.
*Retrieving MRP data from Customized table
SELECT zmtart "Material Type
zwerks "Plant
zberid "MRP Area
zdismm "MRP Type
zeisbe "Safety Stock
zdisls "Lot Size
zdispo "Mrp Controller
zfxhor "Planned Delivery Time (In Days)
FROM zdmmm_mrp_area "Customized table for MRP Area wrt
"plant and mat type.
INTO TABLE i_refmdma
FOR ALL ENTRIES IN i_mdlv
WHERE zberid = i_mdlv-berid
AND zwerks = i_mdlv-werzg.
*If selection succeed
IF sy-subrc <> 0.
*Sort by MRP Area and Plant
SORT i_refmdma BY zberid zwerks.
ENDIF.
ENDFORM. " sub_get_zdmmm_mrp_area
*& Form sub_mat_extn
For extending Material to Plant, all possible Storage Location and
corresponding MRP Area .
FORM sub_mat_extn .
*Local variable declaration
DATA: l_index TYPE sytabix. "For storing sy-tabix
DATA: l_counter TYPE i VALUE 0. "For formatting Error log.
DATA: l_sloc_extend TYPE c. "Flag for Extending the material
DATA: wa_dpop LIKE dpop. "For sending as a exporting
"parameter
DATA: wa_mdma LIKE mdma. "For sending as a exporting
"parameter
DATA: l_stat TYPE c. "For checking the Storage Location
"is Seviceable or not.
DATA: wa_bapireturn1 TYPE bapiret1. "Return Work area of
"'MD_MRP_LEVEL_CREATE_DATA'
*No material is selected.
CHECK i_matnr[] IS NOT INITIAL.
SORT i_plant BY werks.
SORT i_marc BY matnr werks.
SORT i_mard BY matnr werks lgort.
*For extending the material to Plant Storage Location and possible MRP
*Area
LOOP AT i_matnr INTO wa_matnr.
CLEAR wa_marc.
Checking whether Reference Material Exists or not
READ TABLE i_marc INTO wa_marc WITH KEY matnr = wa_matnr-matnr
BINARY SEARCH.
If no reference material exists..populate data for error log.
IF sy-subrc NE 0.
CLEAR wa_error.
PERFORM material_convert USING wa_matnr-matnr
CHANGING wa_error-mat.
wa_error-comm = 'Reference material is not maintained'(003).
APPEND wa_error TO i_error.
CLEAR wa_error.
CONTINUE.
ENDIF.
For retrieving the reference data
PERFORM sub_retrieve_refdata.
LOOP AT i_plant INTO wa_plant.
READ TABLE i_marc INTO wa_marc WITH KEY matnr = wa_matnr-matnr
werks = wa_plant-werks
BINARY SEARCH.
IF sy-subrc EQ 0.
-
Create outbound delivery thru Idoc
I am working on a sales return scenario in SAP as below :--
01. Creating Return sales Order in SAP thru inbound Idoc ( ORDERS01)
02. Triggering outbound Idoc ( ORDRSP/ORDERS05) from return sales order to our return plant.
03. Customer will send returned goods to our return plant. Plant will send us an Idoc to create delivery in SAP.
04. Once delivery is created thru Idoc , our batch job will do PGR.
05. Billing batch job will generate credit memo for return.
I am looking for advise on following points :--
01. Can we create outbound delivery thru DESADV Idoc ?We are also planning to update delivery Item text thru this Idoc.
02. SAP standard provides ( SHP_OBDLV_CREATE_SLS) this Idoc to create delivery with reference to Sales Order but not able to update delivery text thru this ?
03.Any other way-out to create delivery and update delivery text thru inbound Idoc?
Thanks in advance!!
Best Regards/RajeshCreate your own and assign as processing the BAPI or a wrapper for it.
Enjoy -
Cutom T-Code for seding customer details thru IDoc Debmas
Hi Experts,
I have a requirment where in.. I need to send customer details thru IDoc from a custom screen which has cutomer text box and a submit button. After entering cutomer and clicking on submit debmas06 Idoc has to be triggered.
I am not an ABAP expert... please help me with process on devloping the above reqirment.
This is a critical requirment please help ASAP.
Thanks,
SumaHi,
u have to use standalone program..iam giving one sample code..aong with u have define the RFC (SM59,WE21(Create port),WE20(create partner profile,BD64 distribute model view)...u have to do..
when u press on submit button,,,
*& Report ZZ_Program_To_Create_Idoc
report zz_program_to_create_idoc .
tables: ekko,ekpo.
selection-screen skip 3.
selection-screen begin of block b1 with frame title titl.
selection-screen skip.
select-options s_ebeln for ekko-ebeln.
selection-screen skip.
selection-screen end of block b1.
data: header_segment_name like edidd-segnam value 'Z1EKKO',
item_segment_name like edidd-segnam value 'Z1EKPO',
idoc_name like edidc-idoctp value 'Z19838IDOC1'.
data: header_segment_data like z1ekko,
item_segment_data like z1ekpo.
data: control_record like edidc.
data: messagetyp like edmsg-msgtyp value 'ZZ9838MESG1'.
data: i_communication like edidc occurs 0 with header line,
i_data like edidd occurs 0 with header line.
data: begin of i_ekko occurs 0,
ebeln like ekko-ebeln,
aedat like ekko-aedat,
bukrs like ekko-bukrs,
bsart like ekko-bsart,
lifnr like ekko-lifnr,
end of i_ekko.
data: begin of i_ekpo occurs 0,
ebelp like ekpo-ebelp,
matnr like ekpo-matnr,
menge like ekpo-menge,
meins like ekpo-meins,
netpr like ekpo-netpr,
end of i_ekpo.
start-of-selection.
select ebeln aedat bukrs bsart lifnr from ekko
into table i_ekko where ebeln in s_ebeln.
select ebelp
matnr
menge
meins
netpr
from ekpo
into table i_ekpo
where ebeln in s_ebeln.
control_record-mestyp = messagetyp.
control_record-rcvprt = 'LS'.
control_record-idoctp = idoc_name.
control_record-rcvprn = '0MART800'.
loop at i_ekko.
header_segment_data-ebeln = i_ekko-ebeln.
header_segment_data-aedat = i_ekko-aedat.
header_segment_data-bukrs = i_ekko-bukrs.
header_segment_data-bsart = i_ekko-bsart.
header_segment_data-lifnr = i_ekko-lifnr.
i_data-segnam = header_segment_name.
i_data-sdata = header_segment_data.
append i_data.
select ebelp
matnr
menge
meins
netpr
from ekpo
into table i_ekpo
where ebeln = i_ekko-ebeln.
loop at i_ekpo.
item_segment_data-ebelp = i_ekpo-ebelp.
item_segment_data-matnr = i_ekpo-matnr.
item_segment_data-menge = i_ekpo-menge.
item_segment_data-meins = i_ekpo-meins.
item_segment_data-netpr = i_ekpo-netpr.
i_data-segnam = item_segment_name.
i_data-sdata = item_segment_data.
append i_data.
endloop.
clear i_ekpo.
refresh i_ekpo.
endloop.
call function 'MASTER_IDOC_DISTRIBUTE'
exporting
master_idoc_control = control_record
OBJ_TYPE = ''
CHNUM = ''
tables
communication_idoc_control = i_communication
master_idoc_data = i_data
exceptions
error_in_idoc_control = 1
error_writing_idoc_status = 2
error_in_idoc_data = 3
sending_logical_system_unknown = 4
others = 5
if sy-subrc <> 0.
message id sy-msgid type sy-msgty number sy-msgno
with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
else.
loop at i_communication.
write: 'IDOC GENERATED', i_communication-docnum.
endloop.
commit work.
endif.
initialization.
titl = 'ENTER THE PURCHASE ORDER NUMBER'.
Regards,
Nagaraj -
Hi friends,
I have a requirement that, i want to filter one of our plant in IDoc leve, we are using MATMAS as message type.
Currently, we are sending the 888s in 4 plants namely 1221, 1224, 1226 and 1220. Since we are using 1 Material Master for both 1001 and 1090, we no longer need to send the 888 to 1224. Can you please check if we can do the filtering at the iDoc level.
Anyone pls give the clue.
MohanaHi,
Goto bd59 and check whether that plant field present in your message type. Go to BD64 tcode .Select your model view, you will get the no filter set.Double click on it and a pop up appears,in that select the create filter group button and give a name.
Then a list of fields occur,edit the value for plant and enter.
regards,
Manesh.R -
How to extend an existing IDOC!
tell me the steps to extend the existing IDOC !
Thanks1>we31(create new segments with fields u want to populate)
2>we30(create an extension idoc type).in we30 u will get to radio buttons.1>basic type 2>extension.click on the extension and then copy the basic type.Now will get all the segmnts .Now add the new segments under the parent segement which needs to be extended.
3>attach the extended idoc type to basic type and message type to tcode WE82.
4>Now u have to search for an exit where u have to write ur code in order to populate the fields which u have extended.Basically u will write in the Function module.Make sure u r writing in the correct exit.Evry messagetype will have a function module.
5>create a project in cmod and activate the function exit.
IDOC EXTENSIONS
Letâs first look at the concept of IDOC extension. SAP delivers Basic IDOC types such as DEBMAS02, MATMAS02, ORDERS02, and WMMBID01. By extending the Basic IDOC type, you are actually creating a new IDOC type. You create a new segment with the additional fields. This new segment has to be associated with one of the existing Basic IDOC segments. Then you create a new extension type, which is associated with the Basic IDOC type. This results in a new IDOC type. In order for ALE function modules to relate to this new IDOC type, the IDOC type is linked to the corresponding message type. Note that you should not add fields to existing segments but should create a new segment and associate it with an existing segment. This, in a nutshell, is the process of creating IDOC extensions.
In our example, the Basic IDOC type DEBMAS02 is used to communicate Customer Master data to the SAP Customer Master application. Even though the application has a screen to enter and store a contact personâs business address (see Figure 1), DEBMAS02 does not have a segment or fields that communicate the contact personâs business address. If your business requires that this business address be communicated to the other system through the ALE interface for Customer Master, then you have to extend the DEBMAS02 IDOC type, and enhance the corresponding ALE function module.
In DEBMAS02 the contact person fields are present in segment E1KNVKM and the business address of the contact person is stored on the SADR SAP table. You need to create a new segment, Z1SADRX, that is associated with E1KNVKM. This will be done in the process of creating an extension type ZDEBMASX. This extension type will then be associated with a new IDOC type, ZDEBMASZ. IDOC type ZDEBMASZ will be linked to message type DEBMAS for Customer Master. The final step in the IDOC extension process is to check the new objects. This check also verifies the structural integrity of the IDOC type. Letâs look at each of these steps in more detail.
1. Create an Extension Type and a New Segment.
First, letâs determine the fields on table SADR that you are going to provide for in the new segment Z1SADRX. You need fields for name, street, city, region, and country to give the business address of the contact person. You also need fields for the address number. ADRNR is a field in SAP tables such as SADR that uniquely identifies the address of an entity. This field is cross-referenced from other tables to the SADR table to obtain the full description of the address. Because this is an IDOC type for master data, the first field of the new segment will be MSGFN. The message function field informs the receiving system of the action to be taken for that particular segment. In the code that you write for populating the new segment, the value of the message function is the same as that of the parent segment E1KNVKM. In all, you will have 12 fields in segment Z1SADRX (see Table 1).
To create an extension type and new segment:
Use transaction WE30 or from WEDI go to Development -> IDOC types.
Enter ZDEBMASX for Object Name.
Choose Extension Type.
Click on Create.
You will see a pop-up screen. Choose Create New, and enter a description. For version 4.x, enter DEBMAS02 in the Linked Basic Type field. Enter.
You will see a screen with ZDEBMASX and its description in the first line. Click on this line, and press Create. For version 4.x, expand the tree of segments, and place the cursor on E1KNVKM.
You will see a pop-up screen. Enter E1KNVKM as the reference segment. Enter.
For 4.x, press Create after placing the cursor on segment E1KNVKM.
You will see a line appear with E1KNVKM hierarchically below ZDEBMASX, with a description "Customer Master contact person (KNVK)."
Click on this line and press Create. You will receive a message indicating that the new segment being created will be a child segment of E1KNVKM. Enter. A pop-up box appears for the new segment.
Enter Z1SADRX as the segment type, 1 for Minimum, 1 for Maximum. Leave Mandatory segment unchecked. These entries imply that there is only one Z1SADRX segment for every occurrence of the E1KNVKM segment, and also that this segment is not mandatory. Note that if the parent segment is not mandatory, then the child segment should not be mandatory, because this could result in a syntax error during the creation or processing of the IDOC.
For 4.x, you must first create the IDOC segment Z1SADRX (Iâll explain why in a moment) from the menu path WEDI -> IDOC -> Development -> IDOC Segment.
Click on Segment Editor.
On the next screen, click on Create.
Enter a development class for the object. Enter.
This will take you to the screen for segment definition. Enter a description for the segment. Enter the field name, data element, and the data element documentation name. In most cases, all three fields may have the same values. If you are using a field in the segment that is not present in the ABAP/4 data dictionary, you must first create the domain, data element, field, and appropriate documentation before using it in the new segment.
Enter these three columns for all 12 fields. Save.
Click on Generate/Activate, F3 to step back.
From screen Maintain Segment, go to Segment Type -> Release. A checkbox now appears beside the segment definition Z1SADRX (see Figure 2). Check this box. Save.
Save again to store the descriptions of the segment, F3 to step back.
Save the extension type.
It is possible to have several new segments with relevant Basic IDOC type parent segments in a single extension type. However, you can form only one IDOC type based on a single extension type.
2. Create an IDOC Type.
The next step is to create an IDOC type by associating the extension type that you created with the Basic IDOC type. This is a simple process:
From transaction WE30 or WEDI go to Development -> IDOC Types.
Enter ZDEBMASZ for Object Name.
Click on IDOC Type.
Click on Create.
Enter DEBMAS02 for Basic IDOC type.
Enter ZDEBMASX for extension type.
Enter a description.
Enter.
You will see a display of the composite IDOC type with all segments, including Z1SADRX (see Figure 3).
It is possible to associate only one extension type with a Basic IDOC type for a given IDOC type. However, you can have multiple new segments in an extension type.
3. Link IDOC Type to Message Type.
The next step is to link the new IDOC type to its corresponding message type. This is important, because this relationship is referenced in the partner profile parameters where you specify the message type and IDOC type to be used for that particular representative system. To link the message type:
Use transaction WE82, or from WE30, go to Environment -> IDOC Type / Message Type, or from WEDI go to Development -> IDOC Type -> Environment Î IDOC Type / Message Type.
Click on Display <-> Change.
Click on New Entries.
Enter DEBMAS for message type.
Enter DEBMAS02 for Basic IDOC type.
Enter ZDEBMASX for extension type.
Enter your SAP R/3 release number for Release.
Save.
This data is stored on the EDIMSG table and is accessed by several ALE processes to relate the message type to the IDOC type.
4. Check the IDOC Type.
Before checking the IDOC type for consistency, it is important to perform another step that releases the extension type to the IDOC type:
From WEDI go to Development -> IDOC Types -> Extras -> Release Type, or from transaction WE30 go to Extras -> Release Type.
For the Object Name ZDEBMASX and radio button Extension Type, click Yes.
The extension type has now been "released."
You canât edit the extension type once itâs released. To cancel the release for further editing or deactivation, go to WE30 Î Extras Î Cancel release. The final step in the IDOC extension process is checking the validity of the IDOC type:
From transaction WE30 or WEDI go to Development -> IDOC types.
Enter ZDEBMASX for Object name.
Click on Extension Type.
From the Development Object menu select Check.
Repeat the operation for IDOC type ZDEBMASZ.
A check log will be generated for each run with details of correctness or errors (see Figure 4).
In some situations it is possible to receive errors during the check process, especially segment length errors. The incorrect IDOC segment can be repaired and corrected by executing program RSEREPSG. This program checks the formal consistency and repairs incorrect segments. In test mode it will generate a log of formal correctness for the specified segment only. For the program to repair segments in normal mode, the underlying IDOC structures (DDIC structures) must be active. This program rectifies the lengths of the DDIC structures and not the fields themselves. RSEREPSG can also be used to change the person responsible for the object and the release flag.
Menu paths may vary slightly depending on the release/version of SAP R/3, but the procedures and the principles are the same.
ALE FUNCTION MODULE ENHANCEMENTS
Having extended the IDOC type to contain additional fields for an inbound or outbound application, you now want to enhance ALE function modules for populating the additional segment on the outbound or applying the additional segment data on the inbound application. It may be necessary to enhance an ALE function module even in situations where an IDOC extension has not been performed if the IDOC data being passed to and from the application requires modifications. The following approach applies to both situations.
The core working code for ALE processes for a given application area is always encapsulated in ABAP/4 function modules. These function modules are associated with such control information as message types and process codes. So the ALE process checks this control information and derives the name of the function module to invoke for that particular IDOC processing from certain database tables. These function modules contain objects known as customer functions, which can be considered SAP Enhanced user exits. A function module is called at a particular point during the processing of the main program or function module, and it can be used to influence data processing at that point by adding code to the customer function. The customer function behaves like a normal function module and has import and export parameters, tables (internal tables) statement, and exception processing. Unlike a conventional user exit, customer functions give you the ability to modify only data available to you by the function moduleâs parameters and internal tables. While most ALE/EDI function modules are supported by customer functions, there are ALE/EDI processes that still use conventional user exits. There are a few ways to determine which function module to enhance for a given message type/process code:
For master data distribution, from SALE go to Extensions -> Master data distribution -> Setup additional data for message types. Search for message type DEBMAS in this example. You see an entry for DEBMAS associated with function module MASTERIDOC_CREATE_SMD_DEBMAS. This data is stored on table TBDME. The function module names for all master data message types follow this pattern: MASTERIDOC_CREATE_SMD_messagetype. This function module calls another function module of name MASTERIDOC_CREATE_DEBMAS or MASTERIDOC_CREATE_messagetype. Search for the words customer function, and you find several hits that can be used to add code to the function module.
From WEDI got to Control -> Inbound process codes -> Inbound with ALE service -> Processing by function module (transaction WE42), or from WEDI go to Control -> Outbound process codes -> Outbound with ALE service -> With function module (transaction WE41). There will be function modules associated with the process codes. For inbound, the function modules usually follow this pattern: IDOC_INPUT_messagetype: for example, IDOC_INPUT_CHRMAS for inbound characteristics master.
Use transaction WE57 or from WEDI go to Development -> Message/Application Object. The entries list the function module, Business Object, message type, and IDOC type that are used for inbound ALE/EDI interfaces.
Customer functions are not specific only to ALE and EDI but also to all programs/modules in SAP R/3. Customer function is a SAP enhancement component; the other two types are menu and screen enhancements.
All customer function exits are maintained in SAP enhancements and are found by using transaction SMOD. After executing transaction SMOD, pull down (F4) on the enhancement name field, and execute again. This provides you with a list of all SAP enhancements available. SAP enhancements are grouped by development class pertaining to an application area. Choose Application development R/3 SD master data distribution for development class VSV to lead to a screen that lists VSV00001 as an enhancement (see Figure 5). Press Component +/- to display its function exit components. There are four possible components listed, all of which are function exits (and are function modules) that are called from the ALE function modules in the form Call Customer Function Î001â. This is a special occurrence of the ABAP statement Call. Go to item Exit_SAPLVV01_ 001, which you need to enhance for the Customer Master outbound example of an IDOC extension. In the ALE-function module MASTERIDOC_CREATE_DEBMAS, the statement CALL Customer Function 001 is translated in the background to call component EXIT_SAPLVV01_001. Although this function exit can be edited using transaction SE37, you will use a simpler approach.
When you use SAP enhancements and their components, you manage them with an SAP object known as a project, which is like an envelope containing the selected enhancements and their components. A project can be used to control the execution of components and to transport them to other clients and instances in SAP. Basically, the process involves creating a project, including enhancements and components that are to be enhanced, editing the components, and then activating the project. The following process creates a project for our example Customer Master IDOC extension:
Execute transaction CMOD.
Enter name of project, say CSTMAST1.
Click on Create.
Enter a description of the project.
Save.
Click on SAP Enhancements.
Enter VSV00001 for Enhancement.
Save.
Once youâve created the project, edit the function exit components and activate the project. Remember that the code in the function exit enhancement will execute only if the project is activated. In fact, this is a convenient SAP enhancements feature, whereby the work in progress (developing code in the customer function) will not affect users of that application. When the code is completed, the project can be activated so the enhanced functionality takes effect. It can also be deactivated for maintenance.
As mentioned earlier, customer functions (function exits) are embedded in ALE function modules and can be used to influence the creation and modification of IDOC data on an outbound application or to post additional or modified IDOC data to an inbound R/3 application. Function exits are similar to regular function modules, with import/export parameters, tables (internal tables), and exceptions.
The two important factors to consider while developing the customer function are:
1. The point in the ALE function module where the function exit occurs
2. The data made available by the customer function that can be modified or posted to the R/3 application, based on the direction.
Because some function modules have several customer functions, it is critical to choose the function exit best suited for that particular enhancement. Do not attempt to perform activities that the function exit is not designed for. The importance of this point is illustrated by the following description of enhancing function modules for outbound and inbound ALE interfaces.
Outbound interfaces. In an outbound ALE interface you use function exits (customer functions) to populate additional segments created by an IDOC extension or to modify the existing IDOC data segments as per business requirements. Previously, you identified that enhancement VSV00001 has a component EXIT_SAPLVV01_001 (function exit), which can be used for populating the additional data segment Z1SADRX that you created in the IDOC extension ZDEBMASX (IDOC type ZDEBMASZ, based on Basic IDOC type DEBMAS02). You also learned that the ALE function module that calls this function exit is MASTERIDOC_CREATE_DEBMAS, which has a statement Call Customer Function 001.
Browse the function module MASTERIDOC_CREATE_DEBMAS using transaction SE37. You will find that this customer function is invoked for every segment of IDOC type DEBMAS02. In fact, the function exit is called soon after the creation of an existing segment has been populated with data and appended to the IDOC data table (internal table). Also, the function exit is exporting the message type, IDOC type, and the segment name and is importing the IDOC extension type. It is also passing the IDOC data internal table. This indicates that the ALE function module is allowing you to populate additional segments for every existing segment and modify the existing segmentâs data.
Letâs write ABAP/4 code to accomplish the task of populating IDOC segment Z1SADRX with a contact personâs business address:
From SE37, display function module MASTERIDOC_CREATE_ DEBMAS.
Find Customer Function 001.
Double-click on 001.
The function EXIT_SAPLVV01_001 will be displayed.
Double-click on INCLUDE ZXVSVU01.
You will be asked to create a new include object. Proceed as desired.
Enter code (as in Listing 1).
Be sure to perform a main program check (Function Module -> Check -> main program) and extended program check (Function module -> Check -> Extended check).
Now that you have extended the IDOC and enhanced the ALE function module based on the requirements for the contact personâs business address on the Customer Master, letâs test the interface. You should create a logical system and define a port for this interface. You should also configure the Customer Distribution Model to indicate that message type DEBMAS is being distributed to this logical system. The only difference in configuration between a regular outbound ALE interface and an enhanced one is the partner profile definition. While maintaining the outbound parameters of the partner profile, make sure the IDOC type is ZDEBMASZ. The fields for Basic IDOC type and extension type are automatically populated with DEBMAS02 and ZDEBMASX, respectively.
To maintain the contact personâs business address of a customer:
Use transaction BD12 or from BALE go to Master Data ->Customer -> Send and send that Customer Master record by executing the transaction after filling in the relevant fields such as customer number, message type, and logical system.
Use transaction WE02 or WE05 to verify the IDOC created. You should see the new segment Z1SADRX populated with the correct data.
With SAP releases below 4.5B, you cannot capture changes to business address through change pointers because a change document object is not available for capturing business address changes, and also earlier releases have not been configured to write change documents for a contact personâs business address. If you would like this functionality, you can either create change document objects, generate function modules to create change documents, and perform ALE configuration to tie it in, or make a cosmetic change to the contact person screen data while changing the contact personâs business address so that it gets captured as a change to the Customer Master. Subsequently, the ALE enhancement that you performed captures the contact personâs business address.
Inbound interfaces. The process for enhancing inbound ALE interfaces is similar for outbound, with a few exceptions; specifically in the coding of customer functions (function exits) for the ALE/EDI function modules.
The first step is to create an IDOC extension for the specific Basic IDOC type by adding new segments at the appropriate hierarchy level: that is, associated to the relevant existing segment. Populate the data fields on the new segments with application data by the translator or external system/program before importing them into the R/3 System. Then, find the ALE function module that is invoked by the inbound processing. By browsing through the code or reading the documentation on the function exit enhancements using the SMOD transaction, identify the function exit in which you should place your code. The technique used in the code to post the additional or modified IDOC data to the application can vary based on the application rules and requirements, the data available at that point in processing, and the application function modules available to update the application tables. It is important to search first for application modules that process the data and see if they can be called within the function exit. If the additional data in the extended segments in specific to a custom table or resides in nonkey fields of a single or small set of tables, you may be able to update it directly by SQL statements in the function exit. This approach should be carefully evaluated and is certainly not highly recommended.
Another option is to use Call Transaction from within the function exit to process the additional data. For example, in the case of message type WMMBXY for inbound goods movements from a warehouse management system, the standard interface creates batches for materials, but does not update its characteristics. In such a case, you can use Call Transaction MSC1 to create the batch and assign characteristic values to it from within the function exit provided.
Error handling is a very important consideration when making enhancements to inbound ALE/EDI objects. In ALE and EDI inbound processing, workflow is used for handling errors at different levels such as technical and application. If workflow has been configured for the interface, the error messages and workflow items flow to the inbox of the named recipient(s).
It is also critical to enhance the workflow that handles notifications of the inbound ALE/EDI process. In most scenarios this is not a very difficult task because SAP lets you influence the workflow parameters and messages in function exits (customer functions). You typically do this using flags and message codes to trigger certain workflow actions. If you conform to the status codes and flags stipulated for workflow processing, the enhancement could be error-free and seamless. In the case of an inbound IDOC with an extension, you should populate the EDIDC fields IDOCTYP (new IDOC type) and CIMTYP (extension type) accordingly.
IDOC REDUCTIONS
When distributing or communicating master data to other systems, the volumes of data transmitted over communication lines may be large, resulting in performance problems and/or excessive usage of resources such as disk space and bandwidth. Careful scrutiny of the master data Basic IDOC type may reveal that many of the segments are redundant or are simply not being used. If this is true, then the basic IDOC type is a candidate for a technique known as IDOC reduction. The R/3 System provides the ability to eliminate unused segments and irrelevant segment fields from the Basic IDOC type. This procedure is relatively simple and easy to implement. IDOC reduction is available for only a few message types such as DEBMAS, CREMAS, GLMAST, MATMAS, and certain POS messages.
When performing an IDOC reduction, a new message type is created based on an existing message type. The IDOC segments associated with that message type are proposed for editing. Mandatory segments of the IDOC type canât be excluded. By default optional segments are excluded, but you can choose to include an optional segment and only certain fields in the optional segment. If you have extended the Basic IDOC type and created a new IDOC type associated with a corresponding message type and you are creating a new message type (view) based on it for purposes of IDOC reduction, then the enhanced IDOC type is presented for editing along with the additional segments.
Letâs use the Vendor Master IDOC type CREMAS01 as an example to demonstrate IDOC reduction. Message type CREMAS is used for communicating Vendor Master data to other R/3 or external systems. If you browse the IDOC type CREMAS01 youâll see that it has 10 segments, with E1LFA1M being a mandatory segment (see Figure 6). To reduce this IDOC type:
Use transaction BD53 or from SALE go to Distribution scenarios -> Master data distribution -> Reduce IDOC type for master data.
Enter ZCREMS for View (message type).
Click on Create.
You will see a pop-up box. Enter CREMAS in the Derived From field. Enter.
Enter a description. Enter.
You will see a list display with segment E1LFA1M in green and a * symbol. The symbols used in IDOC reduction are: * for mandatory, 1 for selected, - for deselected, x for core selected, and the Î.â for core not selected. The corresponding elements are highlighted in green, white, red, violet, and gray, respectively.
Expand all trees. You will see nine other segments in red.
Place your cursor on the E1LFB1M segment for company code data and click on Select. It turns white with a 1 symbol.
Double-clicking on it will display a list of fields. You can select fields that you require (see Figure 7).
Note that if a child segment is selected, its parent is also selected automatically in order to maintain the hierarchical integrity.
After youâve selected the segments required and its fields, save.
From the main screen, click on Activate.
Activating the new message type ZCREMS will turn on the message type change pointer generation on a particular client. While creating a reduced IDOC type message is a client-independent activity, activation is client-dependent. An entry is created in table TBDA2 for a specific message type in a specific client and is activated. To delete this message type, you need to deactivate it from all clients on that instance. These message types are transportable.
Now that weâve created a new message type for a reduced IDOC type, letâs build the rest of the ALE configuration to work the interface with the following steps:
Define a logical system to represent the other R/3 or external system.
Configure the Customer Distribution Model to send message ZCREMS to this logical system.
Define a port, if needed, for this system.
Define a partner profile based on the logical system and maintain its outbound parameters. Make sure to use ZCREMS as the message type and CREMAS01 as the IDOC type.
Use transaction BD14 or execute program RBDSECRE or from BALE go to Master Data -> Vendors -> Send. Then, to specify a vendor or range of vendors and enter message type, go to ZCREMS and its target logical system.
Execute.
You can also capture changes to Vendor Master data and create IDOCs by executing transaction BD21 or program RBDMIDOC. Use transaction WE02 or WE05 to view the IDOCs created as a result of the preceding test. Notice the segments populated and the basic segments that are absent due to the reduction. You will find that the fields deselected from the segments have a value of /. This is equivalent to a null value. Eliminating segments may result in saving resources, while eliminating fields may not, unless the data is compressed. Also, if you look at the master data ALE function modules for these few message types, youâll see that a function module IDOC_REDUCTION_FIELD_REDUCE is called for every segment being populated. This in itself may be an overhead. It is important to weigh the pros and cons before implementing IDOC reduction. Of course, in certain cases, it may be a necessity for adjustment of data.
Enhancing ALE/EDI and IDOC extensions and conducting IDOC reductions is fairly simple. However, before proceeding with these tasks, you must carefully research the many options available in ALE and develop the best design for your business scenario.
IMPLEMENTING BAPI WITH ALE: A SAMPLE SCENARIO
Business application programming interfaces (BAPIs) provide an interface to Business Objects in the R/3 System. Business Objects are based on object-oriented technologies and represent an application objects, such as an address or a sales order. This next section prototypes an ALE interface that incorporates BAPI methods. When weâve finished, you should have a good idea of how easy it is to incorporate BAPIs with ALE and of how beneficial leveraging the 1000+ BAPIs available in the R/3 System can be when you want to interface with R/3 application objects.
Letâs start with a brief overview of SAP Business Objects and BAPIs.
SAP Business Objects. An SAP Business Object envelopes R/3 data and business processes while making the details of data structure and access methods transparent to a user interfacing with it. It consists of four layers: kernel, integrity layer, interface layer, and access layer. The kernel represents the R/3 data and its attributes. The integrity layer represents the business logic of the object and contains the business rules that govern the values of the kernel. The interface layer describes the interface mechanisms to external applications. BAPIs belong to the interface layer. The access layer represents communication methods, such as COM/DCOM, RFC, and CORBA.
SAP Business Objects and their details are stored in the Business Object Repository in the R/3 System.
BAPIs. BAPIs are "methods" of SAP Business Objects and represent their interface layer. BAPIs are essentially function modules in the R/3 System that are capable of invoking remote function calls (RFCs) for the purpose of communicating data through the function moduleâs import/export parameters and internal tables. BAPIs do not invoke screen dialogs. Like blackbox technology, BAPIs do not require the programmer or user to know the coding and implementation details of the interface to the Business Object. The user simply invokes the BAPI with its appropriate parameters and values in order to accomplish a task such as getting a list of materials from an external system or sending a list of contact person details to another system.
BAPIs can be executed synchronously or asynchronously while using the ALE communication layer for exchanging data. Typically, with asynchronous BAPI communications, an ALE IDOC is used to distribute the data. As we will learn in the following prototype, the ALE distribution model has to be configured in order to use the appropriate BAPI methods for the RFC destination that provides a gateway to the external system (R/3 or other). For this type of communication, an ALE IDOC interface must exist. If a particular BAPI (SAP-delivered or user-written) does not have an ALE IDOC interface, the interface can be generated using certain R/3 tools and procedures.
BAPIs are fast becoming the communication standard for exchanging data between business systems (including R/3). SAP Business Objects conform to Open Application Group (OAG) standards, and BAPIs support the COM/DCOM and CORBA guidelines. ALE and BAPIs is the strategic direction for all SAP interface technologies and will replace SAPâs traditional techniques in the future.
A BAPI/ALE PROTOTYPE ÷ CONTACT PERSON DETAILS
In the previous section, we learned how to enhance ALE functionality using the example of Customer Contact Person details. We extended the IDOC and enhanced a customer function with a few lines of ABAP code to achieve the additional functionality of distributing contact person details. While this was an exercise to learn IDOC extensions and customer-function enhancements, we can prototype a BAPI/ALE interface in this section that accomplishes the same purpose ÷ the distribution of contact person details. In release 4.5 of the R/3 System, message type ADR3MAS and IDOC type ADR3MAS01 have been provided to distribute contact person details with the aid of a BAPI method. The steps weâll walk through in a moment will illustrate the ease with which we can integrate BAPIs with ALE to get an interface up and running for many standard business scenarios or specialized cases that were not supported by ALE prior to the advent of BAPIs.
The ADR3MAS is considered to be a master data message type because it complements business master data, such as customer and vendor master. It is now supported by change document functionality, implying that change pointer mechanisms can be used to capture and then distribute changes occurring to contact person data using ALE IDOCs. The function module that accesses the R/3 data is a BAPI. In the R/3 System, contact person address is a business object. If we search the Business Object Repository (via transaction SWO1) with the keyword "address," for example, we will find business object BUS4003 under Cross-Application Components -> General Application Functions -> Address Management -> BUS4003: Address of a person in a company. This is the business object that pertains to our scenario, and a drill down on it reveals the details of the object, including its methods (see Figure 8). The method that would be of interest to us is "AddressContPart.SaveReplica." For your information, the corresponding BAPI function module is BAPI_ADDRCONTPART_ SAVEREPLICA in the function group SZAM.
Having gathered this information, Letâs build the outbound interface:
Create a logical system (via transaction SALE) to represent the receiver system.
Configure the distribution model. From transaction SALE, use option Maintain Distribution Model to create a model view for this scenario. Specify the sender system (the base logical system for the client you are working in, such as the logical system that has been assigned to that client) and the receiver system (the logical system). After positioning the cursor on the receiver system, click on Method and enter AddressContPart in the Object Name field on the panel that pops up. Also enter SaveReplica in the Method field on the pop-up panel. Enter and save the Distribution Model (see Figure 9).
From transaction WE20, create a partner profile based on the logical system for the interface. Use message type ADR3MAS and IDOC type ADR3MAS01, with an appropriate port.
Activate the change pointer for message type ADR3MAS. From SALE go to Set up Data Distribution -> Master Data Distribution -> Activate Change Pointers. Ensure that change pointer generation is active at the general level as well.
Now that weâve completed the configuration, letâs test the interface. The purpose of this test is only to create outbound IDOCs. Appropriate settings, such as port definitions and RFC destinations, can be made as required for purposes of communicating the IDOCs to the external system (or other R/3 system).
From the Customer Master or Vendor Master screens, create or make changes to contact person address. This should result in the creation of change pointers. (Check table BDCPS for change pointer entries with message type ADR3MAS.) After this, from transaction BALE go to Periodic Processing -> Process Change Pointers, enter ADR3MAS as the message type, and execute the transaction. This should result in a message indicating the number of master IDOCs created. Use transaction WE05 to display the IDOCs.
THE ALE AUDIT
In this section letâs take a look at the prototyping of the ALE Audit. ALE Audit is a powerful mechanism for verifying the success of ALE transactions/messages sent to another system. As you will see, implementing ALE Audit is not only easy but also very beneficial, because it facilitates the monitoring and tracking of transactions across systems while providing an entry point into error handling.
Program RBDSTATE is used for audit confirmation of ALE transactions between two R/3 systems; in other words, it indicates the success or failure of the ALE transaction on the target system. The program reports the status of the transaction on the target system back to the sending system. This process also serves as an interface itself from the target system to the sender system, facilitated by message type ALEAUD. In the following section, weâll look at the various steps needed to set up ALEAUD and execute program RBDSTATE.
SETTING UP ALEAUD and EXECUTING PROGRAM RDBSTATE
Letâs consider two different R/3 systems with base logical systems BK1CLNT010 (sender system) and BK2CLNT020 (target system). Assume that you are distributing characteristics master (message type CHRMAS) from BK1CLNT010 to BK2CLNT020. When you send CHRMAS02 IDOCs from BK1CLNT010, their status is 03 (data passed to port OK) if they were successfully externalized from the sender system. If the IDOCs were received and processed successfully on the target system, the status of those IDOCs on the target system is 53 (application data posted). Remember that you have to create a partner profile for BK1CLNT010 on the target system in order to receive the CHRMAS messages. The inbound parameters of BK1CLNT010 partner on the target system have CHRMAS as the message type and CHRM as the process code.
You now need to configure BK2CLNT020 to send ALEAUD messages to BK1CLNT010, the sender system. And you also need to configure BK1CLNT010 to receive those messages in order to update the status of CHRMAS IDOCs sent to the target system:
On the target system BK2CLNT020, configure the distribution of message flow of type ALEAUD to logical system BK1CLNT010.
Create filter object using object type MESTYP with a value of the message type for which you need audit confirmation. This message type must flow from the sender, BK1CLNT010 to BK2CLNT020. In this example, the value of the filter object type MESTYP is CHRMAS, message type for characteristics master. Save the distribution model. Use transaction BD64 to do this.
On target system BK2CLNT020, create an RFC destination with name BK1CLNT010. Choose the relevant connection type and enter the logon parameters and password for the R/3 system on which BK1CLNT010 resides. Use transaction SM59 to do this.
On target system BK2CLNT020, generate partner profile and port definition using transaction SALE, go to Communications -> Generate partner profile. Specify the customer model as described. Check the partner profile to ensure outbound parameter entries for message types ALEAUD and SYNCH.
On sender system BK1CLNT010, create a logical system for BK2CLNT020. Create a partner profile for logical system BK2CLNT020 with inbound parameters for message type ALEAUD, with process code AUD1.
Distribution of customer model on BK2CLNT020 to BK1CLNT010 is not necessary.
TESTING THE ALE CONFIRMATION PROCESS
Now you are ready to test the ALE audit confirmation process:
From the sender system, BK1CLNT010, send a couple of CHRMAS02 (characteristics master) IDOCs down to the target system, BK2CLNT020. Make sure that the status of the IDOCs is 03 (data passed to port).
Check the target system for receipt of these IDOCs. Make sure that they are in a status of 53 (application data posted).
Execute program RBDSTATE with appropriate parameters. Specify BK1CLNT010 for Confirm to System, CHRMAS for Message type, and date, if necessary.
Upon successful execution, informational messages will be issued indicating the IDOC number and status of the ALEAUD IDOC. (Note that a single ALEAUD audit IDOC can contain audit messages for multiple application IDOCs. This capability reduces the traffic of IDOCs between the two systems and keeps the overhead of audit confirmations at a minimum.)
Check the sender system for the receipt of the ALEAUD message. The status of the CHRMAS IDOCs that you sent to the target system must be changed to 41 (application document created in target system).
This completes the test of ALE audit confirmations (see Figure 10 and Figure 11 for IDOC display of target and sender system).
Audit confirmations can play a significant role in the reporting and monitoring of production systems. You can schedule program RBDSTATE periodically on target systems to report back to sender systems. Keep in mind that you need to maintain a sufficient time lag between the sending of application IDOCs to the target system and the execution of this audit program because the application documents need to be posted on the target system. This program can also be accessed from BALE using Periodic work -> Audit confirmation. -
Hi experts,
I'd like to send companies created by OX02 transaction thru IDOC technology.
Does someone know how to do that? I looked for a message type, however I didn't find anything regarding companies, closer thing was G/L Accounts.
Regards,
Andréuse change pointers ....it will then transfer only changed data or newly created ones
fot that you first have to activate the change pointers globally BD61 and then activate the change pointers for a specific message type and a specific field.BD50 ...so whenever ther is change to that field the data that has been changed will be recorded in BDCP table...
you can also schedule report RBDMIDOC with a particular message type as variant which will read all the changed records.
if there are multiplr changes during the day ....all of them would be recorded and would be sent together once RBDMIDOC runs...
Edited by: Tarang Shah on Mar 27, 2009 1:56 PM -
Java CAPS SAP IDoc OTD thru IDOC descriptive file needs any sap jars and dd
Hi All,
I am doing PoC in Java CAPS using SAP IDoc Descriptive file. As I know for creating SAP IDoc OTD thru it will need certail jar filr and ddls. But creating SAP IDoc ITD thru IDoc descriptive file also we need certain jar files and DLL.
Please let me know on this.
Thanks in advance.Yes, you will need all of the required SAP JCo jars and DLLs even though you are using the IDoc description file. This link might be useful to you - [Creating a SAP ALE OTDs Wizard|http://docs.sun.com/app/docs/doc/820-4380/dsgn_sap-ale-otd_t?a=view]
-
Tracking the changes in HRP tables for sending thru IDOC
Hi ALL,
We are planning to send iDoc to another SAP system with HR Data from different HRP tables. HRP1000,HRP1001,HRP1005,HRP1008,HRP1013,HRP1050 etc
If we change any PA infotypes they are linked to pernr and we can easily track the changes but if there is any change in HRP tables how do we track the changes and send them thru idoc.
Thanks
Bala DuvvuriKiran,
I am planning to use tocde PFAL for both inital loads and delta loads of HR data to other system .Can i get all the changes for HRP tables in PFAL without custom programming?
Let me explain with an example.
I changed the text for one of the org units and I can see the changes in HRP1000.but how will i send this data to another SAP system using PFAL ,how will i track those changes.
I heard that we can enable change pointers on each and every field in all the infotypes,so when i change the org unit text and it is one of the field in PA0001 of every employee a change pointer is triggered .is that true
Thanks
Bala Duvvuri
Edited by: Bala Duvvuri on May 16, 2010 8:33 AM -
Extend Material to Plant via IDOC
I was under the assumption that I can create a material with my idoc type : J3AMAT and then extend that material to any plant I want using the same idoc given that I provide the plant data. Is that correct or am I going crazy?
If you are creating the Material via the SAP GUI with MM01 and simply enter the Basic Data1, Basic Data 2 data, the Material will create. In the same SAP GUI session you then re-enter MM01 and attempt to create data for that new Material for tab "Sales: General/Plant Data". SAP GUI will allow you to select a Plant, and if you have no data created for that Plant it will say that "The material already exists and will be extended".
I wanted to replicate that same thing with the IDoc. So I created the Material with only the Basic Data 1, and Basic Data 2 data via LSMW IDoc Matmas05. Then using the same IDoc, I used the created Material Numbers and added the Plant Number I wished created to the Load File, along with all the data I had to add as a result of troubleshooting the missing data errors from repeated extension Idoc posting attempts. Once I had all the data required for the Plant data, the Material was extended to the desired Plant. I could go to MM03 and see it for that Material & Plant combo. The only problem was that it took more fields than I thought. That most likely has something to do with how the Material Master fields were configured I think.
I did not need to create the Material & Plant data first, and then extend the Material & Plant data to a new Plant. It was Material Master Basic Data to New Plant. -
URGENT - create FI invoice thru idoc IDOC_INPUT_INVOIC_FI
Hi all,
I got a problem while creating a FI invoice thru the IDOC IDOC_INPUT_INVOIC_FI .
In the created FI invoice i need to populate some fields in the profitability segment ( like customer number... ) .
My problem is I don't know where in the idoc i have to set the value .
Can somebody help me ?
Best regards.
Bertrand.Hi,
You can enter partner information in segment E1EDKA1
of IDoc type INVOIC02.
Not sure how much of this you already know, but I figured it doesn't hurt to include the following example:
Run transaction WE60, enter your IDoc type, and execute (F8). This will give you a list of all the segments and the segment fields. Expand the segment E1EDKA1 and then expand the sement fields. The first field is PARVW (you will see on the screen that there are various allowed values listed for this field, e.g. 'AG' = Sold-to party). The next field is PARTN in which you can enter the partner number (e.g. the Sold-to number).
You can use the Find function (after expanding all the branches) to look for any other type of fields you need to populate. Once you find the "business name" of a certain field within the segment documentation tree list, you will be able to see which IDoc segment the field belongs to. This is the place in the IDoc that you will set the value.
If INVOIC02 is not the IDoc type you are using, this same search technique will work for any IDoc type.
I hope this helps you out.
Best Regards,
James Gaddis -
How to extend plant to sales organization
What is the TCode?
Hi Satish,
request you to breif your query, in order to understand and provide exact solution.
What exactly are you asking for..?
to extend Material in to new Plant/ sales Org.
if so, T. Code: MM01
or
to assign plant in to new sales area?
if so, T. code: OVX6
Best Regards,
Amit
Note:
T. Code: OX18 - to assign Plant o Company Code -
Error while creating sales order thru IDoc
Hi,
While using FM IDOC_WRITE_AND_START_INBOUND, I am getting an error 'Customer not found with DUNS number from IDoc' and the application document is nor posted. I am passing valid customers in the ship to party and sold to party segments but still getting this error.
Please advice.
Regards,
RajeshHi All,
Can anybody give me some resolution for the above posted issue!
Thanks in advance.
Thanks,
Deep. -
Park vendor invoice thru' IDOC
Hello All,
The requirement is our vendor sends EDI invoices and they get parked in SAP as IDOCs. IDOC gets posted if GRN exist for a PO.
In purchase order it is GR based IV. If vendor parks invoice and there is no GRN for purchase order then IDOC fails and it goes in status 51 (Error).
Our requirement is, IDOC should get posted even if there is no GRN for a purchase order and client do not want to remove GR based IV tick from PO. After through verification of the parked invoice it gets posted in the system.
We have done the config change in MM>>LIV>>EDI>Enter program parameters, we have maintained value "1" for field "Processing". Inspite of this change system does not process inbound ICOCs and they go in error (51) status.
Please provide solution for this. This is possible to achieve by configuration. Not able to make out where is the problem.
Van you all please suggest a solution.
Thanks & regards.
Sanjayturn you process. instead of directly posting the idocs and wanting the failed ones go into the parked status, park all first and process then the parked invoices.
check OSS Note 501524 - EDI: Parking incoming invoices by default -
Production order confirm thru IDOC
Hello Guru,
we are having problem to our confirm Production order it has COGI error BA deficit on a same material with same batch.
our production order A, B, C, and D are process thru transaction code LM00. afterw that we check the process order thru WE02 and it already has status 64 thats why we do BD20 to Order A,B,C and D (all process in same time) to make it status 53. the problem seems occur after doing BD20 all of this order pick one batch 11111 for component material 123. this cause us 4 COGI error after BA deficit since batch 11111 had no enough stocks to make the requirement of material 123 for the order A, B, C and D.
How was this happen? and how could we fixed this?
Please provide helps
Thanks
RyanHi Rosalinda, i have the same problem. You found some solution ?
Thanks a lot !!!.
Federico Cicerchia
Maybe you are looking for
-
Problem with CS5.5 installation on Windows 7
Hello, I have problem to reinstall CS5_5 on windows Seven I download the source and uncompress on CS5.5\DesignStandard_CS5_5_LS4\Adobe CS5_5 I start the Setup.exe and, after enter serial number and start installation I have exit code 7 Exit Code: 7 -
-
Can I launch an application from keynote?
We have a proprietary application that we want to launch directly from our presentation - can't seem to do it from a hyperlink...any other ways to launch?
-
The problem occurs when i try to parse a double value expressed in scientific notaion. e.g. -3.902317E4. <xsl:variable name="temp"> <xsl:value-of select = "tempExpense" disable-output-escaping = "no" /></xsl:variable> <xsl:value-of select = "number($
-
DYNPRO_SEND_IN_BACKGROUND Dump due to Update Control Screen
Hi All, I have a smartform which is being attached to a SO while creating from Idoc. Due to this smartform processing in update task, it is giving a update control screen and it is giving dump DYNPRO_SEND_IN_BACKGROUND. My question: how to suppress t
-
The icon wont enable and when I go to open it via "open file" some technical sentences come up that make no sense to me. I don't know what is wrong. Never had this problem before. Can you help?