I would love to simply use FakturX or the Peppol module, but Poland has created an entirely different method of e-Invoicing for KSeF (Krajowy System e-Faktur) just to keep things fresh and interesting for developers.
I think the Polish community of Dolibarr users is relatively small, but since I have now 2 and soon 3 businesses that will all be required to use it, I believe that the ‘easiest’ method is to fork FakturX and develop an alternative that uses is GPL licensed bones are a baseline to start from and build a new module upon this.
Is this the way forwards, or is there already work been done on this front? “KSeF Dolibarr” returns me no results in any popular search engines, and KSeF gives me no results on Doilbarr’s portal (not to mention there is no Polish language forum!).
Otherwise, hopefully I can get something working here!
Well I haven’t heard anything yet, so I figure the audience is small. I at least managed to convert over the settings menu and get buttons to show up on invoices for now as well as put together a reasonable design document today to help keep things in order.
I think I will be working on this for some time yet to get it into a somewhat workable version, but when I have a workable version I will update it on (updated repo) InPoint-Automation/Dolibarr-KSeF-Module · GitHub - I have no interest in making it paid because I benefit enough from the Dolibarr community and software here already. Dolibarr works well enough so I can make money at my real businesses instead.
as far as i kno nothing is done in that sense in the dolibarr community and it is nice to see your involvement in the project
Concernint the time to get an answer please rememeber that everybody in the forums are volunteers. Therefore we all do what we can and our part to respond and make this project move forward ! Good job on being part of the team let us know when your development is going. If need be for more technical support you might want to try the discord of dolibarr where you can have more technical questions.
I guess I worded it poorly - on a forum it’s not normal to get a response <8 hours anyways but nobody had dissuaded me from the adventure in the meantime. I started work on it immediately after the first post.
As of this morning I’ve gotten all the Dolibarr side to a min working version. I originally was going to use triggers on PDF generation but I’ve commented them out for now and added another action button on the invoice page for non-validated and validated invoices to either validate & upload to KSeF or on an already validated invoice to upload to KSeF.
I also have a rudimentary table that keeps track of what submissions have been made so an overview of current invoices and what has/hasn’t been uploaded, as well as an option to prevent it providing these buttons for certain clients (e.g. Generic POS customer or Generic Retail Customer or however you name it) since B2C transactions don’t require this.
I now I’ve only to figure out what should be the simple part - the REST API side - but somehow seems the hardest as even with curl requests for testing it manually I can’t get anything working. I know it’s not entirely my fault as there are other people complaining about issues, but anyways I will complete this in the near future.
As they say though, 80% of the progress takes 20% of the time and the last 20% takes the other 80% of the time.
Thanks for the information - I’ll submit a PR to this repository once I’ve got something working.
As of today I’ve got authentication working so big win - now just getting invoice XMLs generated in the correct format so that the system will accept them and I think I’ll be at something min-viable.
But I guess I should be careful to make it in such a way that it can be upgraded without breaking things in the future, since it could end up adding extra slop into this table if it’s run multiple times with different fields in it in future versions, correct? My SQL skills are pretty low-tier
Just to give some update, I’ve got invoice submissions working! It’s a somewhat “minimal” working example - so it doesn’t handle corrective invoices and very likely some edge cases yet, but I am excited to share some screenshots anyways.
On the invoice page, next to “Validate Invoice” button, there is a Validate and Upload to KSEF button. If the invoice is validated “normally” with the Validate button, then instead a “Upload to KSEF” button appears instead. In the event the Third Party is added to the “exclude from KSEF” list in module settings, then these buttons will never appear (although in this example I’m using the Generic TakePOS customer for testing, in general I understand KSeF is not required to submit for B2C transactions)
Once it’s been uploaded via either method, the KSEF number is displayed along with the extrafields, is clickable to open the online verification portal, and displays relevant information.
Finally, the Submission Status page in the lower left on the sidebar opens a page where all submissions to KSEF can be seen. Environment and retries are temporary columns just for development for now, and the two download buttons allow you to look at the FA(3) invoice you sent and the UPO confirmation respectively (but I will have to figure out which icons work better later on)
This is still very much an initial version, but once I get at corrective invoices working properly I will then clean up some of the shitcode that is left from failed attempts and add sufficient comments to the nicer code, some building instructions, and submit my initial PR, hopefully within a week or two! Certainly in time for February next year when this becomes a requirement.
I would argue that it potentially should be a selection on the actual thirdparty. Possible even a subpage/tab where you can select the possibly invoices methods this thirdparty accepts?
Think multi country customers - they might have different invoice methods?
I think having such a selection on the 3rd party tab is a very clever idea - it can use the same table for excluding customers already (to keep everything for KSeF centralized in the module, anyways - vs adding extrafields to 3rd parties directly)
May or may not get to it before initial commit but if not then I’ll have it on the todo list for not too long afterwards.
When I think about how it would “interoperate” with say Peppol and FacturX modules and so on as you mention, I think each one would need its own similar option added to 3rd party (like 3 separate checkboxes in the 3rd party information, one for each invoicing module) - as unless it’s a module that brings all of them under one single control it needs to be independent for each unfortunately.
I managed to add a tab that displays the submission information per invoice, but the badge with the number of items I can only get to show up on the main page.
When navigating to the tab, it stops displaying (but the core modules don’t have the issue). I assume there is a somewhat easy solution, but this is a minor bug to address later.
It should be only 1 ever, but in the (never zero) event something goes wrong (as in the example above) on either side of the endpoint - maybe internet went down, maybe their endpoint is overloaded, maybe something was incorrect with the vat number even - then it pops an error code and should be stored and able to be retried. Having a badge just feels appropriate as all the other tabs have one! Later, this submission history per-invoice needs to be extended to accommodate offline generation of the e-Invoice which is then later uploaded separately in the event their system is entirely down or the internet is out or whatever.
As far as adding badge numbers, I have stepped away from my PC and coding for today (I’ve gotten the QR code injection working on invoices using the built-in TCPDF and barcode stuff which was my final goal for the day) so I don’t have my exact example handy.
You may find some luck with LLMs to try and generate snippets but they are very finicky - they can be useful for speeding up searching through forums and github issues though, especially in non-native language, so long as you use one that provides these URLs and doesn’t just hallucinate them. When dealing with hooks and API calls which require things to be exact you are better off with a window of documentation than even 50 windows of LLMs.
I feel quite good about progress so far - I cleaned up quite a bit of shitcode today and fixed a few others things that felt unpolished for me yet, and so basically all that’s left for me to feel comfortable with an initial release is these corrective invoices.
I regret trying to use php-scoper with phpseclib3 (since based on reading RSA-OAEP SHA-256 isn’t supported by php-openssl)
Translated from https://github.com/CIRFMF/ksef-docs/blob/main/uwierzytelnianie.md
...
the KSeF public key should be encrypted using the RSA-OAEP algorithm with the shortcut SHA-256 (MGF1). The received ciphertext should be encoded in Base64.
...
It works great unscoped, but as soon as I scope it (which I think is ideal for a module including libraries) everything explodes . Debugging this has turned into find-and-replace string hell.
I may have to shelve this for a more experienced PHP programmer
I have disabled the scoping for now and will return to it at a later time. Just a little more polishing up and I’ll have v0.1.0 up … either today or more likely tomorrow
I prefer the alternative quote (this photo taken from internet, but i have the same flag here at the company)
Almost done with the offline invoice handling (for when internet is down or KSeF API is down) - it’s a bit to wrap my head around the requirements but I think I’ve got it, then next up is adding support for certificates since the tokens will stop being valid at the end of 2026 and go certificate only, but this should be relatively straightforwards.
There’s some other QoL things as well, for instance it probably makes sense to be able to schedule a cron job to try uploading the offline invoices every say 4hr until it succeeds, so that you don’t have to go back and manually upload the invoices in this case. Also adding the 3rd party exclusions to the third party tab is on the QoL list.
Got successful uploading with certificates working. The offline invoices rely on certificate handling so I ended up swapping priorities a bit to finish that first. I have offline handling almost done now, and revamped the setup.php to allow chosing token vs certificates for online mode.
As a parallel effort, if someone has some knowledge of this, I could really use some help with understanding how to use php-scoper to scope phpseclibv3 - I’ve done a fair bit of searching and I cannot for the life of me figure this one out. It seems that scoping this library requires either a lot of manual work or many many lines of find/replace to be added to php-scoper. It may have to remain unscoped otherwise which I understand can cause conflicts if another module also includes this library.
- I cleaned up quite a bit of shitcode today and fixed a few others things that felt unpolished for me yet, and so basically all that’s left for me to feel comfortable with an initial release is these corrective invoices.
. Debugging this has turned into find-and-replace string hell.
… better now than when it’s live I guess - 
