Changes in XML from Extended IDOC Basic type

Hi Experts,
We have an outbound PO IDOC (ORDERS05) that is converted to XML. If we are going to extend the IDOC, do we need to change anything in the XML as well? Or the new data will already be there in the XML?
Br,
LM

Hi Experts,
Any ideas on this one??
Thanks in advance,
LM

Similar Messages

How to change the default IDOC basic type from CREMAS05 to CREMAS04.

Hi All,
How to change the default IDOC basic type from CREMAS05 to CREMAS04 when sending Vendor Master Data.
When I generate partner profile, the system will add the latest version of IDOC type which is CREMAS05 to the Outbound message. In my project, I'm asked to use CREMAS04.
I want to use BD14 to send master data directly, but the program will generate IDOC using CREMAS05. Is there a way that I can change it to CREMAS04? And also for using Change Pointers, I want to use the report RBDMIDOC, but i have the same problem.
Thanks
Sai Krishna

execute WE20 and edit the outbound parameters
here is a pretty good example: http://documentation.softwareag.com/webmethods/sapr3_gateway/sap231/pages/sapdist.htm
Edited by: Jürgen L. on Sep 7, 2011 9:49 PM

Processing IDOC Basic type ORDERS05 in CRM...

I'm processing (via WE19) an IDOC (Basic type ORDERS05) to create a Sales order withing CRM. I'm getting there in that a sales order is being raised, although there is no item level details so far. I know that config of the system plays a big hand in what fields within the IDOC need to be populated but has anyone actually posted/raised a Sales order in this way and can you tell me what fields within the IDOC are mandatory. Or perhaps suggest how I might derive this.
Ideally I wanted to extract a sales order and produce an outbound IDOC and then compare the contents, but I can't (don't know how) do this.
Any help would be greatly appreciated.

Hi Garry,
Here is an order from WE19, which works
        E1EDK01
     ACTION: [QUAL] - suggesting 000 - no changes
        E1EDK14
     QUALF: [QUAL] - suggesting 008 - sales org
     ORGID: [ORGANIZATION] - anything you have defined /your side/
        E1EDK03
     IDDAT: [QUAL] - suggesting 002 - delivery date
     DATUM: [DATE] - any date
        E1EDKA1
     PARVW: [QUAL] - may use AG as 'sold to' here
     PARTN: [PARTNER#] - any partner defined
        E1EDKA1      - not necessary
     PARVW: [QUAL] - may have different 'sold to' and 'ship to' or 'bill to'
     PARTN: [PARTNER#]
        E1EDP01
     POSEX [ITEM#] - for example '1'
            MENEE [Unit of measure] - PCE for peaces
                 E1EDP02
               QUALF: [QUAL] - suggesting 001 - customer order
               BELNR: [document number] - document #. any
                 E1EDP20
                WMENG: [Scheduled quantity] - any - quantity
               EDATU: [Date] - any - when to deliver
                 E1EDP19
               QUALF: [QUAL] - for example 001 - used by customer, 004 - used by manufactured
               IDTNR: [material ID] - material ID
        E1EDS01
     SUMME: [Total value of sum segment] - check for the number of lines in PO1.
Hope this helps and do not forget to allot points.
Regards,
Martin

Unable to extend the basic type "SALESORDER_CREATEFROMDAT202"

HI
when iam trying to extend the IDOC basic type "SALESORDER_CREATEFROMDAT202" iam getting an error message "Action is not possiable for generated IDOC types"
To my understanding SALESORDER_CREATEFROMDAT202 is a bapi.So, I guess we can not extend these type of IDOC directly.
Can any one can help me how to copy the BAPI interface and extend it....
or any other solution for this......
can any one can help me reg this.....

I will answer my question!
This is the proble of version we are useing!
the extenction is possiable in sap 4.6 version.
but it is not possiable in ecc6.
So follow the steps i have done
created a new basic type "ZSALESORDER_CREATEFROMDAT202"
where icopy the basic type "SALESORDER_CREATEFROMDAT202" to it
Then i extened the IDOC "ZSALESORDER_CREATEFROMDAT202"
and added the new segments.
FInally while assiging the basic type to extended IDOC given basic type as "SALESORDER_CREATEFROMDAT202"
And assigned to the message type "SALESORDER_CREATEFROMDAT2" to it
then we can use this Structure with
Message type: SALESORDER_CREATEFROMDAT2
Basic type: SALESORDER_CREATEFROMDAT202
Extended:SALESORDER_CREATEFROMDAT202EX
for data picking u can code in the followin function modules:
Function Module for Outbound ALE
ALE_SALESORDER_CREATEFROMDAT2
Function Module for Inbound ALE
IDOC_INPUT_SALESORDER_CREATEFR
There is another method also for this:
create a bapi fm with all the requirements and go to swo1 tc create an object with method as BAPI FM created.then go to TC bdbg and create a bapi ale interface.this will automatically generates the inbound and outbound FM's .Then the idoc will be generated with the added segments...

Status 51 in IDOC Basic type: ORDERS05

Hi,
When Inbound IDOCs of IDOC basic type : ORDERS05 are processed in bulk then few of the IDOCs go to status 51 with error message : "Sales organisation, Distribution channel and division cannot be determined for the customer (followed by customer number)". But when these failed IDOCs are processed again using BD87 few more IDOCs go to status 53. Similarly if the failed IDOCs are reprocessed for 4/5 times without changing any data in the IDOC then all the IDOCs go to status 53.
When I try to create a duplicate IDOC using WE19 then the IDOC goes directly to status 53. So if processed in bulk then few IDOCs go to status 51 and when processed one by one the IDOCs go to status 53 without any problem. Can someone tell me what is the reason behind it and what has to be done to avoid the continuous reprocessing of IDOC.

Hi,
When Inbound IDOCs of IDOC basic type : ORDERS05 are processed in bulk then few of the IDOCs go to status 51 with error message : "Sales organisation, Distribution channel and division cannot be determined for the customer (followed by customer number)". But when these failed IDOCs are processed again using BD87 few more IDOCs go to status 53. Similarly if the failed IDOCs are reprocessed for 4/5 times without changing any data in the IDOC then all the IDOCs go to status 53.
When I try to create a duplicate IDOC using WE19 then the IDOC goes directly to status 53. So if processed in bulk then few IDOCs go to status 51 and when processed one by one the IDOCs go to status 53 without any problem. Can someone tell me what is the reason behind it and what has to be done to avoid the continuous reprocessing of IDOC.

Inbound IDOC basic type HRMD_A07: Why no validation available?

I am using a standard inbound IDOC basic type HRMD_A07 to update employee master data (IT0000 & IT0001). However, i found out that this IDOC just directly updates to the infotypes without any validation. For example, i provide an invalid company code (BUKRS) and personnel area (WERKS), the IDOC still updates into database without any proper validation.
Filled the following fields in the IDOC segments:
E1PLOGI
plvar=01, otype=P, objid=00000001, opera=I
E1PITYP
plvar=01, otype=P, objid=00000001, infty=0000, begda=20120101, endda=99991231
E1P0000
pernr=00000001, infty=0000, endda=99991231, begda=20120101, massn=01, massg=01, stat1=3, stat2=3
E1PITYP
plvar=01, otype=P, objid=00000001, infty=0001, begda=20120101, endda=99991231
E1P0001
pernr=00000001, infty=0001, endda=99991231, begda=20120101, bukrs=XXXX, werks=XXXX, persg=1, persk=EC, abkrs=99, plans=00000111, otype=S
Please help me out in case I am missing something. Thanks.

Additional Info:
In WE21 at the TRFC Port, it is possible to set this Option:
Send Only Fields of Selected Segment Version
The segment data of the IDoc is passed to this port with the length matching the segment definition of the release specified in the partner profile.
But if we are using an reduced message type, all fields of the newest release are in the segement.
The docu tells that this will be done in function EDI_DOCUMENT_OPEN_FOR_CREATE.
But it is never called when createing an material IDOC with BD10.
Bug or feature?
Kind regards
Manuel

F110S - debugging - Idoc basic type PEXR2002

Hi,
i'm trying to debug F110S and its not stopping in FEDI0003 routines. am i missing something.
i have to populate bank details in this Idoc (basic type pexr2002 and message type PAYEXT)
please let me know.
Thanks.
Edited by: vij k on Aug 5, 2009 9:51 PM

figured it out. Thanks.

Idoc basic type PEXR2003

Hi all,
can any one take me the structure of Idoc Basic type PEXR2003.
WE60 ==> Basic Type checked ==> enter PEXR2003 ==> F9 key
Thanks in advance
Ragerds
Mercuryx

Up,
No ideas??????

Release? while assigning Z Message Type to a Standard SAP IDOC Basic type

Hi Experts,
Am trying to assign a custom Message Type to a Standard SAP IDOC Basic type in WE82 transaction, but am not sure How to find the Release(last column of WE82 Tx)? Pls. let me know.
Thank you

Hello,
In case of IDOC, Go to Transaction WE30, type your IDOC name & select basic type & extension.
After that select Go to -> Header data (Shift+F7), you will Idoc header info. In the same pop-up you will find IDOC release for which version.
Regards,
Sameer

How can I delete the IDOC basic type and extension?

Hi,Expert:
There are some idoc basic types and extension which are not used any more in our system.Now we want to delete them.but when I delete them using tcode:WE30, system said that the basic type or extension has been released and they can not be deleted.
How should we do to delete these idoc types?
Thanks

From the top menu > edit> cancel release then try to delete
a®s

What is the IDOC Basic Type for sales order creation

Hi Experts,
Can anyone tell me Idoc Basic type for sales order creation.
Thanks
Prashant

Hi,
The basic types for creating the order are:
1.Orders01
2.Orders02
3.Orders03
4.Orders04
5.Orders05.
The basic type for SIS order is:
SISCSO01.
Regards,
Krishna.

Prob wth Extending HRMD_A06 basic type

Hi All,
I have some custom fields in PA0002 table. So i extended HRMD_A06 and in user-exits i am populating custom fields. Out bound side everything is OK. But it is giving 51 error in inbound side. Probelm with read_namtb subroutine. it is chking the custom segment in T777D table...
I am unable to solve the problem. Can anyone hlp me in this regard.

May be this helps you !!

FYI
SymptomThe standard scenario for the distribution of HR master data and organizational data via message type HRMD_A only covers a limited number of infotypes.
Additional standard infotypes should be distributed using a customer enhancement.
Other terms
PFAL, RHALEINI, HRMD_A
Reason and Prerequisites
In the standard scenario, only infotypes are distributed, which are required for a distributed HR in a non HR-system.
Solution
The following activities are required if standard infotype Pnnnn (with nnnn = infotype number) is to be distributed in addition.
Consider the restrictions at the end of this note in particular!
Release 3.1
1. Source code corrections:
According to the attachment (programs not contained in the standard system), repairs are necessary in the Includes LRHA2U06 and UP50RU01.
You only have to change Include UP50RU01 if it is a PA infotype.
If you also want to distribute infotypes starting with 2nnn or 9nnn, an additional repair in Include LRHALF01 is necessary. Remember that in this case the Infotype 2011 is stored differently than the other infotypes and cannot therefore be distributed.
Note that these changes are not contained in the standard system.
2. Customizing:
Transaction WE31 for Z1Pnnnn (in the sending system and the receiving system):
For each additional infotype, create a new segment type Z1Pnnnn (with nnnn = infotype number).
Transaction SM30 for table T777D only for PD infotypes (in the sending system and the receiving system):
For the entry infotype nnnn, enter Z1Pnnnn in field IDOC segment.
Transaction WE30 for ZRMD_A01 (in the sending system and the receiving system):
With Transaction WE30, create extension ZRMD_A01.
Create E1PITYP as a reference segment type, as child segments of this, the extension segment types Z1Pnnnn. As an IDoc type, create ZRMD_A01 for the basic IDoc type HRMD_A01 and extension ZRMD_A01.
Transaction WE82 (in the sending system and the receiving system):
The entry for message type HRMD_A and basic IDoc type HRMD_A01 is copied to a new entry with the extension ZRMD_A01.
Transaction WE20 (in the sending system):
In the sending system, for the partner number of the receiving system in the outbound parameters, enter ZRMD_A01 as idoc type in the line for entry message type HRMD_A.
Transaction WE57 (in the receiving system):
Copy the entry for function module name IDOC_INPUT_HRMD, basic IDoc type HRMD_A01 and message type HRMD_A, and enter ZRMD_A01 in the field extension.
As of Release 4.0B
1. Source code corrections:
Implement the attached advance corrections or:
Apply Hot Package for 4.0B: SAPKH40B02 or
Legal Change Patch for 4.0B: SAPKE40B02
The Include UP50RU01 must only be changed if it is a PA infotype.
Include UP50RU01 is not contained in the Hot Package and must be changed in accordance with the advance correction if the Legal Change Patch is not applied.
After applying the Hot Package (and manually repairing the UP50RU01) or the Legal Change Patch, only the Customizing activities are necessary.
2. Customizing
Transaction WE31 for Z1Pnnnn (in the sending system and the receiving system) :
For each additional infotype, create a new segment type Z1Pnnnn (with nnnn = infotype number). The function "Create by copying" can be used to reduce the work load.
Transaction SM30 for table T777D (in the sending system and the receiving system):
For entry infotype nnnn, enter Z1Pnnnn in field IDOC segment.
Transaction WE30 for ZRMD_A02 (in the sending system and the receiving system):
With Transaction WE30, recreate extension ZRMD_A02.
The linked basic type is HRMD_A02. Insert the new Z1Pnnnn segments as child segments of E1PITYP.
Transaction WE82 (in the sending system and the receiving system):
Copy the entry for message type HRMD_A and basic type HRMD_A02 to a new entry with extension type ZRMD_A02.
Transaction WE20 (in the sending system):
In the sending system enter ZRMD_A02 as an 'Extension' for the partner number of the receiving system in the outbound parameters in the entry message type HRMD_A with basic type HRMD_A02.
Transaction WE57 (in the receiving system):
Copy the entry for the FM name IDOC_INPUT_HRMD, basic type HRMD_A02 and message type HRMD_A, and in field 'Extension' enter ZRMD_A02.
As of Release 4.5A
Here, the Customizing activities described in Release 4.0B are to be carried out.
As of Release 4.5A, HRMD_A03 is used as the basic type and ZRMD_A03 is used as the extension type.
As of Release 4.6A, HRMD_A04 is used as a basic type and ZRMD_A04 is used as an extension type.
As of Release 4.6C, HRMD_A05 is used as a basic type and ZRMD_A05 is used as an extension type.
As of Release 4.70, HRMD_A06 is used as a basic type and ZRMD_A06 is used as an extension type.
Restrictions:
SAP cannot offer any support concerning compatibility with different releases for the additional infotypes of the enhancement in the standard system. For release specific changes to the infotypes of the enhancement a client-specific solution must be found (project solution).
Other known restrictions:
Known restrictions are listed here with possible solution approaches. If you should discover a restriction that is not yet documented, you can inform us of this via the R/3 SAPNet Frontend with a low priority problem message.
01/25/1999: PA infotypes with subtypes are not found in T591A
For infotypes in personnel administration, whose subtypes are stored in a different table than T591A according to table T582A, distribution works in the transfer mode 'Insert' and using the change pointers. Distribution in the transfer mode 'Update' does not work. The approach to solve the problem is a customer-specific extension of the routine HR_INFTY_GET in program RHALEINI by the corresponding infotype/subtype combinations.
02/01/1999: Workflow infotypes
Workflow infotypes, thus in the area 12xx, are not supported since the object type workflow is not supported in the standard ALE scenario. The approach to solve the problem is the use of the manual transport connection (RHMOVE30).
05/17/1999: Infotype 2011
The Infotype 2011 is stored differently than the other infotypes and therefore cannot be distributed.
11/09/2000: Segment for infotypes with a width of more than 1000 characters
The maximum width of a segment is 1000 characters. For this reason it cannot be generated automatically for infotypes with a width of more than 1000 characters.
A possible solution is to create the segment manually and to only insert the key fields and the application fields that are really needed in the segment in order to avoid exceeding the 1000 characters. The values of the fields are transported from infotype into the segment and vice versa in the case of infotypes that are distributed additionally. The reason is that the fields have the same names in segment and infotype.
07/17/2002: In ALE inbound processing, only the data records of the infotypes are posted - similar to the infotypes to be distributed in the standard. No additional functions regarding possibly dependent or derived data in other (database) tables are executed. A solution approach is to distribute the dependent or derived data in a separate (customer) scenario or implement a customer exit (RHALE001) or a BADI (HRALE00INBOUND_IDOC) with the desired functionality.

IDOC basic type

Hi guys,
Is there anyway to find out the right Basic type which suites our requirement?
Sahil

Hi Michal,
My requirement is whenever a material is created/changed an IDOC should be triggerd.
we are using change pointers concept here.
MASTERIDOC_CREATE_SMD_MATMAS is used to record the changes and its get triggerd when we create/change and then pass the idoc to PI for further processing.
I am also extending my IDOC by adding few fields.
My question is:
1.How do i know which basic type to use?
2.Do i need to populate the fields for an extended IDOC using some enhancements/EXITs or just pass the extended IDOC to PI?
please reply
Sahil

Idoc basic type and extension copied to new extension now how to trigger

HI EXPERTS,
I have copied a basic type and extension of idoc and now my new idoc has extension name say ext1.
my old extension name is ext .
now i want to trigger an idoc with ext1 extension ,i do not want to change idoc settings in we20.
how can i do this ,please some one reply .
Thanks,
Pradeep.

hi nikhil,
reason is we want two different transport paths ,one team is amking changes to existing things ,i am working on another pahse of project .
I have almost reached near to the solution .i have set the message variant in we20 ,now when i trigger its generating 2 idocs
i am trying to write code in exit but in exit there there is no field idoc_mescod or idoc_cimtype
Kindly suggest!!!1
Thanks,
pradeep.

IDOCS - BASIC TYPE FIDCCPO2

Hi ,
   I am creating idocs for vendor invoices.Txn FB60.
   Here in txn i have a field XMWST ( Calculate tax ).This is a mandatory
   field for my requirement.But this field was not found in the segments
   of basic idoc type FIDCCP02.Could you tell me whether i have to map
   some other field that does the same functionality of XMWST.Help me out to
   solve this issue.
Thanks.

Extend the basic idoc type FIDCCP02 in WE30 & Cretae the field that u want . If this is an outbound then , populate the new field under the user-exit of the standard function module that populates this idoc.
Regards,
Barath.
(Reward if the info helps u )

Changes in XML from Extended IDOC Basic type

Similar Messages

Maybe you are looking for