Able to manage and resolved internally.

Hi, are you able to provide some info about how you managed to resolve it? Our finance team have also noticed the new reposting and its making life pretty hard, filling the GL with literal thousands of lines...

This will only happen if you use WIP handling on the work tasks. I’m guessing you have setup Task Cost Codes with at least one used as WIP code? 

Hi @anmise we don’t seem to have any WTCC’s. Also seem to have no WIP vouchers in the system either.

We do have someone looking at it I think, but its been an ongoing issue for a little bit without any answers yet.

Hi @anmise we don’t seem to have any WTCC’s. Also seem to have no WIP vouchers in the system either.

We do have someone looking at it I think, but its been an ongoing issue for a little bit without any answers yet.

Is that your only company? What did you then mean that finance has raised as an issue?

From help:

 

Transfer work task transactions with transaction type; and transaction status: Reposted or Overtake.

• Work task transactions of type Reposting is a result of a transactions which has been reposted and requires to be transferred to finance.
• Work task transactions of type Overtake is a result of a work task transaction which has been created and where the original posting has been reversed and overtaken by a work task posting type. This is used for postings which hasn't a work task specific posting type for its orginal transaction. A work task transaction that has been overtaken is required to be transferred to finance.

Can we eliminate this reposting functionality my removing Task Cost Codes with WIP codes?

@MKG019 Could you kindly explain the new functionality of -re posting in Maintenance module in work task  ? Because, I am searching an account for map TP3 and the business scenario is not clear for me . Please help .

Thanks in advance

We have got the same issue, IFSAPP10, upd10. Many lines reposted, but there was no change in the preposting of those worktasks. Anyone find out how this is caused meanwhile?

@SNBLAVA ,

Hi, After Analysis Following are observation found. As per the functionality in IFS Apps 10, when the No Part lines/Non Inventory parts are purchased and received from the work order requisition, then a work task posting lines with Transaction status Not applicable will be triggered with No posting type. Parallelly a Purchase transaction posting type M91 and M92 is triggered. Once the Supplier invoice is matched against that PO and made it to posted status, then the work task transaction which was Not applicable will be Overtaken. This means the Posting type M93 which was created during matching of PO in manual supplier invoice is being overtaken by Work task posting type TP3. So ideally posting type TP3 needs to be setup for Non inventory purchases from work task.

@XitThejaG:

This works perfectly if the Work Order and Work Task are still open, but not if they have been closed and have the “Finally Posted” tickbox ticked. We often invoice the Work Order to the customer (and then close down the Work Order) before the Supplier Invoice is received. This results in the “Finally Posted” tickbox being ticked on the Work Task Transaction, which means that there is no TP3 Posting that takes place.

Is this something you have come across before/are you able to offer any advice please?

@SNBLAVA  - Have you found a resolution to this? We had 2k transactions show up yesterday in error status to be reposted and we don’t know why the system is trying to repost them. They are all expenses and not purchases. We did make some account number changes at the beginning of our last fiscal year but all of the WO’s they are from are all closed and have been for some time. We don’t understand why the system is continually trying to repost these items. Some of them have been reposted 100+ times, sometimes multiple times at the same time. It’s all very weird. 

@SaraCrank , our issue is still under investigation at IFS. We really don’t know what triggers the creation of so many (useless) transactions. Because nothing changed in the preposting of those GL transactions and also debit/credit amount is zero. So we are very patiently awaiting the outcome. When we know more about this I definitely share this with you off course. But i also would like to recommend you to prepare a case to IFS for this. Best regards Lars

@SNBLAVA - I did create a case. Nothing is changing on our end either. Our have a value in the debit/credit but it all nets out to zero, so we aren’t sure why it’s happening either. When I get a response from IFS, I’ll let you know. Have a great week!

Hi Sara, I was curious...did you got feedback from IFS yet about this issue?

@SNBLAVA - We couldn’t re-create the issue on demand in our non-prod environments so IFS closed the case. I’ve been trying to work out how to manually close the work task transactions but I always get a pop-up saying the conditions to be finally closed haven’t been met but I can’t figure out which condition hasn’t been met. 

Hello,

Has anyone found a fix for this issue? We are getting the same errors.

Hi Jocelyn

Unfortunately we never get a satisfying answer to this problem.

Best regards

Lars