[v7] Discussion: Project-wise billing removed with Timesheets

ERPNext Accounting
, , ,
4

I agree, Timesheets are great, but there’s still a hole left where Time Logs were removed. I still wish there was a simple way for shop floor people to clock in/ clock out. I can tell you that these Timesheets will get screwed up and become a huge headache for supervisors.

In my opinion there should be a “Timesheet Entry” type document for logging time extremely simply. Start time, Hours, Project, Activity Type → submit. These would then be collected on a Timesheet, approved submitted, and processed for payroll.

That’s basically how it works in every time keeping system I’ve ever seen… and it’s always a pain to integrate 3rd party time keeping into ERP. If ERP Next did this out of the box it would be an amazing feature for manufacturing type companies in the US, and make it much easier to do Project based billing.

3 Likes
5

Hi all,

just got the update in dev where the lovely time logs are removed…
I personally don`t like it!
We really got used to the feature of logging per task as that helped us with calculating projects.
would it be possible to have it back and decide what you need by setting (either time log and batch or timesheet)?

6

The new timesheet in rel 7 has the fields you are referring to(start time/end time/project/activity type). Employees can create the timesheet and then it can be approved. Invoicing can pull the data from timesheets to invoice once they are approved.

Hope this suffices your requirement

7

Could you try beta testing the release 7 feature and point out exactly why it would not be usable for you? Specifics help us make the product better and take better decisions.

Thanks

8

I am watching the discussion about time sheet.

I can understand the point of view in keeping the old system, because this is the mechanic of timekeeping, people know.

Why not provide both systems. The old system will result in entries of the new time sheet. So user have the choice to use in some use cases the new and in other use cases the old system.

I think, this should be solvable easily.

9

Hi Pawan,

I checked and came out with the following…
Our employees work on different projects within a week or even a day, they also carry out project work or company related administrative work.
for Analytical reasons the time log / time log batch system was perfect for us as we could overview the effective costs of labour to the representing cost centres we also could determine whether the calculation while pricing up was correct
and how we could optimize calculation or workflows as well as the productivity of certain employees.
With the old system we used the Timelogs in order to log per task and project. hence had the opportunity to batch in order to bill batched time logs. That was conform to our business model as well as the transparency required by our customers and the terminology within the process.

we understand it as follows
Time Log - a duration of a task with notes to that task
Time Log Batch - collection of time Logs representing a duration of a project or one of its milestones

however we find the new time sheet useful for HR purposes if we would define it as a collection of Working time per employee during a certain period of time ( weekly/ monthly).

hence we would prefer the old system enriched with the time sheet as another type of batch for HR or like @Idat-Consulting suggests with the addition of a notes box for each entry.

I also found that the Time Sheet Details start and end times are hard to edit now…

  • I set the time for the start of an event in quick edit
    -now I want to set the end time f.e. 5 hours further up but the hours jump to 1,0 and the
    start time syncs to the movement
1 Like
10

Not really, no.

11

Exactly what I was thinking. If “Time Sheet Detail” was a doc that the user could create alone, (as time logs were) it keeps the dangerous tools out of employees hands. While It negates any need for the timesheet functionality, besides being a per-employee wrapper when it comes to billing on an invoice, it’s a much safer situation.

While this is a great control, and absolutely necessary, I feel like it’s an old solution to a new problem, because as stated:

And I apologize if I come off as bashing the new format altogether, it’s inevitable that mistakes will happen, and it’s become harder to track them.

To continue the thought from above, clicking to applicable time logs from Project made it an instant effort to track entries. The report is great to be able to iron out mistakes, but this again falls back on correcting any mistakes once they’re present. (and the report doesn’t allow the ability to send to the billing process directly as list view filters did)

Also going to miss this quite a bit. Notes on each entry was a suggestion/pull-request I had, but it was rejected because the note field on timesheet was seen as sufficient.

I understand if there are no plans on re-instating TL/TLB, and will look for new workarounds in hopes of continuing to using future versions, but i really hope the concerns from the beta get revisited before release.

Thanks

1 Like
12

Hello @superlack @spa @Idat-Consulting @agerken @Pawan
New timesheets and time logs are intended for similar functionality. Below are some of the concerns we have addressed

A) employee can submit wrong timesheet which lead to incorrect billing “we have restricted employee to submit timesheet and manager can check, correct and submit the timesheet”

B) Fields that are sensitive and should not be seen by employee can be restricted with field permission manager

C) Manager can also make bulk data corrections using data import tool

D) Timesheet can also be created without employee ID (validation is removed) and can be billed.

We are also looking to make timesheet searchable by project for ease of correction by manager and some other changes.

Thank you all for the valued feedback on timesheet . Please keep sending more feedback on this and other new features. We will look to address these soon.

Thanks, Rohit

2 Likes
13

These are all “band-aids,” they fix the symptom of the issue, not the issue. The correct solution is to make the system easy to use so that mistakes don’t happen, instead of making supervisors spend extra time correcting issues created by an overly complicated time keeping system.

Honestly, how hard would it be to just make an extremely simple form for “Time Sheet Entry” or “Labor Transaction” or… “Time Log” that could be created right from the “Make” button in a Production Order, Project or Task?

2 Likes
14

Hi @rohit_w @Pawan

any thoughts on the suggestion of @Idat-Consulting and @superlack?
maybe we find a way to not take away current workflow as of version 6 and
enrich with the pros of the new system

rgds

Sebastian

15

The only easy solution I can imagine for the team, would be allowing Timesheet Detail to be standalone, but batched into a timesheet (via the listview, and helpful filters) Individuality would be based on employee, because of the obvious payroll link it requires. I don’t think employee specifics are a part of the child table currently, but that’s speculation after glancing.

16

That at least would, providing of having the opportunity to take notes per task, ease our life again as we are back to spreadsheets now to do our project management and time keeping.
The V7 changes rendered the ERPNext timekeeping useless for us as we tracked important PM information with it as well
Even our employees hate it! because now they are back on the phone in case of an issue.
and in general it is a change of the workflow we hammered into their heads.
I think this is an issue as change alway causes confusion and this particular one in our case also regression
Of course change can also be efficient and we see the good intention but in our case it went the other way

@superlack
Maybe we should dev a seperate timekeeping app that connects more with PM by forking the old style timekeeping

17

I agree that the old system was foolproof, and an incorrect entry can be multiplied to the weekly scale before it gets caught.

One thing that was mentioned is that administrators can simply use the “Daily Timesheet Summary” report to view all entries and correct them as needed… Not only is it a band-aid as mentioned, but it only works for submitted timesheets. So that’s forcing a timesheet per day, which goes against the merit of the weekly sheet system to begin with.

Following that sentiment, if using a single timesheet per employee, per project, per day is the solution, the obstacle is if they are printed from list view, each timesheet shows up on different pages.

I’ve been trying to play around with various customizations to enable the same workflow again, so far the options are:

Using a timesheet as a Time Log would have been used:

  • No way to batch and reduce pagination upon printing

or

Using a timesheet for a specific employee and the project they’re working on.

  • Timesheets will “disappear” when billed, employees need to create new one upon new project billing cycle

  • No auditing can take place on an in-progress timesheet (besides picking through each one; no reports available for timesheets that haven’t been submitted)

  • Requires employees to make sure all of the information/project info is consistent

  • No note taking per task

Would rather not modify too much out-of-the-box at this point to make it work. New patches in versioning are dangerous. Seems that the link between project and timelogs got lost when clicking hours from project doc, and all associated notes in the time log batches have just been discarded with the conversion patch. Annoyed, but I can’t complain

Would love to know how everybody’s been using it after a bit of time from the v7 release though

18

Hi @superlack, @rohit_w, @Idat-Consulting, @Pawan, @agerken, and all

dev-team: is there any internal discussion on this issue?
Are there plans of any changes?

if not what is the best way for us to adjust to our needs?

  • App that forks old system
  • fixtures/customisations to give us missing fields and reports for filtering

thanks

19

Hi @spa,

We have did some changes to improve UI, also we got contribution from community member to show timesheet on calendar view. You can do another round of testing on beta version.

Thanks, Rohit

20

Very nice to be able to have calendar function back

In regards to customization for reports and filtering, I found that as soon as I added a custom field (project) to the main timesheets doctype, it broke the custom report and calendar functionality.

Calendar

 Traceback (most recent call last):
  File "/home/frappe/frappe-bench/apps/frappe/frappe/app.py", line 55, in application
    response = frappe.handler.handle()
  File "/home/frappe/frappe-bench/apps/frappe/frappe/handler.py", line 19, in handle
    execute_cmd(cmd)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/handler.py", line 36, in execute_cmd
    ret = frappe.call(method, **frappe.form_dict)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/__init__.py", line 879, in call
    return fn(*args, **newargs)
  File "/home/frappe/frappe-bench/apps/erpnext/erpnext/projects/doctype/timesheet/timesheet.py", line 312, in get_events
    }, as_dict=True, update={"allDay": 0})
  File "/home/frappe/frappe-bench/apps/frappe/frappe/database.py", line 137, in sql
    self._cursor.execute(query, values)
  File "/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
    self.errorhandler(self, exc, value)
  File "/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
OperationalError: (1052, "Column 'project' in field list is ambiguous")

Report Builder :

Traceback (most recent call last):
  File "/home/frappe/frappe-bench/apps/frappe/frappe/app.py", line 55, in application
    response = frappe.handler.handle()
  File "/home/frappe/frappe-bench/apps/frappe/frappe/handler.py", line 19, in handle
    execute_cmd(cmd)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/handler.py", line 36, in execute_cmd
    ret = frappe.call(method, **frappe.form_dict)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/__init__.py", line 879, in call
    return fn(*args, **newargs)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/desk/reportview.py", line 16, in get
    data = compress(execute(**args))
  File "/home/frappe/frappe-bench/apps/frappe/frappe/desk/reportview.py", line 21, in execute
    return DatabaseQuery(doctype).execute(*args, **kwargs)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/model/db_query.py", line 79, in execute
    result = self.build_and_run()
  File "/home/frappe/frappe-bench/apps/frappe/frappe/model/db_query.py", line 103, in build_and_run
    return frappe.db.sql(query, as_dict=not self.as_list, debug=self.debug, update=self.update)
  File "/home/frappe/frappe-bench/apps/frappe/frappe/database.py", line 148, in sql
    self._cursor.execute(query)
  File "/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
    self.errorhandler(self, exc, value)
  File "/home/frappe/frappe-bench/env/local/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
OperationalError: (1054, "Unknown column 'tabTimesheet Detail.name as 'Timesheet Detail:name'' in 'field list'")

On a different note, how is the workflow for timesheets supposed to work if employees are entering daily, projects are being billed day of completion, and payroll hours are processed bi-weekly. If an employee just “saves” the timesheet as a draft, it allows them to add to it day by day, to make use of the whole table idea, but doesn’t allow for payroll processing until the project gets billed.

If an employee’s timesheet gets submitted by the manager at payroll processing, hours for projects that have been ended and been billed in between that time, could be wrong, or changed.

If an employee’s timesheet gets submitted everyday, payroll processing and project billing can happen any day, but, its basically just using it as a timelog again, but without the ability to batch. We are currently trying this approach, but are really missing the ability to print TLB with notes corresponding to a particular projects invoice.

If Timesheets could do that from list menu without paginatation, or if it was possible to bundle timesheets into one, I’d be happy with that

21

Did you try using ‘Customize Forms’, it is usually not recommended to make changes directly in the DocType.

About timesheet and payroll, if you intend to link both then probably what you are saying is correct. Are timesheet and payroll linked in your company? If they are linked, then you could possibly customize to pull the data for payroll based on some other criteria than what is delivered as part of V7.

Employees entering timesheet in draft mode daily and manager submitting weekly is the suggested way to operate in the new version.

Thank you for your feedback, it is very helpful in improving v7

22

Thanks for responding.

I do all modifications through the provided “Customize…” options, so as to leave trouble away from versioning/upgrading. The customizations previously shown are both done through that method. Since V7 I feel as if they are going to get me in trouble. The timelog>timesheet patch destroyed a lot of valuable information we had been keeping, but I think we’re just on the mend :slight_smile:

It looks like Calendar view calls for “project” field, but not limited to just the “Timesheet Detail” doctype (if I’m understanding the ambiguous error correctly). I have a “project” field in the timesheet parent doc, so I think that’s the error, but since there are records existing now, simply renaming the field doesn’t help. I would love to submit a PR for the call on project to be specific on the child table if I knew more

The error I have on report view could be caused by a record that was submitted when I was trying to script some information to be used as a title for legibility in list view. I accidentally used doc.name, which seems to be an internal function though it’s not listed as a field. Switched that to doc.title, but it’s still throwing the error in report build view

Timesheet and payroll are indeed linked in my company. It is usable by doing the daily operations fixed per whole timesheet, but that makes the improvement of timesheet tables redundant. Introducing another workflow for them such as saved, approved by payroll manager, then submitted would work, but is also creating more work for the administration side, and the two would have to work around one another, if not being able to double accounted (billing, payroll).

Therein lies the issue I’m seeing from a company that is entirely project based. I don’t think it’s realistic to be able to leave a timesheet in the employees hands for a week, for the amount of untraceable, or forgettable errors that could occur out of human nature in a weeks span. The timeline difference between payroll and project billing is always going to be inconsistent in my field as well, and the current workflow does not allow the two modules to see eye to eye.

I feel like I’m almost pleading for a reevalution on the system, but would be very glad to provide a case report if that would help anything.

23

  • Payroll can run off existing timesheets which are submitted & would be available for payroll processing once they are submitted by employees

  • Global setting to ‘Enable Timesheet adjustments’ feature.

  • The same submitted timesheets would serve as inputs for invoicing to the new proposed ‘Timesheet Billing Adjustments’ doc type

    * If project is selected, grid would show related project timesheets
* 'Billable', 'Adjustment' columns to be editable
* Once submitted 'Make Invoice' button to appear & 'Total Hrs' to be available for billing

This is based on discussions and feedback we have received so far @umair

@superlack,@spa ,@agerken kindly provide any feedback you have on the above proposed page