Id, EntityId, State, Datetime
That should suffice to start.
The Employee also needs the ability to Clock In or Out even without a Workperiod open, though that is already possible via a small oversight in the current code that I would rather not reveal because I like the behavior (hint: it has to do with being able to create a Ticket with no Workperiod open - a function that should not be allowed).
I have noticed that myself, accidentally . I almost planned something around that behavior but ended up deciding not too thinking it might break in future lol.
Actually, do we not already have enough customization available in the current tables? Just add Custom fields to an Employee Entity for State and Datetime.
Then we just need a way to update Entity Data (outside of a Ticket or WorkPeriod). Or am I missing something here? Do we need a new Action or something?
It would need to store Multiple entries for those custom fieldsā¦ which is not an issue if we select hiddenā¦Maybe your on to something.
Right, multiple entries/rowsā¦ thatās where it falls apart. I see now, duh. Back to this:
Id, EntityId, State, Datetime
or maybe betterā¦
Id, EntityId, EntityCustomFieldId, Datetime
Either that or we just made him actually just run haha.
I was thinking and another cool thing about this. Me for example I could use both systems. I can use the time clock and scheduler of samba and still link it with TimeTrex for its payroll function
[Id]
,[EntityId]
,[StateId]
,[Date]
So we would need a new Action, to store running Entity Data into a table such as this, similar to a Transaction.
That sounds good. Lunch, Break etc can be defined as a State as well as In and Out Or it could be any other State for other applications.
EDIT: deleted blah blah pertaining to Custom Entity Data Fields
It should probably be linked to States.
THIS would be New Table:
SELECT
[Id]
,[EntityId]
,[StateId]
,[Date]
FROM [EntityTransactions]
order by [Date]
Sorry Iāve lost the idea when it came to the custom field thing. Why we need that?
Sorry @emre, we donāt need to tie to Custom Field Data. Thatās what I just realized. It should be something like this insteadā¦
Define some new States for Employee Entity:
use [SambaPOS4]
SELECT
[Id]
,[GroupName]
,[Name]
FROM [States]
where [GroupName]='EmployeeStatus'
THIS (or similar) could be New Table: (could be called [EntityStateTransactions])
SELECT
[Id]
,[EntityId]
,[StateId]
,[Date]
FROM [EntityTransactions]
order by [Date]
Then we can run a Report like this:
use [SambaPOS4]
SELECT
e.[EntityTypeId]
,et.[Name] as [EntityType]
,e.[Id] as [EntityId]
,e.[Name]
,tx.[StateId]
,s.[Name] as [State]
,tx.[Date] as [CFDate]
,[AccountId]
FROM [Entities] e
left join [EntityTypes] et on et.[Id]=e.[EntityTypeId]
left join [EntityTransactions] tx on tx.[EntityId]=e.[Id]
left join [States] s on s.[Id]=tx.[StateId]
WHERE 1=1
and et.[EntityName]='Employee'
and s.[GroupName]='EmployeeStatus'
and e.[Name]='Myrna'
ORDER BY e.[Name], tx.[Date]
I will chime in with Time Clock, since I have asked for this feature many times 
I think what we need is a simple Clock IN and Clock OUT time stamp for users or entities. If we have Clock IN and Clock OUT, we can use Custom Report to query their time.
In US, calculating payroll is very complicated. It is best left to professionals. I think, all we need is to track employee time and export this data for payroll professionals.
Below are two sample reports.
A summary for all employees:
Or do we look at it purely from a State perspective and have a [StateTransactions] table instead (not tied specifically to Entities)ā¦
SELECT
[Id]
,[StateId]
,[EntityId] -- will accept NULL for Tickets, Orders
,[Date]
,[Name]
FROM [StateTransactions]
order by [Date]
All you need is an ability to track a Stateā¦ call it Punchā¦ it can have status of in or outā¦ or Lunch In Lunch out or break. Each change of Punchās Status would be timestamped with date/time.
What needs to be stored is that state change.
Lets call it Punchā¦just have a toggle when creating the state to save State Changesā¦
If the toggle is checked it will create a table for that State called dbo.StatesPunch
with
Select
[Id]
,[GroupName]
,[Color]
,[Date]
,[TimeStamp]
,[Name]
From [StatesPunch]
This would populate based on State Changeā¦ Basically what I mean is instead of making a static tableā¦ make it choose to create the table or not
or something like that. Rough sketch of my ideaā¦
@na1978 it really needs to be a little more complete vs just relying on custom reports to build the correct output. Novice users would be clueless how to use it and could get themselves in a lot of trouble if they do it wrong.
I agree that the implementation should be a little more complete, in that the report should be canned for basic use to keep people out of trouble. If that were to be done, we would need a definitive way to mark an Entity as an Employee or Staff (a checkbox) so that they are not confused with other types of Entities.
Iām not so sure we need something like a Punch table at this pointā¦ maybe in the future as a fully fledged Addon.
Now, work with what we have already which is States - just add a [StateTransactions] table and it can be used for Tickets, Orders, Entities, whatever. Then build in a way to create a State Transaction, just like we already have for Accounts (Sales, Expenses) and Inventory.
The Table and the Transaction Type could be implemented very quickly (I believe) so we could start using the power of State Transactions right away, and not just for Employees as @emre already mentioned.
What I meant was not creating specifically a Punch Tableā¦ it would create State[Name] based on what you named the state and if you checked the Store State box. so if you named it Delivery and you checked the Save State boxā¦ it would make a table StatesDelivery
This would keep the current state system in tactā¦ and would not require us to save state information until you specifically want it stored.
SambaPOS does not do this currently. It doesnāt make tables on the fly. It shouldnāt need to either.
Iām not suggesting altering the State table at all. Look at my idea. It will work right away.
I see your point. I am just throwing out ideasā¦ good or bad. While I am motivated by a Time Clock I agree we should shy away from specific Time Clock functions for what we are discussingā¦ that should probably be a more complete system. But if we implement something more basicā¦ it can lead into some better systems now and open it up for more advanced complete packages.
I do not see anything wrong with someone developing a TimeClock sort of speak from what we have discussedā¦ but I do feel what we are doing should not be done with specific purpose of time clock.
Your right sorry I jumped the gun on that.
EDIT: Thinking about it your right there is no need for it to do it dynamicallyā¦ you have it there and it will either use it or not based on your configuration. Using it as transactions would be great. It could lead to better reservation systems, etc.
Define some new States for Employee Entity: ā¦ this table already exists, I just added a new GroupCode (EmployeeStatus, could be EPunch or whatever) and 2 new States (Clock In, Clock Out). I made them inside SambaPOS on the State screen.
use [SambaPOS4]
SELECT
[Id]
,[GroupName]
,[Name]
FROM [States]
where [GroupName]='EmployeeStatus'
Here is the new table, [StateTransactions] very simple, just like all Transaction Tables
SELECT
[Id]
,[StateId]
,[EntityId]
,[Date]
,[Name]
FROM [StateTransactions]
order by [Date]
The only thing Iām uncertain of is the EntityId field. It could be renamed to accept TicketId, OrderId, EntityId, etc. I think it should be there, just not sure what to call it. Or perhaps the table should have all 3 Id fields, and accept NULL when not applicable.