Invoice Printing - Additional PDF output format is required

[murtuza_chhatariya]

Hi,

The requirement is to generate invoice in PDF whenever user demands. Currently 3rd party prints the invoices and stores PDFs in archive but it contains some watermarks. So we are looking for option to generate PDF invoice in SAP itself whenever required. Please suggest your opinions on below analysis.

Can we accommodate two types of output generation through single application form in regular invoicing process and is it advisable from point of view of system resource load? In this option, I think archiving is required to store all PDF created daily.

Or should we go for on-demand PDF creation? Will there be any challenge if user tries to print invoice of an old period?

If we want to print PDF invoice through Application form, which is better option - Smartform or Adobe form?

Thanks,

Murtuza

[Private_Member_7726 · Accepted solution]

Hi,

If you have some legal requirements regarding keeping and being able to reliably reproduce exact copies of invoices then optical archive is definitely a way to go and the pdf... is the de facto standard, I guess. If you are using different preprinted media types, automating reprinting the pdfs on right media can, however, be a challenge, because pdf is device independent and contains no information regarding print mode (simplex/duplex), the media type, input tray and the like.

I have been unable to solve the task of retrofitting this information to print jobs when reprinting pdfs from archive thus far, but I'm sure there are "print workflow" solutions out there that would handle the task (it's just that we don't want additional complexity of interfacing with yet another 3rd party solution and don't even want to consider paying extra for something as simple sounding as that). I'd advise to invest in at least archiving the information potentially needed to reprint the pdfs on right media, too...

If you are using normal REAPRIN0 for output, to add in additional output types with as little change of existing processes for users as possible, I'd suggest you look at FQEVENT R392, Print Workbench Dispatch Controls (which can be assigned in R392), and PWB Form type Collection. The Collection helps to easily work around the fact that IS-U Contract Account can be assigned just one Bill Form. It also allows to conveniently group all "output types" in one place. Even though SAP probably had other goals in mind when designing Collections (primarily sending output via E-Mail I think), I have been able to easily program around all the limitations.

Since the Note 2041251 - EASIBI: Not possible to adapt the print parameters using event R392 came out, the setup will work just as well for single printing as it did for mass printing. We even integrated triggering our E-Invoicing interface this way - via configuring appropriate dispatch controls so the invoice will be just archived and not printed, adding a new PWB Form of type Data Dispatch to collection and controlling what the collection will do (which Forms will get processed and which not, etc) in R392.

Yes, one would need to think carefully about performance implications and avoid doing time consuming stuff like calling smartform multiple times (REAPRIN0 already buffers the invoice and some of master data needed by PWB Formclass IS_U_BI_BILL so there should be no challenges on data access side). Competent programmer will be able to do layout creation once - get the output of SAP form as OTF/PDF once during Collection processing, for example, and work with that.

I like the simplicity, flexibility and extensibility offered and after Note 2041251 can think of nothing else in IS-U I can recommend as enthusiastically as Collections, PWB Dispatch controls and R392 during Invoice Printing. By now we cover and control all invoice output needs using just those, in "one place" so to speak - and no new processes for users, no need to retrain, etc. when we have to add in something new.

On demand recreation of Invoice output is IMO impossible challenge if you want it to look exactly the same as the original. IS-U Print Document does not hold all information needed to produce output (and not all of data needed is time dependent). Then you need to consider the form changes, program changes (including those you are unable to control, like SAP standard changes). I'd not advise it even if the client can live with, say, output being 90% the same as the original and would never use it if there is any kind of legal requirements involved. Optical archives can take care of reproducing documents and cut away all the complexity involved in trying to reproduce complex output from the data ...

cheers

Jānis

[Private_Member_7726]

One word of warning to what I wrote before - I just had to do second modification of that kind in REAABR00SIBI in order to do ROLLBACK WORK in case printing fails (in REAPRIN0 we have had this since last December). We must have the whole collection processed or nothing, so if the first collection step updates/registers something to be PERFORMed ON COMMIT and second step fails, a rollback should happen...

It seems to be settled practice in IS-U Bill printing that no ROLLBACK gets used - only commits. I don't like this (I consider it a good practice for an application controlling the LUW to finish it with either COMMIT or ROLLBACK) but evidently IS-U programmers have had other considerations in mind and I didn't want to get in the "I know the one and only correct way Standard should be working" discussion. So I did the modifications.

cheers

Janis

Edit in: and I don't like very much what I'm seeing when I start to look up the where used list for ISU_INV_BILL_PRINT_METHOD in IS-U standard functionality...:

ISU_BILL_INVOICE_PRINT_ACC has explicit commit, regardless of whether printing failed, and this (no exception processing):

CALL FUNCTION 'ISU_INV_PRINT_METHOD'
... 
EXCEPTIONS
          general_fault = 1
          printlock     = 2
          canceled      = 3
          OTHERS        = 4.

      IF sy-subrc = 0.
        mac_msg_put_we 'S128(AJ)' date_str time_str space space.
        IF 1 = 2. MESSAGE s128(aj). ENDIF.
        y_printed = co_flag_marked.
        IF proclevel = co_displaying_bill.
          swc_call_method iobjref 'PREVIEW' cont.
        ENDIF.                         "proclevel
      ENDIF.                           "sy-subrc

in LEC66F02, FORM bill_all there is no exception processing either...:

  CALL FUNCTION 'ISU_BILL_INVOICE_PRINT_ACC'
...
       EXCEPTIONS
            general_fault = 1
            OTHERS        = 2.

  IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
*         WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
  ENDIF.

These are the things that are IMO bound to sooner or later produce errors and/or "weird behaviors". Luckily, we aren't using the processes where 'ISU_BILL_INVOICE_PRINT_ACC' is involved (yet)...