I'm curious if anyone has found a reliable solution with using SF Products in the following scenario.
Our business model does not have a standard Term or Amount for our products. For example, Product A has a 3 month term with a total budget of $5K. However, months 1 & 2 are $2K while the 3rd month is $1K.
When setting up a product, there is Qty & list price but doesn't allow the breakdown if monthly spend is different.
One note - Product Schedules wouldn't solve this with the current workflow.
With CPQ we can have block pricing and configure units as months and calculate the pricing but for that customer needs to have the CPQ package and license.
If the customer doesn't have a CPQ package then the customer needs to have customer implementation of their own to support the tiers.
With a custom solution, you can reinvent the wheel that CPQ has provided.
Thanks!
Related
I’m interested in getting estimated sales of kindle books from the mws api.
This is for all kindle books in a specific category.
Is this possible?
There is no way to get this information directly from Amazon. What you can do however, is make your own assessment. The best way to do this is getting the products competitive pricing to estimate how much you would be selling the item for as well as sales ranking for that item.
Use products API: Here
Remember:
The Amazon Sales Rank is a number which captures the item's popularity in a certain category, sales rank exists for all products who are part of a category (some products don't have a category). The Sales Rank interval can be between 1 and 1 million+.
In short, the sale rank in amazon (updated hourly) is the factor of how product is selling in comparison with others in same category the lower rank , the better a product is selling, Rank #1 is the best. you can sell it very fast in 24hr if your price is relatively competitive
Unfortunately, Amazon doesn’t reveal the algorithm of its sale ranking.
You can get a general idea of the sales ranking here.
I do descriptive analytics and reporting at a company that sells a wide range of products. We record sales transactions and everytime an item is sold, the following is recorded:
Customer ID (each customer has a unique ID)
Product ID (each product has a unique ID)
Sale date
(Other fields are recorded too - location of purchase, quantity, payment type, etc.)
We sell a few big ticket items, and what I'm wondering is if it's possible to predict whether a customer will buy one of the big ticket items based on their purchase history, using transactional data as described above. We have about 2 million rows of sales data spanning seven years, and in that time maybe 14,000 big ticket items have been sold to 5,000 out of 50,000 customers.
I use SQL Server 2008 R2 which has the data mining feature. I did some brief reading on it but can't figure out what model would be best, or if it's something that's even doable. Can someone point me in the right direction to get started?
Not sure if the SQL server data mining feature is useful. I took a look at the one for SQL 2012 and decided it wasn't.
As for your prediction, this would be a supervised learning problem (just pick any simple algorithm), where each customer is a row and your features would be the different products. Your positive labels then would then be the rows of customers that had bought big ticket items.
what you are looking for is called sequential pattern mining and the specific technique that you are looking for is called discrete event prediction. However with that being said, I don't think you will be able to do what you want to do with an out of the box solution on sql server.
I have been given the following scenario :
HyperAV is a retailer of home cinema equipment. They sell a variety of products including televisions, speakers, amplifiers, Blu-ray/DVD players and cables. The company has its head office in Stockport and 5 retail branches around the UK (in London, York, Cardiff, Manchester and Newcastle) and a large warehouse in Birmingham.
Due to the specialised nature of the products most sales are made in the shops which also have demonstration facilities allowing staff to show off the products to customers before they buy. However, the shops can also take orders over the telephone. The company deals with a number of suppliers who deliver items to both the shops and the warehouse. Limited space is available in the shops, so large numbers of items are stored at the warehouse and sent to the shops when their stock runs low.
The company’s buyer and stock controller are based in Stockport and work together to ensure that each branch has an adequate stock level of fast-selling items. If a shop takes an order for a product that it does not hold in stock, payment is taken and the item is sent to the shop from the warehouse. If the warehouse does not have a product in stock, it is ordered from the supplier by the buyer.
From this scenario I have been asked to draw a use case diagram.
I have received feedback but only to an extent where I have been told it is slightly incorrect. I would like to know if anyone can see what is wrong with it or how i can improve it in anyway?
I will not go and analyze what is right/wrong with your business case, but here are a few remarks:
Do not use Generalization with UCs. Each UC shall be a unique added value the system under consideration (SUC) delivers to the actor. If you have Generalization this means your UC is not unique. E.g. Deliver product: these are two absolutely separate UCs. They use a delivery service. But that's a UC for another SUC (namely the delivery service).
Avoid the use of <<include>>/<<extend>> as they indicate the use of functional analysis. UCs are about synthesis which is the opposite of that.
Use verb-substantive to name your UC. Order for example is not a UC.
Think about the "use" in UC. What is the added value it returns to its actor? If that is not of a real use, it's not UC. Process payment is an administrative task, not a UC. So what is the use behind this?
Imagine you're creating a website that allows people to search for rental cars based on price, amongst other things. Some rental cars are more popular at certain times of the year than others, so their price varies based on date. For instance, a car might cost $90/day most of the year except for December & March, when it costs $110/day, and in January & February it costs $130/day. Is it possible to have a calculated field in Solr, so you can search for a car that costs less than $X/day over the duration of your rental? I'm new to Solr, so have absolutely no idea whether this is possible or not - sorry if I'm asking a dumb question.
One possibility that I've come across would be to index the item once for each price, and have start and end dates for each of these. This copes with the price changes, but won't work for rentals that cross price boundaries; for example, a customer might want to rent a car for one week in February and two weeks in March - we'd end up not finding the car in this case.
I'm using Solr 3.5. Is it possible to do this using a FunctionQuery? I've seen some documentation on them, but all the examples I've seen are using them to return a computed value, rather than performing a search on that computed value. If I can't do this using a FunctionQuery, how could I do it?
I think this might be possible:
In your index you can have different types of columns containing the different prices of different seasons. In your query, you need need to use a product on the price during a certain season against the number of days in that season, and sum it to the product on the price during the other season against the number of days in that season. Yes, you'll have to use FunctionQuery. The means of providing how many days falls into which season that you'll probably have to do on the client that is calling the solr web service. Furthermore, you can try to apply a filter query on the result to pick out the amount that the user is willing to pay.
I need an elegant way to implement credit-based purchases for an online store with a small variety of products which can be purchased using virtual credit or real currency. Alternatively, products could only be priced in credits.
Previous work
I have implemented credit-based purchasing before using different product types (eg. Credit, Voucher or Music) with post-order processing to assign purchased credit to users in the form of real currency, which could subsequently be used to discount future orders' charge totals.
This worked fairly well as a makeshift solution, but did not succeed in disconnecting the virtual currency from the real currency, which is what I'd like to do, since spending credits is psychologically easier for customers than spending real currency.
Design
I need guidance on designing the database correctly with support for the simultaneous bulk purchase of credits at a discount along with real currency products. Alternatively, should all products be priced in credits and only credit have a real currency value?
Existing Database Design
Partial Products table:
ProductId
Title
Type
UnitPrice
SalePrice
Partial Orders table:
OrderId
UserId (related to Users table, not shown)
Status
Value
Total
Partial OrderItems table (similar to CartItems table):
OrderItemId
OrderId (related to Orders table)
ProductId (related to Products table)
Quantity
UnitPrice
SalePrice
Prospective UserCredits table:
CreditId
UserId (related to Users table, not shown)
Value (+/- value. Summed over time to determine saldo.)
Date
I'm using ASP.NET MVC and LINQ-to-SQL on a SQL Server database.
You don't pay your suppliers in Credits, so from an internal accounting perspective it would be better to hold only hard cash values (USD, UKP, whatever) against your products.
When displaying to your site's users you need a currency conversion table which translates hard prices into vouchers. Separating the data model from the front end display is a key design strategy. Whether you decide to show both real cash price and virtual credit price or just the credit valuation should have no bearing on how the data is stored in the database.
Talk to your accounting/finance people. Credit, once given, is as real as any money in double accounting, true you are not paying your suppliers in credits, but you are promising to deliver goods for credits that you will have to pay in hard cash. It should all balance at all times, and to see your complete financial position you should be able to get these credits in your balance sheet.
Try to model accounts and transactions, as well, right from the start - it will be easier to connect to finance/accounting software later and it is always good if you can run reports on both sides for purposes of reconciliation.