pdf Invoice

Hi,

I've never seen the interface of Invoice manager for HikaShop. So I can't say what it can or can't do besides what's written on the link you gave. You would have to talk to the developer directly.

HikaInvoices was developed by another extension developer and is really useful if you need to integrate with the one stop mini shop system of the European Union which can be a pain in the a** in some countries. So it can be useful, and is used by some, but for your needs, it's not necessary.

I think that you want to use the PDF invoice plugin we provide.
It actually already have the invoice number and the payment method name on it.
And adding the Transaction ID to it would be possible as it is stored in the history_data column of the hikashop_history table. That would thus require a MySQL query and a few lines of PHP to be added to the invoice.php file of the PDF invoice plugin.

Regarding your last question with HikaMarket. I'm not sure. The invoice numbering used doesn't matter to the PDF invoice since it takes the invoice number that has been generated for the order when it was confirmed, regardless of how it was generated.
I don't understand what you mean by "invoice layout" ? I don't remember that HikaMarket has the possibility for different vendors to have different invoice layouts ?

Hello,

With the PDF Invoice plugin ; that's not possible unless you perform deep customization.

Afterwards, HikaMarket allow vendors to have their own invoice number ; they already have their own address and data.

Regards,

Hello,

I think it will be difficult. The PDF Invoice is not really an official HikaShop plugin because it was first created by someone from the Acyba team (Adrien).
In HikaMarket ; I started to work on a new kind of PDF plugin which would be very different but integrated in the HikaMarket workflow in the same time. Unfortunately, I had/have a lot of development to do (most of them for HikaShop 3) so the progress on that plugin is not very advanced.

Regarding the PDF Invoice plugin, I talked about "deep customization" because it not something little but it's also a customization. Which means that it would be something specific.
Now, maybe it could be improvement useful for a lot of users, it's difficult to say for me and I can't talk for the HikaShop team on that.

Regards,

Hello,

The PDF invoice is not a "must have" for every HikaMarket users ; because for most of them, it's still the store which receive the payment and create the invoices.
It is a very interesting feature for a lot of users for sure ; but I can see other task in the HikaMarket TODO list more urgent that this plugin. It does not mean that I won't see to progress on that development but I first need to be focus on my current developments.

About the PDF Invoice plugin first created by Adrien ; you should see that with the rest of the HikaShop team. So I will unassign me from that topic to let them continue afterwards.
I think that Nicolas wanted me to be noticed from your request because it was related to HikaMarket, for good reasons. But that topic is related to the PDF Invoice plugin and we are going far from the original subject.

All I can say is that the PDF Invoice plugin can be "compatible" with HikaMarket ; it can read vendor ID in the order object, load the vendor in the database and get some data from fields for the "address" or even the "logo".
That's up to customization for sure but that's something possible.

Regards,

Hello,

Not really no.
I didn't want to use the HTML2PDF lib which is used by the "PDF Invoice". Major problem with the PDF generation is the size of the lib and the size of the fonts ; thus including that directly in HikaMarket will make the package heavy.
So I started to perform various tests and at the end I create the "PDF Serial" plugin in HikaSerial 2.0 ; I hope that with the feedback on that HikaSerial plugin I would find a good base to implement such PDF plugin into HikaMarket.
But right now, I'm more focus on the big refactoring of the HikaMarket order system (which is really important but I'm started to get good results) and also on HikaSubscription beta.

Regards,

Hello,

HikaMarket PDF Invoice
First, I want to base the plugin on the TCPDF lib ( tcpdf.org/examples/ ) and avoid as much as possible the usage of views but have some settings instead.
TCPDF already support the generation of tables, some support of HTML content, the header, the footer. The plugin should mostly support the fact that product listing can be split in different pages (and I think it should repeat the table header in the new pages).

The PDF Invoice plugin mix up the HTML and the PHP ; most of the processing is made directly in the view.
For sure, a new plugin should follow the new standards and prepare most of the data before ; so the code which will handle the display will only focus on the display and will not load (or reprocess) further data.

The vendor would have some settings in order to configure his logo, the text in the footer and maybe something related to the terms & cond.
I like the flexibility of "attach serial" but I know that's also pretty complex. Because users just want to display few fields it is not too problematic but when we're talking about invoices, there are a lot of fields !
It's not easy like that to know what settings would be required but it might be related to "design" for most of them.

About the implementation, I realized during the development in HikaSerial that PDF fonts are really heavy (28Mo, 15Mo in a zip).
I think that I would drop the support of Joomla 1.5 in order to be able to use the Joomla librairies folder.
Thus, the PDF lib can be more independent and the users would be able to install the fonts they want/need.

HikaMarket 2.0.0
There is no planned date for the moment. I was working on the "order edition by vendors" for HikaMarket 1.8.0 but I finally realized that some elements of the core would require major modification, so HikaMarket could really support the "sales repo" feature and let some vendors to create manually orders in the front-end (under specific conditions of course).
That's how I started to remove completely the system of "vendor adjustments" in the system and implement a "order transaction". It would also improve the support of adaptive payment methods.
Afterwards, with my work on HikaShop 3.x, helping the HikaShop support team during holidays, etc ; it does not allow me to have a clean vision of my schedule and of course, it's never possible to know how much time is required for "research" !
But you can be sure that I'm doing my best and I really want to do that release !

Regards,