Hi 

I face the same issue. My invoice gets the info automatically blocked. I am also searching for a solution.

Best Regards

Sophal

Hi

We are facing the same problem with the same setup. Unfortunately this causes unnecessary extra effort on a daily basis. Any help is highly appreciated.

Regards,

Lukas

In Apps 10 some improvements were made in the area of invoice and PO matching and it’s caused some differences in the way it works.

What inventory valuation method are you using and what is the setting for invoice value consideration? Be

And, I assume you have tolerance enabled for your suppliers?

If “Automatic Tolerance Posting Blocked” is “Yes”, this is an indication that they automatic tolerance posting could not be done. This checkbox is visible in Posting Information section. According to help:

Automatic Tolerance Posting Blocked

This check box automatically appears selected if automatic tolerance posting is blocked for the posting proposal. Automatic tolerance posting is blocked when the value entered in the Supplier Invoice Consideration field in the Inventory Part window is Transaction Based or Periodic Weighted Average.

Hi Rituma

If you change the Invoice Consideration to Ignore Invoice Price then it works for me, but i dont know why i shouldnt work for the other Transaktion wether it is a bug or the way it is designed. Maybe you have a deeper explanation for this.

BR

Sophal

Hi Rituma

Thank you for your quick response. Also thank you Sophal for testing & confirming that it works, when using “Ignore Invoice Price”. 

But how can we achieve the same result in our case, where we want to consider the invoice price. We have the following setup:

Intention is to have the weighted average considering the PO and the invoice price (therefore Supplier Invoice Consideration = “Transaction Based”). Some tolerance should be automatically approved (up to 50 CHF or 5% difference).

Reason for that is that the delivery fees might vary by a little. When there are small differences we don’t want to reapprove it but post it directly to the inventory.

Best regards,

Lukas

Hello,

In the thread:

Linda Johanson has explained:

One important aspect here is that if you use header or receipt level as matching level we do not include the tolerance in any matched line. We instead create a new posting line without connection to purchase order. In bug correction 60793 we stopped the tolerance posting to be created because I think when using transaction based the actual matched line needs to be updated. But when using header or receipt level we cannot know which matched line that actually should hold the tolerance and therefore we create a separate tolerance line. When using line level matching the tolerance is added to the matched part line.

From a system point of view, you could have 100 PO lines , each with a different part and the same settings but relating to the same invoice. If the tolerance is 10 pence, there is no way for IFS to distribute the 10 pence across 100 lines, hence system doesn’t know where to put this and we have to interfere manually, and manual interference causes re-approvals. 

The additional complexity is to use invoice consideration for weighted average costed parts because there, again, can be a lot of parts already in stock, all of which get revalued with the changes in invoiced price. Depending on your stock levels, this might result in hundreds or thousands of transactions. Hence we tend to advice against invoice consideration for  average costing methods (unless it’s average per lot batch or e.g. cost per serial). 

The options that I can see (without changing the supplier invoice consideration settings) are:

1. a configuration to create a background job which automatically authorises such scenario
2. for lines that should not update the inventory value, we can create an authorisation rule which can be approved by the AP team (based on amount / code string combinations). 

Hi

I have done some further investigation about the behavior of the IFS System. Main Goal is to match the Invoice Line with the PO Lines automatically when there are Price Differences per Line. 

First I have created an XML File which is based on Line and Part (see attached xml File). Some of the line contains Price differences. I wanted to see if the system is capable of matching those lines with difference when a tolerance is defined on company

I set then the Supplier PO Matching Level to PO Line

the Result is after importing the XML File the system never match the line automatically. It doesnt matter what you set on the inventory part

So I changed Back to Matching Level to PO header and expected now that the system matches the lines . I mean i imported the File with the inventory parts. It also doesnt matter what you setup in the inventory part. The system will never match the Lines by lines automatically in case of price differences. When you set the Supplier invoice consideration to Ignore Invoice Price, the posting lines will be matched automatically but the price difference from Invoice to PO will be balanced with a seperate posting line and not as expected in the invoiced line.

My conclusion IFS Application is not capable to match the Invoice Lines automatically in case of a price Difference. Even the XML File are defined line by line.

Maybe I have created the xml file wrongly, maybe somebody has another solution how the matching is done when differences occurs?

Best Regards

Sophal

Hi Sophal,

does the part number in the xml match with the part number or the suppliers part number in IFS?

Regards

Ralph

Hi Ralph 

I tried it with both tags which are available. That was also my first tought, that the part doesnt match with the inventory part or purchase part. I modified the xml file for the first test with “articleidentifier” then i changed to “BuyerArticleidentifier”. Both didnt work with automatic matching in case of price differences.

Best Regards

Sophal

Hi,

As the tolerance is usually a very less amount, from a business perspective it doesn't matter if the inventory is not updated. Perhaps IFS should think about re-enabling this functionality.

This has become one of a big issue for a customer that almost every invoice should be re approved.