Hi ttzeleznik,

In application 10 standard functionality, pre-postings can be entered at any state as desired by the user. If the mandatory pre-postings are not entered by the time task change to its last state, it is validated and informed to enter the pre-postings at least at that stage. i.e: when trying to finish the work task it will raise an error.

Once the code parts are entered, those will get inherited to the already created transactions upon updating the accountings/creating vouchers.

Hope this helps.

Best Regards,

Yasanthi

@Yasanthi Gunawardena  @Nethmini Kosvinna

Thanks but I’m going to enter a BUG case.  Mandatory Preposting should work the same as the WO, Customer Ord., etc,  i.e., Release is not allowed until Preposting is entered.  Further testing shows at the WO level, the WO cannot be release until Mandatory Preposting is entered.  The same for Customer Ord.s etc, … Release is not allowed until Preposting entered  

Will update post when Case is addressed  Thanks

We have the same issue. And I have even more information, once you have entered the mandatory codeparts they can be deleted without any warning message.

@JJäthing this directly relates to the answer from Yasanthi Gunawardena.

The control of mandatory prepostings is done when finishing the Work Task. The reposting functionality will be used to update any transactions made on the Work Task (both when adding and removing code parts in preposting). So you can alter the code parts (and even removing mandatory ones) all the way up to finishing the Work Task. 

But in our case that does not seem true, the transactions can be transferred to Finance without the mandatory preposting. If the preposting is mandatory it should not be possible to skip it in any way. Change, perhaps, but not delete.

Or do you mean all the transactions where the prepostings are missing will be reposted when the work task is closed? That would definitely be a grave design error as it would corrupt all financial work task analyses..

The reposting (introduced in App10) will not corrupt the financial work task analyses.

If the transactions has been transferred to Finance the reposting will create counter bookings for the original transaction posting and new ones for the current posting information.

Please refer to the release documentation for App10 regarding the new transaction handling for Work Task (including the new reporting functionality) to get a deeper knowledge in this area.

@Thommy 

Would you by any chance know in which of the 16 updates this is described?

Kind regards

Jonas Jäthing

It is in the RTM release.

Here is a link to some useful information (I hope the link works, if not please let me know):

IFS Applications 10 - Webcasts, Presentations and Scripts - All Documents (sharepoint.com)

Thanks Thommy, but id din’t work: “We're sorry, but jathing_jja@floatel.se can't be found in the ifs.sharepoint.com directory. Please try again later, while we try to automatically fix this for you.”

I have the FinancialsNewsApp10RTM.pptx but this issue is not in there.

/Jonas

I also have the ‘IFS Applications 10 Release Notes - Update 16.pdf’ where there are many work task entries but I could not identify any of them being about this issue with mandatory preposting.

/Jonas

@JJäthing :

As mentioned above - here’s an update from my (bug) case:

If the posting type T57 (Pre Accounting Work Task) is set to control type C58 (Mandatory Pre Posting) Work Task can be released without entering Pre Posting. System is asking Pre Posting when Work Task is set to Finished status. This makes sense since the functionality with Work Task is to allow changes in Object ID and Pre Posting until Work Task is finished. Thus pre posing will be altered when object changed as well. The transactions will be updated with new pre-postings through the reposting functionality. Therefore, we don't think we should restrict to have mandatory pre-posting before WT is released.

However, the same behavior should be aligned with WO as well. Thus we will need to do a correction for the WO, where the system will allow to release the WO, but not to finish until pre-posting is updated.

In other words, our conclusion is the behavior with WT is accepted and similar behavior should be applied for the WO.   Thanks & Best Regards,  IFS Global Support

My initial thoughts - have yet to respond to my case:

1. “correction for the WO” - After 15 yr’s of pre-posting logic on the WO, IFS is going to fix it?   What will the user base think about that?   Which UPD will this be in?
2. Current state, if pre posting is mandatory and has no entry - approving preliminary invoice fails!  (however, time, material, etc. flow to GL just fine)
3. What is the harm making this mandatory for Release of WT?  Making mandatory from the beginning does not interfere with change flexibility nor will it cause an error - indeed it avoids errors and hard stops.
4. According to another Com. post, reposting keeps the dates from the original and that period may be closed by time of repost.
5. We do not want to add steps for processing WT if possible (reposting).
6. What I haven’t looked at yet - will the re-posting function catch ALL invoices?

Again to emphasize; What’s the harm making this mandatory for Release of WT? 

Strange, I thought this was public release information.

Are you able to reach a site where the IFS release informtion is shared?

If so then you need to look at the RTM documentation (this reposting functionality isn’t part of any update, but delivered in App10 RTM).

If you still have problem finding it or reaching the linked location please reach out and I can send you over some of the documentation directly.

Thanks @ttzeleznik!

Period end is relevant, as is what happens at year close?

R&D must re-think I believe.

@Thommy , @JJäthing 

Please refer to the release documentation for App10 regarding the new transaction handling for Work Task (including the new reporting functionality) to get a deeper knowledge in this area.

Thommy - can you be more specific on where this information can be found?  Somewhere in F1 help where any IFS user can access?  With such a significant change in this IFS Module, it would seem quite the important to have this easily accessible to users.  The closest I could find is attached but there doesn’t seem to be any “deep knowledge”.

Hi,

I will try to explain the underlying thinking on the change of pre-posting control based on the introduction of reposting in App10.

Pre App10 the Work Order was the planning and executing entity and any pre-posting was handled on the Work Order.

Due to the fact that no change on postings was possible pre App10, when using mandatory pre-posting you were forced to have a pre-posting set on the Work Order at the time of release (since after releasing you are allowed to enter transactions).

With the introduction of reposting the need of not allowing any transactions without having a mandatory pre-posting set is redundant. The gate is instead moved to the point where the reposting will stop = setting the Work Task to Finished. Before that point any information that might lead to a change of postings is allowed (for example changing the Object on the Work Task, which in turn might change the pre-posting), and such a change will be handled and evaluated by the reposting functionality (what would the postings on the work task transactions look like if the transaction was made now – with the current information on the work task?).

I hope this gives a bit of an insight of the reasoning of the move of mandatory pre-posting control gate.

More information around reposting can be found in the online help, e.g. https://docs.ifs.com/ifsclouddocs/21r1/default.htm?openpage=https://docs.ifs.com/ifsclouddocs/21r1/WorkTaskManagement/AboutRepostingWorkTaskTransactions.htm

@JJäthing - I have checked and you as a partner should be able to reach IFS Applications 10 - Webcasts, Presentations and Scripts - All Documents (sharepoint.com). Perhaps you need to be logged in with your partner credentials.

@Thommy Thanks Thommy! I will look up the links you have presented.As I agree with the basic logic I am concerned about period end and year end procedures.
/Jonas

@Thommy 
Presentationen kan jag inte se, men jag har sett flera andra tidigare så det kan vara tillfälligt eller så ska det vara en annan länk. Jag återkommer om jag inte hittar presentationen själv.

Felmeddelandet:

Just FYI:

In support we will enable an information message (but not a hard stop) when the Work Task is released stating “Mandatory Pre-Posting is required for Work Task. Please add required Pre-postings” if the Mandatory Pre-Posting is set for the Work Task.

This will be delivered in App10 Update 18 and in the upcoming 23R1 Cloud release.

Hi, This is not specific for the question in this topic but a more general question related to Pre-posting and the posting control.

For functionality in general we try to “Isolate” the majority of the users from the accounting as something that just happened by using posting controls for automatically building the code string according to rules, this also reduces risk for users to select wrong code part values. On work tasks the primary use of Pre-posting is to handle the cost center and Fixed asset object stated on the Equipment.

From my side I see two base cases here when manual pre-posting is needed on work tasks, 1, when the needed accounting info is missing on equipment’s. 2, when there is missing posting rule possibilities for automation or the control data not can be found thru the work task. The first is most a matter of data setup, but the second is much more interesting for me as here we have a good possibility for improvements, so I would really want to learn about the situations when the posting control not is helping out, I hope there is some of you out there that can come up with examples for me.

@Thommy

Please can you let us know how the re-postings are handled when the work task covers a year end and the previous year is closed. I asked my customer how they would react if they were to receive re-postings of previous years work task cost postings into the the new year. They were not happy at the thought of such a set of postings.

The reposting functionality will repost on the latest open period, so if previous year is closed then the reposted postings will be in the new year.

That is the reality of this functionality.

But I’m wondering if we aren’t making this a bigger thing then it is.

To get repostings then something on the Work Task needs to change that would trigger that new postings are needed (e.g. a change of object).

No changes can be made on a Work Task that is closed and a huge majority of the work task started in for example December should have been closed at the time when the previous year is closed.

The majority of the ones not closed wouldn’t be subject to such changes that would effect the postings, don’t you agree.

So there should be a very small (if any) amount of work tasks that would impact and have new postings in current year and not previous closed year.

But if this is seen as a major problem, then work tasks opened I previous years needs to be closed of prior to the year closure or you need to make sure that object, prepostings etc wouldn’t be changed on them after the year closure.

@Thommy 

Thanks for the prompt reply Thommy!

I can see two possible solution scenarios where a task lasts over a year end:

1. Use WIP-postings (I have not investigated WO WIP).
2. Close the task at year end and create a new task in the new year with manual cost postings matching those of the closed task.

Do you agree Thommy?

Sincerely

Jonas

@JJäthing  in IFS Native HELP the Reposting feature is described here.  You just need to fill in your “local leading string”

………./ifsdoc/documentation/en/WorkTaskManagement/AboutRepostingWorkTaskTransactions.htm

Thanks @ttzeleznik!

I missed that when looking last.

/Jonas

@JJäthing 

I agree on using the WIP-postings. Then the cost will be set on the WIP postings (without any interferance of the reposting) until the triggering point of WIP release, which can be the closure of the work task.

I don’t think no 2 will work, if I fully understand what you suggesting (I can be out of my depth here though).

There is no way of just having a posting on a work task, you will need to have a transaction created where the postings is connected to.

So if you close the task and after new year creates a new one, then you will need to create new transactions on the new task and that I don’t think we want to do.

I think the way to achive what you suggest in no 2 would be to manuallt “counter post” the transactions on the tasks that you want to close for the year and then you can move on to create new tasks with tranactions and postings after new year.

But this would be a lot of manual work…

The WIP handling would be the most straight forward handling as I see it.