Identity and identifiers

MyHoreca Pay uses UUID version 7 for all new internal identifiers.

Rules

Area	Rule
Domain entities	Primary key `Id` is `Guid` (UUID v7)
PostgreSQL	Business/domain PK columns are `uuid`
Generation	Use `IUuidGenerator.NewUuidV7()` — never `Guid.NewGuid()` for persistent entity IDs
EF Core	Do not assign IDs in `OnModelCreating` or entity configurations
Database defaults	Do not rely on `gen_random_uuid()` for business IDs unless explicitly approved and documented as UUID v7
Frontend	Treat backend IDs as opaque UUID strings; never send client-generated IDs as persistent entity IDs

csharp

public interface IUuidGenerator
{
    Guid NewUuidV7();
}

Implementation: UuidV7Generator in MyHoreca.Pay.Infrastructure, registered as a singleton in DI.

The project targets .NET 10 and uses the built-in Guid.CreateVersion7() API behind IUuidGenerator.

Entity creation in application services, import pipelines, auth/audit, and seeding receives IDs from IUuidGenerator via constructor injection.

Unit/integration tests may use DeterministicUuidV7TestGenerator (see MyHoreca.Pay.UnitTests) for predictable IDs.
UuidV7GeneratorTests assert generated values are version 7.
UuidV7PolicyTests (architecture tests) fail the build if Guid.NewGuid() appears in domain/application/persistence/infrastructure/bank-statements source (excluding migrations and build output).

API responses expose entity IDs as UUID strings (string in TypeScript contracts).
React lists/forms may use clientKey or tempId for local-only keys (e.g. draft rows before save). These must never be posted as id for existing backend entities.
Document IDs from Syrve/iiko remain external strings and are not generated by the Pay backend.