Receiving with Rattail

Here we are referring to the process of "receiving" product into the system(s) for the sake of updating inventory and/or cost amounts.

The details of the "receiving" process can vary quite a bit for each organization, but some patterns emerge and Rattail tries to offer tools around these patterns.

Overview

The general feature is meant to allow a user to "receive" product into a unique batch. Population of the batch data can happen over time, e.g. by scanning in product. When the batch is "complete" then it is "executed" - at which point the inventory and/or cost data it contains is "committed" to some DB(s).

The two primary use cases which follow from that, are:

• receiving "from scratch" - i.e. make an empty batch, scan arbitrary product into it
• receiving "from PO" - i.e. make a batch, and immediately populate it from previous purchase order, then scan against that

There also is a special "truck dump" mode which we'll cover further below.

Rationale

Even if you don't use Rattail to track your purchase history "proper" the goal here is for Rattail to still provide useful workflow tools. So regardless of where your true authority lives for purchase data, Rattail should be able to read e.g. PO data from it, and (ideally) write PO data to it as well. (The latter especially can depend on a lot of factors of course.)

Why would you even bother with this? Especially if the system where PO data lives already has a receiving workflow/UI, that's a good question. Short answer is, you may not want to! But then again it is possible that Rattail can be leveraged to obtain a more efficient workflow. This can sometimes make a big difference on labor costs as well as morale.

Of course, if you have no other system for POs then Rattail can provide a basic home for that too.

Receiving From Scratch

There isn't much to explain about this one. The receiving batch starts out empty, and user adds rows to the batch by scanning product etc. When they are finished the batch is marked "complete" - i.e. ready to execute.

An obvious side-effect of receiving from scratch, is that the user can't know (at time of receiving) whether or not each product was in fact ordered in the first place, or which things were ordered but were not received, or whether any products had a cost change etc. For these reasons, receiving from a PO (instead of from scratch) should be preferred.

Since Rattail in this case has no "ordering" data for the batch, the "cost" for each row will usually come from the product master (catalog) tables. In some cases it may also consult previous PO history to obtain a more accurate cost.

Typically when a batch of this type is executed, it will create a PO (and/or similar) records in some DB(s). Note that it generally can't update a PO since none was provided as the starting point.

Receiving from PO

If possible it's generally more useful to receive from a purchase order, because then Rattail (and hence the user) can compare ordered vs. received amounts, to aid tracking down discrepancies etc. Also this usually provides the most accurate cost data.

Where does this "purchase order data" come from then? Usually that is either a "proper" PO whose data lives in some DB(s), or else an invoice file. If a proper PO, user can select it from a list after specifying which vendor. If an invoice file, user must obtain such file separately, and upload to Rattail when making the batch.

Once the batch has been created and initially populated from PO and/or invoice file, then user scans product more or less as normal.

Each row in the batch is "aware" of its current status (e.g. if ordered qty is 4, but received qty is only 2, row is "incomplete") along the way. When all rows are "complete" etc. then the batch itself can be marked as complete, i.e. ready to execute.

Executing a batch of this type is similar to the "from scratch" type, although in this case it's possible to update a PO in addition to creating.

Truck Dump Receiving

The "truck dump" mode is meant to provide some efficiency, in situations where you must physically receive "lots of product" (hence the name "truck dump") but that product is sort of all mixed up, and represents multiple POs/invoices.

The general assumption here is that there are (or will be) multiple POs and/or invoice files which may be used to sort through all the receiving data, once both are available. If you simply have a big pile of product to receive, but know that you won't be able to obtain the PO/invoice data, then you should perhaps do a normal "from scratch" receiving (i.e. don't bother with truck dump).

Structure

A true "truck dump" situation then, will involve one "parent" batch and (usually) two or more "child" batches.

The parent batch must always be created first. This is where the user will scan in product as they're physically receiving.

Each child batch will represent a PO and/or invoice. These are not really meant to be "editable" but exist mostly to provide PO/invoice data to the parent batch.

Workflow

In practice the truck dump workflow is not too different from the "normal" workflow, in that you still have the choice of starting from scratch vs. from PO(s). If you have PO/invoice data available at time of receiving, you should create all child batches at the same time as creating the parent, so that you can receive "against" that.

But if the PO/invoice data isn't available yet, you can still create just the parent and start receiving from scratch into that. When the PO/invoice data becomes available, you can create child batch(es) as needed, to reconcile against the physical receiving data present in the parent batch.

Since there are multiple batches involved, and (typically) multiple users responsible for different parts of the workflow, it is important to have clear definitions for each part and who's responsible for what and when etc.

The parent batch may be marked as "complete" by the physical receiver for instance, indicating it's ready to be reconciled against child batches, but that doesn't mean it's ready to execute. Here we should point out also that child batches cannot be executed; only the parent batch can be executed.

For a parent batch to be eligible for execution, it must be fully reconciled. It isn't an issue for a child batch then, to have rows which aren't represented in the parent (e.g. billed but did not receive). However it is an issue for a parent batch to have rows which aren't (fully) represented within the child batches. Once the parent is fully reconciled, it can be executed.