I try to create an order from a variant and I receive this error:
The variant '2' of product '27610ab0-d9cf-4685-87e7-de6e41fd7dd4'
does not contain a price for currency ''EUR' all countries, all
customer groups and all channels.
Why does it not work, I have already sufficient prices:
Currency Price Country Customer Group
EUR 3.89 All price
EUR 8.99 All regularPrice
The error message appeared because the customer assigned to the cart was in no customer group and the platform tried to find a price which does not require a customer group. But there are only prices connected to a customer group.
The solution is to assign the customer to the customer group "price" or "regularPrice".
Alternatively it would be possible to add a "list price" that has no customer group.
Related
I am trying to create a price rule to fetch price of a product option (in EUR from price book entry). The product option has its pricing listed in price book entry and as one of the options under the main product it is marked as bundled.
I want to fetch EUR price for both the main product as well as the product options irrespective of the Quote's currency. Though I am able to do it for the main product but in case of the product option, the price matching the ISO code of the Quote is getting fetched.
enter image description here
enter image description here
enter image description here
enter image description here
We have a product Xitem, which can have properties Aprop, Bprop, Cprop, and etc unlimited.
For example, let's take a product "Tree". This product may have properties:
Variety of tree ["Persian", "Siberian"]
Tree's age ["From 5 years old", "From 10 years old", "From 25 years old"]
Also, for the product there may be limiters (unlimited), like:
Quantity in stock
The seller of the product
Country/climate where it grew up and where it will be delivered from
Each selected property affects to final price of the product.
By default, product properties are not selected. And there is another rules:
Products may have a base price
Or products may not have a base price and the price depends from selected properties
Also, some limiters may affect to final price or price for extra services:
Quantities from N or M numbers give a discount or affect to a base price
The seller of a product can sell the same product cheaper or more expensive
The country of delivery may affect to the price of delivery
These properties can be unlimited
We can create an entity "property type" that tells to a program how to calculate
Question:
What algorithm of actions is better to use for not create a mess?
I mean, what schema for database to create, fields in the tables and how to operate with them?
So from what I've understand the best example of differences in (Dimension, Dimension Attribute, and Fact) would be something like this:
Dimensions - PRODUCT, ACCOUNT, CUSTOMER
Dimension attribute - ProductName, ProductNumber, CustomerName, CustomerNumber
Facts - usually measures. Dollar, Unit, Height
This is my attempt so it may be wrong. I want to hear your solutions?
A dimension is a collection of "reference information" about a measurable event. The Measurable event is a Fact.
So, if you have data say for example - Retail transactions, you would measure - transaction cost. So, your fact will have sales amount. Now, sales amount in itself does not make sense. You would need information like -
When was the sale done - Date dimension
Who made the transaction - Customer dimension
Which store was it made from - Store Dimension
What was brought - Product dimension
and so on. What information you want capture for each dimension is called the attributes. For Ex: A Customer dimension might have these attributes -
Customer Number
Customer Name
Customer Address
Customer Zip Code
Date Of birth
... and so on.
Dimensions: are qualitative data. These are objects of the subjects.
Dimension attributes : These are columns of dimension table.
Facts : are the quantitative data. The data which can be summed up , averaged or manipulated. If manipulation is done in the data then it would be to provide business insights. Manipulated data eg : time dimension can't be measured but hours calculated using time is a measurable fact.
Example : Consider e commerce company table(amazon) which is Subject
Dimensions:
Product , date , customer , vendor , location(** these all are Objects of subjects**)
Dimension attributes:
PRODUCT - (Product_id , Product_name , Product_class)
DATE - (Order_date , Shipment_Date , Delivery_date)
CUSTOMER - (Cust_id , Cust_name)
LOCATION -(State , city , town , zip_code)
Facts:
PRODUCT - Total number of products sold
DATE - Total number of products sold in last one month/ last one year / last one quater
CUSTOMER - Total amount paid by customer
LOCATION - Total sales done per region , per state , per city
- Total traffic(customer visited) in stores per region
I m doing some sample application where i had created discount field in opportunity product related list and i want to send an approval to the manager if discount range is more than 20% like that but while creating an approval process i m not able to select opportunity product, only opportunity object is visible so that my discount field is not visible over there..
so how can i send an apporval for discount if field is present in opportunity product related list of opportunity..
please suggest me as i m new to salesforce platform
Thanks
You can create a rollup field on opportunity of type count. Have a criteria like: discount > 20%.
Now in your approval process, check for this rollup field, if it is greater than 0 meaning that opportunity has a line item where discount is greater than 20%; that opportunity will be qualified for approval.
So We have our basic tables for the categories, products, and variants of products
categories
id | name | active | parent_id
products
id | name | price | active
c_p_link
category_id | product_id
variants
id | product_id | price | price_override | active | stock
Which works great.
But I have two queries.
The first being how to structure the orders.
We have an orders table
id | customer_id | ordered | status
And we also have a order_products table
id | order_id ..?
this is the one I am curious about.
Say a customer orders 30 of a product. do we
Add 30 rows, and add the price for each individual item on each row.
Add one row, add the combined total onto the row
Add one row, add the individual price onto the row
The next part is, later we are expecting to add voucher support to the cart. e.g. 10% off, buy two, get one free etc. the overall design of this I am not too fussed about right now (this is a couple of months off at least). but I am wondering if that is going to affect which version of the order_products table I should choose?
Disclaimer: I have never written a database model dealing the "Shopping Carts" or "Orders"'
I think the price at time of purchase should be encoded into the purchase data: just like a paper receipt from a store. Let's call this total_price which represents each itemized "line" on the receipt and should not be confused with total_purchase_price.
That is, the amount charged is fixed. It doesn't matter if the product price changes later and changes to prices should not reflect in how much was [to be] paid.
Thus I would have these fields: product, unit_price, quantity, total_price. A computed column of say, base_total_price (unit_price * quantity) can be easily added if required.
Now, the total_price might be a computed value based on say base_total_price * precent_discount field: but, whatever it ends up being, I hold that total_price should exist and should be fixed at time of purchase. (This implies that, if it is a computed column, all inputs are also fixed at time of purchase.)
Addendum: As stated above, I've never designed a model like this before, but one thing I have observed at stores is discounts being applied as a negative cost itemized item. That is, items are bought "at full price" and then the register adds an entry to offset the cost per whatever promotional is occuring. I do not know the merits/reasoning of such an approach.
simply add quantity of product to your order_products table :)
I prefer the 3rd solution, i think it's the best for the performance of your database..