Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Tool to convert SAP-EDI message into a readable document(PDF...) ?

Former Member
0 Kudos

Hi experts,

My need is to have a kind of tool to read + translate the standard "INVOIC02" message into a readable generic document (like PDF by example)

This, because in case of any problem, a basis user can read the data without have to know the EDI (segment, fields, rules ...)

So is there a kind of tool or something similar to do this? Or is anybody on this forum already did this kind of tool?

I precise I search before to open this topic, but nothing really found arround my request (only 1 topic that I'm checking deeper)

thanks for your help

Pascal.

37 REPLIES 37

Juwin
Active Contributor
0 Kudos

Doesn't WE02 help? How different will a PDF form look from WE02 display? If you don't like that display, you have an option to print the IDoc as well. But, WE02 display is cleaner and more readable than the printout.

Expecting a BASIS person to look at the IDoc and comprehend the values, is in my opinion "unreasonable".

Thanks,

Juwin

Former Member
0 Kudos

Hi Juwin,

thanks for your update!

For me the display you said is too technical and a final user can not use it. (it's +/ the same than the EDI file but a bit more readable)

I have in mind a display more graphical instead of a list of segments / fields ... you see what I mean?

I know that some EDI partner (ex. Seeburger, Elemica) did this kind of document ... so I want the same for MY EDI sent

Former Member
0 Kudos

Hi,

If you do not want the control segment or status record then please make use of the table EDIDD or EDID4, for data records. You can download it in ALV format via SE16N.

Regards,

Souvik

Juwin
Active Contributor
0 Kudos

May be you can give a sample of what you are visualizing as output.

Thanks,

Juwin

former_member202957
Contributor
0 Kudos

Hi,

If you need PDF, one way is when you print IDoc as shown by Juwin you get spool number. Use this spool number and report RSTXPDFT4 which will convert Spool into PDF. Hope this helps?

Thanks,

Sunil.

0 Kudos

hi,

no, I don't need a list of segment/fields in a PDF ... I want a PDF (or WORD or other) as a graphical document a bit like this below:

0 Kudos

No way you can get this through standard transaction. Better develop a custom object.

Thanks,

Juwin

0 Kudos

that's I want to avoid ... 

I'm sure that someone else already did this and maybe I can reuse +/- the devt ... ^_^

Otherwise, if I find nothing, I'll do it ... but that's pitty !!

Pascal.

0 Kudos

Hi,

one way is to create Smart form using your IDoc structure. The one you shown is also looks like smart form.

Jelena
Active Contributor
0 Kudos

You seem to be confusing EDI and IDoc format. These are two different things.


Such functionality does not exist for IDocs AFAIK. We work with Seeburger and they don't provide any explanatory PDFs. Their role is to convert IDoc into EDI format and how exactly they do it, frankly, no one cares (that's what we pay for).

WE02/WE05 are quite sufficient for troubleshooting in SAP. We train the designated business users on how to use the IDoc display, how to view the segments and provide them specific instructions for the most common issues. There should be very few of those issues to begin with. If you're frequently dealing with the problems that require extensive analysis then I'd suggest to look for the ways to improve your interface.

Former Member
0 Kudos

Hi Jelena,

Sorry but you are wrong !!

Because we work also with Seeburger and the document I gave in my above message is the PDF that Seeburger create from theSAP_Idoc i sent to them ...

They drive 3 files :

  1. the idoc receive by me
  2. they generate this internal pdf for display data (that's my need but direct in my system)
  3. they create the EDI message in the good format (the one of the customer)

And regarding WExx display : NO it's not sufficient because a jurist will NOT be able (or don't want ??!!) to read a technical document like this.

They want/prefer something graphical/easily readable. (that's not my words but the ones of my jurist team!)

@Sunil Kumar kairamkonda : Yes in case I don't find what I need, I will be obliged to create myself the document ... and in smartforms I guess.

SimoneMilesi
Active Contributor
0 Kudos

I think you misunderstood Jelena's words: what Seeburger/EDI does is different from what Idocs do.

Seeburger isn't a part of SAP enviroment so what it does (or not does) is not something related to sap.

I'm trying to find out why you want to create a pdf from the Idocs segments instead that from the invoice data available in SAP: they are the same!

And Sap also provides a default module with all the most common and useful informations.

It seems, to me, you are reinventing the wheel: SAP gives you Smartforms with automatic (almost) PDF generation so why, again, do you want to generate and Idoc and then convert to PDF?

Former Member
0 Kudos

Hi Simone,

where Jelena is wrong is there:

We work with Seeburger and they don't provide any explanatory PDFs


in our system, the "normal" invoice (i mean the one we print / fax / email / PDF ... = generated by the smartforms) is not really the same than the EDI one.

The 1st reason is :

  • EDI invoice = standard flux/data
  • Smartforms invoice = spécific flux/data.

Then, in EDI, because it's initially a standard process, we remove some informations (like certain tax or things that the customer don't want or things we don't want to send to the customer).

So that's the reason why jurist team asked me to do a readable document (not technical one) for basis user !

In fact, in France we must Archive the ORIGINAL document we send + the last message received by the customer (this is not my words again ).

So I will archive :

  • MY IDOC(and need a tool to make readable in case of mystake later
  • and also the LAST EDI INVOICE MESSAGE received by the customer

And this last is not enough in archiving process because we need also OUR document

This because the both can be different (because between us and customer there are EDI partners like Seeburger, Elemica ... so format + infos transformation!)

do you understand better ?

SimoneMilesi
Active Contributor
0 Kudos

And people complain about Italian burocracy! *giggle*

Ok, now the scenario is a bit more clear but, as you already discovered, you have no other option that create a new smartform which took the data from invoice (the same like Idoc you are sending) and print it.


But.... there is an alternative maybe.
If the edi partners put the the PDF they generate ALSO on an FTP, you can read it from your program.

I did something similar a couple of years ago where we save on external FTP all the invoices before archiving them, but the concept it's the same.

Former Member
0 Kudos

Yes you'r right (FR laws are very rigorous around admin data )

And regarding your proposal, I though about that (archiving the PDF generated by Seeburger) ... but before, I must be sure that it's the EXACT copy on the Idoc we send to them

otherwise : no other choice than smartforms way 

SimoneMilesi
Active Contributor
0 Kudos

If they build the pdf name with invoice nr, you'll be able to link it to the correct idoc since i think your idoc is sent via EDI message so from NAST table and following you can build all the chain.

It's not too hard, maybe a bit long to write, but it's absolutely feasable.

Former Member
0 Kudos

Yep, I'm gonna to see that also ...

And maybe also the way : convert EDI to XML or HTML + print in graphical format 

thanks

Jelena
Active Contributor
0 Kudos

Pascal R wrote:

where Jelena is wrong is there:

We work with Seeburger and they don't provide any explanatory PDFs

I was talking about our company's ("we") relationship with Seeburger. Even if I was wrong how would you know? I'm confused...


Then, in EDI, because it's initially a standard process, we remove some informations (like certain tax or things that the customer don't want or things we don't want to send to the customer).

So that's the reason why jurist team asked me to do a readable document (not technical one) for basis user !

Sorry, I don't get the "so that's the reason" part at all. Who is "jurist", who is "basis user" and what is the specific reason for them to ask for a "readable document"? What would those people do with it?

In SAP you have the ultimate source of information - the billing document (VF03 transaction to display). Then you have the output that can be either in print/fax/email form or IDoc form (you can also do both, of course, with different output types). If you send the billing documents to the customer using EDI then IDoc is simply used to transfer the data to the EDI translator. That translator takes the data from IDoc and converts it into an EDI transmission based on whatever standard you use. (You described that part above.) The legal document that is sent to the customer would be the print/fax/email output or the EDI transmission. IDoc just serves as means to the end, so to say (hence the name "Intermediate Document", even though it's not a document).


In fact, in France we must Archive the ORIGINAL document we send + the last message received by the customer

If this is come kind of country-specific legal requirement then you might want to see if there are any SAP notes on this. Also your EDI partner should be able to advise you in such matters. Not sure why you seem to want to cut them off here, I'd take full advantage of their services.

If you'd like to get intelligent suggestions on SCN then it'd be beneficial to be more clear and explain the legal requirement in more detail and in SAP terms. E.g. what exactly is considered "original document", how would you "archive", what is "message" here and how it's different from "original"? You might want to use the standard SAP terminology to be more clear.

Former Member
0 Kudos

My need is simple: make a readable view of an Idoc I sent ...

>> "basis user" = not an expert in EDI which is able to decipher an idoc file

So for this kind of people, we need a document like I attached above instead of edi format!

Don't ask me why because we ask me to provide this kind of document...

So according to this, I must find the way to convert an EDI in that kind of format ... that's the goal.

But anyway, because it seems to be franco-french ... I will do a display through a smartform or XML or HTML ...

And as already told: I can NOT provide the normal "invoice FORM" (= not EDI) because it's not exactly the same document (even if 95% of the data are similar). It's 2 different print programs : so means 2 different documents for the FR law !!

Jelena
Active Contributor
0 Kudos

Pascal R wrote:

>> "basis user" = not an expert in EDI which is able to decipher an idoc file

So for this kind of people, we need a document like I attached above instead of edi format!

Don't ask me why because we ask me to provide this kind of document...

There is no "idoc file". WE02/WE05 is a human readable format. Why would someone who can't make sense of WE02 have a need to access the IDoc data? Oops, sorry, here I go again with the silly "why" question. I guess if someone asked to printed this in purple ink on the strawberry-scented paper you wouldn't ask questions either...

Well, if the same output program satisfies the requirement then you can simply generate two IDoc outputs and send one to EDI and one to XML file. And then business can pay for the custom development to do whatever they want with the XML file. The last part is still not clear to me (will the proverbial "Janice from Accounting" look at the PDF, then at VF03 and just say "yep, looks OK"?), but since you're fine with it then good luck.

Juwin
Active Contributor
0 Kudos

Hi Jelena,


if someone asked to printed this in purple ink on the strawberry-scented paper

I think this is possible, but only by experts.

Thanks,

Juwin

Ryan-Crosby
Active Contributor
0 Kudos

I got a good chuckle out of this:


Jelena Perfiljeva wrote:

There is no "idoc file". WE02/WE05 is a human readable format. Why would someone who can't make sense of WE02 have a need to access the IDoc data? Oops, sorry, here I go again with the silly "why" question. I guess if someone asked to printed this in purple ink on the strawberry-scented paper you wouldn't ask questions either...

My favorite question to ask is "why?" and it's amazing the kind of response or look I will get.  I'm a bit confused as to why someone that has no expertise in EDI at all would be involved in anything related to EDI.  Seems to be a question of simply not involving the right people for some task/responsibility.

Regards,

Ryan Crosby

Juwin
Active Contributor
0 Kudos

Hi Pascal,

I am still confused, Sorry.

Is this IDoc, outbound from SAP or inbound?


Pascal R wrote:

This, because in case of any problem, a basis user can read the data without have to know the EDI (segment, fields, rules ...)

If it's outbound, what kind of error are you expecting to see in the IDoc? I have never seen an outbound IDoc failing in SAP system, due to a business data reason. Hence, the above statement leads me to believe that this is an inbound IDoc scenario.


Pascal R wrote:

In fact, in France we must Archive the ORIGINAL document we send + the last message received by the customer (this is not my words again).

But, the statement above, makes me feel that this is an outbound scenario.


If its outbound, what transaction is this IDoc based on? Since you are talking about INVOIC02, I am assuming that this is something related to customer billing document. If my assumption is correct, normally, every company will have both EDI/Print output types configured in their system, to address EDI/non-EDI customers. Hence, do you have Print output configured in your system? If yes, then how different is your Print output, from the output you have requested above? Also, if the IDoc is outbound, that means it is based on some SAP transaction - like a customer billing document. If so, does the user have access to VF03? Can he not look at VF03, rather than a PDF document?


Thanks,

Juwin


Jelena
Active Contributor
0 Kudos

@Ryan - could not agree more. There are still many holes in the OP's story (e.g. if the requirement is to preserve a copy of transmission then why does it have to look like a form?) and I was hoping to get clarification but not much luck so far.

@Juwin - thanks for the memories. "So, technically it IS possible?". Haha, classic!

Jelena
Active Contributor
0 Kudos

Juwin, as far as I understand, it's an outbound EDI invoice (=billing document) scenario. Looks like print output is a no-go since a different program is used (RLB_INVOICE vs. RSNASTED in standard). Although I'm still fuzzy myself on what business/legal requirement OP is trying to implement exactly.

Former Member
0 Kudos

to all:

  • yes it's an outbound EDI invoice (us->Seeb->Elemica->Customer) as explained by Jelena (RSNASTED and not ZRLB_INVOICE)

  • We02/05: is not readable by somebody who don't know EDI
    • They can't know which segment correspond to which data (for some : maybe but not evident for all)

  • When I talk about problem ... it's not sending or EDI problem. Because for this, I'm in charge of the solution. We asked me this in case of legal issue
    • (ex. customer is not agree with an invoice: so we can proof with our EDI invoice that all is inside : so there, the famous document I must do will be used (not a flat file with brut data inside).
    • In this EDI invoice we will add ; like in our invoice FORM ; some FR legal information (tax description, RCS, ...) but we can't oblige the customer to add those infos on his side. But us, we sent them to it ... so if legal issue: we must also proof that all the necessary infos was in the EDI invoice

So for all of this (and maybe more) I need to have a new FORM for the EDI invoice with the print program = EDI file!

I'm very surprise of the answers of this topic because I thought we was on this forum to find solutions... and to be honest, instead of this, I have more question than answers and above all I feel we want to impose me a solution to me that I do not feel good from the beginning (WE02 / 05).

My request was simple at the beginning: transform the EDI into PDF ...

So if something exists: I'm interested ... if not, no problem, I will develop it!

Be sure that before to come here I had a look on my SAP + google(sdn or other) ... and I tried here.

But seems that nobody already did that: OK, no problem, I will do differently

Thank you anyway for your help attempt.

(And if I find or do something : I will bring back the solution here )

0 Kudos

Hi,


Pascal R wrote:

  • We02/05: is not readable by somebody who don't know EDI
    • They can't know which segment correspond to which data (for some : maybe but not evident for all)

So you have not answered the question in regards to why someone with no familiarity or expertise in EDI is dealing with EDI in any context.  If there needs to be proof that data was sent it should be handled by someone that knows what they are doing.  I see a couple of possible issues with developing a form to represent your EDI invoice:

1. As Jelena has already stated - IDoc != EDI so unless you send IDocs with no mapping to some other party or with strictly 1:1 on everything then a form does not serve as proof.

2. Should you be able to say #1 is not applicable in your case a form still doesn't serve as a 100% fail proof way to ensure a novice with IDoc/EDI can interpret a form output correctly.

Regards,

Ryan Crosby

0 Kudos

I would be very interested to know what you are going to show on the PDF. Are you going to show segment/field data? Is this only specific for a specific Message Type.

Regarding your comment about "I'm very surprise of the answers of this topic because I thought we was on this forum to find solutions... and to be honest, instead of this, I have more question than answers and above all I feel we want to impose me a solution to me that I do not feel good from the beginning (WE02 / 05)".


You are receiving those comments because you are not stating your requirement.Other people who have posted here are implying that you should be questions as to why a different format of this "EDI" data is required, when SAP already provide it.


As people have said, if Basis are not happy with EDI, then why would they want to look at the data anyway. It is very rare that a basis consultant would be interested in the data. Functional maybe. A functional consultant would know which segment/field is being mapped to the transaction in SAP. If not, they soon will in order to resolve issues.


Irrelevant of whom wants to look at the data, in which you call it EDI. An IDoc is not EDI. When you say EDI, people think EDIFACT..TRADACOMS. So you need to be very specific in what you are asking.


After reading this post, it appears you have ended up in a rather moody place because you are not happy with peoples responses. That implies that your original requirement is not clear...or you are not accepting those responses. All people are asking is "Why is this solution required?"...or "Why would Basis want to look at this data?". Yet you appear not to like those comments.


If it was me being asked to show IDoc data in a different format. I would show them WE02, and refuse to provide any other option. SAP Provide that transaction, its very useful to see the data on the IDoc.



Juwin
Active Contributor
0 Kudos

When I first read OP's post, I also wondered why a Basis consultant wanted to see this IDoc data in a PDF format.

But, later I realized that, OP didn't mean a 'Basis consultant', when he said 'basis' user. What he meant was a 'basic' user, who doesn't have much knowledge on looking at the IDoc screens - a 'basic' training issue, if you ask me.

Thanks,

Juwin

0 Kudos

yes "basis" = "end user" = "user who don't know SAP" = "user who know SAP but not EDI" ...

(not basis as "BC")

sorry for the misunderstanding!

Former Member
0 Kudos

To the ones who don't understand why the EDI file/idoc must be shown in a different format  ... I ask you this:

Why in your SAP ; instead of providing a nice looking FORM ; you don't just provide a file or print a list with inside the structure/fields of the INPUT of the smartform?

You have a smartform to create a structured and nice document ... right?

So there, the need is the same but insteaf of using print program ZRLB_INVOICE I use RSNASTED because it's EDI...

so please stop asking me "why ...why.... why you need this tool" ...

I need it, that's it !!!

So please brings answer or part of solution if you have ... but please stop asking useless questions!

Because this topic has 30 answers ... and only the 2 of Simone help me a bit in my research...

thanks in advance

Jelena
Active Contributor
0 Kudos
please stop asking useless questions!

I don't feel any of these questions were useless. It is reasonable to question the requirements in order to understand them better and to find the most suitable solution. From what you've divulged so far I feel you are searching for a solution for a problem that does not exist. If the customers start questioning your EDI transmissions then they might as well question the PDF or whatever information or format you give them. Legally the customers can't simply dispute an invoice (in any form) without a valid reason. Assuming a PDF will help your company in any way in such situation is illogical. If you don't believe SCN then ask your legal department.

The experienced SCN members are trying to help you to avoid wasting time and resources on inventing a custom solution. SAP is quite a mature ERP system and I'm sure has many customers in France. And if SAP has not provided any solutions like that and no one even asked on SCN about this then I'd ask the business what makes them so special that they require such functionality. If there is some legal requirement (it's still not clear since the story keeps changing) then, again, I'd suggest to search for SAP notes and contact SAP if there is none.

However, it seems you choose not to listen to the reasonable arguments, so I feel this conversation can serve no purpose anymore.

Former Member
0 Kudos

I repeat AGAIN that my jurist colleague ask me to provide a readable document of the Idoc sent (not we0x).

So that's not the fact that I don't want to trust the SCN users or not ...

Personally I prefer tell them to use WE02 ... but it's NOT acceptable for them because is too technical !

So can you understand that or not?

I'm not asking here if it's correct or not (what my colleague ask) ... but a solution or help to my need.

This topic drive me "crazy" !!

All those messages for 0 solution...

JL23
Active Contributor
0 Kudos

"The French Tax Department is granted the right18 to receive communication of all accounting documents, regardless of their format. Where a presumption of fraud applies and a judge has issued a search warrant, documents held in any format can be seized anywhere in France."

from

THE ARCHIVING OF ELECTRONIC DOCUMENTS UNDER FRENCH LAW

the whole document does not say anything else about the format, and you usually can archive any output message in SAP by making use of the print and archive indicator in the message.

If you transmit only bei EDI, then have a second output message type similar to the paper copy  for archive only.

Make sure that you do data archiving for your IDOCs .

Former Member
0 Kudos

thanks for the link. I will try to read and understand ...

regarding archiving : I will archive my message + the one received by the customer ... so normally no problem with that (until now )

In case of problem (and trust me that ; with some customers ; we could have some "disputes" ) I though that because it's an EDI process ... so if a lawyer (or worst : a judge) must have a look, he should be EDI specialist ... or something like that!

But it seems not ... a "normal" lawyer/judge can follow the 'case' ... and so give a WE02 list to a lawer ... you will see his reaction

JL23
Active Contributor
0 Kudos

I would not make assumptions of their ability, if they can't do it alone then they have their experts around. And they are often smarter than we as their business is to deal with all these formats while we usually deal only with our own used formats.

If the authorities had a need in a specific format, then this would be expressed in data specifications, like it is for INTRASTAT.

Former Member
0 Kudos

Hi,

I'm agree with your opinion ... but sometime, unfortunately they don't want to work like you explained (ask to expert)

So I'll try to create a simple generic document, like this, in case of need, we don't need to do it with emergency!