Improved Process Flow for Returned Batches

Transcription

1 Improved Process Flow for Returned Batches Version of this document (date) 12. July 2011 Author Robert Bieber, SAP AG SAP note Component FIN-FSCM-BNK Copyright 2011 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: [Batch: create, approve, send payment instruction to bank] 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 automatically removed from the approval process. In contrast, later approvers can not structurally change the batch. They have the choice to either approve it: In this case it goes to the next approver or (if the current approver was the final one) is converted into a payment instruction that is sent to the bank. Alternatively, they can return the batch to the first approver. What can the first approver do with such returned batches? The original design did not leave him much choice: He could no longer operate on the batch as a whole, but only on the individual payments. These, he could finally reject or resubmit, but not approve. This limited choice made awkward processes: Let us look at the use case that there is a batch with many payments inside, and the second approver discovers that one of them has flaws and should be taken out (rejected). All other payments are ok and should be sent. In this case, he returns this batch to the first approver: Process Flow for Returned Batches 2011 SAP AG Page 1

2 [Batch #977 in BNK_APP for the 2 nd Approver, Tab: Additional Release Steps. Both the batch header and items (= payments) have status: In approval.] After the 2 nd approver pressed the Return button, saved and entered an explanatory note: [Workflow attachment] This batch appears as Returned in the BNK_APP Inbox of the 1 st approver: [Returned Batch #977 in BNK_APP for the 1 st Approver, Tab: Change and Release] The status is not uniform: The header status says Resubmitted by approver while the item status has not changed. It is still In approval. [Items of returned batch] Process Flow for Returned Batches 2011 SAP AG Page 2

3 The first approver can now read the attached note (which was written by the 2 nd ). If he decides that his colleague was right and this payment needs to be removed, he rejects it: [1 st approver rejects critical payment in returned batch] Now, the first approver would like to put the remaining batch back into approval. The system however does not allow him to do this. If he tries, he gets the message: As a workaround, he could resubmit the remaining payments in the batch, and then call program SAPFPAYM_MERGE to put them into a new batch. After these two extra steps (the 2 nd of them outside BNK_APP and quite clumsy) he has a new batch that contains the remaining payments of the original batch. With that, he can start a new approval process: [New batch with remaining payments of # 977: new batch number # 978] The new batch is technically not related to the old (originally returned) one, and all the workflow attachments (communication flow) of the old one are lost. This was the Return process before this note After you have implemented the coding changes of the note, the same use case becomes more streamlined: We start again with the 2 nd Approver returning a batch to the 1 st one: Process Flow for Returned Batches 2011 SAP AG Page 3

4 [2 nd Approver returns batch # 979] As before, he adds an attachment to explain his decision: [Workflow attachment] As before, this batch appears as Returned in the BNK_APP Inbox of the 1 st approver: [Retuned Batch #979 in BNK_APP for the 1 st Approver, Tab: Change and Release] The first difference to the old process is in the status: Now, both header and items have the uniform status Payment batch created, like a new batch at the start of the approval process. We had to make this change as we wanted to make the new action option fit to the existing status model. We assume that like before - the first approver reads the attached note (which was written by the 2 nd ). He decides that his colleague was right and rejects the critical payment: Process Flow for Returned Batches 2011 SAP AG Page 4

5 [1 st approver rejects critical payment in returned batch] We further assume that as before he wants to put the remaining batch back into approval. For clarification, he might first like to add an attachment (not compulsory): [Attachment by 1 st Approver explaining what he did] And then he simply releases that returned batch: [1 st Approver releases returned batch] Afterwards, this batch appears again in the BNK_APP Additional Release Steps section of all potential (agent assignment rules) 2 nd Approvers: [BNK_APP Inbox of 2 nd Approver containing this batch # 979] All workflow attachments are there: Process Flow for Returned Batches 2011 SAP AG Page 5

6 [Workflow attachments of batch # 979] And both the release and status history give information what happened during the process so far. [Status History batch # 979; the highlighted lines show the Return action] [Release History batch # 979; the highlighted line shows the Return action] Process Flow for Returned Batches 2011 SAP AG Page 6