33 lines
1.4 KiB
ReStructuredText
33 lines
1.4 KiB
ReStructuredText
|
|
Employees
|
|
=========
|
|
|
|
Employee data normally comes from the POS, if it indeed comes into
|
|
play at all. You may or may not have a reason to import or otherwise
|
|
act on Employee data using Rattail.
|
|
|
|
It is the User record in Rattail which is given attribution for
|
|
changes made etc. and not the Employee. So even if a certain User is
|
|
also an Employee, when logged in and making changes their User account
|
|
is deemed responsible.
|
|
|
|
Whereas a User record does not technically need to tie back to a
|
|
Person record, an Employee record *must* tie back to a Person. When
|
|
importing Employee data from POS, both the Person and Employee records
|
|
are created in Rattail.
|
|
|
|
There are certain places where an Employee *is* assumed, for instance
|
|
the "Buyer" of a Purchase Order will reference an Employee record and
|
|
not a User. Whereas the creation and execution of a "batch" related
|
|
to purchasing will reference a User. (See also
|
|
:doc:`../../purchasing/index`.)
|
|
|
|
Rattail could also be used as a "time clock" system in which case the
|
|
Employee records must obviously be present, for tracking times.
|
|
|
|
You also can use Rattail to track additional info for each Employee,
|
|
e.g. the start/end dates for their employment over time. Often an
|
|
employee might come and go more than once, and the POS will rarely
|
|
have a way to track historical dates. Rattail has a basic way to do
|
|
that built-in, but more "data extensions" are of course possible.
|