Invoice numbering scheme: Add day based counter

[stefanbaur]

Hi,

I wanted to try out Kraft, but I already fail at the step where I need to define my numbering scheme. My current numbering scheme for invoices is REYYYYMMDDNN.

I tried to use %type%yyyy%MM%dd%i - but this doesn't quite work as expected.

In my case, NN (which corresponds to your "%i") is a number starting with 1, but with leading zeroes. And it resets to 01 with each new day. (So there is a maximum of 99 invoices per day.) Is there any way to implement this in Kraft?

Kind Regards, Stefan Baur

[dragotin]

Interesting. As you correctly spotted there is not day based counter in Kraft yet.

Let me know how your further tests run with Kraft, so if you find it useful and want to continue with it, I can build that feature for you.

[stefanbaur]

Hi Klaas,

I'd like to take a different approach, if that is okay with you.

The license for the proprietary, Windows-only software I'm currently using and that annoys the heck out of me costs about 250 EUR (VAT included). Per year, if I want to be able to use the current version (though I haven't updated it in a while, so actual annual costs are lower).

If you're able to issue a proper invoice for it, I'd be willing to pay 250 EUR (including VAT) if you add that day-based counter with an option to add leading zeroes (for me, one leading zero will do at the moment, but who knows how many will be needed by others once the feature becomes available).

I'd suggest using %n, if that letter isn't already taken, followed by a number in {}, maybe, to indicate the amount of leading zeroes needed? So something like %type%yyyy%MM%dd%n{1} would be the syntax for my use case. (Feel free to add that {1} feature for the %i counter as well, if you deem it useful.)

I'm willing to pay the development costs (up to the 250 EUR limit stated above) through my company, even if I run into other issues that make Kraft unfit for my use. (Though I sincerely hope it fits and I can finally ditch the last Windows-only application here ...) I'm so fed up with this proprietary crap that I'm willing to take that risk. Best case, Kraft works for me, worst case, Kraft got a new feature and I was able to sponsor an open source project (warm fuzzy feeling, good Karma and all that).

If you're interested, let me know. :)

Kind Regards, Stefan

[dragotin]

Thanks Stefan, a generous offer! That is the first time this happens to Kraft. I will look into it soon. Please stay tuned.

[dragotin]

Pushed a solution. You can use %n now in the template. It uses the current date to maintain a counter, that resets the next day, starting at 1.

You can prepend leading zeros by using as much as n's as needed, ie. using %nnn results in 001. This was already implemented for %i, that is why I stood with that format.

@stefanbaur can you build from master, and test this? Let me know if it works for you, and we'll talk about everything else ;-)

[stefanbaur]

Hi Klaas, I'm not exactly an experienced coder (I'm more of a scripting guy), so my guess is I won't be able to build it myself - but that's what I have employees for. ;) Next free slot to have a coder work on it is on Friday (July 1st, 2022), so I'll let you know how it goes. :)

[stefanbaur]

Hi Klaas,

My coder was able to create an appimage for me, and I am able to run it. However, when I try to change the default numbering scheme, the OK button gets greyed out as soon as I try to replace %ii with %nn. You probably have a check built in to make sure that %i(iii...) is always present so the number will always increase. However, with the introduction of %n(nnnn...), you will have to check for "either %i or %n", I guess.

-Stefan

[dragotin]

I added/fixed that check here: https://github.com/dragotin/kraft/blob/master/src/doctype.cpp#L485 but not in the UI. My apologies. Will look into it over the weekend.

Thanks for testing!!

[stefanbaur]

The message in https://github.com/dragotin/kraft/blob/master/src/doctype.cpp#L486 should probably also be changed from "No %i found in identTemplate, appending it to meet law needs!" to "Neither %i nor %n found in identTemplate, appending %i to meet law needs!"

[Ionic]

Apologies for being off-topic here, but are you interested in having CI so that OBS automatically builds nightly packages (mostly AppImage ones) on every push to master? That's probably more convenient than having to build things manually, but you might oppose that to not have users run buggy nightly code if they stumble on it incidentally.

[Ionic]

If you're interested, I've forked your projects and created kraft-nightly on OBS which integrates my GitHub fork via SCM hooks and builds the code on each push of the GitHub repository, which is then picked up by kraft-appimage-nightly on OBS.

The most interesting parts are the .obs/workflows.yml file in the git repository and the _service file in the OBS package. The only non-visible part is the authorization. Hit me up if you need more information.

[dragotin]

pushed commit 539a8b6f37b629e7a5e92e3f8ff402d1ce65acc9 to fix the numbercycle dialog. @stefanbaur ready for the next test.

[dragotin]

@Ionic Thank you very much! That is highly appreciated! I will pull over the parts to my repositories.

My prefered setup would be:

One repo in my OBS Home that has the stable AppImage, that is linked to the homepage for regular download. That is currently https://download.opensuse.org/repositories/home:/kfreitag:/KraftAppI/AppImage/kraft-latest-x86_64.AppImage Currently I am updating that manually whenever I do a release.

With your help I will now create a second package in my OBS homespace called AppImage-nightly that builds on every push into master.

Awesome stuff! Let's see if I can manage to set that up. Thanks again.

[Ionic]

Yes, I've setup separate packages for both kraft and kraft-AppImage nightlies, so that they don't interfere with the release builds. I haven't updated the release builds. Theoretically, you could also have them build off git tags once released, but that I'll leave that as an exercise to the reader (i.e., I'm too lazy to implement that).

You could even go more fancy and setup something that branches the whole repository for each PR. But, likewise, I haven't done that.

[stefanbaur]

Hi Klaas,

I gave the latest AppImage (built from master) a try, but it looks like the numbering with %nn still has bugs. I created a new document, but cancelled it. (So the document list remains empty.) After that, I created another new document, added an item to it, and saved it. This document SHOULD bear the number 01, however, it bears the number 02. I tried to repeat the issue by creating another new document, cancelling it, then creating a new one, but that one is properly numbered 03. So I'm confused where it got the idea to start with 02 instead of 01. Can I selectively reset this somehow by editing a file or issuing an SQL command? Or will I have to purge the entire config (and where is it stored, when using the AppImage)?

Kind Regards, Stefan

[stefanbaur]

Answering the last part of my question myself: ~/.local/share/kraft/kraft.db is the SQLite file. Opening that with the sqlite executable and running sqlite> select * from document; results in: 1|Rechnung2022070402|Rechnung||e9d1b19a-ede4-42c2-bde5-8bb721ca275c||||2022-07-04 11:49:35|2022-07-04|||de_DE|German|| (and some more sample invoices, but as you can see, the first entry ends with 02, rather than 01.)

-Stefan

[stefanbaur]

Dear Klaas,

could it be that in Table AttributeValues, the entry with attributeId 30 is initialized with 1 instead of 0, when no such entry was present before?

Kind Regards, Stefan

[dragotin]

I think I know what happened: You went to the Settings Dialog and added the %n to the pattern. That caused the example in the dialog to be updated. That in turn used the day counter, and incremented it.

After that you created the new doc and canceled it.

Is that what happened?

Solution: When the settings dialog closes the day counter must be set to it's initial value again. That is indeed missing.

[stefanbaur]

Hi Klaas,

Indeed, everytime the dialog is opened, the %n counter increases. I'm a bit confused why this only happens for "Rechnungen", not for e.g. "Abschlagsrechnungen" (which is at the top of the list and thus caught my eye) - that one remains at an example ending in "09", no matter how often I open and close the dialog. This also makes me wonder if the day counter is saved separately for each document type, or only globally: When I create an invoice, RE2022070401 will my first offer ("Angebot", AN) of the day be AN2022070401, or AN2022070402? The latter would be a bug. Each document type should be numbered individually. (I haven't tried that yet, just voicing my thoughts.)

Kind Regards, Stefan Baur

[dragotin]

This should be ok now. Please check again. You can use this AppImage: https://build.opensuse.org/package/binary/download/home:kfreitag:KraftAppI/appimage-master/AppImage/x86_64/kraft-master-0.98+git16+g89685c0-lp152.51.1.Build3.3.glibc2.17-x86_64.AppImage

The day counter is separate for each document type.

[stefanbaur]

Thank you for providing an updated version. I will be out of office tomorrow, but should get around to try it out in the next few days. :)

[stefanbaur]

Hi,

the numbering seems to work as expected now. Feel free to close this issue (or keep it open until the next stable release ...). I've run into an unrelated issue, though, and will file a new issue for that.

Kind Regards, Stefan