I am new to prestashop and I am very much disappointed by the back office entries in database. I have different products with more than 40,000 combinations generated by autogenerated combination. But every product has a different price and impact varies from product to product. I have issue with updating the prices, editing the prices I have to do all that nasty stuff manually or by one by one.
This work wasted lot of time to add the product entries and that giving them prices. Is there any way to edit, update only the price of the specific price after all possible combinations generated by prestashop itself.
Is there Any software or plugins available to make this work easier?
Unfortunately Prestashop doesn't handle specific price in combination. You ll have to calculate price increase.
We got the same issue each time we have to migrate data.
I wouldn't recommend you to put a price at 0 on the main product price as it will appear at 0 on RSS and some modules.
Related
I come to solicit your help after several days of research.
I have a PrestaShop 1.6.1.4 (multishop). This shop is connected with an ERP for manage orders and customers.
For each customers, we have multi-groups. The default group on my databse is 3 (customers).
My problem : Several times a day, my database auto-update and change my default-group by another value for all customers. On my shop, my customers have to be on "customers" group to use search engine and order... This is a real problem !
Someone can help me ?
Thanks a lot !
You should look for some module or custom function, probable related with ERP integration. This should be the cause of group modification.
Anyway, a complete update of all your customers default group should include 3 keywords you can find in your source code: update, customer and id_default_group. So, if you can find a PHP or MySQL sentence that combine this 3 keywords you will find the problem. But, is this is part of an ERP integration you should be careful deleting of commenting this code because it can cause a malfunctioning of your integration.
Good luck.
I am running Prestashop powered shop. I have about 25000 products. I have problems with deleting product. Whenever I press delete button in backoffice it keeps loading. When I refresh the page the product gets deleted from the products list in the backoffice. I have this problem for both old and new products. Can somebody with experience in Prestashop explain me that?
With the help of this thread in Prestashop forum I managed to improve product deletion process. I guess the main reason is MySQL is very slow for delete/update/insert when using InnoDB. So I have dumped my database and changed all occurrences of InnoDB to MyISAM. This helped me to improve the product deletion speed a little bit (5 products per minute).
I am creating a sales invoicing program which has an access database as a backend for storing product and customer information so that the user can choose a customer from a dropdown, select products from dropdowns, etc. What I'm struggling with at the moment is deciding what is the best way of taking input from the user when it comes to products quantity, unit price and total price. Should I just use a bunch of rows of textboxes? But then if the user runs out of rows, I'm screwed. Another option would be to use datagrid view, but then that means no comboboxes and auto-completion resulting in slower input. Keeping in mind that an invoice would obviously need to be stored and then recalled later, what is the best way to go about doing this?
BTW keep in mind I'm quite inexperienced (as you can probably tell by now) with coding in VB so try to keep it simple so I can follow through and understand.
Much thanks for your time and help.
P.S. Here's a link to my relational DB model - a screenshot from access.
Database relationship diagram - MS Access
Your relational design is fine, but what you are looking for is a Main-form sub-form setup.
Per your diagram: 1st Create an invoice form that contains just the information in your invoice table. I would use a combo box to populate the customerID from your customer table.
Next, create a second form for your line items table, and it should be set to display as "continuous forms" so that it will show multiple line items. Once again, use a combo box to enter productIDs from your Product table.
Finally, go back to your Invoice form and use the subform control to add the line item form to it, linking it with the InvoiceID field.
This is really a common setup, there are tons of examples. If you can get a copy of the venerable Northwind.mdb (tons of places it can be found on the internet), you can see how it is done.
Yesterday, my app got 74 downloads in sales but 134 in updates. Are these numbers combined? I'm very confused. How I just look at the downloads overall?
Sales are unique downloads of your app. Updates are users who are either updating from a previous version of your app or re-downloading it after they had purchased but deleted it.
As #SevenBits says, they are completely different numbers and the overall downloads depends on how you define it.
IF:
1. Overall downloads = New sales (whether free or paid) + updates, then you have to add 74 + 134 = 208.
2. Overall downloads = Only New sales free or paid (because updates doesn't count), then its 74.
There isn't a place to look at the sum of updates and new sales/downloads.
Lastly, this is not a programming related question... please see the SO guidelines for types of questions to post.
I am curious regarding this. Is it a better practice to have static html pages displaying the current inventory? This would obviously entail having to manually update these pages when items go in/out of stock, adding new items, etc.
Or is it a more common practice to use dynamic pages to load your store's inventory directly from a database?
If your products never change, and you only have a few products, than you can probably get by without using a database. But if you need to update new products every so often, or if you want to add features like filtering, search, sorting, etc., than having a database is the way to go. It also has the added benefit of organizing your product line in a rational way. If you have more than a dozen products though, you'll want to use a database so that you can code one view that populates according to the product selected. Otherwise, if you want to change the layout, you'll have to do with each product.