I've got a few products where I need the quantities for a specific product to start at a number, 240 for example and then the customer can select in intervals of 240, and for a different product, say 100 units. I need a way to separate a list of quantities for separate products.
You can examine the documentation related to InventoryItem endpoints which leads to InventoryLevel endpoints. Once you get a handle on Locations, you are free to set inventory levels. Note that setting explicit amounts is no longer the fashion, instead you ask how much is there, and then modify that amount with a delta change.
So if you ask for a product's variant level, and it tells you the current availability is 0, your delta might be +240.
Related
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.
Greetings.
I am working on a eCommerce website based on shopify. And for product I want to set a custom price. For example, The standard price of product is $500 but price will vary if user increased the quantity i.e. On 5 - 10 it will cost $450, On 11 - 15 it will cost $400 and on 20+ quantity it will cost $300.
I have searched module for this and also found a module i.e. https://apps.shopify.com/quantity-breaks. But its working on the basis of "Percent" that I don't need. Because I want to place price manually on the basis of quantity.
So please help me out from this and provide your valuable thoughts on the same.
Thanks in advance.
The way this is generally done in Shopify is to create variants where the option values are the price breaks. You have to modify your theme so that when a Qty > price break is entered the product page selects the variant that corresponds to that price level.
Other than the coding portion of this the main issue becomes inventory management since Shopify treats each variant as a separate inventory item but if you use variants to manage price breaks they are not actually separate items.
I think the easiest way to do this would be with a Shopify App. There are many that have price breaks etc. and they are usually easier to set up than using variants as the price break amounts.
I am making a small personal application regarding my trade of shares of various companies.
The actions can be selling shares of a company or buying. Therefore, the details to be saved in both cases would be:
Number of Shares
Average Price
Would it be better to use separate tables for "buy" and "sell" or just use one table for "trade" and keep a field that demarcates "buy" from "sell"?
Definitely the latter case - one table, simple one field (boolean) defining whether it's selling or buying. You should define tables by entities, not by actions taken on them.
This is actually a tricky one. The table you're talking about is basically a trade table, detailing all your buys and sells.
In that sense, you would think it would make sense to have both buys and sells in a single table.
However, in many jurisdictions, there is extra information for a sell order. That piece of information is which buy order to offset it against (for capital gains or profit purposes). While this is not necessary in a strict first-bought, first-sold (FBFS) environment, that's by no means the only possibility.
For example, under Australian law, you can actually offset a sale against your most recent purchase, as long as you have the rationale written down in clear language before-hand. Even though my company follow FBFS, I am allowed to receive bonus issues or supplemental shares which I can then sell immediately. These are offset against the most recent shares bought, not ones I've held for X number of years (this is often handy to minimise taxes payable).
If you follow a strict FBFS, then you don't need that extra information and your trades are symmetrical. Even where they're not, I've implemented it in one table with the extra information, useless for buy orders of course. That seemed the easiest way to go.
You could do it as two asymmetrical tables but that makes queries a bit more problematic since you often need to pull data from both tables. My advice is to stick with a single table with the extra information if needed.
I would also never store the average price. I prefer the quantity, the price per share and the brokerage costs. Every other figure can be calculated from those three, for example:
AvgPrice = (Brokerage + SharePrice * ShareQuant) / ShareQuant
but it's sometimes impossible to work backwards from just the average price, since you don't know what the brokerage was.
And I wouldn't have a boolean for buy/sell, it's just as easy to use negative numbers for the sell orders and it makes balance-sheet-type calculations a lot easier since you just sum values irrespective of the order type instead of needing to negate some of them depending on that order type.
Update: If, as you seem to indicate, you're only going to store aggregate information for each company, I would go for the following:
Companies:
CompanyId primary key
CompanyCode indexed
CompanyName
CompanyBuyQuant
CompanyBuyAvgPrice
CompanySellQuant
CompanySellAvgPrice
then you update the individual columns depending on whether it's a buy or sell. You don't need a separate row for the buy/sell stuff. When the company is first added, both quantities and prices are set to 0.
Your entity is now the company so this makes more sense. One thing you may want to consider is to store the aggregate values of shares bought and sold rather than the average buy and sell prices. That will simplify your update calculations and you can still easily get the averages by dividing the aggregate by the quantity.
So, the following table:
Companies:
CompanyId primary key
CompanyCode indexed
CompanyName
CompanyBuyQuant
CompanyBuyValue
CompanySellQuant
CompanySellValue
When adding a company, set all quanities and values to 0,
When buying M shares at N dollars each, add M to CompanyBuyQuant and N * M to CompanyBuyValue.
When selling M shares at N dollars each, add M to CompanySellQuant and N * M to CompanySellValue.
Get average buy price as CompanyBuyValue / CompanyBuyQuant.
Get average sell price as CompanySellValue / CompanySellQuant.
I'd go with a single table.
You can use negative quantities to indicate a sell. This is a fairly standard sort of indication. Subtraction is the same as adding a negative number!
One table. Each row/item is a trade, whether it's buy or sell.
Also, the aggregate of the quantity column will give you your current position. And cash too (-1 x quantity x price**) aggregated.
Buy or sell if inferred by the sign of the quantity: no need for separate column, unless you want to make a computed column derived from quantity.
**cash: When you sell (negative quantity) you get cash back (positive cash), hence -1 multiplier in case anyone wonders.
"Trade" can be ambiguous and it's not entirely clear to me what you want to do here. Are you interested in storing only your current position in each share or also the history of transactions that show how the position developed?
If you just want to record your holding ("position" might be a better word if you can be short) then I'd simply record for each share the number held. You mention average price, but I'd be cautious about that if you expect at any time to be able to sell part of a holding. What's the average price if you buy 100 at 50, 100 at 60 and sell 50 at 70?
Unless you expect your buy and sell transactions to number in the millions, I'd be more inclined to record each individual purchase or sale as a separate row in a single table and show the totals on demand as the derived results of a simple query.
Let's say I have a scenario where I have a Service that is responsible for retrieving the price of a single product given the ID and another Service that gives me the current stock position of it.
It's okay when I'm looking only at one product, but what about a list page where I have 60 products? What should I do in this case? Call the service product by product to retrieve it's current price and stock position?
I think this would be extremely slow and cost a lot of resources. But what could I do to make it look good and at the same time have performance?
Currently we have these information in the database in a column next to the product. These price and stock columns are updated by a sql service that updates it when is necessary so when I need to grab the value for a lot of products at the same time I just need to select two columns more. It's really fast, but right now we have some more systems in need of this information and I would like to transform all these stuff in a service.
Thanks a lot!
Well, you could always have multiple service methods:
the one you already have, to retrieve a single product, and the price for a single product
create a new service method which would take a list of product ID's, and return a list of product objects - or a new DTO (data-transfer object) that holds product and price
This way, you could keep your current users happy, and also do something to make batch requests work more efficiently.
Can your service method take an array of IDs? And return an array of values? That way if you want one record your array only has 1 item, if you want more, you just populate the array with multiple values?
I have a quote that contains items (store in table QuoteItem):
QuoteItemId, QuoteId, ItemId, Quantity etc.
Now, I need to be able to create a group of chosen items in the quote and apply a discount on it.
Well that's simple, I create two more tables:
Group: GroupId, DiscountPercentage
GroupQuoteItem: GroupId, QuoteItemId
Let's say I have 30 items in a quote.
I made a group that contains items 1-20 from the quote and I applied a discount on it.
Now I need to have another group that contains items 10-30, the problem is about those inner 10 items, I need to control whether the discount should apply on the items after the other discount or it should be on the items' base price.
For instance, I am gonna talk about item no. 15 in the quote: QuoteItem.Cost = 100
I applied 1st discount of 10% = 90.
Now I want to apply the second discount, I need to be able to control if the discount should be on the 100 or should be on the 90.
Same is when I have multiple discount groups and when I wanna apply a complex architecture of discounts.
Any assistance will be really appreciated.
I would look into adding a column to the GroupQuoteItem table, GroupQuoteItem.Priority. This column would be used in the query that determines the final price. If you have N discounts with the same, highest priority, they will be stacked atop each other (the order doesn't matter, thanks to associativity of multiplication).
If all of these high-priority discounts are later removed, lower-priority discounts can take their place. This should help you in setting up pretty complex discount structures.
I hope that at least gives you somewhere to start from.
It really depends on your own business rules. Do you want to apply the discounts on the price after discount or on the original price. When you ask questions like this it helps with SAMPLE Data then show us expected results.
This may be one of those rare times in normalization when you want to store data that you could calculate otherwise. So, in QuoteItem, you could have a Cost field and a DiscountedCost field. If they're the same, then you know no discount has been applied, if they are not, then a discount has been applied. By having this field, you would also be able to do comparisons on what the discount is already and whether you want to add the additional discount. In fact, you could also store that number in an ExistingDiscount field.
Why not store a column in the Group table that specifies whether or not the discount can be accumulated with other discounts versus if it must be applied to the base price only? You could name the field something like "ApplyToBasePriceOnly."
Other than that, I agree with JonH that a lot of this logic should be placed in business rules. I think your general database structure looks pretty good.