VbzCart/packages

A package is either "outgoing" (i.e. part of a shipment) or "incoming" (i.e. a customer return).

See VbzCart/code/VBA/Form frmPackage and VbzCart/code/VBA/clsPackage for how this used to work in Access.

General

Whenever package lines are altered, it should be told to recalculate its totals based on the line values.

Outgoing

Outgoing packages can take items from stock or return items to stock, where the package data mainly reflects the final contents of the package as shipped.

Fetching Items

This is where items are added to the package.

• The web form indicates the locations of stock that might be used to fill the order.
• User enters the quantity to use (remove) from each location, and presses "Fetch Stock" button.
  • If "do it for real" box is not checked, subsequent data changes are displayed as hypothetical rather than actually being done.
• If the current package is "new", then a package record is created.
• The code then creates or updates package line records as necessary to accommodate the stock being added to the package.
  • For each unit moved from stock, QtyShipped should be incremented.
  • item sale amount(s)
  • per-item shipping (total)
  • per-package shipping (max)

Finalizing

This is where we sort of make the package "official": statuses are updated, totals computed, etc.

• (We used to increment a "QtyDone" field in ord_lines for each line in the package, but now we recalculate that dynamically (as needed) by summing up the package quantities.)
• (We used to calculate totals at this stage, but that is now done whenever the package contents are modified.)
• Add a transaction record to the order for the amount owed for this package.
• Time-stamp package as "finished".

Returning Items

It is sometimes necessary to return items to stock from an outgoing package, typically when the shipping user has made an error of some kind. It is also useful when testing or demonstrating the shipping process, so items removed from stock in the database but not actually removed from stock can be "put back" where they were (in the database).

For each unit in a package line that is returned to stock, QtyShipped should be decremented.

• If QtyNotAvail is greater than zero, it should also be decremented
  • ...although there may be other things that should happen. It may be that we should just zero out QtyNotAvail and QtyCancelled when items are taken out of a package.

Incoming

Incoming packages can only return items to stock, where the package data mainly reflects the contents of the package as received (before returning items to stock).

When units are moved back into stock, QtyShipped should be decremented but QtyReturned should remain unaltered.