33 lines
1.5 KiB
ReStructuredText
33 lines
1.5 KiB
ReStructuredText
|
|
||
|
|
Editing
|
||
|
|
=======
|
||
|
|
|
||
|
|
Rattail makes it possible to edit most data it contains regardless of
|
||
|
|
its nature. This of course includes Person-related data.
|
||
|
|
|
||
|
|
However just because you *can* edit data in Rattail, does not mean you
|
||
|
|
*should* do so. You must keep in mind, "which system is the
|
||
|
|
authority?" for any given data point.
|
||
|
|
|
||
|
|
In other words if you import Customer records from your POS, but then
|
||
|
|
do not configure an export mechanism to get any changes made in
|
||
|
|
Rattail *back* into the POS system, then by far the easiest thing is
|
||
|
|
to just not allow editing in Rattail. But you still can view the
|
||
|
|
data, and use various app features which leverage the data (e.g.
|
||
|
|
:doc:`../../custorders/index`).
|
||
|
|
|
||
|
|
However if you *do* configure export mechanisms then you may want to
|
||
|
|
allow editing directly in Rattail. This can be any data point which
|
||
|
|
is supported by the export mechanism. For instance if you allow
|
||
|
|
editing of a Customer name in Rattail, the change could be synced back
|
||
|
|
to POS.
|
||
|
|
|
||
|
|
But it's also possible for Rattail to contain "more" data than the
|
||
|
|
source (e.g. POS) system does. For instance your POS DB may have a
|
||
|
|
field to track the "birthday" for each Customer, but maybe you also
|
||
|
|
need to track their "favorite color" and the POS DB does not provide a
|
||
|
|
way to do that. In this case you can import Customer records from POS
|
||
|
|
into Rattail, and then allow editing in Rattail only for the "favorite
|
||
|
|
color" field. Best of both worlds, you can now track whatever you
|
||
|
|
want with no need to export data back to the source system.
|