on 2019 Jun 21 12:25 PM
Hi together,
we would like to Import via Idoc Scenario (SUBMAS02) more than 132 digits to the IDENTIFIER in segment E1BP1077RI. How could I do this?
In manuel way, there is the longtext availible but I don't see this possibility in Idoc...
Request clarification before answering.
Hello Holger,
Please try E1BP1077IL , and do let me know if it is useful for you.
Thanks
Satya
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Holger
as I have tried to explain: start with the other way around ..
Not being the ALE expert story is like: you need more than one "segment"; all of them (according to my understanding) are needed to handle per segment 132 CHARs. So if you have a "long text": you need as much as E1BP1077IL segments to pass on the data.
Always the best is to learn from: do an "outbound".. and based on what you can see. try the "inbound"
C.B:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Holger
I have done a further check via google and found this document:
http://www.amicuk.com/lsmw-bus1077-specifications-for-cg02/
Could be of interest to you
The same here: https://blogs.sap.com/2016/03/10/lsmw-for-specification-management/
So generally: LSMW approach can "trigger" the generation of SUBMAS IDOCs
In many cases ALE is partially outdated" and for data integration now "WebServices" are used more and more often
Keep in mind my comment: the "target object" (spec id) is not ! allowed to be edited by somebody. In this case the ALE inbound process can not work; this is a general issue which is as well true if somebody would like to use SAP EHS OCC for data import. The target objects should ! not be blocked by different user and honestly: in may be roughly 1% of cases this is the case; so somebody is blocking the spec id in "Edit" mode; so you need a strict control of ALE INbound process; the goods news is: the IDOC is still there; the bad news is: the inbound process (if spec id was blocked) must be started now manually
C.B.
PS keep in mind: the "customizing" content of the IDOC must be in sync with the target system
E.g. if in the IDOC a component type "X" is used but "X" does not exist in the target system: the inbound is not possible. The same is true for any "phrase" related information, "UOM" related information of information based on e.g."Regulatory lists"
To make an example: if you use content (like former CLEO) per "CLEO" update you will get a guidance document: what kind of "new customizing" must be established or which "new master data" (like phrases) must be established
I have no clue how you have arranged this correlation to your business case; but it can be a point point for the "Inbound" process
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Holger
I have done a further check via google and found this document:
http://www.amicuk.com/lsmw-bus1077-specifications-for-cg02/
Could be of interest to you
C.B.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Holger
based on your last comment this is now my picture:
a.) We have a Non SAP system as the source system; this system creates "XML" files
b.) You have still some "middleware" in place (but not SAP PI) to get an IDOC based on XML file
I am not the ALE expert. But may be get in touch with an "ABAPer" and check this function module:
C14ALE_IDOC_INPUT_SUBMAS
This function module "consumes" at the end SUBMAS IDOCs. On top: generally take a look on function group C14ALE; here all relevant function modules for ALE handling are managed
Overall: so the trick is (in my opinion) to look on the "middleware" which needs to transform the XML file to an SUBMAS IDOC (including long text options)
There is on tzhe top some "but" (kind of warning):
1.) if you create a new spec: this should be no problem
2.) but if you do updates on existing spec. The list of issues here is "endless"; e.g. the spec ID is not allowed to be "blocked" by a user or process in "Edit" mode
Even looking on SAP to SAP connection for SUBMAS: there is always a risk that in "inbound" process something can go wrong; so a "strict" monitoring is needed.
The issue might be: you might not always know at which point in time an "IDOC" need to be consumed; but the IDOC inbound handling (for SUBMAS) create a log (refer to SAP help). You can check this Log for "issues" and based on that you have a better chance to manage the ALE
Discussion in this FORUM has shown, that the SUBMAS handling is not easy and there a lot of pitfalls to consider.
But the monitoring of ALE and "error" fix is really time consuming and the error fixes handling is a different story
As shortly explained: yes we have some ALE discussion here, But quite limited (< 20 threads ?) and your scenario is specific (but refer to the othere listed threads; some of them refelct your wish a little bit
C.B.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Holger
now you have "lost" me..
Let us assume this scenario:
You have a target SAP ERP system in which EHS is prepared. The IDOC can only be "booked" in the system based on two approaches
1.) the spec id is still part of the IDOC
2.) or by using e.g. an "identfier" the corresponding target object can be identfied
1.) is the variant you should use (but how should teh soruce system know your spec ID ?). Now if you have a souce system in which EHS data is prepared we have two choices/options:
The source system is a SAP system or the source system is a "non SAP" system
For Case one. SAP can handle outbound and inbound without any problem (I am not aware o any problem). Here you need to influence teh SAP approahc. The "long text" are corrected dispatched and booked in the target system
For case 2: in most case you use SAP XI/PI as "middleware" and then this creates the IDOC for EHS
If you use this option: the SAP XI/PI must be prepared in such a way to generate the correct IDOC structure so that long texts are supported (I am not an ALE expert); but important is: in SAP XI/PI the "mapping" must be done so that the spec ID is identifed or you will not get the IDCO booked in the target system
May be this document might help a little bit:
https://wiki.scn.sap.com/wiki/display/HOME/Step+by+Step+procedure+for+creation+of+IDOC
For relevant "technique" part. https://wiki.scn.sap.com/wiki/display/ABAP/List+of+BAPI%27s
could be of interest and there: e.g. BAPI_BUS1077_SAVREPMUL
Here some threads which are linked "partially" to your topic:
These are related the "inbound" topic
https://answers.sap.com/questions/10741548/data-transfer-of-substances-fails.html
https://answers.sap.com/questions/12327599/inbound-submas-idoc-from-external-system.html
https://answers.sap.com/questions/107314/hello-willem-just-to-ask-how-you-have-used-the-inb.html
and this is related to "outbound" topic
https://answers.sap.com/questions/3491390/extraction-program-for-ehs-ehs-to-xi-scenario.html
https://answers.sap.com/questions/9087412/idoc-from-ehs-tables.html
https://answers.sap.com/questions/10687821/background-possibility-for-data-exchange-ale-with.html
https://answers.sap.com/questions/9823515/mapping-of-properties-to-characteristic-fields.html
C.B.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dear Christoph,
yes ist quite complicated and I have never heard from other EHS customers that approach / scenario which we use succesfully since 3 years.
Regarding your comment we use this:
1.) the spec id is still part of the IDOC -> data came out of an non SAP System via XML.file and we have used SAP PO in the past but now we have a Service Provider with his own midlleware which generate out of the xml, IDOC on our system which generate new specs or update These specs...
Hello Holger
up to now i never get in touch with one person using ALE for data migration/data import
We can use some assumptions:
1.) any "long" text (like identfier or user defined text) can be distributed via ALE without any doubt
2:) But if your "segment" is the right one to look at? No idea
The "best" is (like with EHS standard import) first to do the "other way" around
So you have a spec with an identfier which is longer than 132 digits: distribute this spec to some target system. SAP EHS is doing the right "thing" in the right sequence. Then just check the IDOC structure and how in SAP standard the "outbound" is done. Based on that: you can do the "inbound" (hopefully)
A further option is: if you have a ABAPer : check the document here: https://www.consolut.com/en/s/sap-ides-access/d/s/p/5/doc/YY-EHS_MD_120_40_02.html
There is a standard BAPI which is doing the work
E.g. check:
There are some threads discussing "similar" challenge
https://answers.sap.com/questions/10066398/distribution-of-specifications-using-ale-with-reci.html
https://answers.sap.com/questions/7131264/ehs-interface-to-distribute-the-specification-data.html
https://answers.sap.com/questions/12327599/inbound-submas-idoc-from-external-system.html
https://answers.sap.com/questions/107314/hello-willem-just-to-ask-how-you-have-used-the-inb.html
https://answers.sap.com/questions/9087412/idoc-from-ehs-tables.html
C.B.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.