Hello,
I have a weird bug. When I remove the custom field color from my product, the already ordered products also the color gets removed.
So for example. I have Product One with custom field Color = Black, Red and green. These are all strings and all seperate instances. When I remove the color black from that product. Every Product One that is ordered is the color black removed. How is this possible?]
EDIT: So I checked the database and this is what is set at the product_attribute column:
{
"3": "570",
"15": "573",
"17": "624"
}
Is this in reference to? Because if that is so, how can I get it back. I tried readding the field, but it won't display. Is it because I removed the ID from the color from the product and now it doesn't know the reference? Seems like a really dumb way of programming it? Why not just use the name and the value of the custom field?
EDIT2: I think in the database jos_virtuemart_product_customfields I need to change this. But why is it removed in the first place? And how can I get it back? I'm fine with adding a row to the database so it works again but I cannot understand why this would happen in the first place. Seems really dumb to have it work like this.
EDIT3: I got it working again by manually adding a row with the correct id's, and disabling the custom field so it doesn't show up in the productdetails page. But I'm kinda confused why this happened. Can someone explain to me why this happens?
The problem is that the render is dynamic in the order, this mean that if you remove the field after in the product, the order dont have any reference anymore and cannot display it.
Quote from: Studio 42 on October 19, 2019, 13:04:52 PM
The problem is that the render is dynamic in the order, this mean that if you remove the field after in the product, the order dont have any reference anymore and cannot display it.
But that doesn't make any sense at all. Why remove the whole row? Instead of just disabling it? THat seems like a major oversight because existing orders should never lose any custom fields, unless you specify it. That is a major oversight. This is really detrimental to the webshop because suddenly I don't have any color set on the ordered product.
Look at the PDF
Quote from: AH on October 21, 2019, 12:54:41 PM
Look at the PDF
That's an option, but my clients use the order screen in VM self to check the orders, and also use a XML export function on the website to get the orders in XML format for better administration.
I see your problem - especially when customfields may be changed
Quote from: AH on October 25, 2019, 12:57:01 PM
I see your problem - especially when customfields may be changed
So is there a solution for this? Or do I need to workaround this issue at the moment? (I can for example use the database to add the disabled check in the database)
There is no solution
Custom fields are rendered every time the order is viewed using the stored values but they are "run" through the plugin which attempts to re-render them
Quote from: AH on November 01, 2019, 13:24:17 PM
There is no solution
Custom fields are rendered every time the order is viewed using the stored values but they are "run" through the plugin which attempts to re-render them
Great, so that seems like a major design flaw. Good to know.
You can always attempt to redesign it yourself and provide the solution back to the core for review
Or if you have a gold membership - you could ask for a modification to be considered going forward
https://extensions.virtuemart.net/support/virtuemart-supporter-membership-gold-detailr this to be reviewed
Hmmm,
not so easy. Sometims you want to change a product also for an existing order (for example, update the provided download).
The simple customfield string also writes the values plain into the db, imho
I did not think it was easy - after looking at the order item database entries and the plugin coding :)
I found a workaround. Maybe this is something that could be implemented because, well, it's already there.
If I make a child product I have 2 extra options and the custom field, 2 checkboxes, d checkbox and o checkbox, meaning the disable checkbox and the override checkbox. When I use the disable checkmark, the color disappears from the productdetails page, but is still there in the order itself. Unfortunately this is not default behaviour, the only way for me (as far as I know) to get these checkboxes is to use child variants, or, go into the database and set a 1 at the override column. Now the checkboxes appear and I can disable the custom field.
Is it possible to add these checkboxes default? Because that would be a simple yet effective solution.
So when you remove a customfield, which was used in an order, it should issue an warning and set it to a kind of "hidden". Hmmm.
another idea is to store the data somewhere. I have an idea.
Quote from: Milbo on December 20, 2019, 09:31:41 AM
So when you remove a customfield, which was used in an order, it should issue an warning and set it to a kind of "hidden". Hmmm.
another idea is to store the data somewhere. I have an idea.
Yeah exactly. That would be great. Because I think this can happen to other users as well, because it's not really apparent that when you delete the custom field it also deletes it in the order, which could be detrimental (at least in my case). Luckily I have some sort of workaround now, which is a hassle to do, but at least it works. But it could be implemented a more user friendly way ofcourse.
Why user delete customfield? :)
@pinochico:
Because there can always be a need for it.
It's also needed at some times to change other relevant data for invoices in product data.
Trouble is what I call "over-normalization":
Essential data of invoices should never be changeable. They must stay intact (in Germany: 10 years starting at year after invoice date).
Your choice with VM is limited because there is only one:
Save invoice as PDF and have a good backup.
edit:
Trouble is "hardcoded" when you have a local audit by your tax authority years later:
You can't export invoice data to XML like it's needed i.e. in Germany.
edit2:
Another good example is problem when VAT rate is changed. Many (very expensive) accounting systems had real problems with this when VAT rate in Germany was altered from 16% to 19%.
Quote from: Milbo on December 20, 2019, 09:31:41 AM
So when you remove a customfield, which was used in an order, it should issue an warning and set it to a kind of "hidden". Hmmm.
another idea is to store the data somewhere. I have an idea.
Is this fixed? The issue arose again today. It's kind of annoying to deal with, because a lot of orders are sent out wrong :(
Quotebut my clients
You have clients - I guess you do not deliver your effort for free - Maybe you/they could fund the development and testing of the change you require.
This may get done but wholly depends on what else requires doing and what time people have to test such a change.
Quote from: diri on January 18, 2020, 10:03:11 AM
You can't export invoice data to XML like it's needed i.e. in Germany.
You can create a vmextend plugin to export orders as XML for eg. You really mean that a compoennt can be valide by default for all countries ?
For eg. some users want remove the orders but it's not tolerate in France. So how to handle this case ?
Taxe rules in EU are not same as in China, and in some cases the taxe rule change by country in EU ....
Hmmm,
If I change VAT or CF, I always add new ones and turn off old. NEVER delete them. We have e-shops for more than 10 years and I have no problems with this practice.
Why do you do things differently than I do?
:D
Why do you expect such knowledge from casual user?
You look like a technician with related background knowledge of bookkeeping(or vice versa). With such a combination you will never do such mistakes.
Casual user will change whatever is changeable. Believe it - it will happen.
@studio42
I don't expect anything at first moment. I'm watching different software to have knowledge about capabilities and flaws. Therefore I know about possibilities and effort to catch some flaws of several software (be it Magento, Shopware, ..., whatever).
XML export mentioned is something special for Germany (format is specific) - maybe something similar is needed somewhere on earth as well. I don't know.
If you want to handle such obligations the way mentioned by you (save PDF, export XML) it's not as simple as it sounds:
You need kind of specific DMS as well. Otherwise you are in real trouble because there are more obligations (eg GDPR is valid for each EU citizen everywhere on earth!).
It would be much easier to deal with it in DB. Effort to implement it is very low.
Saving invoice data to - eg - two unchangeable tables (invoice with basic data, invoice_detail holding each line (position) of invoice). Only re-print of invoice or export data to whichever format needed is possible with this data. Such transfer of data should happen latest when invoice is send to customer. Changing invoice later for whatever reason must invalidate old data and transfer of new data is needed. In every bookkeeping known by me a change of invoice after delivery requires to generate a new invoice number for first invoice is invalid because of change.
This is not according normalization of a DB but, it fullfills every existing or arising need for further processing. As a plus you would have kind of real order and invoice history.
And: User can change whatever he wants to change at data of frontend system (POS). No matter what mistake he makes - he will recognize what happens very fast without having real influence on bookkeeping which would cause a lot of expenditure to fix it.
This is way beyond the scope of the first issue which was -
QuoteCustom fields are rendered every time the order is viewed
Quote
If you want to handle such obligations the way mentioned by you (save PDF, export XML) it's not as simple as it sounds:
You need kind of specific DMS as well.
Which you will have to have when you store customer data regardless of the formats/systems etc So you would have this in place already, if not you are not compliant with GDPR.
QuoteIn every bookkeeping known
An excellent point - And you may have seen, from your extensive reviews of systems, that VM is NOT a bookkeeping system it is e-commerce with some invoice capabilities - if you turn on these settings - dont expect VM to manage everything like a bookkeeping system. If you want/need bookkeeping - export the orders to a bookkeeping system.
Currently VM has the capability to LOCK order edits and invoices based on an order status having been set in the process - that is as good as it is for now.
QuoteIt would be much easier to deal with it in DB. Effort to implement it is very low.
Then please provide your changes to the project for them to evaluate - this is open source and everyone can contribute (note not all changes make the cut)
Quote from: AH on February 12, 2020, 09:30:28 AM
This is way beyond the scope of the first issue which was - QuoteCustom fields are rendered every time the order is viewed
I'm sorry but, I disagree. This problem is caused by holding normalized product data related to orders / invoices instead of separating order / invoice data.
QuoteQuote
If you want to handle such obligations the way mentioned by you (save PDF, export XML) it's not as simple as it sounds:
You need kind of specific DMS as well.
Which you will have to have when you store customer data regardless of the formats/systems etc So you would have this in place already, if not you are not compliant with GDPR.
Being compliant to GDPR and other obligations is basic for me.
QuoteQuoteIn every bookkeeping known
An excellent point - And you may have seen, from your extensive reviews of systems, that VM is NOT a bookkeeping system it is e-commerce with some invoice capabilities - if you turn on these settings - dont expect VM to manage everything like a bookkeeping system. If you want/need bookkeeping - export the orders to a bookkeeping system.
Currently VM has the capability to LOCK order edits and invoices based on an order status having been set in the process - that is as good as it is for now.
Even an invoicing-only system has to obey the rules (eg invoice numbers). Nevertheless in case of using VM as shop I transfer VM's invoice data to another system and real invoices are generated in this other system (which is my own development and in active use since about 20 years now). Online payment is triggered by backend afterwards. VM is used as quasi pure frontend in this case. I call it "catalog extended" for this.
There is no need for transfer when VM is used as catalog only.
Quote
Then please provide your changes to the project for them to evaluate - this is open source and everyone can contribute (note not all changes make the cut)
I'm aware of this and waiting for upcoming development to have chance to estimate how VM develops. I need to port my own things to PHP as well in case of publishing ... :(
diri, if you really need, save the data in a table that cannot be altered when the invoice is rendered. So you can reuse it after for your case.