scenarios

This would likely make a better "intro" diagram to the overall concept(s) represented by the Rattail approach.

This was the original graphic, still present (as of this writing) on the prototype ("new home page") site.

After giving this more thought, I believe what this represents is more of the "Rattail point of view" of the system. I.e. from its perspective, all those "other systems" are just that.

One thing this doesn't really address (well) is the "users" / web app piece. The v2.0 graphic does a better job of that.

Here are a couple of basic "feature-specific" solution diagrams.

Rattail has a generic "batch" framework which allows arbitrary actions to be done via batch, meaning the relevant data is brought into a temporary table, where the user may review and/or modify it as needed, and ultimately "execute" the batch which applies the data changes to the live system(s).

Each type of batch requires its underlying tables to be defined, and a "handler" must be defined which is responsible for the practical / business logic for the batch. Also the web app should expose the batch for user interaction.

Many batch types will be custom, unique to a particular organization. Some batch types are generic though, and are provided directly by Rattail (e.g. purchase order, vendor catalog, vendor invoice, inventory, labels). Custom handlers may be defined for any of these generic batch types, and the web UI modified as needed.

The "truck dump" feature is a sort of "advanced" mode of product receiving.

In an ideal world, when product arrives from the vendor, it is "organized" somewhat to reflect the original purchase order. Generally, there is one invoice for each PO, so this allows the receiver to process one order/invoice at a time. (If this describes you, then you do not need the truck dump feature.)

Sometimes though, all product from all orders is mixed together when it arrives, and there is no practical/efficient way to separate the orders prior to the receiving process. We call this situation a "truck dump" and the Rattail receiving framework has a way to deal with it.

Basically, instead of a single receiving batch, we create at least three - one for the "parent" and then two or more "child" batches. (If you only had one child, then again you would not need the truck dump feature.)

The receiver then processes "all" product into the parent batch. At some point (can do it either at the beginning or end), "child" batches are created, e.g. from invoice data file upload, and all rows between parent and children are matched up.

Once everything has been gotten straight, the parent batch is executed, which in turn will execute each child batch. At that point execution of each child batch should go mostly as though it were a single receiving batch and there had been no truck dump involved.

See also the Rattail docs for Product Receiving.

And for even more chaos, take a look at these row relationships.