Packages shouldn't be split

[sohara]

@huoxito In our app it's important to make sure that bundles ship together. If one 'part' of the bundle is backordered then the entire shipment should remain together as one shipment. The behaviour we are seeing now is that they are being split into two packages, one with backordered variants and the other with on_hand variants. Can you think of any way to change this behaviour? I think that maybe we would have to override the Package class so that the content items know if they are part of an assembly or not?

[mrpollo]

Hey @sohara i think you might want to look into the backorder splitter https://github.com/spree/spree/blob/2-0-stable/core/app/models/spree/stock/splitter/backordered.rb sounds like it's splitting your order

[huoxito]

Here's a suggestion (I'll try to implement that myself later on, just need to think more about it before pushing here):

When looping through parts in Packer, here https://github.com/spree/spree-product-assembly/blob/2-1-stable/app/models/spree/stock/packer_decorator.rb#L28-34, we could do something like self.holds_bundle! and then here, https://github.com/spree/spree/blob/master/core/app/models/spree/stock/packer.rb#L12-18, only split if that Packer instance doesn't deal with a bundle.

[sohara]

@huoxito @mrpollo Thanks so much for your suggestions. I'm not sure what's going on with our stock situation here because the bundles are being split even when I remove Spree::Stock::Splitter::Backordered from the ssytem (the only splitter is Spree::Stock::Splitter::ShippingCategory ). I'll try this out on a stock spree store and see what happens.

[huoxito]

@sohara keep in mind that we build packages as per Stock Location so if the bundle has parts in different stock locations you will still end up with part split across packages / shipments. Would that be the case here?

[sohara]

@huoxito Yes, I realize that is the default behaviour but it is not desired for us... in general we'd like to keep bundles shipped together so customers don't have to pay extra shipping costs.

The strange thing is that I am not sure what is splitting the shipments on our store:

Spree::Stock::Splitter::Backordered.class_eval do

  def split(packages)
    return_next packages
  end

end

And the shipments are still being split, even though it prevents splitting when I add it to a stock Spree store. So there must be some other behaviour in our app that is also doing some 'splitting'. I will let you know if I can track it down.

[huoxito]

I think this is a better way to remove the Backordered splitter:

Rails.application.config.spree.stock_splitters = [Spree::Stock::Splitter::ShippingCategory]

By doing that none of your packages should be split by their backordered / on_hand status, being an assembly or not. In case we want to join parts from different Stock Location in the same shipment we probably need write a new Adjuster class or make the AssemblyPrioritizer join those parts on the same package. I'm afraid that will be a bit more complicated.

[sohara]

@huoxito Yes, I thought that should work, but I tried that yesterday and our shipments were still being split.

We don't want to join parts from different stock locations, we just want to not split shipments that have backordered parts. Instead we just want to have the entire shipment 'backordered' until all the items are in stock.

[huoxito]

Ok so please let us know if you can reproduce it on a fresh Spree install with product-assembly.

On Thu, Oct 10, 2013 at 3:01 PM, sohara notifications@github.com wrote:

@huoxito https://github.com/huoxito Yes, I thought that should work, but I tried that yesterday and our shipments were still being split.

We don't want to join parts from different stock locations, we just want to not split shipments that have backordered parts. Instead we just want to have the entire shipment 'backordered' until all the items are in stock.

— Reply to this email directly or view it on GitHubhttps://github.com/spree/spree-product-assembly/issues/56#issuecomment-26076408 .

Washington L Braga Jr

Developer Spree Commerce, Inc.