* validate slapos_manual_accounting_trade_condition
* propagate ledger from order builder
* add ledger to the accounting template
* aggregate source_project on payment
* stop building payment transaction automatically
* drop template_sale_invoice_transaction
  it is only used in one place. Let's create it manually
* try to reduce cast error
* reduce the alarm frequency
* check the payment when it is updated
* drop not needed payzen_sale_trade_condition
* new id generator per node is used
* test: make the html differences more visible

* test: always create open order before trying to allocate
* define subscription prices on Sale Trade Condition
  Prices are defined on Supply Line inside Sale Trade Condition.
  Drop prices from Subscription Condition.
  Instead, link the Subscription Condition to a Sale Trade Condition.
  Apply the Sale Trade Condition on the created Open Sale Order.
  Stop duplicating properties from the Subscription Condition to the created Subscription Request.
  Payment is managed by the 'payment' category, and not the language.
  This allows to remove all '==zh' conditions.
  Instead, use custom Sale Trade Condition.
* use explicit id to improve understanding of all paths
  Clarify trade condition title
* use the trade condition reference instead of the id
  sale trade condition are versionned.
* no need to rely on the catalog to validate the trade condition
* factorise code
* add new trade condition versions
* The new versions do not include any price informations.
  It is needed to create new Trade Condition which inherite from those versions.
  Update preference to use those latest trade conditions.
* rename couscous trade condition
* remove zh templates
* change subscription price. Do not defined it as ttc
  Try to understand why price is not always copied
* restore original price
* restore previous price setting
* set round price
* disable invoice generation for consumption to see test impacted
* XXX consumption price must be set to 0
  XXX migrate existing packing list
* no need to create open order slowly
* trade condition has more than one supply line
* WIP create open order for compute node
* alarm to create compute node open order
* categrory
* define comp node subscription price
* add SlapOSLedgerConstraint
* add SlapOSLedgerConstraint on all * Transaction
  XXX FOrces tests to fail as much as possible if ledger is not configured.
  Add test to ensure constraint is configured
* hardcode automated ledger category for the newly created sale packing list
* propagate ledger in the simulation tree
* build ledger category from delivery builders
* aggregate ledger from order builder
* ensure ledger category is allowed on the portal type when using the constraint
* requires ledger on Hosting Subscription, Open Sale Order and Sale Packing List
* hardcode ledger value on Open Sale Order and Hosting Subscription
* open order must propagate the ledger value
* automated ledger path
* add ledger to the accounting template
* source_administration is not used anymore on Compute Node
* source_administration is not used anymore on Compute Node
* add source_project constraint on all portal type requiring a ledger
* set the source_project on the open sale order
* propagate source_project in the simulation/builder
* remove source_project constraint from the ledger property sheet
* add SlapOSVirtualMasterSourceProjectConstraint on all accounting portal types
* use Software Product instead of the service slapos_instance_subscription
* build movement using Software Product
* consider Software Product as a Service
* use Software Product
* search the trade condition with searchPredicateList
* ensure trade condition is found
* disable open order alarm
* disable open order creation
* add slapos_virtual_master_subscription service
* allow using open order for different kind of item
* add constraint to check if open order has a sale trade condition
* reactivate open order alarm
* check if Sale Trade Condition has a business process
* ensure open order line has a resource, price, quantity
* new constraints for open order / sale trade condition
* only automate invoice with automated ledger
* only automate packing list with automated ledger
* only automate packing list with automated ledger
* only automate packing list with automated ledger
* add new business process to go from order to invoice
  This may be temporary.
  Name is bad on purpose for now.
* not sure if it is a good idea to hardcode the business process list...
* do not crash if open order line is not linked to an instance
* force total_quantity to be > 0 instead of checking quantity property
* XXX support Open Order Cell
* XXX constraint must also support Cell
* create Open Order Cell
* first version to fetch trade conditions and prices
* select the correct software release/type on open order
* get price from sale supply
* do not create the open order if the software product can not be found
* set price on the open order
  it requires to create a temp sale order, where sale supply is automatically applied
* SlapOSVirtualMasterSourceProjectConstraint on Sale Supply
* InstanceTree_getSoftwareProduct also return release and type variations
* wip sale supply test
* configure Sale Supply predicate
* test Supply Line matching and getPrice
* allow Supply Line to define price even if resource has variations
  Force quantity unit to match (no convertion for now)
* order Supply Predicate matching
* Supply Cell before Line
* stop hardcoding default quantity unit
* add comment if price not found
* quantity is defined on cell
* do not create Hosting Subscript before the price is found
* slapos_accounting: link Hosting Subscription to project
* Cloud Contract is not global for ERP5 Site, but per Virtual MAster
* project needed on assignment/compute node
* export module business application
* revert zero_emission_ratio service deletion
  I do not remember why I dropped it
* set source/destination_project and ledger on created payment
* drop slapos orga and accounting template
* propagate ledger from order builder
* add ledger to the accounting template
* aggregate source_project on payment
* drop template_sale_invoice_transaction
  it is only used in one place. Let's create it manually
* drop the aggregated packing list logic
  Some parts are still there, but linked to subscription, which I will check later
* testSlapOSAccountingBuilder
  Recreate the expected organisation.
  Drop the aggregated builder test
* revert aggregated builder test removal
* drop consumption/reservation/subscription business process
* drop all trade conditions
* force using ledger=automated
  Disable all simulation logic if the automated ledger is not used
* builder test: set ledger and destination_project
  Use a test trade condition
* drop Base_testSlapOSValidTradeCondition
* update testSlapOSAccountingRule
* drop compatibility with expliciate trade condition usage
* add Project_getAccountingCurrency
* ensore project has a currency before generating an open order
* do not explode the workflow history with the same comment
* testSlapOSAccountingRule stop using hardcoded trade condition
* do not expand packing list if no invoice is supposed to be generated
  (aka, no need for slapos_consumption_trade_condition)
* testSlapOSAccountingBuilder stop using deleted business processes
* testSlapOSAccountingAlarm: only ledger/automated movement are built
* testSlapOSAccountingBuilder: stop using deleted business processes
* testSlapOSAccountingAlarm: update test
* drop usage of createZODBPythonScript
* testSlapOSAccountingInteractionWorkflow: a project is required on the Instance Tree
* stop hardcoding expected trade condition
* testSlapOSAccountingSkins update to latest changes
* testSlapOSEntityCreatePayment: stop using invoice template
* drop Base_useSaleTradeConditionReference
* drop usage of createZODBScript
* call OpenSaleOrder_reindexIfIndexedBeforeLine on an Open Order, instead of the Alarm
* testSlapOSAccountingRule: factorise Sale Supply creation
* test InstanceTree_requestUpdateOpenSaleOrder
* do not invalidate open order, as it breaks the simulation
* keep slapos_legacy_aggregated_subscription_trade_condition_2022 when uninstalling it
* do not duplicate arguments
* set Ban Account from the trade condition source payment
* constraint to check if invoice has a source payment defined
* stop checking specialise == getPreferredAggregatedSaleTradeCondition. Check ledger instead
* build source/destination decision/payment
* no causality on invoice
* do not invalidate open order
* test: define source payment on the open order
* builders: do not merge movement with different prices
* builder: set aggregate on cell, not line
* builder: group movement by specialise
  Previously, we has 1 invoice per simulation tree.
  But we want to reduce the number of invoice, without using the "aggregate" builder trick
* SimulationMovement_buildSlapOS search by specialise
* test that dedicated trade condition / supply are applied
* invoice builder: group movement's date on the delivery level
* invoice builder: dates are now set on delivery. Do not modify causality if it exists
* testSlapOSAccountingBuilder: update quantity unit of software product
* testSlapOSAccountingBuilder: typo
* do not hardcode payzen payment mode
* get payment mode from the trade condition's payment condition
* invoice payment mode is fetched from trade condition
* payzen payment mode is not set anymore on invoice
* source project is not required on Payment Transaction
  Customer can buy Virtual MAster
* do not filter by destination_project__uid=None
  It leads to always return nothing, as it does a join to the category table
* the virtual master subscription Service has a time/month quantity unit
* Open Order, Packing List, Hosting Subscription may not be linked to a Project
* do not aply trade condition if source/destination projects are different from order
* do not require Project on Sale Invoice Transaction
* do not require a Project on Sale Supply
* disable open order creation
* stop creation Open Sale Order from Instance Tree
* deprecate Alarm_requestUpdateInstanceTreeOpenSaleOrder
* trigger alarm as soon as Item are marked as subscribed
* export service_module/slapos_compute_node_subscription
* contraint: source_section is not required on Open Sale Order
  Needed for accounting less Open Order.
* constraint: source_section is not required on Sale Packing List
* constraint: no Organisation as destination / destination_section
* export month quantity unit convertion
  To drop warning in logs
* drop InstanceTree_requestUpdateOpenSaleOrder
* rules: stop diverging on source/destination payment
  Those info are not supposed to be set on order/delivery (ie, there is no field for this)
* drop duplicated config
* set the source payment before finalising the sale invoice
* ensure the same currency is used on Order and Trade Condition
* force all Sale documents to use a consistent price currency
* add script to generate the deposit
* add deposit account
  XXX configuration must be reviewed
* add Deposit service to use on the invoice
* deposit service is not taxable
  XXX to check with accountants
* business process: no need to have 2 credit path
* creation causality link between the deposit payment and invoice
* put destination account in the transaction line
  XXX no way currently to support having no destination if the destination_section does not handle accounting
* add alarm slapos_update_delivery_simulation
  Generate invoice from packing list
* generate accounting for resource_use/use/trade/deposit
* add slapos_simulation_interaction_workflow
  Speed up execution of the simulation process by triggering alarms as soon as it is needed
* generate Open Order simulation as soon as it is simulated
* do not stop invoice until the stop date is passed
* stop setting the source_payment on the Invoice
  It is too early, and prevent other Simulation Movement to be aggregated
* set source_payment just before closing the invoice
* checkConsistency after the source_payment is set
* serialise on business link to try grouping all user invoices movements
* destination project is not required on invoice
  Do not search with a None value
* Extend the invoice causality with the parent simulation movement explanation
* drop not needed movement group
  Previous movement group already force the same invoice
* use the discount_service on the discount service
  No idea if it is a good idea or not for now
* generate accounting movement for discount service
* also compare invoice price with discount sale packing list
* no need to update open order period anymore
* drop unused script
* drop unused slapos_request_update_instance_tree_open_sale_order
* drop unused SubscriptionRequest_*etAggregatedConsumptionDelivery
* drop not needed slapos_start_confirmed_aggregated_subscription_sale_packing_list
* drop slapos_api_invoicing_workflow
* add an alarm to close the open order
* no need to reindex open sale order
* expand the open order one last time, to no miss any period
* use Base_reindexAndSenseAlarm
* drop jump_related_grouped_sale_packing_list
* drop slapos_contract_request_validation_payment alarm
* drop unused script
* drop Project_getAccountingCurrency
* test: slapos_request_update_instance_tree_open_sale_order was dropped
* test: drop outdated tests
* test: update titles
* test: InstanceTree_requestUpdateOpenSaleOrder was dropped
* test: drop tests related to dropped scripts
* test: use valid trade condition to generate the simulation
* only run alarm once per day
  Interaction workflow are now supposed to trigger the alarm when needed
* run alarm once per day
* require trade_condition_type on Sale Trade Condition
* search Sale Trade Condition by trade_condition_type
* set trade_condition_type on temporary Sale Order
* ensure trade_condition_type matches
* disable packing list generation from tioxml
  Everything is broken currently...
* drop testSlapOSContractAlarm
* drop create_new_cloud_contract action
* drop jump_to_cloud_contract action
* test: SoftwareInstance_requestValidationPayment was dropped
* drop CloudContractLine_getRemainingInvoiceCredit
* drop Person_isAllowedToAllocate
* drop Entity_statSlapOSOutstandingAmount
* test: change class inheritance
  do not inherit from a class with existing test, as it forces subclass to keep exactly the same test function name
* lint: do not redefine id variable
* fix: do not use unrelated causality value
  Builder passes all movement used to generate all the invoice
* allow closing the invoice has soon as the stop date value is reached
* test: wip accounting checks
* do not access the object if not needed
* drop Entity_statOutstandingAmount
* wip Entity_hasOutstandingAmount
* wip: create from multiple invoices
  using Entity_getOutstandingAmountList
* group also outstanding amount by ledger
* drop PaymentTransaction_start
* use the same ledger than the payment transaction
* create Payment Transaction to pay all user's invoices
* improve Payment line title
* allow to pay invoices at a date
* test paying invoices
* test: fix create payment tests
* drop preferred_default_pre_payment_subscription_invoice_template_property
* test: templates were dropped
* drop preferred_default_pre_payment_template
* drop getPreferredAggregatedSubscriptionSaleTradeCondition
* drop preferred_aggregated_sale_trade_condition
* test: unused variable
* test: fixup testSlapOSAccountingConstraint
* test: fix trade condition retrieval
* drop preferred_instance_delivery_template_property
* drop slapos_accounting_instance_delivery_template
* drop slapos_accounting_instance_delivery_line_template
* drop preferred_aggregated_consumption_sale_trade_condition
* drop SlapOSAccountingSystemPreference
* keep organisation_module/slapos/bank_account
* disable packing list generation from tio xml
  this is not critical for now, and will be upgraded later
* fixConsistency is not called anymore on Hosting Subscription
* drop template_compute_node
* drop template_member
* test: there is no causality_state anymore on instance tree
* test: fix consistency on Hosting Subscription does not set the periodicity date
* drop unused script
* reduce number of sale trade condition to check
* stop using fixConsistency to set hosting subscription periodicity
  Set it directly from the script which create it
* reduce alarm frequency
* constraint: be consistent if invoice has no source payment
* check more usable invoices
* do not forget to retry building the simulation movement
* test invoice generation and aggregation
* test: fixup trade condition retrieval
* try to reduce conflicts when building the deliveries
  No need to trigger multiple build for the same group of movements
* drop not needed serialize
* fix open order simu tests
* test fix TestDefaultTradeModelRule
* test: fix one test
* test: fix builder tests
* drop unused AccountingTransactionModule_getUnpaidInvoiceList
* only check Invoice amount
* use default parameters
* do not hardcode any reversal trick
  Invoice must be correctly grouped.
* Entity_getOutstandingAmountList parameters default value changed
* use SaleInvoiceTransaction_isLettered script
* show Cancelled status on reversed Invoices
* do not check reversal transaction to display state
  it is impossible to understand
* do not check payment_mode when creating reversal invoice
* only show the reversal action to accountant
* drop not needed SaleInvoiceTransaction_resetPaymentMode
* test: use PinnedDateTime from mixin
* archive Compute Node, Project open order and hosting subscription
* archive Open Order as soon as Item is invalidated
* test: checking float equality is not absolute
* allow destination_section to be an Organisation
* fixup deposit account configuration
* test: set the destination on the Payment Transaction
* add deposit debit business path
* generate tax accounting movement only if the total price is not 0
* product can have different trade model line applying
* try to limit errors in the simulation with checkConsistency
* check that taxable base_contribution is correctly set on Movement
* ensure the source_section has a region set
* script to calculate the vat rate of every line of a sale delivery
* do not check VAT calculation if no accounting is generated
* add more constraint on the delivery destination section
* VAT calculation

A Software Product is a variated resource with 2 axes:
- Software Product Release Variation (optional variation),
  to not force updating Order/Delivery every time one Instance is upgraded
- Software Product Type Variation
It is linked to a Project (virtual master).

Redesign the Upgrade Decision logic.
It is now a Ticket, generated by the Allocation Supply configuration:
- upgrade is different for every Project
- upgrade can be triggered on a specific Node, or for a specific user

Upgrade Decision is created automatically only if there is a single possible release allocable
for a Software Product.
Otherwise, it must be created manually.

The Upgrade Decision must be approved by the Project manager,
who is responsible for the Allocation Supply configuration.

Also in this commit:
* drop template usage
* trigger alarm with interaction workflow

A project reference is required to create a compute node.

Add compatibility with the user request
Console client does not send a project reference.
Try to guess it for simple cases

Drop the allocation scope open/subscription/public logic.

Instead, use Project as Virtual Master, and force
all slapos_cloud object to be linked to one Project:
* every Compute Node is linked to a Project
* any Project's Instance can be allocated on a Project's Compute Node

Allocation is managed by configuring an Allocation Supply document,
which defined on which Compute Node a Software Product can be allocated.

User are not allowed anymore to change the release/type/shared state of their Instance Tree.

Managing Compute Node is done on the virtual master level, and so,
there is no need to define any Compute Node administrator.

A Software Product is a variated resource with 2 axes: software release url and softare type.

Slave Instance are now allocated on Instance Node, which is created
from the Software Instance which will control the configuration.
Slave Instance allocation is also controlled by an Allocation Supply,
which allow separating the Software Instance and Slave Instances versions.

There could be any number of virtual master in the system.
Every virtual master defines its own Software Products.
Because of this, it is not possible to change a document's virtual master
after its creation.

Instance request can be propagated on another virtual master, by
allocating them on a Remote Node document, which will generate
a new Instance Tree request on another virtual master.

Also in this commit:
* trigger alarms as soon as possible with interaction workflow
  which allows to reduce some alarms frequency
* drop never used Organisation logic
* drop person.requestSite
* drop audit_validation_workflow
* drop ComputePartition_getCustomAllocationParameterDict
  This is a hack incompatible with virtual master standalone logic.
* drop cloud contract
* do not sort security base category when generating local roles
  Otherwise, it is not possible to ensure source_section/function and destination/function generate the same local role
* stop using hardcoded currency/organisation/trade condition/business process
* drop templates usages
* add One Time Virtual Master Access Token portal type
  Needed for compatibility with the compute node deploy script

* add new business application categories
* export edger category
* automated ledger is not only for accounting
* drop allocation_scope/open categories
  All compute nodes are public now
* add use/trade/deposit category
* do not use the same title for 2 categories
* Add trade condition type categories.
  This will be used to automatically select a Trade Condition in slapos_accounting
* add invoicing taxable vat categories

* drop default_or_child_aggregate_reference
* drop  default_or_child_aggregate_uid catalog key
* drop unused follow_up_default_or_child_aggregate_uid
* drop causality_subscription_request_related_uid related key

This make usage of the relationfield nicer.

This reverts commit d127603b.

  This is required due interacton workflow call on _setAlloctionScope.

  We could change the capacity_scope to close (so allocation worklfow order dont matter, but
  it would change the expected behaviour if we drop the interaction workflow, so it is more
  reasonable keep the existing behaviour unchanged.

See merge request nexedi/slapos.core!615

same as nexedi/erp5@2e366054

With the previous approach, the test depend on the order of attributes,
but this order is not stable when hash randomization is enabled and we
don't care about order of attributes in this test.

This is no stable with hash randomization, with PYTHONHASHSEED=593 this
test failed.

slapos_cloud:testSlapOSCloud fails with PYTHONHASHSEED=385

this is done by upgrader in production, so it's consistent to do it
before test

sorted and with the usual workaround for trailing space bug

See merge request nexedi/slapos.core!613

See merge request nexedi/slapos.core!614

  This is quite specific to project based instances, so no need to add into every instance

  Test some particular cases or features that MUST not be used, to ensure nobody the editor is handling it properly.

See merge request nexedi/slapos.core!609

See merge request nexedi/slapos.core!612

  Latest version had significant changes, so pin the version for now

See merge request nexedi/slapos.core!611

Since ERP5 commit 6546e47f51 (erp5_software_pdm: a Software Product is
a Service, 2022-09-07), the message changed

  This cause editor do not render the form.

   It is better use the parameter_xml directly since, since there are no need for the editor
   handle hashed version of the parameters.