On the check out page I need users to choose a delivery date. Their needs to be multiple shipping options (that cost different amounts), but these are restricted based on what day you choose. Alternately if you choose a shipping method first, this will restrict what days you can choose for delivery.
One shipping option is ‘saturday’, and the delivery date must be a saturday.
Another shipping option is ‘next day’, the delivery must be the next day, and the order must be made before 2pm.
The final option is 'standard', which has no limitations except it cant be delivered on a saturday, and the delivery cant be the next day.
Also, I need to be able to restrict dates for delivery for all shipping options, as deliveries wont be made on bank holidays or the day after.
Im really struggling to do this so Id appreciate any pointers. If I can only achieve some of what I need that may be ok as a compromise.
Thanks
This sounds like a perfect case for using a calendar table to identify which dates are actually holidays. While I don't have specific experience with Ubercart, I've used calendar tables in a number of different solutions, and even wrote up a blog entry that details how to create and use a calendar table with a MySQL server. It's quite long, so rather than post the whole thing here, I'll just point you to the actual entry at http://www.brianshowalter.com/calendar_tables.
Related
Hello FullCalendar team,
I am looking to build a feature that would limit the type of events that could go into a specific timeslot.
For example, I would like to indicate to a front-desk end-user that only a certain type of appointment was allowed to be entered into the timeslot. Perhaps the timeslot only takes meeting types that are tagged "check-ins" and "follow-ups" arbitrarily set by some higher up admin.
What would be the best way to go about building this limitation and displaying it to the user? I saw that there is an overlap function I might be able to use along with background-events. The higher-up admin might be able to create background-events that if they overlap with another requested event then limits the type. THen it would be very clear that any certain color-coded event set by the higher-admin would indicate that only certain types could be added.
But am I missing a very obvious way to do this? I was hoping there might be an easier way to templatize the day for end-users. Appreciate the advice.
I use Woocommerce to add orders from admin manually. Most of my clients pay after 15 to 90 days after order is created, in some cases longer than 90 days.
I notice that Woocommerce Analytics always shows revenue based on Order created date. I agree with it by one point of view as order was created on that day, so, the revenue belong there.
I think orders tab in Analytics shows it right, which is Date, Order, customer, amount, etc..
But I think Revenue should be based on order->get_paid_date() rather than created date as the money still comes in on the paid date. If Woocommerce changes the formula, it would make little to no difference for those whose orders are paid online immediately. And it will take care of those whose orders are paid later on.
Just curious, since logically Revenue is the money coming into account and Analytics>Orders tab shows Orders by created date well already.
Thanks for your input for me to understand how Woocommerce thinks.
Currently Woocommerce Analytics does not take paid date meta into account, it considers order creation date for revenue consideration.
It depends how one looks it, it's right and wrong.
For my use, where customers pay days or months later, it's wrong. but still the order was placed on the creation date, so, the revenue should still be linked to the creation date. so, it's right too.
One thing I did was from Analytics settings, I removed some custom status of the order to exclude from Analytics, that way until the order is actually either in Pending status or Completed status, it does not consider it in revenue. Not a perfect solution, but it helps me to exclude canceled and some custom status like Quotation not be included in Revenue.
I ended up programming my own custom admin page where I pulled all orders in completed status with paid date between start and end date and did the total manually to get my actual income for the year.
Just for someone else looking for similar question, it might help.
My client has two customer types (enterprises and individuals), he wants to propose different prices regarding the customer type. This customer type should be defined when the customer creates its account. I still haven't found a solution to do this automatically : after account creation depending on whether the customer said he is an enterprise or an individual, I want that the right price is automatically selected. Do you have any idea of how to do this without a manual user role given ?
Before registration, is it possible de display both prices so that the enterprise also knows what it will have to pay if it registered ?
That would be awesome if you have any idea of plugins doing this or how to code this.
Thanks a lot
Have a good day !
I believe you are looking for a what will be called a Wholesale User Plugin. There's a handful of them out there that you could look into. It will allow you to set up multiple user roles with different pricing structures.
We set up enhanced ecommerce tracking for our shop where we among other things track payment method for each order. In our shop, as a customer, I completed two orders with visa payment option, which can be seen in GA:
Two orders created with visa option, all fine (don't mind the duplicate records for now).
But then I create a third order in our shop with sofort banking (just another payment option) and look how things change:
All order payment methods were changed to sofort banking. Of course I've tried hard reload to see if caching is not involved and even waited a day to see if it changes anything but no, the records stay with sofort banking.
Now we come to the second problem - the duplication. For some reason when I filter with Secondary dimension: Checkout Options (as can be seen on the pics) I get for each tracked order 2 records in the table. Those two problems might be somehow connected.
The question is: Does anyone have an experience with this and knows where the problem might be? If you need additional info please let me know, as of now I don't know in which direction to elaborate.
I have two database tables
this is a sample database of a Ticketing system.
Figure 1: Sample table of air ticket.
Figure 2: Sample table of tax.
Requirement:
When ticket is made from the interface, it has multiple taxes of different names every time.
How can I store this information i.e. 'n' number of taxes for each ticket with different names every time.
I have tried to make many to many relationship but the problem is:
For each ticket if the tax is not setup, then need to add the tax first.
Any optimal solution for this?
"the problem is: For each ticket if the tax is not setup, then need to
add the tax first."
This is not a real-life problem. In real life governments declare taxes well in advance of collecting them, This gives organizations sufficient time to amend their systems which need to handle taxes. Tax is never a surprise.
"But this is very tiring solution for the end user.... to make bunch
of tax setup for each ticket"
This sort of thing is reference data, and is the duty of the system developer (hint: that's you) to populate the reference data tables. Or at least provide a screen where the user can create or amend various taxes. This is a different function from defining a ticket type.
The Ticket Creation screen should have a drop-down list (or similar widget) displaying all the existing taxes, which allows the user to pick the relevant one(s). If you reall think it's necessary you can include a link to the Create Tax screen, but that really is a very confusing workflow.
If the commentators are correct, and this is a ticket purchasing function, then your design is seriously wrong. Sales taxes must be included automatically to the cost of the purcahse as part of the transaction. Otherwise nobody would pay any tax.