Report import using CG36/CG36VEN

[christoph_bergemann]

Hello

since years we are using the "Cg36" process for mass upload of e.g. SDS e.g. in pdf format. Now we have learned that there is a "small" difference to CG36VEN. And for this difference i would need your help.

Imagine this; you use CG36VEN for upload of a pdf file. In doing so: the user interface is forcing you to specify the "number of pages" of the pdf file. This information is

a.) stored in database

b.) and you need it especially if you "print" a pdf file using report distribution process

I am not aware of any kind of option in CG36 to specify the "number of pages" of pdf file. We have "only" the key file and there is no "tag" to define the number of pages.

Now we have identified: without the "number of pages" of pdf file: some subprocesses (like printing using SAP spool) can struggle.

Therefore. do you know any option for "CG36" (in relation of key file) to prepare the "number of pages" in they key file?

C.B.

PS: it is clear that by using some customer specific function module in import process we can solve the problem.. but why does the standard not support this?

[satya11719]

Hello CB ,

Entschuldigung for late reply , I was never tried this PS file creation for *.PDF file, But in my previous project they used count number of pages manually and update in the loading file.

I will try this if there this if i get a chance.

https://www.consolut.com/en/s/sap-ides-access/d/s/doc/YY-EHS_SRE_IMP_100_01/

Regards

Satya

[christoph_bergemann]

Dear Satya

the issue is not the "ABAP" part (may be tricky but possible) and then using an enhanced the key file (so that the number of pages is part of the key file); so here I can see a solution. But you need a "up front" process by analysing my "mass" all relevant pdf files to "calculate" the number of pages and then to add this information in the upload process as automated as best(not using human power). For data migration: you need to think about at minimum 1000 pdf files... nobody will check the number of pages manually... this is to "high costs" and to use a "simpe" approach (use an "average number of opages during upload) is a not stable process.

Any how: we need to improve the process

C.B.

[satya11719]

Hello christoph.bergemann

I do observed the same , in my previous project they got some tool to fetch the page numbers automatically in the Key file.

I will check and let you know about the tool.

Thanks

Satya

[christoph_bergemann]

Dear Satya

we will discuss now internally how to go on. The main risk in using the original SAP process (as it is) is later the "report distribution process" in relation to the "LET" subprocess and the "bundling" process.

Issue is the system set up: how many pages can be put in one "letter" to ship to customer.

E.g. imagine this might be 20 pages are defined in customizing

As in SAP process the number of pages are defined for "IBD" documents using the customizing.. you need to think about a "good" value. The value "10 pages" might not be bad. But the real pdf file can be 20 pages as well.. But the bundle process will use the value "20"...

Like you: we are looking now for an option by extending the process by using "key" file approach.. there is only one "practical" but...

Imagine you would like to upload > 1000 documents.. (and this happens very often) you must detect the number of pages per file and prepare then the key file data.. big manual work... May be we find some option

C.B.

PS: for the practical but, I used "google" now... it seems to be that there are lot of discussions running to "identify the number of pages of pdf file" and there seems to be some tools/processes available which can be used to check a "folder" in which you can have pdf files and the tool will check any pdf file and "extract" somehow the number of pages which will then be stored in some "file" so that the user has the relation pdf file "X" contains "Y" pages.. Very interesting; need to go with this research

PPS: for those who are interested..

E.g. page : https://www.consolut.com/en/s/sap-ides-access/d/s/doc/YY-EHS_SRE_IMP_100_01/

is showing the detail of the process BUT do not list the environment parameter which is used to define the number of pages; so please check the code of FM C13G_DOKX_SDB_PREIMP; you will find this parameter in the code

[christoph_bergemann]

Dear Satya

can you comment on the content of the link I have specified? In this link this sentence is listed:

"The performance for shipping inbound documents can be improved if you program the system so that a PostScript file is also created for each *.PDF file when inbound documents are imported. This means that for inbound shipping, the *.PS files required are available immediately and do not have to be created first."

Any experience in how exactly this generation of the "PS" file has to be handled?

C.B.

[former_member602203]

Hello Christoph,

we use CG36 for more than 100 SDB's in one-import-step. Therefor we use function module EHS_DXSDB and pdf as well the conneced key file. With these way you dont enter the number of pages...

[christoph_bergemann]

Dear Holger

this is our finding as well BUT.. i have checked the story now deeper. Now I have learned this (in relation to CG36)

1.) there is an "environment parameter" which you can use to define the number of pages (never have had in touch with this parameter); this parameter does not make sense as any pdf can have whatver kind of pages (number of pages)

2.) if the "environment parameter" does not have any set up (in your system) by Default SAP stores the value "1" in DMS (number of pages = 1); as well this does not really make sense

3.) in CG36VEN you can specify the "number of pages".. but the field is not mandatory to use (it is not defined as "mandatory" in user interface). I did not check if internally (that means number of pages = space) the ABAP code will "set" the number of pages to "1"

Overall: for me it does not make sense to use SAP standard import.. we will now adjust our approach for mass upload

The number of pages are very important if you use "pdf" file in report shipment process. This number of pages is critical for the "bundling" process and only if you print ! it is not critical if you use "eMail" distribution

C.B.