anchor.diff:  </overdueConfig>
   ----
   
  +In more details:
  +
  +* `WARNING`:
  +** `timeSinceEarliestUnpaidInvoiceEqualsOrExceeds` is set to 10 days as specified by the scenario
  +** `blockChanges` is set to true to prevent users from changing plans
  +** `disableEntitlementAndChangesBlocked` is set to false, since we still want the user to have access to the service
  +** `autoReevaluationInterval` is set to 4 days to make sure that if there is no payment (which would trigger a re-evaluation of the overdue state), the state will be correctly recomputed and transition to `BLOCKED` 4 days later
  +* `BLOCKED`:
  +** `blockChanges` is set to true to prevent users from changing plans
  +** `timeSinceEarliestUnpaidInvoiceEqualsOrExceeds` is set to 14 days as specified by the scenario
  +** `disableEntitlementAndChangesBlocked` is set to true since we now want the user to NOT have access to the service
  +** `autoReevaluationInterval` is set to 8 days to make sure that if there is no payment (no overdue trigger), the state will be correctly recomputed and transition to `CANCELLATION` 8 days later
  +* `CANCELLATION`:
  +** `subscriptionCancellationPolicy` is set to `END_OF_TERM` to indicate that subscriptions should be cancelled in such a way that we do not generate credit for the account (no proration)
   
   === Payment retries
   
  -In addition we need to configure the payment system to retry failed payments; the system property `org.killbill.payment.retry.days` specifies the retry policy associated to payment failures. In our case we need to set it to `1,1,8` to indicate 3 payment retries, the first one after 1 day, and then 1 day after, and the last one 8 days after the previous one (as specified in our scenario).
  -
  +Additionally, we need to configure the payment system to retry failed payments. Each time a payment is retried, the overdue system will react and adjust the state depending on the payment status.
  +
  +Kill Bill comes with a built-in retry mechanism. The property `org.killbill.payment.retry.days` specifies the retry schedule for payment failures (e.g. insufficient funds). In our case, we need to set it to `1,1,8` to indicate 3 payment retries, the first one after 1 day, then 1 day after, and the last one 8 days after the previous one (as specified in our scenario).
  +
  +Additionally, if you need more granularity in how you want to retry payments, you can implement your own logic in a Payment Control plugin (which goes beyond the scope of this tutorial).
   
   [[customers]]
   == Example of Customers
  
positive.code: 3. The system should block the entitlements associated with the account after 14 days
  4. The system should automatically cancel the subscriptions after 21 days
  
  == Configuration of the System
  
  === Catalog Configuration
  
  Your catalog will contain a plan entry that specifies two phases, one for the trial period and one for the recurring monthly charge of $10 -- note that we omitted the other parts of the catalog such as alignment rules, ... which is beyond the scope of this tutorial:
  
  [source,xml]
  ----
  <plan name="movies-monthly">
      <product>Movies</product>
      <initialPhases>
         <phase type="TRIAL">
             <duration>
                 <unit>DAYS</unit>
                 <number>10</number>
             </duration>
             <fixed>
                 <fixedPrice>
  	         <!-- empty price implies $0 -->
                 </fixedPrice>
             </fixed>
         </phase>
      </initialPhases>
      <finalPhase type="EVERGREEN">
          <duration>
              <unit>UNLIMITED</unit>
          </duration>
          <recurring>
              <billingPeriod>MONTHLY</billingPeriod>
              <recurringPrice>
                  <price>
                      <currency>USD</currency>
                      <value>10.00</value>
                  </price>
              </recurringPrice>
          </recurring>
      </finalPhase>
  </plan>
  ----
  
  === Overdue Configuration
  
  The configurartion below defines the 3 different states:
  
  * `WARNING`:
  ** `timeSinceEarliestUnpaidInvoiceEqualsOrExceeds` is set to 10 days as specified by the scenario
  ** `disableEntitlementAndChangesBlocked` is set to false since we still want the user to have access to the service
  ** `autoReevaluationInterval` is set to 4 days to make sure that if there is no payment (no overdue trigger), the state will be correctly recomputed and transition to `BLOCKED` 4 days later
  ** `blockChanges` is set to true to prevent users from changing plans until they clear their balance (was not specified in the scenario, but probably a good practice to follow)
  * `BLOCKED`:
  ** `timeSinceEarliestUnpaidInvoiceEqualsOrExceeds` is set to 14 days as specified by the scenario
  ** `disableEntitlementAndChangesBlocked` is set to true since we now want the user to NOT have access to the service
  ** `autoReevaluationInterval` is set to 8 days to make sure that if there is no payment (no overdue trigger), the state will be correctly recomputed and transition to `CANCELATION` 8 days later
  * `CANCELATION`:
  ** `subscriptionCancellationPolicy` is set to `END_OF_TERM` to indicate that subscriptions should be cancelled in such a way that we do not generate credit for the account (no proration)
  
  
  [source,xml]
  ----
  
negative.code:        <initialReevaluationInterval>
             <unit>DAYS</unit><number>4</number>
         </initialReevaluationInterval>
         <state name="CANCELLATION">
             <condition>
                 <timeSinceEarliestUnpaidInvoiceEqualsOrExceeds>
                     <unit>DAYS</unit><number>21</number>
  