Answered

WF - vendor Invoice approvals for discrepancies on partial invoicing. Unmatched variance dragging!!!

(0) Share

Report

Posted on by Veronika Filonenko

1,255

My case scenario is have a vendor invoice workflow direct discrepancies to be approved by users if over or under tolerance threshold.

We use a total invoice matching workflow not the line one.

The following business scenario which is very typical:

PO of 300 units @ 0.33$ Expected total invoice amount 99$

Receiving 1 290 units @ 0.50$ = 145 $ vs expected 95.7$ = Discrepancy of 145-99 = 46$ to be approved. Approved through workflow.

Receiving 2 10 units @ 0.33$ = 3.30 $ vs expected 3.30$ = Discrepancy of 0$ BUT 49.3 appears to be unapproved on the total invoice.

The problem is that, that second partial and final invoice has no discrepancies on it, but it dragged the total discrepancy of the first partial invoice.

Which I do understand from the system perspective, but from the user perspective its cumbersome. Because the approver has already approved 1st invoice with the 46 $ discrepancy. At the 2nd invoice, the system throws the invoice in the WF to be approved again based on the amounts from previous invoices. So for the approver who receives the item to be validated, it is not very clear because it is past dragging up until the very end. Plus the discrepancies were already approved at each time they happened.

Basically, I would like to know if there is a combination of parameters that would allow the 2nd invoice to not be stop for additional approval?

2437.18734.1.jpg

6622.51437.2.jpg

4442.3666.a.jpg

7367.8446.4.jpg

Categories:

Financial Management

All responses (5)

Answers (1)

Suggested answer

Veronika Filonenko 1,255 on at

Like (0)

Report

RE: WF - vendor Invoice approvals for discrepancies on partial invoicing. Unmatched variance dragging!!!

After playing around with different parameters, I came to understand the logic and the workflow itself and WF condition is very important in my scenario.

There are 2 conditions in the WF for vendor invoice.

Invoice matching successful --- considers any discrepancy (unit, price, total) as a fail, so as soon as there is 1 thing that fails in you partial receiving/invoicing - the status of the invoice header will be failed for all invoices of the same PO. This was my case.

Invoice totals matching successful ----- + Invoice total matching set to 'No', it will ignore all discrepancies. Because the WF condition is looking for that parameter to value threshold allowed, and because it is set to no, it lets pass through the discrepancy.

In the end, it's either failing everything, or it lets pass everything. Works as designed. We would need either to review the whole logic of the process and configuration which is a big change considering number of entities involved or for now stay as is.

Voilà.
Veronika Filonenko 1,255 on at

Like (0)

Report

RE: WF - vendor Invoice approvals for discrepancies on partial invoicing. Unmatched variance dragging!!!

Hi Ludwig,

We do only 2 way matching for proc categories, so no receiving. I adjust the price directly on the line of the invoice, like it would be done for any other invoice received with a different price than ordered on the PO. That is why we have the WF that goes back to the buyer to validate the discrepancy.

For all other screen shots that you added, my results are the same. Second failed -- 49.3$ and. And yes my WF is based on a)

a) Invoice matching successful

b) Invoice total matching successful

and these 2 option quite frankly behave the same way.

I would say the problem is in the WF because, the status on the header of the Invoice at the end, is Failed. So it doesn't really look any where else, it stops there.

I have opened a support case with MS. I will let you know if they'll give me any direction.

thanks
Verified answer

Ludwig Reinhard Microsoft Employee on at

Like (0)

Report

RE: WF - vendor Invoice approvals for discrepancies on partial invoicing. Unmatched variance dragging!!!

Hello Veronika,

I tried to take a look at this issue in my demo machine and have the following questions:

1. You mentioned above that you receive first 290 pcs for $0.5. How did you make this price adjustment when posting the product receipt? In my system this works only if I change the price in the PO and reconfirm it.

2. I do not have a workflow configured but did not have to approve the second invoice separately

My parameter settings are the following:

The first invoice shows a matching failure at the header level

So does the second one

This is, however, the totals match. As I do not have the totals match enabled, I could post the second invoice without problem.

Here is the review form that shows that there is no problem with the lines

Summary:

I think the totals match is not going to work in this case as you will always receive errors - as you mentioned.

I am not sure if your workflow criteria is correct because it seems to look for the total match status only, which was 2x failed in my case.

Can you identify a similar matching criteria condition for the line level match?

This should change the outcome.

Best regards,

Ludwig
Veronika Filonenko 1,255 on at

Like (0)

Report

RE: WF - vendor Invoice approvals for discrepancies on partial invoicing. Unmatched variance dragging!!!

Hi Ludwig,

The whole point here is exactly that. We do not want the system to validate totals, that is why we unchecked the parameter for 'Invoice total matching'.

But it still validates the total of the invoice.

All other parameters in Price and quantity have been tested not should not have an impact on the Invoice total. Which we unchecked, but it looks like it does not read it.
Suggested answer

Ludwig Reinhard Microsoft Employee on at

Like (0)

Report

RE: WF - vendor Invoice approvals for discrepancies on partial invoicing. Unmatched variance dragging!!!

Hi,

Habe you tried changing the parameters to only check for variances that are greater? Your setup says greater or smaller.

Another thing to think about is whether the totals matching is right for your company. Especially when you have multiple partial deliveries then you will always get this kind f error that the total doesn't match.

Best regards

Ludwig