Overdue changes to support Hierarchical Account

For all the existing overdue handlers in OverdueListener the code needs to now detect when this is parent account and propagate the changes to the children (in addition to itself).

OverduePoster needs to be called to create a new notification for each child so processing happens asynchronously

Tests:

• Create unit in overdue with one parent and a few children

[sbrossie]

@matias-aguero-hs I see… our api is a bit confusing (and broken in my opinion) and you just took advantage of that: We allow to pass both an accountId and a context (which contains an accountRecordId). The assumption is that both accountId and accountRecordId should point to same account, but there is nothing enforcing that, so what you described is correct.

At some point we will need to revisit that (at the very least add some comments) and a better solution would be to remove accountId and simply rely on the context. This is fine for now. Nothing to do. Let’s move on.

[matias-aguero-hs]

You’re right, the code is sending childAccount object and parentAccountContext. The unpaid invoices are retrieving by context and childAccount object is used to build the BillingState object result. That’s why the code is using both accounts.