One word of warning to what I wrote before - I just had to do two modifications in REAPRIN0 and REAABR00SIBI in order to do ROLLBACK WORK in case printing fails. 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 Invoice 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 corrrect way Standard should be working" discussion. So I did the modifiactions.
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. "proclevelENDIF. "sy-subrc
in LEC66F02, FORM bill_all there is thno exception processing...:
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 "wierd behaviours". Luckily, we aren't using the processes where 'ISU_BILL_INVOICE_PRINT_ACC' is involved (yet)...