Comments (16)
I think we're in violent agreement: if you don't use shipping methods that depend on dimensions, you don't have to have the part on your products. USPS and FedEx could still look for it though.
from orchardcore.commerce.
I understand now. But taxes on the products in the cart also depend at least in part on the destination of shipping. That is the match I meant.
from orchardcore.commerce.
Some Nwazet implementation links for reference below. NWazet used the USPS shipping service, which may be a little dated, but gives a good reference point for what it takes to implement a shipping service for items that vary in size and weight, to any place in the world.
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/IShippingAreaProvider.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/IShippingMethodProvider.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/ShippingService.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/UspsService.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/UspsContainer.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/UspsShippingMethodProvider.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/UspsWebService.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/WeightBasedShippingMethodProvider.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Services/SizeBasedShippingMethodProvider.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Models/UspsSettingsPart.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Models/UspsShippingMethodPart.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Models/UspsShippingOptionList.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Models/WeightBasedShippingMethodPart.cs
- https://github.com/bleroy/Nwazet.Commerce/blob/master/Models/SizeBasedShippingMethodPart.cs
from orchardcore.commerce.
I don't know about other countries, in the USA the notion of a "Size" picklist is very handy as a lot of clients set up their generic shipping pricing matrix based on "Size" and "Destination" (where "Destination" is either a state and/or country. This works pretty good because of flat rate boxes. So for the generic one I would love to see a toggle between "Size" based approach and "Unit" based approach.
from orchardcore.commerce.
Fixed rate and Rate by size/weight with excel spreadsheet import/export.
from orchardcore.commerce.
Destination:
I think resurrecting something like the Territories form Nwazet would be useful, to match shipping and taxes.
I think the generic shipping method should not have "size" or properties like that. We should, however, provide an extension point for those. Meaning that a shipping method would have its own list of those conditions
from orchardcore.commerce.
Please open a separate issue for territories.
The reason for having size outside of providers is that they really are common. If I ship through FedEx and USPS, they will both require weight. I don't want to have to enter a USPS weight and a FedEx weight for the same product. Am I missing something?
This being said, we could have a weight part, a volume part, and so on.
from orchardcore.commerce.
Specifically the weight:
I see that as something attached to the product. Both USPS and FedEx providers would look for that on products in a checkout step where shipping is "computed".
A free or fixed price shipping would not need that.
from orchardcore.commerce.
Destination:
I think resurrecting something like the Territories form Nwazet would be useful, to match shipping and taxes.
Shipping providers usually returns prices with tax. So there is no need to tax again shipping rates. It's supposed to be added on top of the actual invoice total price + taxes :
(Multiple Product Prices) = (Invoice Subtotal + Tax)
(Invoice Subtotal + Tax) + Shipping Price = Invoice Total
from orchardcore.commerce.
you would still need to tax the other products in the cart, right? Or do shipping providers take care of that?
from orchardcore.commerce.
The shipping price is a separate product which includes it's own tax. If you use USPS they will include tax depending on where the package departs from. Though, the shipping tax is not part of the Invoice tax because it is a service that is not given by you but by the shipping provider. So you don't need to manage these tax in your accounting.
The shipping provider is a "subcontractor"
Though the tax provider is a feature that we require too.
from orchardcore.commerce.
Is implementation of shipping (costs) is already in progress?
I am currently porting an O1 website to OC.
In O1 Nwazet.Commerce there was an IShippingMethodProvider interface. Implement a custom shipping method just needs to derive from that interface.
For Orchard Commerce, I do not see any interfaces or preparations for handling shipping costs.
Since my shipping costs calculations depend on the ZIP, I would ask user for ZIP and store it together with the calculated shipping cost. But where to store them? Should ShoppingCartViewModel be extended to keep the info about shipment?
I thought about implementing a new class deriving from ShoppingCartEventsBase and use this to calculate the shipping costs.
Would that be a way to go? If not, any suggestions?
ShoppingCartViewModel
Thanks,
Dieter
from orchardcore.commerce.
Hi Dieter,
this issue is not in progress. It's up for grabs to the community if anyone is interested.
I would ask user for ZIP and store it together with the calculated shipping cost. But where to store them?
I don't think storing the price is the best approach. If your shipping cost only depends on the shipping address, then it's more efficient to store a table that correlates ZIP to shipping price as an OC site setting or in appsettings.json and just look that up when needed.
You can already generate shipping cost as an additional cart item using current OrchardCore.Commerce like this:
In OCC if the user has a saved address (in ~/user/addresses
) that's taken into consideration during the initial price calculation. Also when you change the shipping address fields during checkout, that too triggers order recalculation using the ~/checkout/price
API.
Under the hood, price calculation uses the same IPaymentService.CreateCheckoutViewModelAsync()
that payment processing and order creation relies on as well. Internally that fetches the shopping cart and creates a model of it. At the end of the shopping cart model creation it invokes the IShoppingCartEvents.ViewModelCreatedAsync()
event.
So if you add your own IShoppingCartEvents
implementation, you can use it to add an extra entry to viewModel.Lines
representing the shipping costs, and increment viewModel.Totals[0]
accordingly. You may have to update the ShoppingCartCell_Action.cshtml and ShoppingCartCell_Quantity.cshtml shapes to prevent interacting with this generated entry.
Hope this helps.
from orchardcore.commerce.
Thanks Sára,
I am actually trying this and looks great.
Wenn adding an extra entry to viewModel.Lines it is necessary to also reference a Product content item, since otherwise code will not work in many places.
To distinguish a shipping cost product from a normal product, what do you think about having a separate content type "ShippingCost" with a ProductPart and stereotype "ShippingCost". That would allow to make ShoppingCartCell_Action.cshtml, ShoppingCartCell_Quantity.cshtml etc. more generically.
Thanks
from orchardcore.commerce.
Hi Sára,
when adding the shipping cost only to the viewModel.Lines as described before, it is not part of the created order :(
PaymentService.CreateOrUpdateOrderFromShoppingCartAsync calls
via alterOrderAsync(order, isNew, total, cartViewModel, lineItems);
e. g.
CreateOrUpdateOrderFromShoppingCartAsync
but the implementation of CreateOrUpdateOrderFromShoppingCartAsync update the lines of the order part
orderPart.LineItems.SetItems(lineItems);
to the supplied lineItems, not to the lines of the view model.
Any suggestions?
from orchardcore.commerce.
This could be fixed in Payment/Services/PaymentService.cs in methods CreatePendingOrderFromShoppingCartAsync and CreateOrUpdateOrderFromShoppingCartAsync:
Instead of _shoppingCartHelpers.CreateOrderLineItemsAsync(cart) call _shoppingCartHelpers.CreateOrderLineItemsAsyncEx(cartViewModel)
(created CreateOrderLineItemsAsyncEx similar to existing CreateOrderLineItemsAsync but accepting the view model of the cart instead of the cart itself).
See also #397
from orchardcore.commerce.
Related Issues (20)
- Catalog navigation and Search (OCC-192) HOT 4
- Upgrade to Orchard Core 1.9 once it's released and remove Newtonsoft.Json from the code base (OCC-194) HOT 3
- Boolean product attributes not stored in the order screen. (OCC-195) HOT 1
- Product Attributes should display the field label or name instead in cart and order display (OCC-196)
- Cloudsmith publishing is broken (OCC-197) HOT 1
- Prevent checking out if there are unavailable products in the cart (OCC-199) HOT 4
- Integrate exactly payments for EU/UK merchants (OCC-203)
- Have a new community survey (OCC-204) HOT 1
- make class Address partial (OCC-205) HOT 13
- OrchardCore.Commerce.Tests.UI.Shortcuts NuGet misses metadata (OCC-207)
- Checkout exception if the Billing/ShippingAddressFieldEditor shapes are not present (OCC-208)
- The File Content Definition not generate ContentDefinition.json (OCC-213)
- CreateOrderLineItemsAsync does not take care of product discounts (OCC-214) HOT 1
- I have Created a new price variants product content item, but it couldn't display variants inventories. (OCC-217)
- Running FullSecurityScanShouldPass locally fails (OCC-218) HOT 5
- When Creating a new Product Content Item in BagPart, ProductPartIndex don't update. (OCC-220) HOT 1
- Multiple payment intents are created during a single session (OCC-221)
- Aggregating multiple products into a new product that has indepdent unit price,inventory, attributes and SKU, and can be sold indepdently. (OCC-222) HOT 2
- Upgrade to Orchard Core 1.8 (OCC-223) HOT 13
- Ambiguous HTTP methods (OCC-225)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from orchardcore.commerce.