remove big mistake: orders from product

Signed-off-by: Nico Schottelius <nico@nico-notebook.schottelius.org>

doc/uncloud-manual-2020-08-01.org

@@ -84,6 +84,14 @@ python manage.py migrate
 * URLs
   - api/ - the rest API
 * uncloud Products
+** Product features
+   - Dependencies on other products
+   - Minimum parameters (min cpu, min ram, etc).
+   - Can also realise the dcl vm
+     - dualstack vm = VM + IPv4 + SSD
+   - Need to have a non-misguiding name for the "bare VM"
+   - Should support network boot (?)
+
 ** VPN
 *** How to add a new VPN Host
 **** Install wireguard to the host
@@ -219,7 +227,85 @@ VPNNetworks can be managed by all authenticated users.
      - Product
 ***** TODO Recurring product support
 ****** TODO Support replacing orders for updates
-****** TODO [#A] Finish split of bill creation
-****** TODO [#A] Test the new functions in the Order class
+****** DONE [#A] Finish split of bill creation
+       CLOSED: [2020-09-11 Fri 23:19]
+****** TODO Test the new functions in the Order class
+****** Define the correct order replacement logic
+       Assumption:
+       - recurringperiods are 30days
+******* Case 1: downgrading
+        - User commits to 10 CHF for 30 days
+        - Wants to downgrade after 15 days to 5 CHF product
+        - Expected result:
+          - order 1: 10 CHF until +30days
+          - order 2: 5 CHF starting 30days + 1s
+          - Sum of the two orders is 15 CHF
+        - Question is
+          - when is the VM shutdown?
+            - a) instantly
+            - b) at the end of the cycle
+          - best solution
+            - user can choose between a ... b any time
+******* Duration
+        - You cannot cancel the duration
+        - You can upgrade and with that cancel the duration
+        - The idea of a duration is that you commit for it
+        - If you want to commit lower (daily basis for instance) you
+          have higher per period prices
+******* Case X
+        - User has VM with 2 Core / 2 GB RAM
+        - User modifies with to 1 core / 3 GB RAM
+        - We treat it as down/upgrade independent of the modifications
+
+******* Case 2: upgrading after 1 day
+        - committed for 30 days
+        - upgrade after 1 day
+        - so first order will be charged for 1/30ths
+
+******* Case 2: upgrading
+        - User commits to 10 CHF for 30 days
+        - Wants to upgrade after 15 days to 20 CHF product
+        - Order 1 : 1 VM with 2 Core / 2 GB / 10 SSD -- 10 CHF
+          - 30days period, stopped after 15, so quantity is 0.5 = 5 CHF
+        - Order 2 : 1 VM with 2 Core / 6 GB / 10 SSD -- 20 CHF
+          - after 15 days
+          - VM is upgraded instantly
+          - Expected result:
+            - order 1: 10 CHF until +15days = 0.5 units = 5 CHF
+            - order 2: 20 CHF starting 15days + 1s ... +30 days after
+              the 15 days -> 45 days = 1 unit = 20 CHF
+            - Total on bill: 25 CHF
+
+******* Case 2: upgrading
+        - User commits to 10 CHF for 30 days
+        - Wants to upgrade after 15 days to 20 CHF product
+        - Expected result:
+          - order 1: 10 CHF until +30days = 1 units = 10 CHF
+
+          - order 2: 20 CHF starting 15days + 1s = 1 unit = 20 CHF
+          - Total on bill: 30 CHF
+
+
+****** TODO Note: ending date not set if replaced by default (implicit!)
+       - Should the new order modify the old order on save()?
+****** DONE Fix totally wrong bill dates in our test case
+       CLOSED: [2020-09-09 Wed 01:00]
+       - 2020 used instead of 2019
+       - Was due to existing test data ...
+***** TODO Bill logic is still wrong
+      - Bill starting_date is the date of the first order
+      - However first encountered order does not have to be the
+        earliest in the bill!
+      - Bills should not have a duration
+      - Bills should only have a (unique) issue date
+      - We charge based on bill_records
+        - Last time charged issue date of the bill OR earliest date
+          after that
+        - Every bill generation checks all (relevant) orders
+          - add a flag "not_for_billing" or "closed"
+          - query on that flag
+          - verify it every time
+
+
 ***** TODO Generating bill for admins/staff
       -