Terms: will use FDM2 – as the name of future-redesign of current FDM.

• The FDM database become ugly with most of new features we added here
• Sometimes the data dublicated from user's view like the same cinemas, the same countries
• Most reports uses special calculation block to have the same results, and it's work too slow, very hard for the server
• We can not move some code into quicker PHP code because the calculation block too complex
• The program applies all exchange rates everytime on running any report, this process eat CPU power, the website is working slowly
• Some of new features broke the basic FDM concepts used with first databases structure

• The database will have better logical structure
• All dublicates in data will be removed
• We can add some things that will be familar for users from other countries
• We can use both PHP and C# code for FDM2 parts
• Based on PHP libraries – we can add the support of HTML / PDF reports out
• We'll minimize the volume of calculations for the unit Calc

We needed to fix all prices for every day. This is needed to eliminate bugs with differences in numbers.

These bugs coming everyday and every month. The reason – calculate-based design of FDM database.

I think we should remove this way, and make all numbers final.

So, box office record in FDM2 will be as a set of days 1-7.

Every day will have next structure

Primary keys: date_on, films_id (may be prints_id), screens_id, formats_id, usual

Fields: nbo_lc, gbo_lc, attd, nbo_us, gbo_us, locked

Note: Fixed invoice will add more day records into the box_office line (usual = 0 – usual day, 1 – fixed)

Questions:

• May be better to assign the day with the film copy (prints_id) than with the TITLE (films_id)?
• Royalti? May be royalti also should be fixed and calculated here.