Adding new product with category tree - specific price problems - prestashop

I installed an add-on for bulk action (called ba_importer v 1.1.24), I upload an Excel file with my data and create a group of products.
I can set the categories' tree or manually add ID of main categories and associated. I tried with no luck to use the tree features (like Home/Products/etc) and so I use all the ID of main category and all the associated. The result is a product with the correct categories set, but with no specific price from the customer group linked to a category.
I tried to edit a single product, remove all categories and set it one by one (set one, save, set one, save etc.) and then the specific price from the group linked to a category appears to the product.
Is there a better solution? I'm thinking about make a personal PHP page that reads an Excel file and sets all the information about the product, but I'm scared to face the same problem with the specific price. 

There is no such thing as "category-related specific price",
if you have specific prices tied to customer groups , these are created as a result of the add/update product action with ps_specific_price DB entries having id_group with your restricted ID.
It is likely that the bulk module acts directly with DB queries to speed up things and bypasses this operation, I've seen this behaviour with those kind of modules in the past.
Since you are talking of a paid add-on, I would definitely seek help from the developer.

Related

Shopware API search products endpoint total from a stream inconsistent

I have two dynamic product groups
First: Test Product with variants
Conditions: Product Is equal to Variant product
Result total 7 like I expect this
Second: Active Products
Conditions: Active yes
we allready see that the stream ids are just set to 5 products
Now we get a total of 5 instead of 15 products like expected?
Why is it inconsistent, and how can I modify my request to consider also the variants?
You shouldn't rely on the stream_ids column as an indicator which product is shown in a dynamic product group at any given moment. This is because there are multiple more things that factor into whether a product is shown to a user in a dynamic product group.
The filters you define for the group resolve to an SQL query, which in simplified terms would yield something like WHERE active = 1 AND id IN ('...', '...'). So the stream_ids column isn't used to select the contents of a group, but the entire query including all filters is executed in the storefront request. The result of that query is what you see in the preview of the dynamic product group.
Why doesn't it correlate completely with the content of stream_ids?
Shopware features inheritance of fields. If fields of a variant haven't been assigned a value, they may inherit that value from their parents. This may not be reflected in the contents of stream_ids. In fact the children/variants may even inherit the contents of stream_ids.
Then there's the fact that contents of the product group may vary, depending on the current sales channel. That may be because the sales channel features a different language, hence the content of a translatable field used in a filter may vary. Also if you use price filters, there is the possibility of products with multiple prices, which might only be shown if certain conditions are met, defined by the rule builder.
In short, don't count on the stream_ids, which can't reflect all these variables but are used in some capacity internally, for invalidating caches and such. Instead use the preview to judge what the average user might find when they see a product group. There's also the possibility to choose which sales channel the preview should apply to, for the exact reason, that contents may differ depending on the sales channel.

What kind of dynamic content is available in Eloqua?

In Eloqua, can you send out an email to a contact list but version the "hero" image headline for each segment using dynamic content blocks?
And then can you do the reverse, have the main image remain the same, and dynamically populate products below that they've purchased in the past?
For scenario 1, yes that is possible out of the box.
Scenario 2 however is a bit more complicated and would generally require a 3rd party tool to provide this type of dynamic code generation based upon a lookup table (in this case a line item inventory or purchases). Because a contact could have zero or more products (commonly as individual records in a CDO), you would generally need to aggregate or count the number of related records, and then generate your HTML table and formatting around those record values, and be contextually aware if it is the first or last record (to begin and close the table). Dynamic content does not have mathematical functions and would not be able to count those related records - this is something usually provided by a B2C system like SFMC using ampscript or dynamically generated through custom code and sent through a transactional SMTP service. You could have multiple dynamic content on top of each other, but your biggest limitation becomes the field merge, with only lets you select a record based upon earliest/last creation date, or last modified. This is not suitable if you have more than 2 records. A third party service that provides a cloud content module for your email is your best bet.

Searching products using details.name and details.value using the Best Buy API

The Best Buy Search allows to search products specifying a criterion on details.name and details.value fields.
http://api.remix.bestbuy.com/v1/products(details.name="Processor Speed" & details.value="2.4Ghz")?apiKey=YOURKEY
However details is a collection. The query above actually returns all products has a detail entry named "processor" and a detail entry whose value is "2.4Ghz" but not necessarily in the same details entry. Is there a way to create a query that will return only products for which those value and name are for the same details entry ?
Unfortunately there is no way to do this unless the particular detail you are interested in has been exposed as a top level attribute (processor speed has not). To accomplish this you will need to run your query as you have described, and then comb through the results and remove the irrelevant products in your own code.

Prestashop: use BlockLayered class methods and/or DB tables for price range button?

I've got to build a standalone menu button with submenu that contains links to price ranges.
I activated the blocklayered module (not for this task, only for regular left-column filters). So the relative db tables are in place and populated.
I want to make a controller specific for price ranges. So I've got to do the right query and maybe set up the same url vars as the blocklayered module so they wil not conflict.
Would it be too crazy to import blocklayered or blocklayered-ajax in my controller and use part of their functionality? Maybe not good because of object duplication or other issues?
Or maybe, would it be a bad idea to use the blocklayered tables (for example layered_price_index) to help me get filtered products? I'm wandering if it would be a better solution than re-doing all by myself, or if instead it's not good for some reason.
Any idea?
It really depends on which amount (among the ones below) you would like to take into account in your price range filter:
Amount without taxes
Amount including taxes
Amount including discount/promotion
Amount in several currencies or only one currency
Amount for a specific customer group or for everyone
Amount base on any other product price rule
The easy way:
You can build a price range controller easily by yourself, handling only a single currency and prices without taxes and reduction. It will probably be 90% accurate (because of the missing discounts a product might not show up for a certain range).
In that case, you can easily build a query on the ps_product and ps_specific_price tables and SELECT in real-time the right products for a given range.
The proper way:
You want to handle discounts, price rules, specific prices, etc. If you build a real-time query including all these calculations and parameters, it may slow down the server.
Build a product price cache or re-use the one setup by the Block Layered module.

Database Design: Line Items & Additional Items

I am looking for a solution or to be told it simply is not possible/good practice.
I currently have a database whereby I can create new orders and select from a lookup table of products that I offer. This works great for the most part but i would also like to be able to add random miscellaneous items to the order. For instance one invoice may read "End of Tenancy Clean" and the listed product but then have also an entry for "2x Lightbulb" or something to that effect.
I have tried creating another lookup table for these items but the problem is i don't want to have to pre-define every conceivable item before I can make orders. I would much prefer to be able to simply type in the Item and price when it is needed.
Is there any database design or workaround that can achieve this? Any help is greatly appreciated. FYI I am using Lightswitch 2012 if that helps.
One option I've seen in the past is a record in your normal items table labeled something like "Additional Service", and the application code will recognize this item and also require you to enter or edit a description to print with the invoice.
In the ERP system which we have at work, there is a flag in the parts table which allows one to change the description of the part in orders; in other words, one lists the part number in the order and then changes the description. This one off description is stored in a special table (called NONSTANDARD) which basically has two fields - an id field and the description. There is a field in the 'orderlines' table which stores the id of the record in the special table. Normally the value of this field will be 0, which means that the normal description of the part be displayed, but if it's greater than 0, then the description is taken from the appropriate row in the nonstandard table.
You mean something like this?
(only key attributes included, for brevity)