0
Hi,
After another loss of time trying to understand the pitfalls of Invoice-Manager when reading and interpreting the data from HikaShop, here is my report:
I discovered another VERY BIG synchronisation problem with Hikashop data and I'm sure I'm not the only one
Like many people , i have created HikaShop products with options. Yes, options exist in HikaShop !!!...
For example:
A product which code is "FS-135.8K.B" may have two options which codes are respectively "FF-J2K" and "FF-3F"
When a client places an order, he (she) have the choice between the two versions of the parent product:
and he (she) may order both versions of the product if she want (no ?), in any quantity (no ?)
For this example, in HikaShop, "FF-J2K" and "FF-3F" are just special products attached to their parent product "FS-135.8K.B"
This relationship can be deduced by reading and interpreting properly the content of the "xxxx_hikashop_order_product" table.
The columns named "order_product_id" and "order_product_option_parent_id" shall be considered, (see the attached file)
This is what does HikaShop when generating the content of a cart.
And this is what Invoice-Manager should do when reading the data from the HikaShop table
But the problem is that Invoice-Manager ignores these relationships !!!!
And this can lead to catastrophic results inside the generated invoice.
Concretly,:
IM creates as many lines in the Invoice as it finds in the table for the identified order, without interpreting the nature of what line it reads.
In certain situations, this leads to ENORMOUS MISTAKES in the invoice generated by IM.
With the illustration i provide in the attached file:
ordering 20 products "FS-135.8K.B" having option "FF-J2K" and 100 products "FS-135.8K.B" with option "FF-3F" should generate only 2 entries in the invoice (like does HikaShop cart):
But in reality, Invoice-Manager has an erroneous behaviour in this case.
Here is what IM provides in the invoice:
Not only there are 4 entries but the quantities are wrong !!!!
And obviously the other calculations, like the total amount doesn't match what the client have buid
After another loss of time trying to understand the pitfalls of Invoice-Manager when reading and interpreting the data from HikaShop, here is my report:
I discovered another VERY BIG synchronisation problem with Hikashop data and I'm sure I'm not the only one
Like many people , i have created HikaShop products with options. Yes, options exist in HikaShop !!!...
For example:
A product which code is "FS-135.8K.B" may have two options which codes are respectively "FF-J2K" and "FF-3F"
When a client places an order, he (she) have the choice between the two versions of the parent product:
- "FS-135.8K.B" with option "FF-J2K"
- or "FS-135.8K.B" with option "FF-3F"
and he (she) may order both versions of the product if she want (no ?), in any quantity (no ?)
For this example, in HikaShop, "FF-J2K" and "FF-3F" are just special products attached to their parent product "FS-135.8K.B"
This relationship can be deduced by reading and interpreting properly the content of the "xxxx_hikashop_order_product" table.
The columns named "order_product_id" and "order_product_option_parent_id" shall be considered, (see the attached file)
This is what does HikaShop when generating the content of a cart.
And this is what Invoice-Manager should do when reading the data from the HikaShop table
But the problem is that Invoice-Manager ignores these relationships !!!!
And this can lead to catastrophic results inside the generated invoice.
Concretly,:
IM creates as many lines in the Invoice as it finds in the table for the identified order, without interpreting the nature of what line it reads.
In certain situations, this leads to ENORMOUS MISTAKES in the invoice generated by IM.
With the illustration i provide in the attached file:
ordering 20 products "FS-135.8K.B" having option "FF-J2K" and 100 products "FS-135.8K.B" with option "FF-3F" should generate only 2 entries in the invoice (like does HikaShop cart):
- one entry for "FS-135.8K.B" having option "FF-J2K" with qty 20
- one entry for "FS-135.8K.B" having option "FF-3F" with qty 100
But in reality, Invoice-Manager has an erroneous behaviour in this case.
Here is what IM provides in the invoice:
- one entry for "FS-135.8K.B" with qty 100 !!!!!!
- one entry for "FS-135.8K.B" with qty 100
- one entry for "FF-J2K" with qty 20
- one entry for "FF-3F" with qty 100
Not only there are 4 entries but the quantities are wrong !!!!
And obviously the other calculations, like the total amount doesn't match what the client have buid
Your Reply
Please login to post a reply
You will need to be logged in to be able to post a reply. Login using the form on the right or register an account if you are new here.
Register Here »