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

Mni/source selection #33

Closed
wants to merge 2 commits into from
Closed

Conversation

vrann
Copy link
Contributor

@vrann vrann commented Jun 22, 2017

Design the extension points to inject multi-sources into the checkout process.
Issue: magento-engcom/magento2#30

Description

  • it should call Source Selection interface to allocate Order Items per sources
  • it should allow calculation shipping rate requests and aggregation of the results for the sources
  • it should display correct totals including the shipping cost
  • it should display the carriers and the sources for the merchant in the backend
  • It should reduce the stock number for the affected sources.

…i-Source

- prototype of the rate request per package
…i-Source

- prototype of the rate request per package
@vrann vrann self-assigned this Jun 22, 2017
@vrann vrann requested a review from maghamed June 22, 2017 21:34
*/
public function setAddress($address);

public function getQty();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need qty here as it is already part of \Magento\Quote\Api\Data\CartItemInterface?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, because qty here is the number of the product in this particular package. It can be less or equal to the qty of the product in the cart. I.e. 10 products with sku1 were requested, 6 fulfilled from source 1, 4 from source 2.

Copy link
Contributor

@ishakhsuvarov ishakhsuvarov Jun 23, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't it make sense to just have different quote items in different packages? As it is already implemented even in the current version of the Shipping Assignments

Duplication of the Qty in multiple places leads to complicated code which would be potentially hard to maintain

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with @ishakhsuvarov here.
Duplication of QTYs is misleading.
As QuoteItem (which represents single product SKU) has Qty
and Package which could consist of several SKUs has Qty (btw, why single, but not an array of quantities?)

So, it's hard to maintain and keep in consistent state.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's why I proposed to consider usage of Visitor pattern here,
to separate Data from Algorithm implementation.
That could help us to live with current data structure of Quote

@@ -34,6 +34,18 @@ public function getItems();
*/
public function setItems($value);


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest refactoring this interface in case we are already introducing BiC, as it does not reflect the desired state described in the latest version of the Multishipping design

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, let me see

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had a discussion regarding implementation of the Visitor pattern to integrate MSI with Quote. Maybe it is better to research that solution?

/**
* Skip if this item is virtual
*/
if ($item->getProduct()->isVirtual()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should virtual items be even included in the package?

Copy link
Contributor

@maghamed maghamed left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked through the interfaces added and modified.

For now Package interface introduces duplications of Qty data (Qty already represented in QuoteItem).
Also In ShippingAssignment we have a duplication of ShippingAddress.

We should have the only source of truth.
And taking into account that modification of Quote/QuoteItem interfaces is painful, it makes sense to consider Visitor pattern, which will provide an ability of segregation algorithm and Quote data

/**
* @return \Magento\InventoryApi\Api\Data\SourceInterface
*/
public function getSource();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we no need to return SourceInterface in this interface, because Package can't contain the whole Source entity, it's not an Aggregate Root for the source.

What it can contain is a reference to SourceId.

*/
public function setAddress($address);

public function getQty();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agree with @ishakhsuvarov here.
Duplication of QTYs is misleading.
As QuoteItem (which represents single product SKU) has Qty
and Package which could consist of several SKUs has Qty (btw, why single, but not an array of quantities?)

So, it's hard to maintain and keep in consistent state.


public function getWeight();

public function getItemQty();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's the difference between Qty and ItemQuantity?

public function getItems();

/**
* @return \Magento\Quote\Model\Quote\Address
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it should be Magento\Quote\Api\Data\AddressInterface
not the implementation


public function getItemQty();

public function getPhysicalValue();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is business data represented with this Interface method?

PhysicalValue of the package?

*/
public function setAddress($address);

public function getQty();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's why I proposed to consider usage of Visitor pattern here,
to separate Data from Algorithm implementation.
That could help us to live with current data structure of Quote

* @param \Magento\Quote\Model\Quote\Address $destinationAddress
* @return Package[]
*/
public function getPackages($store, $items, $destinationAddress);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we accept $store parameter here?
Just to read the configuration data? Why can't we resolve it?

in any case if we want introduce scoping , which we usually not do - it should be called $scope , but not $store.

* @param \Magento\Quote\Model\Quote\Address $destinationAddress
* @return Package[]
*/
public function getPackages($store, $items, $destinationAddress);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this method supposed to be called several times in case of multi-shipping delivery?

/**
* @return \Magento\Inventory\Model\PackageInterface[]
*/
public function getPackages();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again ShippingAssignment interface has get/setQuoteItems
you also intorduce get/setPackages which also have get/setQuoteItems

/**
* @return \Magento\Inventory\Model\PackageInterface[]
*/
public function getPackages();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moreover there is a get/setShipping method here which returns
\Magento\Quote\Api\Data\ShippingInterface
so, you have also duplication of the shipping address here and in Package.

@naydav naydav closed this Oct 12, 2017
phoenix128 added a commit that referenced this pull request Apr 22, 2018
… to use plugins

Void methods were breaking Interceptor classes because of the presence of a return statement.
Return statements with any kind of value (even null) is forbiddent by PHP7.2 .
Interceptor generation clas has been modified to check the void return type and unit tests have been adjusted accordingly.
@maghamed maghamed deleted the mni/source-selection branch December 11, 2018 18:12
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

Successfully merging this pull request may close these issues.

4 participants