46C Payment blocking and Logistics invoice verification

[Kjetil Kilhavn]

Unfortunately it doesn't. Furthermore, it seems that the MRBR transaction
doesn't care what block code the FI document has. Admittedly the test I
performed was crude. I created an invoice in MIRO which was blocked. I then
updated BSEG directly to set the block code to the code which was "not
changeable". The invoice could still be released from MRBR.
 
The whole thing is a mess it seems. Current plans involves estimating the
cost and consequences of two different approaches:
1) Continue handling invoices as today and tighten security
The invoice handlers currently never release a MIRO invoice (i.e. don't use
MRBR), they release the invoices in FI directly. So we will block access to
MIRO to avoid releases. In addition we will have to have a substitution on
FI documents to change the block code from R to our chosen "not changeable"
code. If it is a problem that MM invoices are in an incorrect state
(blocked) for instance in relation to archiving we will also have to
develop a special program to release the MM invoices which have had their
corresponding FI documents released.
 
2) Start using more of the standard MM functionality
The invoice handlers will have to change their routine from releasing FI
documents directly to releasing via a modified MRBR. The MRBR modification
consists of preventing them from releasing invoices blocked due to amount
as these are to be released by the task manager in our approval system. In
addition a modified FBL1N will have probably have to be developed to allow
them to follow up inquiries with the same wealth of search criteria that
they have today - preferrably with an enhanced result set (read: to please
them).
 
 
Thoughts and experiences from "process war veterans" (actually, from
anyone) will be appreciated.
--
Kjetil Kilhavn
 
 
 
 
 
                    John Haworth
                    <jhoworth at csc.com>          To:     SAP-WUG at MITVMA.MIT.EDU
                    Sent by: SAP                cc:
                    Workflow                    Subject:     Re: 46C Payment blocking and Logistics invoice verification
                    <Owner-SAP-WUG at MITVM
                    A.MIT.EDU>
 
 
                    11.06.2002 13:17
                    Please respond to
                    "SAP Workflow Users'
                    Group"
 
 
 
 
 
 
Hi
 
If using MIRO, could you have all invoices blocked with a 'Workflow block',
which could only be unblocked from within the workflow, automatically, if
there was a valid GRN, otherwise send it on to person responsible. I know
you can set up the workflow block in SPRO under FI, not sure if it applies
within LIV.
 
John
 
 
 
                    Kjetil
                    Kilhavn              To:     SAP-WUG at MITVMA.MIT.EDU
                    <KJETILK             cc:
                    @statoil.com>        Subject:     46C Payment blocking
and Logistics invoice verification
                    Sent by: SAP
                    Workflow
                    <Owner-SAP-WU
                    G
 
 
                    11/06/2002
                    08:04
                    Please
                    respond to
                    SAP Workflow
                    Users' Group
 
 
 
 
 
 
I was about to send a long message when I remembered to check the archive
first (very useful), so you won't have to read an even longer sad story :-)
Since then I have come further, and for FI invoices our Statoil-specific
solution is now probably going to be OK. However, LIV has been a problem
for many a developer it seems - and now it is my turn.
 
It is a requirement here that all invoices that are without reference to
purchase orders and which exceeds certain amounts (depends on company code)
should be blocked for payment until they have been approved by a person
responsible for the cost object they are assigned to.
 
My problem is that registration of invoices is performed both via FI (FB60)
and MM (MIRO) - the latter of which is the problem. As mentioned the FI
invoices are now probably going to be OK. Setting up (through the
Customizing / Implementation Guide (SPRO)) a payment block for LIV
documents was not to difficult either. There are two problems remaining.
 
1) No event for amount blocks
When registering an invoice in MIRO which ends up as blocked due to the
amount limit there is no event.
There are two events defined on BUS2081 - and they are for price and
quantity differences. There is no separate event for amount blocks. When a
LIV document is blocked due to price differences the corresponding event is
triggered.
 
2) The payment block code in the FI document is not the same as for an FI
invoice blocked automatically
While the FI documents get payment block code A (which has been set as Not
changeable), the follow-on document to a LIV invoice gets payment block
code R (Invoice Verification). I can't find a reference to this code in
customizing, and this means the block can be released manually (since only
one code can be Not changeable).
 
Does anyone have any experience with payment blocking due to amounts?
 
I suspect an object extension is what I have to do - we already have a
ZBUS2081, so I will just continue enhancing that.
The plan (unless someone has a solution which avoids extending the object)
is to define an event for amount blocks, a use the ReleaseSingle method to
release the block when approval has taken place and have a second step in
the workflow which releases the block on the corresponding FI document.
--
Kjetil Kilhavn
 
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.
 
 
 
 
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.