Add docs for receiving batch, esp. complete flags

docs/features/purchasing/receiving/batch.rst

@@ -0,0 +1,56 @@
+
+Receiving Batches
+=================
+
+In all cases, "receiving" in Rattail involves a :term:`batch`.
+
+Each batch is created with a certain "workflow" and this will
+determine some of the behavior described below.  But see also
+:doc:`workflows` for more info.
+
+
+Batch Life Cycle
+----------------
+
+All receiving batches have the following general life cycle in common:
+
+* batch is created
+* (optional) batch is reviewed and/or updated
+* (optional) batch is marked "complete"
+* batch is executed
+
+Most of this is already described in :doc:`workflows` but here we'll
+add some notes regarding the review/complete steps in particular.
+
+
+Batch "Complete" Flags
+----------------------
+
+The idea is to introduce a step for sake of "handing off" the batch
+from one user to another.  For instance there might be several users
+capable of "receiving" in general but maybe only one user should be
+actually executing the batches.
+
+There are 2 flags for use with this idea:
+
+* "receiving complete"
+* "complete" (i.e. "review complete" or "fully complete")
+
+So a complete typical life cycle might look like:
+
+* batch is created with invoice file, by user A
+* batch is manually received (updated) via mobile phone+scanner
+* user A marks batch as "receiving complete" (sets 1st flag)
+* user B then reviews batch and adjusts costs as needed etc.
+* user B marks batch as (fully) "complete" (sets 2nd flag)
+* user C executes batch and performs any follow-up tasks
+
+Note that the app should "lock down" the batch if either of these
+flags are set.  Meaning, the received quantities should be frozen and
+not allow adjustment.  (Flags can be un-set if further adjustments are
+needed; then flags should be set again when complete.)
+
+Note also that user C for instance can probably see "all" batches
+regardless of their current state and complete flags etc.  They either
+"just know" how to filter the batches to find things ready to process,
+or perhaps a custom view is defined to help with that.

docs/features/purchasing/receiving/index.rst

@@ -8,5 +8,6 @@ All about *receiving* product which was ordered from the vendor.
    :maxdepth: 3
 
    overview
+   batch
    workflows
    accounting

docs/features/purchasing/receiving/overview.rst

@@ -20,21 +20,10 @@ handled in a separate third phase; see
 always applicable but often will be.  Anomalies refers to anything you
 want it to, e.g. if a product cost has increased too much.
 
-Receiving is done via batch.  The user creates a batch via one of the
-supported workflows:
+Receiving is done by way of a :term:`batch`; see :doc:`batch`.
 
-* From Scratch - aka. just start scanning items
-* From Invoice - upload invoice file, then scan "against" it
-* From Purchase Order - choose existing PO, then scan against it
-* From Purchase Order, with Invoice - choose PO *and* upload invoice
-  file, scan against it
+The batch may behave (or the user may use it) differently depending on
+the batch "workflow"; see :doc:`workflows`.
 
-We say "scan" above, as it is possible to do these tasks with a mobile
-phone and bluetooth scanner.  But paper-based receiving is also a
-supported method; in this case after paper check-in has been
-completed, user would "auto-update" all line items to be "received"
-and then *undo* that for any exceptions (credits).
-
-The user then will review the batch, add/modify line items as
-appropriate.  Once satisfied that all data is correct, batch is
-executed, which typically will update the master purchase record etc.
+When a receiving batch is executed, it should accomplish one or more
+of the "concerns" listed above.  Details will vary by implementation.