37 lines
1.6 KiB
ReStructuredText
37 lines
1.6 KiB
ReStructuredText
|
|
Batches
|
|
=======
|
|
|
|
Batches are a sort of hybrid of import/edit/export. They assume a
|
|
certain "data set" will be brought into a dedicated workspace, using
|
|
whatever (sometimes custom) logic, then the user previews the
|
|
"results" before committing to it. See also :doc:`/data/batch/index`.
|
|
|
|
For instance one common type of batch is for new Customer entry.
|
|
Maybe there is a web form which some users fill out to enter new
|
|
Customer records, but in fact those go into a "queue" / batch and are
|
|
not truly injected to the system proper until the batch is reviewed
|
|
and executed by some (possibly more highly authorized) user. This can
|
|
be helpful not only for workflow optimization but also custom data
|
|
validation, and/or preventing duplicates from entering the system.
|
|
|
|
Another type might be for a periodic import to "sync" 2 systems which
|
|
do not normally stay in sync. For instance if your POS and CRM do not
|
|
stay in sync all the time, but maybe once a month you export the data
|
|
from one system to Excel file, for import to the other. It is of
|
|
course possible to make a Rattail "importer" (or "exporter" depending
|
|
on your perspective) which could automate this. But for sake of
|
|
better visibility and instilling confidence in the logic, you might
|
|
prefer a batch.
|
|
|
|
In the above example the process might be like:
|
|
|
|
* export data from CRM to Excel
|
|
* upload file as new batch in Rattail
|
|
* preview the changes; execute the batch
|
|
* which generates yet another file, e.g. CSV
|
|
* which you then import to the POS
|
|
|
|
There are many possibilities here; for instance more likely the batch
|
|
writes directly to POS when executed.
|