Introduce Stock quantity calculation #94

aleron75 · 2017-09-15T22:30:02Z

This is not a complete PR but I'd like to start having a feedback on what implemented so far, that is GetProductQuantityInStock service.

In particular, I'd like to ask:

whether namespace under which I put the service is correct;
whether naming is correct;
whether it is correct to use DDL in GetProductQuantityInStock class;

- Add DocBlock to Reservtion constructor - Fix ReservationBuilder not passing Reservation ID

- Add GetProductQuantityInStock service interface and implementation

maghamed · 2017-09-17T08:13:22Z

app/code/Magento/Inventory/Model/Stock/Command/GetProductQuantityInStock.php

+    {
+        $productQtyInStock = $this->getStockItemQty($sku, $stockId) - $this->getReservationQty($sku, $stockId);
+        return (float) $productQtyInStock;
+    }


@aleron75 you raised a correct question.
Whether MySQL logic should be placed in the Domain Service implementation.

we usually don't do that introducing intermediate level of abstraction.
For example, Repository does not make direct requests to MySQL table, what it does - it uses ResourceModels to get needed data.

Ideally, Implementations of Service Contracts should be agnostic to the Data Access Layer.

What I recommend to do in this particular case - I propose to introduce two Models and inject them into this Service.

The first model would be responsible for retrieving StockItem Quantity (implementation of your getStockItemQty method).

The second one would be responsible for getting Reservation Quantity (getReservationQty in current code)

So, you would end up in current service with next code:

$productQtyInStock = $this->stockItemQty->execute($sku, $stockId) - $this->reservationQty->execute($sku, $stockId); return (float) $productQtyInStock;

sounds good, just to be sure, by "I propose to introduce two Models" you mean Resource Models, is it right?

@aleron75 Correct, Resource models

maghamed · 2017-09-17T08:14:45Z

app/code/Magento/InventoryApi/Api/GetProductQuantityInStockInterface.php

+ * Copyright © Magento, Inc. All rights reserved.
+ * See COPYING.txt for license details.
+ */
+namespace Magento\InventoryApi\Api;


whether namespace under which I put the service is correct;

Yes, the namespace is correct.
As we are going to expose this service as a Public API being used in client code - it should be placed in the Magento\InventoryApi\Api

maghamed · 2017-09-17T08:17:40Z

app/code/Magento/Inventory/Model/Stock/Command/GetProductQuantityInStock.php

+ * Copyright © Magento, Inc. All rights reserved.
+ * See COPYING.txt for license details.
+ */
+namespace Magento\Inventory\Model\Stock\Command;


I prefer to put this implementation upper level,
as it's going to be one of the most-used services provided by Inventory
(as all the front-end code needs Get Product Qty to render some data on front-end, make checkout etc.)

So, I propose to put it under this namespace:
Magento\Inventory\Model

maghamed · 2017-09-17T08:23:46Z

app/code/Magento/InventoryApi/Api/GetProductQuantityInStockInterface.php

+ *
+ * @api
+ */
+interface GetProductQuantityInStockInterface


whether naming is correct;

It's a good question
When I proposed a name for this service - GetProductQuantityInStockInterface
I meant that this service will "retrieve product quantity which is available (in stock)"
We use this naming currently (In stock/ Out of stock).

But, having "Stock" entity introduced by MSI.
The service name could be "read" differently. Like - get product quantity for specified Stock (Stock entity).

Currently, this service accepts $stockId as one of the parameters
public function execute(string $sku, int $stockId): float;
Thus, following this signature - service returns Qty for provided $stockId

Based on the above IMO current naming - GetProductQuantityInStockInterface is appropriate.
But if you have objections - let's discuss and re-name one

I agree, here we have a term "stock" that violates the "ubiquitous language" DDD principle because in the same context it can mean both the "available quantity" (more high-level) and the "virtual aggregation" (more low-level);

probably we should think about it;

what's more, as I introduced during our last weekly meeting, in the future, when we will have the sales channel connected to our stock (virtual aggregation), maybe this service could be better named GetProductQuantityInSalesChannelInterface but at the moment it is good enough to leave it as is

@aleron75 you made a very true statement regarding violation of "ubiquitous language".
There is definitely an issue with this naming.

Regarding GetProductQuantityInSalesChannelInterface I thought about this.
But came up to the conclusion that naming like InSalesChannelInterface sounds like a "leaky abstraction".
As I am not sure that on the level of this interface we should expose a knowledge that we have a relationship SalesChannel to Stock and that it's enough just to provide $stockId to get Product Qty for your Sales Channel.
Moreover potentially we could have the single Stock being re-usable by different Sales channels.
For example, there are 3 websites:
website A, website B, website C
and we have the only stock - Stock A
Thus, all of those websites will use the same stock

So, semantically it's incorrect to say - give me product quantity for current Sales Channel providing $stockId as the parameter.

Does it make sense?

semantically it's incorrect to say - give me product quantity for current Sales Channel providing $stockId as the parameter

you're perfectly right, it should be instead:

"give me product quantity for current Sales Channel providing some channel id as the parameter"

where the $channelId should be derived from the website in the current context;

by the way at the moment let's leave the service as is and just postpone this discussion when we'll work on the channel entity; thank you

@aleron75 100% agree, let's see how our interfaces will evolve and later align naming accordingly.

My opinion is to follow YAGNI principle.
Now we do not have the clear vision about sales channel abstraction. How to do this extensible and clear...
And we have chance to create service which will not be related to our future implementation

So we should not create service related to Sales Channels. We will do it when we will work on this task.
I believe that we could create some prototype (how to work with Sales Channels) in separate branch or provide some interfaces on our wiki page
But we need to keep our develop branch in clear state

- Move GetProductQuantityInStock service to upper namespace - Implement GetProductQuantityInStock and ReservationQuantity resource models - Refactor GetProductQuantityInStock service to use GetProductQuantityInStock and ReservationQuantity resource models

aleron75 · 2017-09-19T09:12:20Z

I have a question regarding the IsProductInStock service I have to implement to complete this PR.

Since at this abstraction level we don't deal with "status" (indeed, disabled sources and disabled quantities have already been taken into account by indexation), is it a simple check that product qty in stock is greater than zero?

If so, is it correct to inject the GetProductQuantityInStock service as a dependency for IsProductInStock or should I use the resource models as I did for the former service?

The first solution seems correct to me since I wouldn't repeat the same code but I want to be sure that using a service in a service is an accepted practice in M2.

Thank you

maghamed · 2017-09-19T11:30:31Z

app/code/Magento/Inventory/Model/GetProductQuantityInStock.php

+    public function execute(string $sku, int $stockId): float
+    {
+        $productQtyInStock = $this->stockItemQty->execute($sku, $stockId) -
+            $this->reservationQty->execute($sku, $stockId);


if we are putting both positive and negative values to the Reservation.
Looks like we need to Add $this->reservationQty->execute($sku, $stockId);
But not Substract

For example,
Stock is 100 products.
We have Reservation for -10 products

100 - (-10) will lead to increase of stock but not deducation

That's because I intended a "reserved quantity" (positive number) as something I don't have to consider as available because it's "reserved", thus not available and thus something that has to be subtracted from total quantity.

Your interpretation is opposite and it's ok to use it but that also means that there is space for interpretation that is error prone.

I will fix as you suggest but probably we should find a naming that's less subject to interpretation.

I've just re-read your spec here and you were perfectly clear on the meaning of adding (+) and subtracting (-) but for some reason, I inverted it in my mind

maghamed · 2017-09-19T11:33:26Z

app/code/Magento/Inventory/Model/ResourceModel/Reservation/ReservationQuantity.php

+ * Copyright © Magento, Inc. All rights reserved.
+ * See COPYING.txt for license details.
+ */
+namespace Magento\Inventory\Model\ResourceModel\Reservation;


let's add declare(strict_types=1); for all newly created files in the scope of MSI project

on which line do you prefer to add this directive?

just after <?php, before copyrignt disclaimer comment

just after copyrignt disclaimer comment

just afternamespace directive

just afternamespace and use directives

just find this tool: https://github.com/dypa/declare-strict-types
didn't use it yet but maybe can be useful

My choose is
just after copyrignt disclaimer comment
It should be before any code ... but copyright looks like some additional meta data for class (also it can be generated via tools automatically)

maghamed · 2017-09-19T11:35:50Z

app/code/Magento/Inventory/Model/ResourceModel/Stock/StockItemQuantity.php

+            ->setIndexId(StockItemIndexerInterface::INDEXER_ID)
+            ->addDimension('stock_', $stockId)
+            ->setAlias(Alias::ALIAS_MAIN)
+            ->create();


BTW , why do we have a builder with method create, but not build
@naydav that's probably question to you

Yes, we can rename method to build

Also, if I do not mistake we decided to introduce some sugar service which must encapsulate logic of table name resolving

maghamed · 2017-09-19T11:42:48Z

app/code/Magento/InventoryApi/Api/GetProductQuantityInStockInterface.php

+ *
+ * @api
+ */
+interface GetProductQuantityInStockInterface


@aleron75 100% agree, let's see how our interfaces will evolve and later align naming accordingly.

maghamed · 2017-09-19T11:48:35Z

app/code/Magento/Inventory/Model/GetProductQuantityInStock.php

+ * @see \Magento\InventoryApi\Api\GetProductQuantityInStockInterface
+ * @api
+ */
+class GetProductQuantityInStock implements GetProductQuantityInStockInterface


This service looks like a perfect candidate to be covered with both:

Integration
and

Web API
testing

Looks like to have two separate interfaces for API and SPI is redundant
Implementation of API is only proxy to SPI

We have the same situation with SourceItemsSave operation
And we decided to have only one interface (which presents API and SPI in one interface)

Interface
https://github.com/magento-engcom/msi/blob/develop/app/code/Magento/InventoryApi/Api/SourceItemsSaveInterface.php

Implementation
https://github.com/magento-engcom/msi/blob/develop/app/code/Magento/Inventory/Model/SourceItem/Command/SourceItemsSave.php

For Repository we need to extract SPI parts in separate set of interfaces due Repository represents Facade pattern (accumulate some functionality together)
But for single command, it looks like overhead (after creating we need to maintain this code)

Thus now looks like we have some mess in our interfaces:
GetProductQuantityInStockInterface
GetProductQuantityInterface

As proposed by @naydav and discussed with @maghamed we will simplify the implementation getting rid of the command layer;
thus we will delegate effective computation to resource model, injected into the services in place of the command.

maghamed · 2017-09-19T11:50:08Z

app/code/Magento/InventoryApi/Api/GetProductQuantityInStockInterface.php

+/**
+ * Service which returns Quantity of products available to be sold by Product SKU and Stock Id
+ *
+ * @api


Btw, we need to add this service to Web API webapi.xml

in
https://github.com/magento-engcom/msi/blob/develop/app/code/Magento/InventoryApi/etc/webapi.xml
to make it reachable from outside of Magento using "headless" approach

Sure, wondering if I can use the Magento_InventoryApi::stock ACL for that API method or should create a new one for reading stock data

We have open task for refactoring of our ACL rules
Generally, I believe that we need to simplify our resource counts.
Single resource Magento_InventoryApi::stock is enough for all operation with stock

But in this case need to discuss maybe need to relate on some product resource

maghamed · 2017-09-19T12:11:40Z

@aleron75 Regarding your question:

Since at this abstraction level we don't deal with "status" (indeed, disabled sources and disabled quantities have already been taken into account by indexation), is it a simple check that product qty in stock is greater than zero?

Very valid question!
From what I see. If we will use just a simple check like Qty > 0 it could make some limitations for those who have more sophisticated rules for inStock check.
For example, we have 2 products left in the warehouse.
But according to the store settings, we could sell product starting from 3 items with an increment of 3 (like, 3,6,9,12 and so on).
Or if someone will decide to implement Safety Stock functionality introducing a threshold below which store is not allowed not sell products, to prevent the product sold out.

Based on the above I propose to introduce SPI interface responsible for this calculation. And out of the box it would be simple and straightforward (simple check that product qty in stock is greater than zero).

Pretty similar what we have with Repositories when we have an API and SPI with command.

And as you proposed further. you can re-use this command in the service GetProductQuantityInStock

As you correctly mentioned:

The first solution seems correct to me since I wouldn't repeat the same code but I want to be sure that using a service in a service is an accepted practice in M2.

Usage of one service inside the implementation of another one - is not recommended (this is no strict rule, but it's considered as a good practice).
Because if you have Service A and Service B.
And Service B called inside the implementation of Service A.
You can't be sure that if somebody will provide another implementation of Service A -> Service A2 and substitute default DI preference.
Service B would be still called.

aleron75 · 2017-09-22T07:24:15Z

Hi, regarding the suggestion below:

I propose to introduce SPI interface responsible for this calculation. And out of the box it would be simple and straightforward (simple check that product qty in stock is greater than zero).

If I understand correctly, here is a prototype of what I should implement:

IsProductInStockInterface (in InventoryApi module)
IsProductInStock (in Inventory module) class implementing IsProductInStockInterface
IsInStockInterface (in Inventory module) which represents a command interface
IsInStock command (in Inventory module) implementing IsInStockInterface
inject IsInStockInterface dependency in IsProductInStock and use that dependency in IsProductInStock::execute() method to delegate concrete implementation to the SPI command

is the above correct or am I missing something?

thank you

- Add webapi declaration for GetAssignedSourcesForStockInterface service - Fix quantity calculation by adding (not subtracting) reservation qty

- Introduce the GetProductQuantity command - Change GetProductQuantityInStock and IsProductInStock service implementation to use GetProductQuantity command - Add webapi declaration for IsProductInStockInterface service

- Add Cleanup resource model

- Fix coding style issues

naydav · 2017-09-25T10:45:03Z

app/code/Magento/Inventory/Model/GetProductQuantityInStock.php

+ * @see \Magento\InventoryApi\Api\GetProductQuantityInStockInterface
+ * @api
+ */
+class GetProductQuantityInStock implements GetProductQuantityInStockInterface


Looks like to have two separate interfaces for API and SPI is redundant
Implementation of API is only proxy to SPI

We have the same situation with SourceItemsSave operation
And we decided to have only one interface (which presents API and SPI in one interface)

Interface
https://github.com/magento-engcom/msi/blob/develop/app/code/Magento/InventoryApi/Api/SourceItemsSaveInterface.php

Implementation
https://github.com/magento-engcom/msi/blob/develop/app/code/Magento/Inventory/Model/SourceItem/Command/SourceItemsSave.php

For Repository we need to extract SPI parts in separate set of interfaces due Repository represents Facade pattern (accumulate some functionality together)
But for single command, it looks like overhead (after creating we need to maintain this code)

Thus now looks like we have some mess in our interfaces:
GetProductQuantityInStockInterface
GetProductQuantityInterface

naydav · 2017-09-25T10:49:13Z

app/code/Magento/Inventory/Model/IsProductInStock.php

+    private $commandGetProductQuantity;
+
+    /**
+     * IsProductInStock constructor.


Extra comments

Now we have open PRs with removing this comments
https://github.com/magento-engcom/msi/pull/103/files

Generally, we need to expand static tests. We need to add one more rule to our current rules set.
But now to do this task in scope of MSI looks like overhead

naydav · 2017-09-25T10:52:08Z

app/code/Magento/Inventory/Model/Reservation/ReservationBuilder.php

@@ -109,6 +109,7 @@ public function setMetadata(string $metadata = null): ReservationBuilderInterfac
    public function build(): ReservationInterface
    {
        $data = [
+            ReservationInterface::RESERVATION_ID => null,


Why do you add this string? By default reservation id is null
But maybe I do not take into account some cause

The reason is that If we don't pass the reservation ID, the constructor (used by the object manager) will throw an exception because it's a constructor mandatory parameter

naydav · 2017-09-25T10:54:24Z

app/code/Magento/Inventory/Model/ResourceModel/Reservation/Cleanup.php

+            ->having('sum(' . ReservationInterface::QUANTITY . ') = 0');
+        $groupedReservationIds = $connection->fetchCol($select, 'grouped_reservation_ids');
+
+        foreach ($groupedReservationIds as $reservationIds) {


Maybe it is better to collect ids and perform single query instead to perform query in cycle

naydav · 2017-09-25T10:56:26Z

app/code/Magento/Inventory/Model/ResourceModel/Reservation/ReservationQuantity.php

+ * Copyright © Magento, Inc. All rights reserved.
+ * See COPYING.txt for license details.
+ */
+namespace Magento\Inventory\Model\ResourceModel\Reservation;


My choose is
just after copyrignt disclaimer comment
It should be before any code ... but copyright looks like some additional meta data for class (also it can be generated via tools automatically)

naydav · 2017-09-25T11:00:09Z

app/code/Magento/Inventory/Model/ResourceModel/Stock/StockItemQuantity.php

+        $select = $connection->select()
+            ->from($stockItemTableName, [StockItemIndex::QUANTITY])
+            ->where(StockItemIndex::SKU . '=?', $sku)
+            ->limit(1);


Limit is redundant because SKU is unique key
So we have only one record per product in this table

naydav · 2017-09-25T11:02:28Z

app/code/Magento/Inventory/Model/Stock/Command/GetProductQuantity.php

+    {
+        $productQtyInStock = $this->stockItemQty->execute($sku, $stockId) +
+            $this->reservationQty->execute($sku, $stockId);
+        return (float) $productQtyInStock;


(float)
Looks like is redundant typecasting
Now we have clear declaration of return type in StockItemQuantity and ReservationQuantity
So there is no possibility to get some type different from float

naydav · 2017-09-25T11:05:45Z

app/code/Magento/InventoryApi/Api/GetProductQuantityInStockInterface.php

+/**
+ * Service which returns Quantity of products available to be sold by Product SKU and Stock Id
+ *
+ * @api


We have open task for refactoring of our ACL rules
Generally, I believe that we need to simplify our resource counts.
Single resource Magento_InventoryApi::stock is enough for all operation with stock

But in this case need to discuss maybe need to relate on some product resource

naydav · 2017-09-25T11:14:08Z

app/code/Magento/InventoryApi/Api/GetProductQuantityInStockInterface.php

+ *
+ * @api
+ */
+interface GetProductQuantityInStockInterface


My opinion is to follow YAGNI principle.
Now we do not have the clear vision about sales channel abstraction. How to do this extensible and clear...
And we have chance to create service which will not be related to our future implementation

So we should not create service related to Sales Channels. We will do it when we will work on this task.
I believe that we could create some prototype (how to work with Sales Channels) in separate branch or provide some interfaces on our wiki page
But we need to keep our develop branch in clear state

naydav · 2017-09-25T11:18:58Z

app/code/Magento/Inventory/Model/ResourceModel/Reservation/Cleanup.php

+ *
+ * @package Magento\Inventory\Model\ResourceModel\Reservation
+ */
+class Cleanup


Maybe we need to provide SPI interface for this action

For example, we have SPI for creation of reservations and I could replace implementation on my own (for example I would like to save reservation in some key-value storage)
But we don't provide the possibility to replace the implementation of reservation deleting.

It is a little strange for me

- Remove command layer for GetProductQuantityInStock and IsProductInStock and use resource model - Add declare(strict_types=1); directive after copyrignt disclaimer comment - Delete some extra comments - Provide ReservationCleanup SPI interface and concrete implementation - Remove useless limit(1) from query - Remove some redundant typecasting

- Delete some extra comments

- Fix wrong reservation table quantity field specification - Fix preferences in di.xml - Add integration test for GetProductQuantityInStock service - Add integration test for IsProductInStock service

- Remove useless dependency from Checker in GetProductQuantityInStockTest

maghamed · 2017-10-05T05:55:49Z

app/code/Magento/Inventory/Model/IsProductInStock.php

+    {
+        $productQtyInStock = $this->stockItemQty->execute($sku, $stockId) +
+            $this->reservationQty->execute($sku, $stockId);
+        return $productQtyInStock > 0;


I believe we could leave as-is current implementation for now.
But a little bit further we will have a story from our Backlog
https://github.com/magento-engcom/msi/wiki/MSI-Roadmap

Make Stock calculation and check availability services to support Backorders functionality (M)

where we would need to add a support of Backorders. Also Dropshipping functionality could also affect this service

maghamed · 2017-10-05T06:09:48Z

app/code/Magento/Inventory/Model/ReservationCleanup.php

+                ['grouped_reservation_ids' => 'group_concat(' . ReservationInterface::RESERVATION_ID . ')']
+            )
+            ->group([ReservationInterface::STOCK_ID, ReservationInterface::SKU])
+            ->having('sum(' . ReservationInterface::QUANTITY . ') = 0');


It's not the most effective way of cleaning up reservations because we will remove all reservations (for given stock_id and sku) just in case - all the reservations quantities summing up will result 0

For example, if we have

SKU STOCK_ID Reservation sku-1 1 -10 sku-1 1 5 sku-1 1 2 sku-1 1 3 sku-1 1 -1

we will leave it as-is, but potentially already in this case we could remove everything except
sku-1 1 -1

But I agree that currently we could leave it as-is

maghamed · 2017-10-05T06:10:55Z

app/code/Magento/Inventory/Model/ReservationCleanupInterface.php

+interface ReservationCleanupInterface
+{
+    /**
+     * Clean reservation table to prevent overloading.


I would not expose that reservation table is used on the level of this service, because potentially it could be Redis queue

Don't introduce a leaky abstraction , as we need to be agnostic to the DAL at this level of abstraction

maghamed · 2017-10-05T06:40:14Z

app/code/Magento/Inventory/Test/Integration/Stock/GetProductQuantityInStockTest.php

+        $reservations = [
+            $this->reservationBuilder->setStockId(1)->setSku('SKU-1')->setQuantity(3.5)->build(), // unreserve 3.5 units
+        ];
+        $this->reservationsAppend->execute($reservations);


why do we have this code

+ $reservations = [ + $this->reservationBuilder->setStockId(1)->setSku('SKU-1')->setQuantity(3.5)->build(), // unreserve 3.5 units + ]; + $this->reservationsAppend->execute($reservations);

without any asserts afterwords ?
is this kind of rollback action? which should prevent to affect further calculations?

maghamed · 2017-10-05T06:42:07Z

app/code/Magento/Inventory/Test/Integration/Stock/GetProductQuantityInStockTest.php

+                ->addDimension('stock_', $stockId)
+                ->setAlias(Alias::ALIAS_MAIN)
+                ->create();
+            $indexStructure->delete($indexName);


it's better to make such operation in Rollback Fixture than in tearDown
because you will copy-paste this tear down code among other test classes which use the same fixtures

maghamed · 2017-10-05T06:45:54Z

app/code/Magento/Inventory/Test/Integration/Stock/IsProductInStockTest.php

+                ->addDimension('stock_', $stockId)
+                ->setAlias(Alias::ALIAS_MAIN)
+                ->create();
+            $indexStructure->delete($indexName);


that's the copy-paste I was talking above

maghamed · 2017-10-05T06:47:21Z

app/code/Magento/Inventory/Test/Integration/Stock/IsProductInStockTest.php

+        $reservations = [
+            $this->reservationBuilder->setStockId(1)->setSku('SKU-1')->setQuantity(8.5)->build(), // unreserve 8.5 units
+        ];
+        $this->reservationsAppend->execute($reservations);


is this kind of rollback action? which should prevent to affect further calculations?

…ulation # Conflicts: # app/code/Magento/Inventory/Model/Reservation/Validator/QuantityValidator.php # app/code/Magento/Inventory/Model/Reservation/Validator/ReservationValidatorInterface.php # app/code/Magento/Inventory/Model/Reservation/Validator/SkuValidator.php # app/code/Magento/Inventory/Model/Reservation/Validator/StockIdValidator.php # app/code/Magento/Inventory/Model/Reservation/Validator/ValidatorChain.php # app/code/Magento/Inventory/etc/di.xml

-- refactoring

- Merge Pull Request magento-engcom/import-export-improvements#94 from VincentMarmiesse/magento2:42-imageskeys - Merged commits: 1. 8d3a237 2. 100e123 3. 36a053f 4. 2bbf5e0 5. c52ad59

Mc 20336

L3 pr 20210310

aleron75 added 2 commits September 14, 2017 15:11

Introduce Stock Qty Calculation

46c9efa

- Add DocBlock to Reservtion constructor - Fix ReservationBuilder not passing Reservation ID

Introduce Stock Quantity Calculation

f37b38e

- Add GetProductQuantityInStock service interface and implementation

maghamed suggested changes Sep 17, 2017

View reviewed changes

maghamed suggested changes Sep 19, 2017

View reviewed changes

aleron75 added 4 commits September 22, 2017 13:14

Introduce Stock quantity calculation

a82fe04

- Add webapi declaration for GetAssignedSourcesForStockInterface service - Fix quantity calculation by adding (not subtracting) reservation qty

Introduce Stock quantity calculation

c6a642d

- Introduce the GetProductQuantity command - Change GetProductQuantityInStock and IsProductInStock service implementation to use GetProductQuantity command - Add webapi declaration for IsProductInStockInterface service

Introduce Stock quantity calculation

2db99e4

- Add Cleanup resource model

Introduce Stock quantity calculation

8f2b014

- Fix coding style issues

naydav reviewed Sep 25, 2017

View reviewed changes

aleron75 added 2 commits September 27, 2017 20:14

Introduce Stock quantity calculation

eeb4545

- Delete some extra comments

maghamed added Award: complex Award: special achievement labels Oct 1, 2017

aleron75 added 2 commits October 4, 2017 17:59

Introduce Stock quantity calculation

7ae88aa

- Fix wrong reservation table quantity field specification - Fix preferences in di.xml - Add integration test for GetProductQuantityInStock service - Add integration test for IsProductInStock service

Introduce Stock quantity calculation

89209cc

- Remove useless dependency from Checker in GetProductQuantityInStockTest

maghamed approved these changes Oct 5, 2017

View reviewed changes

Valeriy Nayda and others added 4 commits October 5, 2017 15:49

MSI: Introduce Stock quantity calculation

555110a

-- refactoring

MSI: Introduce Stock quantity calculation

13a74ee

-- refactoring

MSI: Introduce Stock quantity calculation. Fix static tests coupling

328d920

maghamed merged commit a1c1f64 into develop Oct 6, 2017

aleron75 deleted the msi-stock-qty-calculation branch October 6, 2017 15:58

vrann pushed a commit that referenced this pull request Jan 31, 2018

MAGETWO-87123: #42 - Dynamically fill the image keys #94

faec06f

smoskaluk mentioned this pull request Mar 23, 2018

Exception in Low stock report for product with another name on additional storeview #737

Closed

sidolov pushed a commit that referenced this pull request Oct 18, 2019

Merge pull request #94 from magento-arcticfoxes/MC-20336

f5001f7

Mc 20336

magento-cicd2 pushed a commit that referenced this pull request Mar 17, 2021

Merge pull request #94 from magento-l3/L3-PR-20210310

423c7e5

L3 pr 20210310

Introduce Stock quantity calculation #94

Introduce Stock quantity calculation #94

Conversation

aleron75 commented Sep 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aleron75 Sep 19, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

aleron75 commented Sep 19, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aleron75 Sep 22, 2017 • edited Loading

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

maghamed commented Sep 19, 2017 • edited Loading

aleron75 commented Sep 22, 2017

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

naydav Sep 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aleron75 commented Sep 15, 2017 •

edited

Loading

aleron75 Sep 19, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

aleron75 Sep 22, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

maghamed commented Sep 19, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading

naydav Sep 25, 2017 •

edited

Loading