What are you trying to achieve?
Hi there! I’m new to Make and have created a scenario that takes data from Toggl (time reporting) and inserts it into Bexio (ERP).
***First off: It seems to be working. ***
But I’d like to have something like a “sanity check” to see if what I cobbled together makes sense or if there are WAY easier and more stable ways to achieve my goal 
My company charges different rates based on the time or day of the week:
BZ1 = Mo - Fr, 08 - 18. No surcharge.
BZ2 = Mo - Fr, 00 - 08 and 18 - 24, plus n%.
BZ3 = Saturdays, plus nn%.
BZ4 = Sundays, plus nnn%.
“BZ” is the abbreviation of “Betriebszeit”, German for “operating hour”.
Bexio handles the actual rates. So depending on when the record was started I will assign a different “client service id” in the Bexio “Create a timesheet” module. Finally, after creating the timesheet, I add a “bx_gebucht” tag to the Toggl time entry and if it’s not “BZ1” then also a tag e.g. “bz3” if it’s a Saturday.
Steps taken so far
I’m using “Watch Time Entries” from Toggl to catch new records. The filter to pass to the next module is that the time entry needs to have a “stop” as well as a “start” entry. This avoids working on entries that are still running.
In between there’s some matching of project names/IDs between Toggl and Bexio, probably not interesting for this post (it works).
Then we come to the router. My logic is that I will first check if the start date is in one of times with a surcharge. I basically work from the bottom up: BZ4, BZ3, BZ2 and the last route is set to “fallback” without any filters to process entries for “BZ1”. The field with the start time I get from the Toggl connector is “1. Start”.
The filters for BZ4 and BZ3 are:
- Condition: “setday(1.Start; sunday)”
- Text operators: equal to “1. Start”
(“saturday” for BZ3)
I then created two filters for BZ2. One for midnight to 8am:
- Condition: “1. Start”
- Time operators: Less than or equal to “sethour(1. Start; 8)”
…and the second for 6pm (18:00) to midnight:
- Condition: “1. Start”
- Time operators: Greater than or equal to "sethour(1. Start; 18)
The last route is the “fallback” and doesn’t have any filters. The idea here is that all entries that are not caught in one of the previous routes are handled by this route.
I’m actually a bit amazed that this just seems to work right away out of the box. Therefore my question here about a “sanity check”. Here are some of the inputs and outputs generated by a test flow that had entries for all BZ1, BZ2 (both in the early morning and late night) and BZ3.
Input from Toggl (expected BZ is in the “description” field):
[
{
“id”: 3613910302,
“workspace_id”: xxx,
“project_id”: 87763531,
“task_id”: 95900046,
“billable”: true,
“start”: “2024-09-21T14:00:00.000Z”,
“stop”: “2024-09-21T15:00:00.000Z”,
“duration”: 3600,
“description”: “BZ3”,
“tags”: ,
“tag_ids”: ,
“duronly”: true,
“at”: “2024-09-20T12:09:49.000Z”,
“server_deleted_at”: null,
“user_id”: 3785384,
“uid”: 3785384,
“wid”: xxx,
“pid”: 87763531,
“tid”: 95900046,
“permissions”: null
},
{
“id”: 3613910635,
“workspace_id”: xxx,
“project_id”: 87763531,
“task_id”: 95900046,
“billable”: true,
“start”: “2024-09-20T12:45:00.000Z”,
“stop”: “2024-09-20T13:45:00.000Z”,
“duration”: 3600,
“description”: “BZ1 normal”,
“tags”: ,
“tag_ids”: ,
“duronly”: true,
“at”: “2024-09-20T12:09:54.000Z”,
“server_deleted_at”: null,
“user_id”: 3785384,
“uid”: 3785384,
“wid”: xxx,
“pid”: 87763531,
“tid”: 95900046,
“permissions”: null
},
{
“id”: 3613910924,
“workspace_id”: xxx,
“project_id”: 87763531,
“task_id”: 95900046,
“billable”: true,
“start”: “2024-09-20T19:00:00.000Z”,
“stop”: “2024-09-20T20:00:00.000Z”,
“duration”: 3600,
“description”: “BZ2 abends”,
“tags”: ,
“tag_ids”: ,
“duronly”: true,
“at”: “2024-09-20T12:10:07.000Z”,
“server_deleted_at”: null,
“user_id”: 3785384,
“uid”: 3785384,
“wid”: xxx,
“pid”: 87763531,
“tid”: 95900046,
“permissions”: null
},
{
“id”: 3613910355,
“workspace_id”: xxx,
“project_id”: 87763531,
“task_id”: 95900046,
“billable”: true,
“start”: “2024-09-20T02:45:00.000Z”,
“stop”: “2024-09-20T03:45:00.000Z”,
“duration”: 3600,
“description”: “BZ2 morgens”,
“tags”: ,
“tag_ids”: ,
“duronly”: true,
“at”: “2024-09-20T12:10:16.000Z”,
“server_deleted_at”: null,
“user_id”: 3785384,
“uid”: 3785384,
“wid”: xxx,
“pid”: 87763531,
“tid”: 95900046,
“permissions”: null
}
]
The first route filters “Saturdays” and caught Bundle 1. Correct, the time entry is for Sat 21st September.
The second route filters “Sundays” and didn’t catch anything on this run (correct, there wasn’t a new time entry for a Sunday).
The third route filters "Mo - Fr 00 - 08) and caught Bundle 4. Which is also correct, the time entry is for Fri 20th September 2:45am.
The fourth route filters "Mo - Fr 18 - 00) and caught Bundle 3. Again correct, the time entry is for Fri 20th September at 7pm.
The fifth route doesn’t use a filter but is the “fallback” route and is used for “BZ1” or normal business hours. It caught Bundle 2, which is a time entry for Fri 20th September 12:45pm.
Again - I’m not complaining that it works. I just wanted to ask if my logic is more or less OK or if I’m missing something obvious. Besides the fact that if a time entry in Toggl starts on a Friday at 4pm (normal business hours) and ends at 9pm then it would be booked as “BZ1”. Still not sure if I can solve this in here or if I’ll just have to do one time entry from 4pm to 6pm and the second one from 6pm to 9pm.
