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

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.

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..

@Thommy 

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

Kind regards

Jonas Jäthing

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

@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? 

Thanks @ttzeleznik!

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

R&D must re-think I believe.

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 
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:

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.

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.

@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

@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.