Any idea ?

Hi @mlowicki 

You shouldn’t need to do more then you have done.

A shot in the dark - are you using WIP cost codes? If so, can you double check that the WIP code has been reversed to the ordinary cost code on all transactions.

The only reason I can think of would be that for some reason one (or many) of the transactions has a WIP cost code (that is the criteria that are checked). 

The accounting cycle is a collective process of identifying, analyzing, and recording the accounting events of a company. It is a standard 8-step process that begins when a transaction occurs and ends with its inclusion in the financial statements.

Hi @mlowicki & @Thommy ,

We are receiving the same error message and are using WIP Cost Codes.  We can confirm that one of the transactions did not have a WIP cost code applied (this was a non-inventory external purchase), yet somehow also ended up finally posted.  We are unable to reverse the finally posted status even after trying an Overring Cost Code. 

Do you have any other suggestions on how to handle this M93 work task transaction that is in an overtaken status AND finally posted?  We would have expected the M93 to create a TP3 during the reposting job now that the status is Overtaken.  

Hi @ssmith_DHP 

I don’t think adding an Override Cost Code will do much in this case.

The strange thing are as you say that you haven’t got any TP3 record created, that is really strange.

What are the status on the Work Task?

I would try to have the Work Task first in like Work Done stage and then use Release WIP to Final Accounts on the rows that have WIP codes on them and then again try to remove Finally Posted.

Still I’m puzzled why you didn’t get a TP3...

Hi all,

Was there ever any resolution to this? We have the exact same issue.

When a Non-Inventory Part is purchased, the preliminary Cost line is added to the Work Order/Work Task. When the Supplier Invoice is received, the M93 posting occurs and is then replaced with the TP3 posting...BUT this only happens if the Work Order is still open when the Supplier Invoice is entered.

In many cases, we have already invoiced the Customer and closed the Work Order - as a result of this (together with the overnight Transfer Reposting Transactions job), the “Finally Posted” tickbox is ticked - this means that when the Supplier Invoice is entered, there is only the M93 posting and no related TP3 Posting. 

We then have the same issue as was originally raised on this thread, that there is an error message when trying to Remove Finally Posted.

The only way to move the M93 posting on to the correct place would be to use a Q-voucher, which is not an acceptable solution.

Any help at all would be much appreciated.

ChrisD - After discussions and research with IFS, we have been told that a fix for the External/Non-Inventory Purchases will be available in Cloud 23R1 or later.  Below is a copy of their response:

Our product development team stated that the correction needs to be totally redesigned and they don’t have much information on this now as it is still in the early stages of the process. It could most probably be that instead using M93 to repost, we may use M92 from the purchase receipt transaction. Then cost code can stamp in the cost line and it will be difficult to decide at this point if we are going to implement a check to control this behavior and in what level the control would be.
 

Hope that helps. In the meantime, we have added a custom validation check that disallows any work tasks to be moved to HISTORY until all external purchase costs have a connected/finally posted Supplier Invoice.  

Hi @ssmith_DHP,

Do you know who has communicated this?

I’m a bit puzzled (again ) since we have fixed this in a support issue a few month back (it works now in App10 and later Cloud releases).

Solution was that the Transfer Work Task Reposting Transactions job would not set the transactions to finally posted if accounting doesn´t exist (which it doesn’t until the supplier invoice has been matched).

@Thommy That response was received directly from IFS Customer Support Group as we were advised to create a case for this issue.  Do you know which Apps10 Update the issue/fix was deployed on?  

@ssmith_DHP  This is fixed in APP10 UPD16