News:

Looking for documentation? Take a look on our wiki

Main Menu

Removing color from product custom field removes it from order itself

Started by Kuubs, October 19, 2019, 09:50:38 AM

Previous topic - Next topic

pinochico

www.minijoomla.org  - new portal for Joomla!, Virtuemart and other extensions
XML Easy Feeder - feeds for FB, GMC,.. from products, categories, orders, users, articles, acymailing subscribers and database table
Virtuemart Email Manager - customs email templates
Import products for Virtuemart - from CSV and XML
Rich Snippets - Google Structured Data
VirtueMart Products Extended - Slider with products, show Others bought, Products by CF ID and others filtering products

diri

@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%.

Kuubs

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 :(

AH

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.

Regards
A

Joomla 3.10.11
php 8.0

Studio 42

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 ....

pinochico

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?
www.minijoomla.org  - new portal for Joomla!, Virtuemart and other extensions
XML Easy Feeder - feeds for FB, GMC,.. from products, categories, orders, users, articles, acymailing subscribers and database table
Virtuemart Email Manager - customs email templates
Import products for Virtuemart - from CSV and XML
Rich Snippets - Google Structured Data
VirtueMart Products Extended - Slider with products, show Others bought, Products by CF ID and others filtering products

diri

 :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.

diri

@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.

AH

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)
Regards
A

Joomla 3.10.11
php 8.0

diri

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.
Quote
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.
Being compliant to GDPR and other obligations is basic for me.
Quote
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.
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 ... :(

Studio 42

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.