Helper class to hold event names on const variables.
If you are using a const in a controller, other plugins subscribers may not be able to use this controller property, if the subscriber is loaded before the controller was registered (via another subscriber). Hence we need this static class to access the properties safely.
Doctrine subscriber that uses the Doctrine onFlush event to update the order attribute's pickwareLastChanged property whenever the order is updated.
Since we have to update the timestamp whenever Order is updated, but need to make the actual change in Order's Attribute (which is not configured to cascade updates to Order), using preUpdate doesn't work. Also, we cannot use postPersist and postUpdate either, because we cannot safely call $em->flush() in those callbacks.
The only viable (and correct) approach to do this is to make the necessary changes in onFlush and then update the unit of work accordingly so the Attribute always gets flushed along with the Order.
Factory class to create StockLedgerEntries that will share the same value for specific properties.
Manager class used to create appropriate stock history entries for the various stock actions.
The following stock actions are supported:
1) PURCHASE New items of an article are purchased for a given purchase price and stored within the warehouse.
2) STOCKTAKE All available items of an article within the warehouse are counted and the article's instock quantity is updated accordingly.
3) SALE A given amount of items of an article has been sold and is removed from the warehouse.
4) RETURN A given amount of items of an article has been returned by the customer and is added to the warehouse.
5) MANUAL The instock quantity of an article is changed manually.
6) INCOMING An arbitrary incoming amount is added to the stock.
7) OUTGOING An arbitrary outgoing amount is removed from the stock.
These actions can be roughly divided into two groups: "incoming" and "outgoing", whereas "incoming" refers to all history entries, which are related to the storage of items within the warehouse and "outgoing" refers to all entries, which are concerned with the removal of items from the warehouse:
a) "incoming":
manual entry with positive change amount
b) "outgoing"
History entries for "neutral" stocktake actions (change amount is zero) play a minor role and therefore are not listed above, since they "have no effect" and are created only for informational purposes.
To enable the computation of the inventory value (Bewerteter Warenbestand) for a given reference date, we need to link "outgoing" and "incoming" entries in a suitable way. If possible, each "outgoing" entry is therefore related to an "incoming" entry, which is called it's source lot entry. "Incoming" entries are assigned to "outgoing" entries based on their "free capacity" and in accordance with the LIFO (Last In First Out) principle, meaning "incoming" entries are assigned in their reversed creation order. The assignment process is (roughly) as follows:
1) get a list of all "incoming" entries for the given article in their reversed creation order 2) compute the "free capacity" for each "incoming" entry in the list, whereas the "free capacity" is calculated as follows: change amount of "incoming" entry minus the sum of the change amounts of all already assigned "outgoing" entries 3) Remove all entries from the list, whose "free capacity" = 0 4) Check "free capacity" of the first list entry: a) "free capacity" >= change amount of "outgoing" entry? Create a new "outgoing" entry for the given change amount and assign it to the "incoming" entry b) "free capacity" < change amount of "outgoing" entry? Create a new "outgoing" entry with change amount = "free capacity" and assign the "incoming" entry to the newly created "outgoing" entry. Remove the "incoming" entry from the list and repeat step 4) until no unprocessed change amount remains or the list is empty 5) If some unprocessed change amount remains, create a new unassigned "outgoing" entry for the remaining change amount (purchase price = default purchase price)
"Outgoing" entries created in step 4) are called assigned, whereas those created in step 5) are called unassigned. If the assignment process results in a single "outgoing" entry, this entry is called a singlepart entry otherwise the set of newly created entries is called a multipart entry.
The instock quantity of each article, which is tracked within the stock history and the one maintained by Shopware (within the article details) may differ, since Shopware updates his counter as soon as a new order has been created, whereas the one maintained within the stock history is intended to track the physical item movements and is therefore (usually) not updated before the order is completely fulfilled and all items have been shipped. To keep these counters in sync the manager class takes care of updating the Shopware counter, when creating new history entries.
Remark: The purchase price of the default customer group of the active shop is used as default purchase price.
Base class for all pricing types (classes). Pricing are used to assign purchase prices to a given number of items. A pricing consists of one or more price items. A price item comprises a purchase price together with its applicability (number of items the purchase price can be applied to) and, if it exists, a reference to the related incoming history entry. The price items form a partition in the following sense: the sum of the applicabilities of all price items equal the given number of items, which should be priced using the pricing.
Simple class to model a list item of a pricelist as well as a pricing item.
The default pricing assigns the default purchase price of the associated article to all items, which should be priced.
The purchase pricing assigns a given purchase price to all items, which should be priced.
The purchase pricing assigns "no" price to all items, which should be priced. This pricing is used when no actual stock change took place (e.g. change of bin location) and therefore no purchase price is relevant.
This class receives the requests from the custom analytics backend controllers.
It fetches based on the request several sales information and returns it to the view.
Backend controller used for auto loading the article module extension that adds a new tab for supplier assignment to the article details window.
Backend controller used for auto loading the article module extension that adds a new tab for listing all supplier orders in the article details window.
This controller provides a backend action for all articles for uninitialized stock.
Backend controller used for auto loading common Ext JS modules for supplier and supplier order management.