Maybe this would be best route. What I am wondering is how to handle those transactions… it would need to be held somewhere separate from Accounts… Maybe we need a Settings/States/Transactions section similar to Accounts/Transactions
OR
Pull states out from Settings make it its own category.
Exactly 
, this would be awesome for Reservations, and again, it would work right away with some Automation Actions, Rules, etc.
Not sure where to put them, probably right under States…
Might be a better approach, I agree. Afterall, anything having to do with Transactions (Accounts, Inventory) has it’s own section - because it’s special. 
State Transaction Types? Why we need that?
I didnt mean that… I meant just the transactions themself. Like what is in Accounts/Transactions
It may not look like that but that gives general idea.
I’m just following what I’ve seen in other parts of SambaPOS. Because essentially, we’re talking about creating a State Transaction.
Maybe that should be static and invisible @QMcKay I am trying to think of different transaction types we would use for States… isnt the main thing just a timestamp transaction? Or were you thinking something like Ticket State Transaction… or Order State Transaction or Entity State Transaction? In that case I could see why State Transaction Type with those 3 under it would be useful but I dont think being able to name your own State Transactions would be useful… maybe I am wrong?
or
Maybe Order State Transaction, Ticket State Transaction , Entity State Transaction can just be toggled when you make your State Transaction Type.
I feel it should be called something other than Transaction as there is no exchange being made… I am not sure right this second what it would be called tho lol
Maybe State Change Type and State Change History…
Good idea, just a Toggle.
I see what you’re saying… maybe Transaction isn’t the correct terminology. Still, if you look at the current Transaction Tables they are built in a similar way, though they always do have a a Source and a Target. In regard to States, there isn’t a Source or Target, persay.
Maybe just StateLog?
Cool, I’m down with that. @emre, make it so! 
LOL, I think @emre may have been lurking here all along @kendash… probably sitting back with a cocktail smoking a cigar and watching the plan unfold before he touches his keyboard…
OK after trying to bring a lot of little pieces together I think I’ve decided how to start.
First of all that will be specific to Entity States. Of course it will be easier to implement same thing for other states but there is no reason to make querying harder as we never need to query other state types together.
Implementing it like we implemented transactions thing is a nice idea however that concept is in fact useful to format data entry screens. As we don’t need to update states manually I don’t think there will be a use for that. We already categorize them by configuring a Entity State Name and we can use that.
I think that log entry should saved to database at the time we end a state. I mean we should create clock-in log when user clock-outs. So we can both record start time - end time on same row and I believe that will make querying a lot easier. In fact I’m trying to find that simple solution for hours because I always thought I should record it at the time state updates.
We’ll trigger that logging through an action. SambaPOS already triggers a rule for state changes and we can use same mechanism. Believe me using an action will be awesome because we’ll be able to create a logic. I saw some additional info such as extra hours or other values I don’t understand. Maybe we could store such values just inside log row and ability to log it conditionally will allow us to create different values for different cases. For example X will be 1 if duration > 5 hours. I need to find a way to store such additional values.
Still thinking…
That makes a lot of sense. I have been looking at TimeTrex structure since it is open source I have access to everything. Its very complex so its hard to derive what would relate to our stuff were doing with Samba… but its also really interesting seeing how they handle it.
Great idea, that way the data isn’t disjointed - trying to match the Clock In row to the Clock Out row could become a disaster when you look at my suggestion for storing the data. (Bad Q, BAD! I should know better).
Would you also have “Previous/Original/Opening/Beginning” State and “Former/Altered/Closing/Ending” State fields to store the actual State Ids? That could be useful.
@QMcKay That sounds very similar to what TimeTrex does with its structure… I noticed it has Altered, Created by,… etc
Kind of makes me wish I installed it into sqlexpress I could just send you some stuff to look at… but I preferr Postgresql because I love open source 
Keep going… I need more ideas
I need to step out for a bit but when I get back ill be an idea factory… good or bad hahaha
State Table: (unchanged, 2 new States added under [GroupName] EPunch)
SELECT
[Id]
,[GroupName]
,[Name]
,[StateType]
,[Color]
FROM [States]
where [GroupName]='EPunch'
New Table [StateLog]:
use [SambaPOS4]
SELECT
[Id]
,[EntityId]
,[StateBeginId]
,[StateEndId]
,[DateBegin]
,[DateEnd]
,[DateUpdated]
,[Name] -- arbitrary, set from a Template and/or a Rule?
FROM [StateLog]
Report: (all tables exists with exception of proposed [StateLog] table)
use [SambaPOS4]
SELECT
e.[EntityTypeId]
,et.[Name] as [EntityType]
,e.[Id] as [EntityId]
,e.[Name]
,sl.[StateBeginId]
,sb.[Name] as [State]
,sl.[StateEndId]
,se.[Name] as [State]
,sl.[DateBegin] as [SBeginDate]
,sl.[DateEnd] as [SEndDate]
,right('00'+convert(varchar(5),DateDiff(s, sl.[DateBegin], sl.[DateEnd])/3600),2)+':'+right('00'+convert(varchar(5),DateDiff(s, sl.[DateBegin], sl.[DateEnd])%3600/60),2)+':'+right('00'+convert(varchar(5),(DateDiff(s, sl.[DateBegin], sl.[DateEnd])%60)),2) as [DurationHMS]
,right('00000'+convert(varchar(5),convert(decimal(5,2),convert(decimal(5,2),DateDiff(SECOND, sl.[DateBegin], sl.[DateEnd])/60)/60)),5) as [DurationDEC]
,sl.[Name] as [SLName]
FROM [Entities] e
left join [EntityTypes] et on et.[Id]=e.[EntityTypeId]
left join [StateLog] sl on sl.[EntityId]=e.[Id]
left join [States] sb on sb.[Id]=sl.[StateBeginId]
left join [States] se on se.[Id]=sl.[StateEndId]
WHERE 1=1
and et.[EntityName]='Employee'
and sb.[GroupName]='EPunch'
ORDER BY e.[Name], sl.[DateBegin], sl.[DateEnd]
Will this Time Clock implementation calculate the employee salaries from the hours clocked?
No. It will only track State Changes. The rest is up to you (for now). Currently, we’re just discussing rudimentary State Logging that could be used to track Entity States to give Duration.
The main thing I really liked about integrating into time trex was the scheduling side of the software. Also being able to keep track of employee information in timetrex… Best of all is if someone forgets to clock in or out it will email the manager to let them know they missed a time ouch they were scheduled for. Also the reports are really nice and the ability to put digital policies and do payroll!
@antasp3136
The great thing about State logging is it would enhance integrations like TimeTrex. I would use State logging and TimeTrex. Timetrex does my payroll so I need it and it is only in my advantage to integrate it. State logging just makes it that much better.
@QMcKay that looks great.
As @QMcKay said, no it would not, however it may be possible to develop a solution that could do this by entering pay rate as a custom entity value…
@emre, this is slightly off-topic, but since we’re talking about States and State Logging… Where does [StateType] come from? Is it “internal”?
P.S. I assume [StateType] 1 is Ticket State? Correct?
