Hello

Maybe check the real data...
if there are 12,000 hours of information, they are surely there.

There is a difference between what you fill in on the tickets and on the activity.
For a planning activity, where the tickets are linked to an activity, the actual workload indicated on the activity takes into account the workload of the activity AND ALL the tickets attached. The load displayed therefore does not necessarily correspond to all of your tickets.

Of course I have checked all tickets. That s why I attached screenshots. The real time is 3 hours but in the assignments section its shows that the person had been working for 12949.7 hours. Moreover, overall hours for the project are increased for that amount

HI,

Are you really sure that no one had filled workload on this activity into the past regardless tickets ?

Of course, I checked all the tickets.

I didn't say to check the tickets. I said to check the real data... so the imputations.

That's why I have attached screenshots.

And your captures are useless since we cannot make the link between the real which is indicated for the activity and what was informed on a ticket... reread what I explain above. They are not the same data...

The actual time is 3 hours but in the assignments section it shows that the person worked for 12949.7 hours.

tickets + "maybe" work on the activity

  In addition, the overall hours of the project are increased by this amount

which seems logical

Hello,

Perhaps similar to something I've experienced also, related to the start / strop time counter on tickets ? 

See this thread if maybe it can help :
https://www.projeqtor.org/en/forum/2-submit-issues/12646-problem-with-start-stop-work-on-tickets/  
 

What does it mean that toy cannot link the real time which is indicated for the activity and what was informed on a ticket. Cannot you calculate that the sum of tickets does not equal to 12 thousands hours?!

All advice is superficial. I did everything what you said again, nothing changed

User can input real time on activity. Let say they enter X days of real work on Activity A.
If then users link tickets to this Activity A as planning activity, and enter real work on the tickets, let say total of Y days, then real work on the activity is X + Y.

Yes, I do understand that. However, the developer enter the real time in 1 ticket, estimated time was 7 hours, he finished the task for 6,5 hours (screenshot attached). So, the overall real time for the ticket is 6,5 hours. The ticket is linked to the activity. There is only one ticket which is linked to that activity. Our developers dont have rights for the timesheet section to put the real time data to the activity. 

Taking into account this information, the overall real time shoud be 6,5 hours for the activity. Is that right? 
However, the real time for that activity is almost 18 thousands hours. My question is how is that possible? 

Can you please try this query on the DB

select * from work where refType='Activity' and refId=6761

What is the result ?

The result in the attached file

You only get one Row ?
To be sure, please execute

select count(*), sum(work), min(workDate) as start, max(workDate) as end from work where refType='Activity' and refId=6761

count|sum    |start     |end       |
-----+-------+----------+----------+
    1|0.81250|2023-05-16|2023-05-16|The result in the attached file

Sure there is an issue.
The sum of work is 0,8125 days (6.5 hours).
To try and fix :
=> Be sure to use the latest release (V10.3.5). Migrate is needed.
=> Go to the activity
=> Update left work for assignment with too many real work displayed (you can add 1 day / remove one day)
This should fix the value.
 

Morning,

We have updated our system to version V10.3.5

Yes, it is working:
=> Go to the activity
=> Update left work for assignment with too many real work displayed (you can add 1 day / remove one day)

However, it does not fix the problem in general. Do I need to do it manually always? Are you going to fix the bug?

However, it does not fix the problem in general. 

What do you mean

Do I need to do it manually always?

There is no automatic fix for this issue, possibly generate on an old version.

Are you going to fix the bug?

As long as I know, there is no remaining bug.
Data entered on V10.3.5 are correct.