I am building a system that publishes products from our inventory to our eBay seller account. Everything is working fine, but I just keep thinking which call should I use when I update the quantity in our inventory.
RelistFixedPriceItem and AddFixedPriceItem both are working well, except that on eBay I will have same item with two different itemID, one is sold and one is active...
is that ok? Does it have something to do with eBay listing terms?
Any Advice?
Thanks
AddFixedPriceItem creates a new listing that does not include any data regarding the previous listing's statistics or sales data. RelistFixedPriceItem will create a listing for the product that does include the sales data from the original listing.
The eBay best match search engine uses a listing's sales stats as part of its algorithm to determine search standing. So if your original listing had a good number of views or sales, I would definitely recommend using ReslistFixedPriceItem. However, if your previous listings was stagnant for a long time without many views or sales, it might be more advantageous to use AddFixedPriceItem instead to give the listing a clean slate.
eBay is always changing their search algorithms, so there is no hard and fast rule here. You really just have to find out what works best for your particular products. Experimentation is key.
Related
I am a shopify partner, I am trying to get around the the variant limits of shopify by coding an app and also because my client has a complicated formula for calculating the price. I don't have a problem with the part that adds the information for my variants to the order, however when I want to modify the price based on the user selection, it doesn't seem an easy task to do.
I came across couple of apps which does the same thing by adding a new product or variation which is not optimal for my use case, is there any app that does the job without adding extra information to the database, if so, how?
Qualified Yes
Unfortunately, Shopify doesn't give us a lot of options to edit prices of items dynamically. Here are the two options that I know of that will allow you to adjust the price of a product directly - however, both have limitations.
Using Shopify Script Editor
If you're working with a Shopify Plus merchant, you can use the Shopify Script Editor to dynamically adjust the prices of products, provided that the direction you adjust is down. You cannot increase the price of a product using the script editor - so for your use case, the list price would have to be the most expensive possible price that the item sells for, which you would then discount appropriately using the app.
Using draft orders
Using an app, you can use Shopify's Draft Order API to create an order with custom discounts and/or create completely custom items that are independent of the products set up in the product database.
The basic flow for this is that when the customer clicks 'checkout' you halt the normal navigation, send the cart contents to your app, create a draft order with the appropriate pricing, then supply the front-end code with the draft-order checkout/invoice URL so that you can send the customer there instead of the normal checkout. This has several limitations, however, including that prices of existing products can only be discounted, not increased, and the fact that Shopify will not allow a customer to use discount codes on a draft order invoice - once an order is set up this way, Shopify's assumption is that all prices are final.
Disclaimer: Sorry if someone sensible doesn't like a response with a link :) I'm not related to this app I'm just a user.
On a project with complex pricing, we use the app Wholesale Pricing Discount by Wholesale Helper we liked because is easy to import multiple pricing by-product and relate it by customer.
this app does not multiply the products, they use customer tags. maybe that can give you some guidance.
An important rule on Shopify is you can't increase the price by API on an order, you can just reduce i
I'm building an integration for my warehouse and using Amazon's API's to get product information from UPC. I've ran into a number of times where a result comes back accurately from the GetMatchingProduct on MWS API but not from the Product Advertising API. Even Vice Versa has occurred.
Why might this be? Is there a reason I should just use one or the other?
Example: UPC - 363824072463
MWS brings back ASIN - B0057UUHGU which is the relevant one that also comes back when you just search Amazon. However the Product Advertising API does not return this in its list of results at all.
We have found that often times new, or recently changed items take a little while to correctly populate in the Product Advertising API.
Also, for what you say your purposes are, I would be cautious relying on the Product Advertising API. It is a sales tool, so sometimes when given an out-of-stock item, for instance, it will return results of a different item (maybe similar, maybe was variated with it, etc) as the purpose of that API is to drive sales to Amazon.
I have designed some API which have some nested resources and I am wondering how to reduce the number of POSTS when I am creating some records.
for example, I have the following resources:
/orders/
and
/orders/{order_id}/products/
at the moment I need to run two POST separately if I need to create a new order or a new order's product but I would like to reduce the time for this and run only one POST.
Is this possible? is there any documentation I can read about this?
Thank you
Although you might have found your answer in an other thread there is still some issue regarding your endpoint design.
The first intuition that your endpoint give is that product resource could exist in several place.
./orders/{order_id}/products/{prod_id}
./products/{prod_id}
The question you should ask yourself is: Do you really want to refer to product?
Can product be leaving outside of any orders?
Having a resource sitting in 2 different place might not be that great as you are managing 2 different endpoint with similar behavior. Keeping consistency between both endpoint is not that easy.
My 2 cent is to avoid the term product as it can be confused with a single instance of a product. For example if you sell a toothbrush branded AAA, sku 1234 an order is not compose by this product but by one off the item that you have in stock. The item is "instance" of the toothbrush branded AAA, sku 1234.
As I understand your question you are not really referring to a product but more to a stock-item which should be a unique id.
The resource stock-item if you decide to have one should exist prior to the order. I guess the customer is not adding item to your stock and at the same time purchasing this item.
In conclusion I think that you are not creating the stock-item resource at all when creating orders but just making a reference to it.
A client of mine has a service-oriented ecommerce site on Shopify and he's asked me to assist in making a few changes. I've never utilized the service so I'm not really familiar with it.
The price list was static at first since the client used the same vendor however now that they're growing - and therefore using multiple vendors - the costs are fluctuating and therefore the prices on Shopify need to reflect that.
I need to set it up so that when a customer logs on a vendor is programmatically chosen based on their geographic location and the prices (shown to the customer) adjust accordingly.
Is this possible? And if so, what objects/API docs should I be looking at. I seems as if I can easily hard code this with IF statements but I'd like this to scale cleanly so I'm looking for a more efficient solution.
I think this should be possible. Based on your comment:
Will I not have a zip code for the customer? – RyanMac
The easiest way would be to create a Product Variant for each region. Based on the customer.default_address you could find the customers ZIP code. Next step would be to use this within the product.liquid template to select the correct variant.
The biggest problem you have is determining their location. When a customer logs in, you know who they are, so you could dish out only products of interest to them. Problem is, how do you lump people into those regions? You have your work cut out there. When you create a customer you can assign them any code you want, so perhaps you could just match customers to vendors using a match on that. Lump any customers into GroupA and you show only products with Vendor GroupA, any customers assigned to GroupB render products from vendor GroupB....etc
I'm working on a store that has two types of products: perishable food and general merchandise. The food must always be shipped overnight via FedEx, and the other merchandise must always be shipped via USPS. If somebody orders products from both categories, they must be shipped separately.
Do you know of an existing module or configuration settings that would allow for this?
If not, it sounds like a custom module would be the other solution. In this case, what is the best approach? I'm thinking it would be splitting the order into a multi-address shipment, using the same address for both but with different shipping methods. Unfortunately I'm not sure how to do this programatically, so any tutorials/samples/resources would be greatly appreciated.
Probably the sanest way to handle this would be to create two orders per product type, each shipping with a different carrier to the same address. This also IMO makes more sense from a stores tracking perspective as you can handle each independently from each other.
To get you on the right track(since Magento is especially cryptic in this part of itself) you should read the Inchoo programmatically create order in Magento post and by the same author Programatically create customer and order in Magento with full blown one page checkout.
Basically as I see this going is:
Get the customer order
Itinerate through each product inside the order and split it up in two arrays for each product type
Create a separate order for each product type and use the different shipping methods for each.
You will probably have to extend a some controllers OR do it the non-standard way and use helper functions for this, the hard parts will be integrating the payment/shipping modules inside your order process. Going this way will have you creating the full checkout process as the one page checkout Magento provides won't really work and is too much pain to get to work because of the way it uses AJAX.
Also another alternative is to hook in to Magento's pre-create order events and create the orders there using already defined order data split it up in two orders, but this is something I never heard or saw implemented at the moment so you'd have to do it "blindfolded" so to speak.
An easier approach would be to use a custom field that defines your product's shipping method, this way you just add that and don't care about custom orders. You just react with that, however tracking will become mostly impossible IMO.
Over-ride the Free Shipping module.
You can setup a sales rule that applies to certain products and makes them 'Free Shipping', leaving the other products to your chosen main shipment provider.
You will need to see how this works, however, the point is that Magento does have something built in to split an order into two shipping categories, albeit only a sales rule on free shipping. But you have source code...