Vendor sub-order does NOT get invoice number when using Mangopay

-- HikaShop version -- : 2.6.4
-- HikaMarket version -- : 1.7.2
-- Joomla version -- : 3.6.2
-- PHP version -- : 5.6

FYI: Mangopay Payment Plugin 1.7.3

Hi there,

In the Hikashop config I have:
- Payment confirmed order status: confirmed

I have setup 3 Payment Methods:
- Bank Transfer
- Stripe
- Mangopay

After the order gets confirmed then it gets an invoice number, both the parent order and the vendor suborder. This process happens OK with Bank Transfer and Stripe. However there is a problem when Mangopay is used, the parent order gets invoice number but the vendor sub-order does NOT get invoice number when confirmed.

This tells me it is not a configuration problem (it works fine with Stripe and Bank Transfer) but a problem with the Mangopay plugin.

I have checked php error logs as follows:

When Bank Transfer is used -> no errors

When Stripe is used
When Mangopay is used
It looks like the PHP notice is the same when using Stripe and Mangopay, so I'm not sure this is the source of the problem. But unfortunately there is no other error message.

Please help, thanks!

Hi,

I do not reproduce your issue but I think I know what could be the cause.

HikaMarket refuse the modification of a sub-order when that sub-order is "paid".
Because MangoPay is an adaptive plugin, it mark itself the sub-order as paid.

But, in HikaMarket 1.7.1 we introduced some modifications to allow the modification of the sub-order if it does not affect the "order_vendor_price" Because you have HikaMarket 1.7.2 ; you should have that code in your HikaMarket order class and the modification of the sub-sale should be authorized because the sub-orders are not updated with a modification of the order vendor price.
Now, in order to be sure, you can just add two lines of codes just before the " $do = false;" So, if the sub sale update is blocked, you will see a warning message with some details.

Regards,

Hi, thanks for that.

Unfortunately the execution does not get into neither of the "if's" on the piece of code that you suggested. I had to take those two lines of code outside of the if's to see some message, as follows:

In this case the Message I see is as follows:

It looks like the function is being executed twice. The testing order was a 30 euros order where there were no fees, so all the money goes to the vendor.

Thoughts? thanks!

Hi,

You place the display of the message before the first "if" ; so you have the message when a sub sale is modified ; but it does not mean that the update of the sub sale will be refused.
And regarding the messages, there "vendor price" and the "old vendor price" are never the same, so the sub sale is update each time.

Regards,

Hi,

I had tried putting the display of the messages inside the "if's" but I didn't get any message.

I tried this:

But didn't get any message.


I also tried this

And didn't get any message.


From what you say I understand the updating of the suborder is not being rejected, right?

So that's fine, but the suborder it is NOT getting an invoice number when confirmed via the Mangopay plugin.

What else could be going wrong?

Thanks

Hi,

That's right, HikaMarket is not blocking the update of the sub orders.
You are using the latest version of the Mangopay plugin (1.7.3) and that is also the plugin I am using in my local website but I can't reproduce your issue in that website.

Regarding your PHP log, you have warnings in the email notification (which would be fix in the next release).
You have the order notifications emails for both MangoPay and Stripe plugins ; which mean that the vendors are notified for the update of their orders.
MangoPay do not touch the sub sales ; it just modify the main order to make it "confirmed", like any other plugins.
So there is no code or nothing suspicious in that plugin which could explain the problem you have ; I have read several time the code of that plugin and I can't explain your issue.

Regards,

Hi,

I think the problem could be in Hikamarket, in the order class.

I did the following troublshooting.

In administrator/components/com_hikamarket/classes/order.php, in the function generateOrderInvoiceNumber I added the following code:



When I make a purchase using the Stripe plugin (where I get an invoice number for the suborder) I get the following messages:
After submitting the cart:

After submitting the credit card:

Then I make a purchase using the MangoPay option.
There is no message after submitting the cart since I'm redirected to Mangopay to enter the credit card details.

After submitting the credit card details:

As you can see, when using Mangopay as payment method and the execution arrives to the generateOrderInvoiceNumber() function in the order class, the fact that there is an Invoice created date in the Old Order property stops the creation of the invoice number for the suborder. This does not happen when using Stripe as paymeny method, and the suborder gets an invoice ID.

Thoughts?

Hi,

Because you have added some trace in your file, the lines are not the same.
So I don't know what is your line 840.
My line 840 is empty and the line 841 is and there is no reference of the "order_id" or code which can generate a warning on the order_vendor_price.

Now the real problem is that, an order without "order_id" is being created and not updated.
I am sorry but I don't understand the tests you made nor the result you have ; they are not what I can see in the source code of the HikaMarket 1.7.2 package.

Regards,

Hi,

Line 840 refers to the lines you suggested me to add:
They go into the beforeUpdateSubsale function as follows

The other tracing lines I have added in the administrator/components/com_hikamarket/classes/order.php are inside the generateOrderInvoiceNumber function as per my previous message.

I attach the full order.php file so you can see the line numbers - I attach it as .txt file because I'm not allowed to attach php files


What don't you understand? It looks pretty clear to me where the problem is. The key seems to be in the administrator/components/com_hikamarket/classes/order.php, inside the generateOrderInvoiceNumber() function.

As you can see in this function, there is an if condition to cancel the generation of the invoice:
When Stripe payment method is used, then when this function is called for the suborder
Hence the if does NOT execute and the execution of the function continues and gives and invoice ID to the suborder

When Mangopay payment method is used, then when this function is called for the suborder Since $order->old->order_invoice_created has a value, then the if gets executed and the return false stops the execution of the rest of the function. Hence the suborder does not get an invoice ID

Hi,

Okay ; now I understand the messages you got in your log.

1 - The PHP warning messages are normal (and not problematic).
The code is called for both triggers (create / update).
It is logical that when the order is created, there is no "order_id" because there is not an order in the database yet.
When the order is created, there is also no "old" order.

2 - You're right, there is a problem regarding the order_invoice_created ; but due to the fact that there was a lot of messages that I don't understand what it was coming from, I missed the important point.

In the mangopay plugin, you will find a query which update the sub orders for the vendor payment. To
And the reason why you got the issue and I was not is the ordering of the plugins in Joomla.
HikaMarket get the notification thanks to his plugin "hikashop / market" and the mango pay plugin via "hikashoppayment / mangopay".
In your case it looks like the payment plugin is called before, so it updates the database and then when HikaMarket is notified, the suborders were already marked.

Regards,

OK, thank you very much Jerome. It looks like we are getting to the bottom of the issue.

However I'm still not 100% clear about the solution you suggested:

a) Just change the query you mentioned in the Mangopay plugin? ( will this be changed in the future version of the plugin?)
b) Just re-order the plugins? ( is this a reliable solution?)
c) Both change the query AND re-roder the plugins?

Many thanks!

Hi,

Just apply the patch in the plugin ; it will be fine.
Because the plugins are in two different groups, you cannot change their relative ordering.

Regards,

Thank you very much Jerome, this is now working fine.