cancel
Showing results for 
Search instead for 
Did you mean: 

Always generation of new spool request when using message type WNAK

Former Member
0 Kudos

Hey!

I have one question regarding the printout of message type WNAK.

In SAP standard the print program RWBNASTV and entry routine ENTRY_ABR_NATRAB is used.

Now I want to ensure that at every printout generates a new spool request.

Problem is that when a user prints a purchase order and after that a Sett. Crdt Agrmt (WNAK) the second printout is attached to the previous spool.

How can I ensure that there is always a new spool file generated without copying the print program and the corresponding function modules before OPEN_FORM?

In the print conditions I only know the function "Immediately print" but that is no help if the printout is attached to the purchase order which was printed before.

Is there no flag which escpecially ensures that for this message type should be always be generated a new spool request?!?!

I hope you know something else.

With kind regards.

Mark

Accepted Solutions (0)

Answers (2)

Answers (2)

becky_sander
Explorer
0 Kudos

If the spool attributes are the same, it will automatically combine as a previous person mentioned. One attribute that you might be able to impact from your output condition records is the spool title. If you can get them to be different for your two outputs, it should separate them.

Becky

Former Member
0 Kudos

In the Print options structure ITCPO , there is a parameter named TDNEWID , right ? IF you set this, wont it create a new spool each time you print it.

Former Member
0 Kudos

Yeah. Thats true. But therefore I have to copy the print program with the corresponding function modules and I think thats to much effort for such a little adjustment.

Is there nothing which I can set in message customizing or in the print conditions?

Former Member
0 Kudos

I alreadey copied the print program and the function modules but I am still looking for another solution because I think that is not the best solution for the problem.

I changed following in include LWNPNFO0 (copied to LYWNPNFO0):

--- Konvertierung der Kommunikationsdaten: --

MOVE-CORRESPONDING pi_nast TO lvs_snast.

MOVE sy-repid TO lvf_program.

CALL FUNCTION 'CONVERT_COMM_TYPE_DATA'

EXPORTING

pi_comm_type = lvs_comm_type

pi_comm_values = lvs_comm_values

pi_screen = pi_screen

pi_newid = 'X'

pi_country = pi_tocountry

pi_repid = lvf_program

pi_snast = lvs_snast

IMPORTING

pe_itcpo = lvs_itcpo

pe_device = lvf_device

pe_mail_recipient = lvs_recipient

pe_mail_sender = lvs_sender

EXCEPTIONS

comm_type_not_supported = 1

recipient_creation_failed = 2

sender_creation_failed = 3

OTHERS = 4.

IF sy-subrc <> 0.

MOVE sy-subrc TO po_retcode.

PERFORM error_message_arrang_append_sy TABLES ptx_error_messages

USING pi_kona

dummy_vake.

ENDIF.

CHECK po_retcode = 0.

...............

...............

*--- Öffnen des Formulars:

CALL FUNCTION 'OPEN_FORM'

EXPORTING

archive_index = toa_dara

archive_params = arc_params

device = lvf_device

dialog = ' '

form = pi_formular

language = pi_nast-spras

OPTIONS = lvs_itcpo

mail_sender = lvs_sender

mail_recipient = lvs_recipient

EXCEPTIONS

canceled = 1

device = 2

form = 3

OPTIONS = 4

unclosed = 5

mail_options = 6

archive_error = 7

OTHERS = 8.

IF sy-subrc NE 0.

Edited by: Mark Müller on Jul 30, 2009 10:36 PM

Former Member
0 Kudos

Does nobody has a idea?

Is there another part of the forum which I can post this issue. Perhaps it better fits there?

Former Member
0 Kudos

I guess that is the way SAP works.

IF the parameters like Client , Owner, Format , Output device, Number of copies, 'Deletion after output' etc are same,

the new spool will get appended to an existing spool, which is still active.

OSS Note 85318 will give you a better picture. It very clearly conveys that this is SAP's standard beheviour.

Former Member
0 Kudos

Yeah. I also know but that way was not wanted by the consultant.

OK, then this seems to be the only ways to get the new spool request.

Thanks for your answers.

Edited by: Mark Müller on Aug 1, 2009 11:42 AM