Batches, delivery and reversal

Generating a file, getting it to the finance system, and putting it right when something is wrong. Three separate things, deliberately.

A batch

Generating produces a batch: a file, a list of the lines in it, and a checksum of its own bytes. Every batch is at the finance interface with its lines, its totals and a link to the orders behind it.

The batch is the record of what was sent. Its bytes are stored and checked against that checksum before they are ever sent anywhere.

Delivery is separate from generation

This is the most important thing on the page. A batch that generated correctly and failed to deliver is retried, never regenerated.

Regenerating is how a line gets invoiced twice. So delivery is a state of its own, tried again until it succeeds, and nothing about a failed attempt touches the file. A batch sitting in "delivery failed" is a network problem, not a finance problem, and the fix is to retry it.

Delivery happens on its own

A job attempts outstanding deliveries on a schedule, and alerts you where one keeps failing. You can retry by hand from the batch, and you can download the file to send by another route if you have to.

Reversing a batch

Where a whole batch should not have gone — wrong period, wrong coding — reverse it. That records the reversal, with your reason, and puts the lines back into the pool for the next run.

A batch can be reversed once. Reversing a reversed batch is refused rather than silently doing nothing, because the second attempt is somebody who thinks the first did not work.

Credit notes

Where an order has already been invoiced and something is wrong with it, the answer is a credit note rather than a deletion. Raise it from the order: the credit and the corrected line go out in the next run, and the accounts continue to say what actually happened.

The batch links to the orders in it, which is how you get from an exported batch to the order a credit note is raised against.

Reconciling

The finance system's answer comes back as a return file. Reading it in reconciles the lines it names, and any row naming a reference in no batch is kept and shown rather than dropped, because that is a real condition and dropping it quietly is how a discrepancy survives to year end. See interface formats, returns and the customer master.

A monthly rhythm that works

1. Run the pre-flight, fix the faults.
2. Generate and let delivery happen.
3. Read the return in, and look at what did not reconcile.
4. Run "sold but not yet billed" and account for anything on it.