Goal: make FDM more reliable, stable and recent.

Full redesign of the database.

Concept of atoms.

One atom = film + screen(in cinema) + day

each atom has fixed exchange rate for local currency for this cinema

In feature such record could be modified but as an additional delta for each position only:

• number of attendance (sold tickets)
• cost of them
• gbo
• nbo
• …

Of course we may also store each ticket. But I think enough to summarize them into 'atomic day'.

Each atom store info about the user who did entered it.

If the atom require to be modified – that will be new atom refer to old one as 'modified' atom.

That I've describe main processing being with films.

For cost calculation we may also review and write how it should be look as.

• never delete old records
• never change old records
• the reports should calculate data by adding to atoms all modifiers which whatever happening

Ok, this approach in use in blockchain for example – all data being stored forever. Easy to know what was happened in past time.

The database after the update may be have less tables. I think we will use InnoDB engine and transactions.

• well work with correct exchange rates
• fix invoice feature
• not need to lock months
• less bugged calculation engine
• simplified logic of calculations

The goal to use the recent technologies which getting much better in last years. C# now has future methods and a lot of other logical improvements.

I think to create atomic structure using current database.

When engine will be ready – we will run all tests to compare old reports with new reports may be even in automic mode which will go through excel reports and compare each cell automatically.

Then from some day we will go to fdm_2

ok, this is my draft about how it could be