Migration of tenants from Conta DIY to Patron

Conta DIY has en endpoint that can be used to export all tenants and push them to Patron. We need a migration cli tool that uses the admin endpoint in Conta DIY to export tenants and then imports them into Patron.

User authentication is synced since Conta DIY uses it for authentication. UserProfile data is not synced between firestore and Conta DIY. Other services (salary, pracsys, finsta, patron) has no local information about a user, and only refers to them by user id.

Conta DIY receives events when tenants are created and updated, but currently does nothing with them. This way they can keep their data in sync. This is the same as all other services do (salary, pracsys, finsta).

The Patron frontend expects that every tenant has an organization number. The pages "work" with tenants without organization number, but some of the elements looks wrong. We also need support to create personal tenants in the registration pages.

Conta Standard and Conta Smart is purchasable from Patron. We need to determine what other products should be purchasable from Patron and how to handle invoicing, upgrade, downgrade, cancellation etc. We already have events for purchases that Conta DIY can respond to.

Today we have a manual invoice job that runs on demand. This job creates a draft invoice in Conta DIY and marks the period in Patron as invoiced. The draft is later accepted manually by Sandra. There is a big risk to move all invoicing to Patron in one go.

One suggestion is that purchases of Conta Standard/Smart directly in Patron should be invoiced in Patron. This requires that these products is somehow marked in Conta DIY so they don’t get invoiced from there.

The invoicing job needs an overhaul to run automatically with service accounts using custom tailored apis in diy for fetching and creating customers. It also needs to have knowledge of all products for Conta AS in DIY.

We must expose anonymous data to PowerBI so management can track usage of our services. In DIY they expose selected db-tables directly. We do not want to do this.

Start page must be redesigned to fit needs of all tenants that can use our products. This means improving the flow for managing access, subscription and tenant settings/details, as well as onboarding new customers. Customer onboarding will firstly be managed by DIY using patron APIs, but will in time be moved to start page as one common place to do customer onboarding.

We want shorter tenant ids to make it easier for integration partners to use our services. Also, more human readable ids will be used HRIs).

We must implement support for tenant lifecycle from provisioning to cancellation of subscription to deletion. Also includes export of tenant data. User deletion relates in the sense that we cannot delete a user that is the sole owner of a tenant.