Using account_dunning, I have configured the procedure with the following dates.
1 Month
1 Week
1 Day
Based on tests I have carried out, this order is correct. When generating dunning notices (invoice unpaid for 2 days), it will first check the first line (1M) and, as it does not match, it will check the next one, which also does not match, and when it checks the last line, it will find a match and create the invoice with that dunning level.
When I regenerate the dunning notices, I notice that it does not advance to the next dunning level, but instead puts the dunning notice in final status.
Looking at the code, I do not quite understand why one is added here. That is, given how the different levels behave, it would always go to final and never advance to the other levels, and if it does advance, it will advance to levels with earlier dates.
Normally, to make a dunning claim, the procedures range from more amicable to more serious if the debt extends over time.
Therefore, the first level is 1 day, and as time passes, the dunning claim should become more serious and change levels.
As configured in Tryton, the last level is the first dunning level, and when regenerating and advancing levels, the status of the dunning claim changes to final. And the order of the levels cannot be reversed because then all dunning letters would go to the first level (1 day) regardless of how long they have been unpaid.
Dunning in Tryton is implemented as a succession of levels. So it is intentional, that any overdue move line starts with the first level regardless of how long it has been unpaid. After the duration (overdue), the next level becomes actual, and so on.
Maybe you can fiddle out an initial temporary levels scheme for your existing overdue move lines. E.g. handle the 1 month level solely in a temporary procedure at first. After this add another temp procedure with the 1 week level and handle them. After this you can define your default procedure with 1d, 1w, 1m levels for the existing an new dunnings. HIH
