Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different shipping methods by item #38

Open
marfago opened this issue Jan 19, 2015 · 7 comments
Open

Different shipping methods by item #38

marfago opened this issue Jan 19, 2015 · 7 comments

Comments

@marfago
Copy link

marfago commented Jan 19, 2015

Hi,

Would it be possible to ship items with a subset of available shipping methods?
Suppose you have items i1 and i2 and shipping methods sm1,sm2,sm3, I would like to configure the plugin to have (for example)
i1->sm1,sm2
i2->sm2,sm3

Is it possible?
Thanks.
M@rco

@rnixx
Copy link
Member

rnixx commented Jan 20, 2015

hi, this feature is not implemented.
-r

@marfago
Copy link
Author

marfago commented Jan 20, 2015

Could you please point out a possible solution in order to implement this feature?
Thnak you.
M@rco

@marfago marfago closed this as completed Jan 20, 2015
@marfago marfago reopened this Jan 20, 2015
@rnixx
Copy link
Member

rnixx commented Jan 21, 2015

may you describe the user story and feature a little more in detail. so others can add their thoughts and then we can think about the possible implementation. thx

@marfago
Copy link
Author

marfago commented Jan 21, 2015

Suppose the shop offers 3 shipping methods:
-mail service (2€)
-insured mail service (3€)
-carrier (10€)

Suppose the shop sells digital printed photos on paper, digital printed photos on cups, digital printed photos on pillows.

A buyer of a photo on paper asks to deliver it by public or insured mail service (cheaper) and not a carrier.
But, a buyer of a pillow should not be allowed to select any mail service, since the item cannot be shipped in that way (it is too heavy or too big).

A buyer of 1 paper can ask for mail shipping, but a buyer of 1000 cannot (only carrier should be allowed).

The simplest way to handle this use case is to simply assign to any item the allowed shipping methods in the back-office. A little bit complicated approach is to configure some rules (for example based on overall weight,size,number of items in the basket, or more, based on administrator's assignments) in order to the system to show the available choices to the user.

@rnixx
Copy link
Member

rnixx commented Jan 30, 2015

i would prefer defining the possible shipping methods on the item. But it's no done then. At checkout time a check must be performed whether all items can be shipped by an intersection of possible shipping methods, and if not, the shipping must be split up, which also implies changes how the shipping is stored on the order, since an order may contain more than one shipping then.

@marfago
Copy link
Author

marfago commented Jan 30, 2015

There is one more scenario. Sometimes the shipping method does not depend only on the item category but on the quantity or weight or distance (for instance domestic shipping / international shipping).
So a post check on some (dynamic?) rules should be performed before accept the order.

@rnixx
Copy link
Member

rnixx commented Jan 30, 2015

there are so many different usecases out there that it might be close to impossible to implement all thinkable combinations in a generic manner.

what all the shop packages try to achieve is a common and documented way of hooking into it by defined interfaces, each for defined purpose, at the same time providing senceful defaults.

your proposal makes me think of the following general requirements if we want to get things done here without polluting the software in the first place:

  • there need to be support for different shippings per order, which may or may not include shipping weight calculation features, as example in response to your latest comment.
  • each shipping method should be implemented that it's basically bound to IBuyable, including item specific settings if necessary, cascading shipping settings defaults.
  • there should be 0-n shipping methods possible per item, probably with application priority.
  • shipping methods which apply to a potential order (filled shopping cart) should get evaluated due to some kind of evaluation pipeline, ending up with an enumeration of shippings to use with corresponding value and related items.
  • the shipping pipeline execution should have it's own API to be used for cart rendering (dynamic), checkout process (dynamic) and order processing (finally persisted) where appropriate.
  • Basic interfaces which can be extended already exist in https://github.com/bluedynamics/bda.plone.shipping/blob/master/src/bda/plone/shipping/interfaces.py
  • The interfaces should be extended by an IOrderShipping interface (or whichever name used) describing the overall order shipping related API.

Additional thoughts and ideas are highly appreciated.

@jensens jensens transferred this issue from bluedynamics/bda.plone.shipping May 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants