Invoices related to future date should not consume actual year budget

[Former Member]

Dear Experts,

could you please help me regarding the following question:

Invoices related to purchase order (PO) items with competence date in the future has to consume the budget of the year of the PO competence date and not on the year of the invoice posting date.

For example PO 1

item 1 competence date 31.12.2009 value 100

item 2 competence date 31.12.2010 value 200

Invoice posted on 31.05.2009

for PO 1 item 10 value 100 and

PO 1 item 20 value 200

The budget has to be reduced for item 1 in 2009 and for item 2 in 2010.

When posting the invoice on 31.05.2009 there is no budget available for 2010. The budget for item 2 should only be saved on a commited budget for 2010 and not be checked for available budget.

We are using update profile 300 and marked payment budget as not active for availability control.

Do you have any idea how to solve this business requirement?

Thanks a lot for your help!!

Regards,

Thomas

[mar_novalbos]

Hello Thomas

Have you considered the possibility to set up 'Due date' as FM Update date for Invoices? (i.e. value type 54 in your update profile)

And for invoice reversals, you can also implement a badi if you want to use due date as well (see note 968469)

I think this might suit you

Kind regards

Mar

[Former Member]

Hello Mar,

thanks for your help!

I think it is a good idea to select a different FM update date for invoices.

One further question:

In this case do you think we will also solve the following issue?

"When posting the invoice on 31.05.2009 there is no budget available for 2010. The budget for item 2 should only be saved on a commited budget for 2010 and not be checked for available budget."

Will AVC check for available budget in 2010 or won't it check?

Thanks & Regards,

Thomas

[mar_novalbos]

Hi Tomas

Normally, the invoice will reduce the PO and if the PO amount is lower, AVC will be called too. Of course AVC will behave depending on your settings...

So, first question is: will you be able to post a PO in 2010 without any budget? is it allowed in your organization..?

cheers

Mar

[Former Member]

Hi Mar, yes in our organization it is really allowed in this case (but we are not a Public Sector customer - a Finance customer - but still using PSM-FM ... kind of a rare situation )

I found out, it is possible by defining filter settings for actual/commited values (excluding Invoice from 2010 on).

Anyway I tried out your solution, overriding the update profile:

By changing the commited budget (which is the budget we use), the system throws warning message "FI164 - The update date in the commmitment budget differs from the standard".

As it is just a warning message I anyway saved. But now it is not possible to save an invoice with delivery date in next year anymore, as the system throws the error message "FI 009 - The update profile (DATE) is inconsistent".

Do we need any further changes or do you think it is not possible to use FM this way? Thanks so much for your help!!!

Regards,

Thomas

[mar_novalbos]

Hi Thomas,

Sorry, I have more questions for you:

-'filter settings for actual/commited values (excluding Invoice from 2010 on)'. if you exclude your invoice now, you should think about what will happen when 2010 comes. should/should not FM be updated?

- And now, concerning to those warnings and errors, I would like to know this:

• Settings in OF36: Which value types did you override?. I presume you are still using profile 00300, right?

• are you testing with brand new documents posted after the update profile change, or are you using an "old PO" and trying to post a "new Invoice"?

• Current release and support package

(I hope you are testing all of these changes in a development system )

Kind regards

Mar

[Former Member]

Hi Mar,

regarding the -'filter settings for actual/commited values (excluding Invoice from 2010 on)':

In 2010 FM should be updated. To be honest, I do not know for sure how it works (I am quite new to FM and the deputy of our FM main consultant who is currently on vacation), but we are using this also for purchase requisitions and purchase orders. The problem in our organization is, that there are no budgets for the next years available, but it should anyway be possible to order things for next year.

regarding the warnings and errors:

- we still use profil 0300

- I override value type 54 (Invoice) - Commited Budget -> Delivery Date

(we deactivated payment budget ledger, so there is no need to change Payment Budget)

- The value types 50 and 51 (PR and PO) use already using Delivery Date in our system (I am not sure if this standard in profile 0300 or if we overrided it)

- in this case I tested with an old PO and created an invoice with TA MIRO.

- we use EA-PS 600, Support - Package Level 0012

Thanks a lot!!

Thomas

[mar_novalbos]

Hi again

Well, I would focus on adjusting the update profile rather than using filters for commitments/actuals. You might refer to the documentation in the corresponding IMG activity :

"Requirements

As far as possible, exclude only the value types that are at the start of a commitment chain (for example, purchase requisitions, funds reservations, purchase orders and so on), but not cash-relevant value types, such as invoices or payments.

When excluding a given value type, you must also exclude all other value types of earlier steps in the commitment chain. Example: If you exclude funds precommitments, then you must at least exclude funds reservations, too.

Note that you must set the GR/IR update indicator for the value MM invoice receipt in the Customizing settings of your FM update profile (transaction OFUP), if you exclude value type 60 (parked documents), but not value type 54 (invoices)."

Update profile 300:

- Value type 54 (Invoices) should be better customized using 'Due date' (this is normally calculated based on payment terms)

- If you tested a new invoice with an old PO, it is very probable that you have inconsistencies, so errors may appear. If you are in a development system, I think you could leave it like that and prepare a completely new document chain to test the profile changes.

You can also reconstruct existing old values by using the tools provided in note 189761

good luck

Mar