Update invoice_subsystem.adoc

userguide/tutorials/invoice_subsystem.adoc

@@ -6,7 +6,7 @@ Driven by the entitlement and subscription modules, along with the catalog confi
 
 Before we dig into examples, let's review some of the characteristics of the invoicing algorithm. The first thing to recall is that there are different ways to invoice customers and this is specified inside the catalog configuration. For the sake of simplicity we will discard usage-billing altogether here and focus on recurring subscriptions (along with fixed-term charges).
 
-Invoicing for recurring subscriptions also comes in two different fashions, or so called `billing modes`. Such a mode is defined at the catalog level, and there are 2 options:
+Invoicing for recurring subscriptions also comes in two different fashions, or so called `billing modes`. Such a mode is defined at the `Plan` level-- with a possible default at the catalog level -- and there are 2 options:
 
 * `IN_ADVANCE`: In such a configuration, each recurring subscription is charged at the begining of the period (in advance), and as a consequence, this can lead to pro-ration credits upon certain cancellation or change of `Plan` (special policies can be configured to make the system generate or not such pro-ration credits).
 * `IN_ARREAR`: In such a configuration, each recurring subscription is charged at the end of the period (in arrear), and as a consequence there is never any pro-ration credit generated because the system always know what to bill for (things can't change back in time).
@@ -1265,7 +1265,9 @@ First, the system now has a safety bound mechanism on the upper limit of invoice
 
 Second, the invoicing system will automatically park an account when an illegal state is reached during invoicing. This could be because the data associated with the account looks corrupted (which could happen because of previous bugs that did corrupt the data, manual data manipulation, or existing bug in the system).
 
-The way to get out of that state is to fix the issue that lead to that state in the first place and trigger a new invoice generation. For cases where there are many parked acounts, we have added an administrative https://github.com/killbill/killbill/blob/killbill-0.18.6/jaxrs/src/main/java/org/killbill/billing/jaxrs/resources/AdminResource.java#L262[api] to go through all parked accounts and issue an invoice generation for each of those, only leaving in the parked state, accounts whose state has not been fixed yet. If you think the issue that lead into that state is not a problem with the account state (data) but a bug in the system, please report to the https://groups.google.com/forum/#!forum/killbilling-users[mailing list].
+The way to get out of that state is to fix the issue that led to that state in the first place and trigger a new invoice generation. If this issue arose because of a bug, fixing the issue may require voiding invoices creating the issues. 
+
+For cases where there are many parked acounts, we have added an administrative https://killbill.github.io/slate/#admin-trigger-an-invoice-generation-for-all-parked-accounts[api] to go through all parked accounts and issue an invoice generation for each of those, only leaving in the parked state, accounts whose state has not been fixed yet. If you think the issue that led into that state is not a problem with the account state (data) but a bug in the system, please report to the https://groups.google.com/forum/#!forum/killbilling-users[mailing list].
 
 == Summary