Ship Bills & Invoicing#

A Ship Bill is the shipment + invoice document that closes out (all or part of) a Sales Order. It’s the point at which revenue and AR post to GL.

Flow#

1. User picks SO lines / quantities to ship.
2. ShipBillHelper creates the ship-bill header and pulls line detail from the SO.
3. Tax is computed by ShipTaxHelper using the ship-to jurisdiction.
4. Freight and packing details come from the Packing List.
5. On save: on-hand decrements, revenue and AR post to GL (ArSetupHelper defaults), and the ship-bill is available to print / email.

Batch invoice emailing#

Batch emailing is one of the most-actively-used flows (see MD-4731 in recent commits). Key rules:

• Emails go to billing contacts on the customer / SO. getSuppliersEmailIds also honours a CC email address mapping added by MD-4731.
• Each email must attach the invoice PDF with the correct invoice number — a batch-emailing bug in that ticket was that the wrong number could be attached.
• The batch modal must fully reset after a successful send so that state doesn’t leak between batches.

If you’re touching batch email, keep those three invariants in mind — they’re the exact issues the recent tickets fixed.

Business rules#

• A ship-bill can only be voided while it hasn’t been paid; a paid invoice must be adjusted via a credit memo (AR).
• Serials shipped are recorded on the ship-bill line — this is the customer-visible record of what serial went where.
• Consignment shipments (customer consignment consumed) go through the same helper but skip the on-hand decrement (stock was never ours) and skip revenue posting.
• Tax logic supports multi-jurisdiction ship-to; jurisdiction resolution is ShipTaxHelper’s job, not the controller’s.

Where it lives#