Counter reset not working

Self-Hosted | v4/Legacy
1

Hi again,

another problem: My counter does not reset. I’ve set the counter reset to “monthly”, so I assumed that today a new counter should start.
The cron jobs are enabled and have been running fine today, but the counter has not been reset.

The “next reset” field was set to yesterday (e.g. 2020-07-01) but now the field is empty.

As a workaround, could I reset the counter from outside? Where is it defined e.g. where do I have to tweak the system? Otherwise I will have a problem next month, since the invoice format is set to {$date:ym}{$counter} with 3 digits and the counter is already at 800, so it will overflow next month If I don’t get it reset.
I know, I can manually set the counter, but I need a solution that doesn’t involve human interaction :slight_smile:

2

Sorry, I can’t explain that. When the counter is reset it should also set the next reset date.

3

Hmmm, this means, that the function doesn’t work at all, because both the counter reset and the date reset don’t work as expected.
Can you point me to where exactly these both values are saved on $this->save(); ? Could it be a write permission problem?

4

Actually I can confirm this.
Since the beginning (Spring 2018) we have configured a monthly invoice counter reset:

image

But the invoice numbers were actually never reset and are just incrementally increasing.

Turns out it never really bothered me, but yes, it seems that the reset counter doesn’t work.

5

Can someone please point me to the relevant code snippets and/or database location, so I can debug this?

1 Like
6

Thanks for your help debugging, the code is linked above

7

I know, but this code doesn’t help me at all…
where’s the function for
$this->save();
defined? Where in the database is the value saved?

As I said, I’m no programmer, it doesn’t work if you just point me to “this is the code”, because the above code says almost nothing to me.
I understand, this part is generating the numbers, and it looks fine to me, but it seems that the problem is the saving of the value (e.g. ninja does call the function to to set the counter to 1, but the save() doesn’t work), and for debugging this, above code doesn’t help .

8

We use a framework called Laravel which handles the code for the ‘save’ function. From many years of experience the problems is much more likely to be with the code we’ve written than with the framework code.

I believe this value is stored in the accounts table.

9

Ok, understood… I don’t speak Laravel, I will try to narrow down the problem but it looks like I will not be much helpful here. I was hoping this problem could be some permission problem but I found the counter value in the accounts table at the invoice_number_counter field.
So, if we don’t find out why the cronjob does not trigger the counter reset, I will overwrite the above field on the next month change to make sure that the next invoice package start with 1 again.

I checked the database content, which currently looks like this:

    invoice_number_counter: 855
      quote_number_counter: 1
reset_counter_frequency_id: 4
        reset_counter_date: NULL

So, it seems that the reset_counter_date doesn’t get set correctly, which triggers the return false in above line 323 (if no reset counter date, return false). No idea why this is, though.
But now comes the really funny part… the “reset date” field in /settings/invoice_settings#options is set to 13.07.2020 (e.g. $today).
Edit: Could it be possible that the function has problems with the difference between the date format 13.07.2020 and 2020-07-13, because my system is set to german?
The {$date:ym}{$counter} patterns are set correctly, so my invoice numbers start with “2007” this month, but perhaps save() is unable to write 13.07.2020 into a database field that is set to ``reset_counter_date date DEFAULT NULL,, because if I manually set the reset counter date to next 1st, it’s 2020-08-01 and the settings page displays 01.08.2020 correctly…

1 Like
10

Nice, great debugging! Yes, that’s very likely the problem as it explains why the features works for most people.

11

You’re welcome :slight_smile:
I try my best, and it’s some kind of good motivation for me since I want to use this software at my company, and I almost perfectly integrated it already so I do not want to have to change this again…

Hopefully someone can check the code for my hints and verify them - and then push a bugfix update :slight_smile: