I'm trying to obtain the Listing price via the Etsy API. But I stuck in a problem with discounted prices.
There is a listing that I'm trying to obtain: https://www.etsy.com/listing/679432133/turkish-kilim-geometric-kilim-handmade. It's original price is $590 and discounted price is $236.
The problem is that I get only the original price via open API: https://openapi.etsy.com/v2/listings/679432133/?api_key=MY_KEY&fields=price, but I need to obtain the discounted one.
I'm reading the documentation already for the past three years but it looks like it's impossible via API.
Any help?
Unfortunately, getting the discounted price is not available when getting listings via the API. Mainly because the discounted price is not an attribute of the Listing itself. Rather, the discounted price is usually derived from applying any number of coupons/sales/promotions from within your shop.
For example, if you have listing A at $100. Then run a 50% off sale for any quantity purchased... then the discount price is $50. Then if you edit the sale to require a purchase quantity of 2 or more... then the price is back to $100. And if you offer a coupon for a specific item for 10% off, now the price is $90.
All of this is just to illustrate how the discounted price for a listing is not really a direct attribute of the listing alone... but rather is a "derived" price.
If you want to know the discounted price, then the closest thing that I can think of is that you would have to use the API to add the listing to a cart. That will return the contents of the Cart that does have a field named "discount_amount" that will let you detect any line item discounts applied to the cart. From there you could subtract the "discount_amount" from the "total" to try and calculate the discount price.
At best, however, this would be an approximation of the discount price you are looking for.
Related
So I have a table categories with the following columns:
Id, Category, Vat, Tax
And a products tables with the following columns:
Id, idCategory, Code, Product, Stock, buyingPrice, sellingPrice, Sales
When creating a new product the value of a product is entered and the buyingPrice is calculated by adding the Vat and Tax from the categories table to the value.
The sellingPrice is then calculated by a percentage markup of the buying price.
I now want to be able to automatically update the buyingPrice of all products if the Vat or Tax is changed.
I have tried creating a trigger but I am currently unable to work it out. I'm not sure if it's because the original value is not saved or if I am doing it all wrong. I have never created a trigger before so any push in the right direction would be appreciated.
I think Strawberry has a great comment here; you should store the VAT and tax separately and apply them to the base price that you store, rather than storing it as a final selling price that includes VAT or tax.
In your scenario, what happens if the VAT is reduced by 0.5%? Your trigger can be modified to properly account for newly inserted items, but how will you go back and correct existing ones? In the US, an item can be exempt from sales tax (if the purchaser is a certain type of non-profit organization or other exempt business, or in certain states during a sales-tax holiday). Again, in the US, sales tax calculations regarding putting an item on sale can be complicated. I'm not making the assumption that your situation will require dealing with those situations, but it seems like it would benefit you to not need to recalculate every item in your database if any of these were to apply.
If you really insist on this, I'd personally rather use a view to calculate the price on the fly rather than using a trigger to calculate it on insertion, but that's just me. Again, I'd ultimately prefer to handle this in the application logic.
I have a process wherein I need to keep the history of a database records information, however the user needs to be able to change it at any time they please.
Scenario:
Seller creates an item with price of $5 and name of "foo"
Buyers buys item, an order is created linking to that item id
A while later, seller updates item name to "foobar" and item price to $6
Buyer views order history. The item name should be "foo" and price should be $5 since that's what they bought it at, but they are "foobar" and $6, respectively
This happens because when the seller updates the item, they are updating the same item the order is related to.
I thought of 3 possible solutions to this problem, and I would like to get your thoughts on which one you think is best (maybe from your prior experience), or a better solution I have not yet thought of. This is my first time dealing with this situation, so not sure how best to proceed without needing a refactor later.
My solutions:
Make the item name and price immutable.
Bad UX, cause now user has to delete item and recreate it if they want to make a modification
Requires some kind of deleted_at column in case user wants to delete the item after it has been purchased so that I can still keep it for referencing later to grab history data
Create a second table for history purposes
Not horrible, but requires a second table with a different name, not a big fan of the idea
Would have to run queries potentially twice to check both tables for similar data, as opposed to just querying one table
Create two records in the same table, and mark a boolean flag or some other flag to differentiate from historical/current records
I like this one the best, but not sure if the boolean flag may have any negative performance implications
I've encountered this issue too, particularly in product catalogs where the price changes frequently. Or the price may be on sale or discounted for a specific customer for some reason.
The only solution I've found is to copy the relevant product details to the customer's order record at the time they buy the product. In your example, at least the product name and the product price would be copied.
This might seem like it goes against the philosophy of "don't store redundant data" but it's not redundant—it's a fact that the customer bought the product for some specific price on a specific date, and that is still a useful fact forever, even if the current price for that product changes.
There should still be a link to the original product table, so managers can track how many orders included each product, for example. But the current price in the product table does not affect the record of each customer's order.
You might also need to create a product history table, to keep a record of all the times the price or name was changed. But that's for historical record-keeping only, it wouldn't affect typical queries during shopping or buying activities.
In this design:
Product table always stores the current price.
When a customer buys a product, they copy the current price into their own order record.
When a manager changes a price, the app creates a new record in the ProductHistory table.
The most recent record for each product in the ProductHistory table matches the current price for the same product.
I recently discovered Poloniex's API and am a big fan. I am puzzled about the following thing though: I query one Poloniex's BTC-ETH trade history for a 24h trading period. E.g., https://poloniex.com/public?command=returnTradeHistory¤cyPair=BTC_ETH&start=1489190400&end=1489276799 queries all BTC-ETH trades on March 11, 2017 (UTC). The returned JSON contains 46,675 trades (below the API's max result size of 50k). When counting up all the sell- and buy-trades contained in this JSON, I see that there is a total of 8,814.124270 coins bought vs 7,754.184259 coins sold. How can that be? Shouldn't those two numbers be the same? What am I missing?
Thank you very much in advance.
A buy is when someone buys the ask, also known as an uptick.
A sell is when someone sells the bid, also known as a downtick.
Everything that is stuck on the book is considered liquidity. Market price buyers and sellers remove liquidity. People who put orders on the book add liquidity.
So no, the buys should not equal the sells as it is totally possible that all that happened one day is that everyone kept hitting the buy button.
Consider this, if the buys equalled the sells, why would you need the data sent twice, and how would you know whether the bid or ask was taken?
What Im trying to do is create a shipping estimator if you will. At this point ups and fedex have volume based prices and unfortunately my vendor doesnt supply dimensions for each product. However they do offer weights.
In table one I have Part#, weight, and price of shipping of past shipments.
In table Two I have Part#, weight of never been shipped items.
What I would like it to do:
set up a query that will take products from table 2 and find like weighted items from table 1, average there shipping prices and us this new number as the estimated shipping for the new product. The part im having a hard time wrapping my head around is searching for a range of weights. Lets say my product is 5lbs and I want to get shipping prices of all products ranging form 4.75 to 5.25.
My knowledge of access is somewhat limited. I would really appreciate some guidance here.
SELECT PartsUnshipped.PartNr, PartsUnshipped.Weight,
(SELECT AVG([ShipPrice]) FROM [PartsShipped]
WHERE [PartsShipped].[Weight] >=[PartsUnshipped].[Weight]-0.25
And [PartsShipped].[Weight] <=[PartsUnshipped].[Weight]+0.25) AS Estimated
FROM PartsUnshipped
This is one way to do it. Another way would be to simply join the two tables and run an Avg on the Shipped price but then you would only return non-nulls.
I have a Product database table with columns such as product_id, price, and inventory_count.
A user clicks to buy a certain product at a certain price. My program generates a confirmation page listing the product and the price. Everything is fine and the user clicks "Confirm". My program updates the inventory_count of that product and charges the user's credit card the amount listed in the product's price.
But during the time after the confirmation page is generated but before the user clicks "Confirm", the price of that product has been changed. So the user might have seen a price of $10 in the confirmation page but after he clicks "Confirm" the price in the Product table has already been changed to $11 and that's what he will be charged.
What's the best way to handle a situation like this? I'm using MySQL and Python if that's relevant.
Create a new table for pending purchases with the price you intend to actually charge, and add items to it when you generate the confirmation page.
Deduct from the Product table's inventory_count when you add an item to the Pending table, then you can re-increment the inventory_count if the purchase doesn't go through.
You definitely should carry over the price from the time the customer last had the chance to change his mind. I'm sure that's also a legal issue in which you'd not look so good.
Anyway, can't be to hard to implement one last check after the customer has confirmed, right? Maybe you then could show a notice that the price has changed.
I my opinion you should avoid situations like this (if I were your customer I would be disappointed).
But if you can't, when customer press confirm, do the last check of price and show message to user if it changed.