anchor.diff:          tenant_record_id: 338
    1 row in set (0.00 sec)
   
  - mysql> 
  + mysql>
    mysql> select * from payments where account_id = 'ea58b7dd-eb23-4065-a3e5-980291d45ab8'\G
    Empty set (0.01 sec)
  - 
  +
   ----
   
   
  
positive.code: 
  == Overview
  
  Starting with Kill Bill 0.18.x, we have introduced support of HA (Hierarchical Accounts), and so in this tutorial we will review first what the feature is about, and then explore how it works and which apis to use.
  
  Let's review first what we have prior to introducing the HA feature: In the Kill Bill terminology, a customer will be represented as a Kill Bill `Account`, and such `Account` will then be invoiced based on its current subscriptions and one-off charges. Payments will also be made by using the default payment method associated with the `Account`.
  
  The idea with the HA feature is to delegate some of the payment operations associated to an `Account` to a `parent Account`. Some typical use case for the feature are:
  
  * Affiliate model: In the affiliate model, payments associated to some customers are made through the `parent Account` but each individual `Account` will manage its own subscriptions and will have access to the associated invoices.
  * Sub-Organization: In large organizations, it is common to see sub organizations that work independently, and yet parent organization is responsible for the payments.
  
  The new HA feature allows for the following:
  
  * Ability to set an `Account` as the child of another `Account`
  * Ability to specify on an `Account` that it will be responsible for paying its own invoice (current behaviour)
  * Ability to specify on an `Account` that the parent will be responsible for the payments
  * Ability to transfer credit from child 'Account' to parent 'Account'
  * Ability to list all children `Account`
  
  == How does it work?
  
  The Kill Bill `Account` abstraction has been enhanced to allow specifying a parent `Account` and whether or not that parent `Account` is responsible to pay children's invoices. A parent `Account` is an `Account` that contains one or more children `Account`. When such a parent `Account` exists and when its children have been configured to delegate their payments, the following happens:
  
  1. Every time the system computes a new invoice (or adjusts an existing one) for a given child `Account`, the parent gets notified and also computes a special summary invoice that will include all the items for all the children on a given day.
  2. The payment system will ignore the child invoice as it knows this should be paid by the parent.
  3. At the end of each day (UTC time), the summary invoice will transition from `DRAFT` to `COMMITTED`
  4. As a result, the payment system will attempt to make a payment for the parent summary invoice using the default payment method associated to the parent `Account`.
  
  As we can see, each child `Account` can still have its own subscriptions and matching invoices, but associated payments are delegated to the parent through the daily computation of a summary invoice.
  
  The balance associated with both the child invoice and parent summary invoice will be zero until the end of the day when the transition from `DRAFT` to `COMMITTED` occurs. At this point, if the payment succeeds, then such invoice balances remain to zero. If not, then each invoice balance (child and parent) becomes equal to its invoice amount.
  
  In terms of dunning (overdue), since parent `Account` are the one making the payments, then overdue system will compute dunning state based on the per-tenant overdue configuration and parent `Account` 's payment state. The children `Account` will inherit the same dunning state as their parent. As a result one unpaid parent invoice that did not contain any invoice item for a given child would still put this child in an overdue state.
  
  
  == Tutorial
  
  Let's create a child `Account` associated to one parent `Account` to see what happens (we assume the defauly demo bob/lazar tenant already exists):
  
  
  Let's create first the parent `Account` (we can see its ID in the `Location` header that is being returned) and also add a default payment method:
  
  [source,bash]
  ----
  
negative.code: == Conclusion
  
  There is a lot more to demo (regarding dunning, invoice adjustment, ...), but this should provide a highlight of what the feature is about. Note that this is a new feature in 0.18 and as such it should be seen as Beta (you are responsible to verify it works accordingly to your use case, load, ...).
  