Error in commitment fund date from a payment request

[Former Member]

Hello,

When we try to post a payment request from a funds commitment position that has been added to the fund commitment in a date later than the posting date of the payment request, we receive an error message FI_E050.

In our example the message FI_E050 is "Posting date/period 20.04.2009/004 is earlier than existing date/period 07.07.2009/007".

The posting date of the payment request is 20.04.2009, the posting date of the funds commitment is 02.01.2009 and the creation date of the position of the funds commitment is 07.07.2009.

We found the same issue for a modification of a commitment position and we solve it in SPRO as told by SAP OSS but now we have found the same error in an added position.

Anyone has found this issue?

Thank you very much in advance.

Kind regards

[mar_novalbos]

Hello Maria Blanca,

It looks like PBET is (or has been active before?) in certain value types. PBET means that all FM updates will be chronological: i.e. an earmarked funds cannot be reduced in a date earlier than the latest update date of the earmarked funds.

Can you check your update profile settings and see also if you have any overrides to update profile in OF36?

If PBET is active either at update profile or at value type level, then you should not post the request in a posting date earlier than 07.07.2009.

There is more information in the help.sap.com:

[http://help.sap.com/saphelp_erp60_sp/helpdata/en/f0/ca5716260211d28a430000e829fbbd/frameset.htm]

See 'Recording Actual and Commitment Data -> Period-Based Encumbrance Tracking ' (which is PBET)

Hope this helps

Kind regards,

Mar

[Former Member]

Hello Mar,

Thank you for your answer.

I have looked at PBET and now it is active only for commitment items (value type 65). But these problems happens between a reservation fund and a precommitment which do not have PBET active. Actually, PBET is active for commitments because it solves the problem for the modification of a precommitment item but it seems not to solve the problem for the creation of a new line.

Do you know if it could be a OSS error?

Thank you in advance.

[mar_novalbos]

Hi,

Sorry, I am a bit confused now:

You previously mentioned error happens with a payment request from a funds commitment (i.e. value type 65) and PBET is active, hence FI_E050 is justified

and now, you refer to Funds reservations and Funds precommitments whitouth PBET. But do you get FI_E050 too? Do you know if PBET has ever been active in these value types?

and I'm sorry too because I don't get this statement:

"Actually, PBET is active for commitments because it solves the problem for the modification of a precommitment item but it seems not to solve the problem for the creation of a new line."

Does this mean that PBET is active on value type 65 but not in 82? When exactly do you get the error: when adding a new line to the Funds commitment or to the Pre-commitment?

further: which update profile are you using? You can check it with report RFFMMONI.

and please note that activating/deactivating PBET may lead to inconsistencies and therefore changes must be analyzed and tested very thoroughly!

Please let us know

Kind regards

Mar

[Former Member]

Hello Mar,

I will try to explain it better. Sorry for the inconvenience.

The FM update profile is 000359.

PB: Annual-Based Encumbrance Trkg is marked.

CB: Period-Based Encumbrance Tracking is marked.

Then, we have the value type 65 with this values:

Payment Budget X

Commitment Budget X

Year-Dependent Control Between Pa

Payment budget reduced X

Commitment budget reduced X

Payment Budget Date, Fiscal Year B

CB Date, Fiscal Year B

PB Date, Approval Year F

CB Date, Approval Year F

CCN logic payment budget

CCN logic, commitment budget

PB: Period-Based Encumbrance Trac X

CB: Period-Based Encumbrance Trac X

Budget assigned X

Revenue/expenditure control

PB: Annual-Based Encumbrance Trkg

CB: Annual-Based Encumbrance Trac

Approved Amounts in Payment Budge

Approved Amounts in Commitment Bu X

Rest of the values has not been updated with a profile value type dependency.

After your answer, I have made a test between a funds reservation and a funds precommitment to ensure that the error was made because of the activation of PBET. Then I get that if I add a position to the funds reservation and I use this position in a funds precommitment, I get FI_E050 too. I use the same dates that you can find in the first post.

On the other hand CB Period-Based Encumbrance Tracking is active for value type 80, 81, 82 and 83 (and 65). I suppose this is active because of the profile.

Please, if you need more info I can send you and image of the RFFMMONI.

Thank you very much in advance.

Kind regards

[mar_novalbos]

Hello Blanca,

Ok, now I got it, sorry I did not fully understand the question before

PBET logic works as follows, imagine this example:

Post a Funds reservation with posting date 01.04.2009 -> FM update date is 01.04.2009

Change the Funds reservation today (FM relevant changes such as amount changes or adding new items)-> a new record in FM is posted today (period 07)

If you now try to post a Funds pre-commitment against the Funds reservation, with Posting date 01.05.2009, expected FM posting date of this Funds pre-commitment should be 01.05.2009 (i.e. posting date) but the Funds reservation should be reduced as well. Since the reduction is to be posted at 01.05.2009 but the latest change occurred at period 07, reduction is not possible because it's not chronological. Then, you will get FI_E050

As per the online help:

Period-based encumbrance tracking enables you to map a change history of commitment documents during the course of a fiscal year in Funds Management. This means that document and account assignment changes are entered in commitment as individual documents in period-based encumbrance tracking and do not result in original document data being overwritten. The data records generated in commitments are logged as amount type Change together with the corresponding change date.

finally, concerning to PBET activation, I presume it's active in your profile also due to Budgetary Ledger Integration.

Hope this will help you

Kind regards

Mar

[Former Member]

Hello Mar,

Thank you for your answer.

Do you know how we can modify import of a document and then use this document as the reference for another one (like the examples reservation fund with pre-commitmet or commitment in a payment order) ? Is it only possible with a value adjustment to the document?

Finally, CBET active is the same than PBET active. Because for reservations it does not seem PBET to be active.

Thank you very much for all your help.

Kind regards

[mar_novalbos]

Hi

Ability to change the amounts in a funds reservation will depend on flag 'Value adjustment required' at item level. This flag can be set either manually or by other means like defining this field as mandatory, or flagging it via Workflow method...

So, if this flag is set, you can only change the amounts through a Value adjustment, otherwise you could make the change manually.

About CBET, what does CBET mean?

as far as I know, profile can be either 'Period Based Encumbrance Tracking' (PBET) or 'Annual-based encumbrance tracking', but I don't know what CBET means in your case....

(don't be confused with texts in RFFMMONI: PB is 'Payment Budget' and CB is 'Commitment Budget')

Probably RFFMMONI is showing Funds Reservations are updating CB (commitment budget) + either

'Period-Based Encumbrance Tracking' or 'Annual-Based Encumbrance Tracking'

I think this can help you

regards

Mar

[Former Member]

Hello Mar,

Thank your very much. Now, I am getting a clearer idea of this issue.

What I meant with "making an adjustment" was in the situation that you make a modification to a reservation in a date after the date of the precommitment and you use the reservation in the precommitment. Now I am getting the FI_050 error so I suppose that the only way to make the modification to the reservation is to make a reservarion adjustment with the date of the precommitment and then use the reservation in the precommitment. Is it correct?

Just let me ask some questions. I need Period Based Encumbrance Tracking if I want to have the LM updated? Do you know in which cases is Annual Period used?

Thank you very much for all your answers.

Kind regards

[mar_novalbos]

Sorry Blanca, I have lost the track

are your settings consistent for both value types: 81 Funds reservations and 82 Funds pre-commitments?

You may have problems with document chains if PBET is active for some value types only....

Decission to activate PBET is normally made by customers, depending on how they want to update FM and have a trace of the change history in Funds commitments/actuals. Please read the online help about PBET versus ABET to see how FM gets updated

If you want to use Budgetary Ledger, it should be activated additionally. PBET should be active if you want to work on a period basis

There is some documentation here:

[http://help.sap.com/saphelp_erp60_sp/helpdata/EN/fc/66163f9959a808e10000000a114084/content.htm]

cheers

Mar

[Former Member]

Hello Mar,

The active types are equal for values 80, 81, 82, 83(Commitment Period) and 65 (Payment Period).

What I have tried now is that if I modify a position, I have no error. But if I add a new position, the error appears. Is that logical? PBET is active for all kind of documents and the error only appears if I add a new position to the document and I use this line.

Sorry for all these questions but I do not see which is the difference between making a modification to the position and adding a new position (modification dates in the system are the same in both cases).

Thank you very much in advance.

Kind regards

[mar_novalbos]

Hello Maria Blanca,

I suggest you to send an OSS message (use component PSM-FM-UP ) to have SAP checking your issue. otherwise this thread is going to be confusing.

Then we will update this thread with our findings, Ok?

thanks!

Regards,

Mar

[Former Member]

Hello Mar,

A note OSS was the first action we made. The answer was what you are telling us (PBET active) and that it was better to solve the issue in this forum (what we are doing now) because it is not an OSS issue.

Anyway, we are going to make a note OSS explaining that case. When we have answers we will publish it in that thread.

Thank you very much for your answers!

Kind regards