[Feature Request]: Support token sheet operation

[dmohns]

Preflight Checklist

• I have read the Contributing Guidelines for this project, if it exists.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Some SHS providers provide their Tokens (unlock and time-based) as xlsx sheets which are shipped with the SHS.

Currently, MPM cannot work with sheet based tokens, as we always rely on the existence of an (third party) API to generate Tokens.

Users that wish to digitalise their operations maybe continue to rely on these sheets. It would be great if MPM work seamlessly with these.

Proposed Solution

Introduce a mechanism that allows users to upload and manage token sheets for individual SHS devices. When MPM processes a payment for a device with an associated token sheet, it should automatically assign and send the next available token from that sheet.

For this to work reliably, users would need following feature set

1. Token Sheet Upload

   • Allow users to upload a token sheet and associate it with a specific SHS device.
   • Support common formats (e.g., CSV or similar structured data).

2. Automatic Token Allocation

   • When a payment is processed, MPM should:
     • Select the next unused token from the associated token sheet.
     • Mark the token as used once it has been assigned.

3. Token Visibility & Management

   • Provide a clear overview of all tokens per device, including:
     • Used tokens
     • Available tokens
   • Allow users to:
     • Manually mark tokens as used or unused
     • Edit or correct token states retrospectively (e.g., if a token was used outside of MPM)

4. Auditability (Optional but Recommended)

   • Track when and how tokens were used (e.g., via MPM vs. manual update)
   • Provide basic history/logging for traceability

Alternatives Considered

N/A

Additional Information

Open Questions / Considerations

• Should this functionality be implemented:
  • As part of the core system (provider-agnostic), or
  • As a plugin-specific feature depending on the SHS provider?
• Are there provider-specific constraints that would influence token handling logic?