I wanna know how to make an ERD OR Relationship Scheme out of this. I've been practicing ERD's but this one is really confusing the hell out of me.
This is what I could make out of the narrative currently but not exactly sure how correct I am.
The owner/manager of SCBD, gives you the following information: SCBD conduct a number of
different tours to known microbrewery regions around Victoria. Each Daytrip has an ID, and a
description, and may run many times in a year (such as the West Daytrip). Frequency depends
on the season and the specific daytrip.. Each time it is run it is called an ‘Event’. Each event has
a fee. Fees have usually increased by around 10% each year. SCBD have a number of
customers. Each customer has a name, ID and gender. SCBD customers make bookings for
daytrip events. Payment is made by credit card. (you do not have to worry about recording
credit card details etc.). The date that a booking is made is also recorded.
Related
I am trying to implement seat based pricing but the documentation doesn't cover scenarios for changing plan mid subscription.
For reference these are the docs I am following: https://developer.paypal.com/docs/api/subscriptions/v1/
Let me give you an example. Lets say I have this pricing:
1-10 seats $5 each per month
11+ seats $3 each per month
To mimic this in PayPal I create 2 quantity based subscription plans. One with a quantity price of $5, the other for $3. Both plans are on the same product and have term set to monthly.
There are a few situations I am unsure how to handle and cannot find this information in the docs. They are as follows:
1) User signs up for 1 seat on the 1st June. On the 15th June they decide to change to 5 seats. The docs say this will be adjusted in the "next billing cycle" but I am unclear what that means. Their next billing cycle is in 15 days so does that mean they get access to 4 seats for free that month? What I would want to happen is the difference is calculated. The user has paid $5 so far and is halfway through the month so half a month cost is $2.50. The new subscription price is $25. So the remainder of the month would cost $12.50. So the difference to pay is $10 to cover them to the end of the month with the additional seats until they will then be billed $25 for a full month. Is this in anyway possible?
2) User signs ups for 5 seats. They then upgrade to 20 seats halfway through the month which moves them onto a different plan to get discounted pricing. How does situation 1 play out again in this regard when changing plans? How are the differences calculated and billed?
It seems in the old billings API you could override the setup cost when creating the subscription but that no longer seems possible. It is not possible to add the setup cost to a plan because this needs to be added dynamically based on the elapsed time in billing cycle, change in seat quantity and change in plan cost.
Have PayPal really removed all possible ways of dealing with package upgrades?
To have new arbitrary costs, setup or otherwise, you would need to dynamically create a bespoke package/plan for that particular checkout.
I'm trying to get Dialogflow to report sales in different time periods. When I ask things like
what's the sale last month
what's the sale in march 2011
They work fine. However, if I didn't specify "last" or year, Dialogflow always think I'm asking about the upcoming period (which I guess works great for restaurant booking, etc.). For example, "what was our sale in april" would guess that I mean April of next year.
Should I write a fulfillment to deal with this or is there a way to specify only historical periods only?
Another related question is it has trouble understanding notations like 2010q1 or q2/2015 which is quite common in economics and finance. "q1/2000" would extract only q1 (correctly, but with the upcoming q1). "2000q1" wouldn't be recognized at all.
Thanks!
Let's say we have a reactive sales forecasting system.
Every time we make a sale we re-calculate our Forecast for future sales.
This works beautifully if there are lots of sales triggering our re-forecasting.
What happens however if sales go from 100 events per second, to 0. And stay 0 for a long time?
The forecast we published back when sales were good stays being the most up to date forecast.
How would you model in this situation an event that represents 'No sales happening' without falling back to some batch hourly/minutely/arbitrary time segment event that says 'X time has passed'.
This is a specific case of a generic question - How do you model time passing with nothing happening in an event based system - without using a ticking clock style event which would wake everyone up to reconsider their current values [an implementation which would not scale].
The only option I have considered that makes sense:
Every time we take a sale, we also schedule a deferred event 2 hours in the future that asks us to reconsider our assessment of that sale.
In handling that deferred event we may then choose to schedule further deferred events for re-considering.
Considering this is a very generic scenario, you've made a rather large assumption that it's not possible to come up with a design for re-evaluating past sales in a scalable way unless it's done one sale at a time.
There are many different scale related numbers in the scenario, and you're only looking at the one whereby a single scheduled forecast updater may attempt to process a very large number of past sales at the same time.
Other scalability issues I can think of:
Reevaluating the forecast for every single new sale doesn't sound great if you're expecting 100s of sales per second. If you're talking about a financial forecasting model for accounting, it's unlikely it needs to be updated every single time the organisation makes a sale, if the organisation is making hundreds of sales a second.
If you're talking about a short term predictive engine to be used for financial markets (ie predicting how much cash you'll need in the next 10 seconds, or energy, or other resources), then it sounds like you have constant volatility and you're not really likely to have a situation where nothing happens for hours. And if you do need forecasts updated very frequently, waiting a couple of hours before triggering a re-update is not likely to get you the kind of information you need in the way you need it.
With your approach, you will end up with one future scheduled event per product (which could be large), and every time you make a sale, you'll be dropping the old scheduled event and scheduling a new one. So for frequently selling products, you'll be doing repetitive work to constantly kick the can down the road a bit further, when you're not likely to ever get there.
What constitutes a good design is going to be based on the real scenario. The generic case is interesting to think about, but good designs need to be shaped to their circumstances.
Here are a few ideas I have that might be appropriate:
If you want an updated forecast per product when that product has a sale, but some products can sell very frequently, then a good approach may be to throttle or buffer the sales on a per product basis. If a product is selling 50 times a second, you can probably afford to wait 1 second, 10 seconds, 2 hours, whatever and evaluate all those sales at once, rather than re-forecasting 50 times a second. Especially if your forecasting process is heavy, doing it for every sale is likely to cause high load for low value, as the information will be outdated almost straight away by the next sale.
You could also have a generic timer that updates forecasts for all products that haven't sold in the last window, but handle the products in buffers. For example, every hour you could pick the 10 products with the oldest forecasts and update them. This prevents the single timer from taking on re-forecasting the entire product set in one hit.
You could use only the single timer approach above and forget the forecast updates on every sale if you want something dead simple.
If you're worried about load from batch forecasting, this kind of work should be done on different hardware from the ones handling sales.
I have here a Websphere commerce 7 Fp 5 Aurora B2B which is using Orgs, contracts and price lists maximum order quantity that we limit each "Store" Org to buy 3 each so that there is enough to go around. We have 3 sets of entitlements to that most guys Max is 3, better stores max is 5 and a few really good ones max qty is 10.
So we don't have to worry about allocation, these rules let every store buy based on their entitlement. When they try to put more in the cart then they should, they get a message "You are requesting to order more than your allocation limit. Please change your requested quantity." I don't know where this comes from.
Some users buy for 5 or more stores which is selected at checkout during payment. This keeps those store owners from having to have a bunch of log ins to keep track of.
We recently openned up Order Management, we call it multi-cart because this enables a store owner to create more than 1 cart by going to order management and create a new order. This makes it much easier for our store owners to manage what they are buying and paying and receiving with out having to call and email our CSR teams.
But now we noticed that some stores are taking advantage of the Multi-cart to buy more that the MAX qty they are allowed. It wouldn't be so bad, but they are buying all the 1 per customer stuff and all the other stores are calling and complaining because they didn't get their share. It really isn't fair.
I was thinking of all the different places to add a SQL check of order history and pending orders. Here is what I cam up with.
ATP - Inventory check
Pro- best place since customer, sku, entitlement, and everything else pretty much happens here. It is right up front.
Con- It doens't have ship-to, so the guys with more than 1 store need to be added as an exception leading sloppy business logic that could change regularly
OrderItemAddCmdImpl and overloading ExtendOrderItemProcessCmd
Pro - Bring ship-to selection up to the front and control everything here.
Con - Not certain overhead will like it.
At checkout
Pro - this also will have everything
Con - I kind of want to reserve this for all payment handling. It is a little dirty to read throught the order lines and to kick back error with SKU.
Have the ERP handle the exception-
Con - I realized we are setup that all Orders ship complete, we would have to change this and don't really want to because there are additional credit card penalties for charges less then amount held on credit.
So, the questions are what are your thoughts on additional pros and cons?
Are there other places that I'm missing that would make more sense?
We might need to create a new CommandTask and then append it to all existing flows.
OR
As the WebSphere Commerce team to build this new logic into the next release of WebSphere Commerce.
So, for this scenario the answer was creating a JDBC Query that will be called when items are added to cart that sums the Qty by sku of pending orders.
When orderitems are added to the cart, the query will return the item in error if exceeded and not add item.
The query will again run at checkout if all orderitems being paid for exceed total qty max by SKU by shipping address on payment page allowing chance for customer to change billing address if we are limiting item max qty by shipping address.
Hi just got to say you are all life savers you know so much.
Ok got a store 1.72 magento and all working ok so I assign a registered person to Trade and they get all the trade prices for trade group for each product.
Problem is or should I say haven't been able to work out.
How do I create this so up to £200 subtotal they get standard prices over gets trade, to stop people buying one top at a time.
I see the discount amount from subtotal but as products they select are random wouldn't be able to calculate that.