## Purpose

Lets an admin generate a frozen, per-employee lunch billing snapshot for a chosen date range, mark employees paid against that specific snapshot, and delete a mistakenly-generated one - so leaders have a stable, shareable record to post to a group chat and check off against.

## ADDED Requirements

### Requirement: Admin can generate an invoice for a date range
The system SHALL allow an admin to generate an invoice for a `from`/`to` date range, optionally scoped to a company. Generating an invoice SHALL snapshot, for every employee with at least one active order in that range (matching the scope), their total amount owed at that moment. The `to` date SHALL NOT be in the future (the period must have already elapsed).

#### Scenario: Admin generates an invoice for a past, complete month
- **WHEN** an admin generates an invoice for a `from`/`to` range that has already fully elapsed
- **THEN** an invoice is created containing one line per employee who ordered in that range, each with their total amount owed at generation time

#### Scenario: Admin attempts to generate an invoice for a range that hasn't ended yet
- **WHEN** an admin requests an invoice whose `to` date is later than today
- **THEN** the request is rejected and no invoice is created

### Requirement: An invoice's amounts are frozen at generation time
Once generated, an invoice's per-employee amounts SHALL NOT change on their own, regardless of orders added, edited, or removed afterward for that same date range. The only way amounts change is an explicit refresh (see below), and a refresh never overwrites a line already marked paid.

#### Scenario: An order is added after the invoice was generated
- **WHEN** a new order is placed for a date already covered by a generated invoice, and the invoice is not refreshed
- **THEN** that invoice's previously snapshotted amounts remain unchanged

### Requirement: Admin can refresh an invoice's unpaid amounts from current order data
The system SHALL allow an admin to recompute an invoice's not-yet-paid employee lines from current order data, replacing their previous snapshot while keeping the same invoice id, `from`, `to`, and scope. Employee lines already marked paid on this invoice SHALL be left unchanged and SHALL still count toward the invoice's totals.

#### Scenario: Admin refreshes an invoice with no paid lines
- **WHEN** an admin refreshes an invoice that has no employee marked paid
- **THEN** all of the invoice's employee lines are replaced with a fresh snapshot computed from current order data for the same date range and scope, and the invoice keeps its original id

#### Scenario: Admin refreshes an invoice that has some paid lines
- **WHEN** an admin refreshes an invoice that has at least one employee marked paid
- **THEN** the paid employee lines keep their existing frozen amount and paid state, while the remaining unpaid lines are recomputed from current order data

### Requirement: Invoices cannot have overlapping date ranges when their scopes could bill the same employee
The system SHALL reject generating a new invoice whose date range overlaps an existing invoice whose scope contains, is contained by, or is identical to the new invoice's scope - an unspecified company means "all companies". Two invoices scoped to different, specific companies do not conflict even if their ranges overlap. This check SHALL be atomic against concurrent invoice generation, so two requests racing for the same or a containing/contained scope cannot both succeed.

#### Scenario: Overlapping invoice for the exact same scope
- **WHEN** an admin generates an invoice for a range that overlaps an existing invoice with the exact same company scope
- **THEN** the request is rejected, and the response identifies which existing invoice conflicts

#### Scenario: An all-companies invoice conflicts with any company-specific invoice
- **WHEN** an admin generates an invoice with no company scope (all companies) for a range that overlaps any existing invoice, regardless of that invoice's own scope
- **THEN** the request is rejected

#### Scenario: Different companies do not conflict
- **WHEN** an admin generates an invoice for a range that overlaps an existing invoice scoped to a different company
- **THEN** the new invoice is created normally

### Requirement: Admin can mark/unmark an employee as paid within an invoice
The system SHALL allow an admin to mark or unmark, independently for each employee line within a specific invoice, whether that employee has paid.

#### Scenario: Admin marks an employee paid within an invoice
- **WHEN** an admin marks employee X as paid within invoice Y
- **THEN** employee X's line within invoice Y reflects paid, without affecting employee X's status on any other invoice

### Requirement: Admin can delete an invoice
The system SHALL allow an admin to delete a previously generated invoice at any time, regardless of whether any of its employee lines are marked paid. Deleting an invoice frees its date range and scope for a new invoice to be generated.

#### Scenario: Admin deletes a mistakenly-generated invoice
- **WHEN** an admin deletes an invoice
- **THEN** the invoice and its employee lines no longer exist, and a new invoice can be generated for the same (or an overlapping) date range and scope