Session package management for aesthetic clinics

The catalog prepares the offer before a sale

The clinic stores a name, type — package or monthly plan —, session count, total price, per-session price and, when relevant, an active base service. An item can be edited, disabled and enabled again without deleting its record.

The catalog accepts one to 365 sessions. Monthly plan is an offer classification; it does not create automatic recurring billing, which remains a separate payment workflow.

• A unique name in the clinic catalog
• Base service validated inside the same clinic
• Only active items are offered in a new sale

A sale keeps a snapshot for the client

In the client profile, the team selects an active catalog item and records its name, total sessions and price. Those values become a sale snapshot, so editing the catalog later does not silently change a package already purchased.

The operation confirms the client belongs to the clinic and requires front-desk permission. Recording a package documents access to sessions; it does not by itself process or reconcile a payment.

The balance tracks what was purchased and used

The client profile shows total and used sessions, a progress bar and the current state. After a use, the server returns the new used-over-total count instead of relying on a browser-only calculation.

When one or two sessions remain, the system attempts a deduplicated renewal notice. The final use changes the state to finished, and no use can take the count beyond its total.

Each appointment consumes one session only once

A use requires an existing appointment for the same client. In one transaction, the package is locked, expiry and balance are checked, the count is incremented and the use stores its appointment, package, client, state and responsible user.

An idempotency key and the appointment itself protect the operation. An exact retry returns the stored result; conflicting combinations are rejected instead of consuming a second session.

• Increment requires an active package with remaining balance
• One appointment cannot consume another package through a retry
• Every use leaves an audit record

Expiry follows the clinic's local date

A package can have no expiry or a civil date. When listing and before using it, the system compares that date with the clinic's configured time zone rather than the server's UTC date.

Once the date has passed, active becomes expired and the change is audited. The system checks again if the local date changes during the operation.

States preserve the operational history

A package begins active, becomes finished after all sessions are used and may become expired by date. A manager can cancel it while preserving the record and its balance at that point.

The interface distinguishes active, finished, expired and canceled. Concurrent cancellation and use are serialized, and an unexpected change asks for a refresh instead of overwriting the latest result.