BCM Returned Attachments from Bank

6
Attachments for Returned Batches ¤ 2010 SAP AG Page 1 Attachments for Returned Batches – Immediately and Simultaneously Version of this document (date) 14. July 2010 Author Robert Bieber, SAP AG SAP note 1488375 Component FIN-FSCM-BNK Copyright 2010 SAP AG. All Rights reserved For Payment Batches (logical Files) we have an approval process based on Workflow (Release Tool) and realised in transaction BNK_APP: In this approval process, there is a fundamental difference between the first approver (user), and later ones (second, third; number depending on the settings): The first approver can edit the batch, i.e. remove payments. In the extreme case when he removes all payments there remains an empty shell which is no longer subject to the approval process. In contrast, later approvers can not structurally change the batch. Either they approve it. In this case it either goes to the next approver or (if the current approver was the final one) the batch is converted into a payment instruction that is sent to the bank. Or they return it to the first approver. Here we are concerned with the details of this return action: Suppose, a later (2 nd or 3 rd …) approver returns several batches: [BNK_APP, second tab, mark and return] He saves and gets the action log popup:

description

BCM Returned Attachments

Transcript of BCM Returned Attachments from Bank

Page 1: BCM Returned Attachments from Bank

Attachments for Returned Batches 2010 SAP AG Page 1

Attachments for Returned Batches –Immediately and Simultaneously

Version of this document (date) 14. July 2010Author Robert Bieber, SAP AGSAP note 1488375Component FIN-FSCM-BNK

Copyright 2010 SAP AG. All Rights reserved

For Payment Batches (logical Files) we have an approval process based onWorkflow (Release Tool) and realised in transaction BNK_APP:

In this approval process, there is a fundamental difference between the first approver(user), and later ones (second, third; number depending on the settings): The firstapprover can edit the batch, i.e. remove payments. In the extreme case when heremoves all payments there remains an empty shell which is no longer subject to theapproval process.

In contrast, later approvers can not structurally change the batch. Either they approveit. In this case it either goes to the next approver or (if the current approver was thefinal one) the batch is converted into a payment instruction that is sent to the bank.Or they return it to the first approver.

Here we are concerned with the details of this return action:

Suppose, a later (2nd or 3rd…) approver returns several batches:

[BNK_APP, second tab, mark and return]

He saves and gets the action log popup:

Page 2: BCM Returned Attachments from Bank

Attachments for Returned Batches 2010 SAP AG Page 2

He continues and transaction BNK_APP is complete. However (unless he hasreplaced the standard Release tool workflow templates with appropriate own ones)he’s not done with these three batches yet. They have not yet been returned to thefirst approver.

Namely, he first needs to produce (for every single batch returned) a text attachment,where he is supposed to explain why he returned the batch. He either sees this taskin this workflow inbox:

Or in a popup in TA BNK_APP:

When he executes this task, he gets an attachment window where he enters hisreason for returning the batch:

Only after having completed this attachment, the first approver will get a Returnedwork item for that batch and can proceed with his work.

[BNK_APP for the first approver, with Returned Batch Work Item]

Page 3: BCM Returned Attachments from Bank

Attachments for Returned Batches 2010 SAP AG Page 3

This standard process for returning batches is quite clumsy. The main point ofconcern is, that returning a batch and entering the reason for this are too far apart. Auser might even overlook that he is still supposed to enter a reason. Thus he mightthink the batch is already back at the first approver while in fact it lingers in themiddle of nowhere.

To overcome this problem, we provide the new note 1488375. This is a standardnote along with a modification proposal. The standard part of the note will not changethe system behaviour.Only if the modification has been applied and the workflow settings have beenchanged (as described in detail below), the process will change.

In the new process logic, after returning the batches, saving and getting the actionlog popup:

The user will immediately get an information popup (message):

Then there comes the attachment screen where he enters the reason:

He saves and thus ends this BNK_APP session.

The system immediately sends the Returned Batch work items to the first approver:

[BNK_APP for the first approver, with Returned Batch Work Items]

Each of them has the same attachment that the other (later) approver entered as ajustification for returning.

Page 4: BCM Returned Attachments from Bank

Attachments for Returned Batches 2010 SAP AG Page 4

Now the first approver proceeds as before.If we compare the old and new approach, we see that in the new approach, enteringthe attachment is part of saving the return action, while in the old approach it cameisolated afterwards.

Technically, the coding fix and coding modification in the note give us the early(linked to save) attachment. To get rid of the late (isolated) attachment, we have tochange some BCM settings and maintain different workflow templates for theBNK_COM release procedure. This requires some workflow development skills.

In BCM customizing we have view V_TBCA_RTW_LINK.

Note 1041016 tells us to maintain this as follows:

The late (isolated) attachment is defined within the sub-Workflow templates50100021-23. Thus we have to replace them with own templates that do not havethese attachment steps.

As an example how to proceed, we take template 50100022. First, we copy it to ourown template: In TA SWDD, we enter it as WS50100022 and choose (in the menu)Save as:

Page 5: BCM Returned Attachments from Bank

Attachments for Returned Batches 2010 SAP AG Page 5

We enter an appropriate abbreviation and name and continue. The system will askfor a development class (package) in the customer name range and return an Id forthe copied workflow template. In our example, this is WS46000024.

This template has two branches, that are labelled ‘Returned during the ReleaseDialog’ (a copy of 50100022 has one such branch, of 50100023 has three branches)

Both branches start with an Add Attachment step:

We mark these Add Attachment steps and delete them (one after the other).

We save and activate and enter the new sub-Workflow template (here 46000024) inview V_TBCA_RTW_LINK for BNK_COM instead of the original one (50100022).

Page 6: BCM Returned Attachments from Bank

Attachments for Returned Batches 2010 SAP AG Page 6

Thus we are done with BNK_COM 02.