X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;f=SL%2FPriceSource.pm;h=ea1c1ac9026e5971360157bdf889c8b643345e62;hb=826d79929635c726f7459296fafa7e630c00e72d;hp=8df73ce45e5ccc4fd076e38c77408b675fbfbd73;hpb=7801c6c2e0841eb9fbc404f9970e19918ac80c44;p=kivitendo-erp.git

diff --git a/SL/PriceSource.pm b/SL/PriceSource.pm
index 8df73ce45..ea1c1ac90 100644
--- a/SL/PriceSource.pm
+++ b/SL/PriceSource.pm
@@ -137,7 +137,7 @@ Which one is the "best"?
 
 =head1 GUARANTEES
 
-To ensure price source prices are comprehensible and reproucible, some
+To ensure price source prices are comprehensible and reproducible, some
 invariants are guaranteed:
 
 =over 4
@@ -149,8 +149,12 @@ and it is up to the user to change a price.
 
 =item 2.
 
-If a price is set from a source, it is read only. A price edited manually is by
-definition not a sourced price.
+If a price is set from a source then the system will try to prevent the user
+from messing it up. By default this means the price will be read-only.
+Implementations can choose to make prices editable, but even then deviations
+from the calculatied price will be marked.
+
+A price that is not set from a source will not have any of this.
 
 =item 3.
 
@@ -172,12 +176,12 @@ information about rising or falling prices.
 =head1 STRUCTURE
 
 Price sources are managed by this package (L<SL::PriceSource>), and all
-external access should be by using it's interface.
+external access should be by using its interface.
 
 Each source is an instance of L<SL::PriceSource::Base> and the available
 implementations are recorded in L<SL::PriceSource::ALL>. Prices and discounts
 returned by interface methods are instances of L<SL::PriceSource::Price> and
-L<SL::PriceSource::Discout>.
+L<SL::PriceSource::Discount>.
 
 Returned prices and discounts should be checked for entries in C<invalid> and
 C<missing>, see documentation in their classes.
@@ -209,21 +213,23 @@ Returns all available discounts.
 
 =item C<best_price>
 
-Attempts to get the best available price. returns L<empty_price> if no price is found.
+Attempts to get the best available price. returns L<empty_price> if no price is
+found.
 
 =item C<best_discount>
 
-Attempts to get the best available discount. returns L<empty_discount> if no discount is found.
+Attempts to get the best available discount. returns L<empty_discount> if no
+discount is found.
 
 =item C<empty_price>
 
-A special empty price, that does not change the previously entered price, and
+A special empty price that does not change the previously entered price and
 opens the price field to manual changes.
 
 =item C<empty_discount>
 
-A special empty discount, that does not change the previously entered discount, and
-opens the discount field to manual changes.
+A special empty discount that does not change the previously entered discount
+and opens the discount field to manual changes.
 
 =back
 
@@ -247,7 +253,7 @@ when no record is available, such as calculation the worth of assembly rows.
 A possible solution is to either split price sources into simple and complex
 ones (where the former do not require records).
 
-Another would be to have default values for the inpout normally taken from
+Another would be to have default values for the input normally taken from
 records (like qty defaulting to 1).
 
 A last one would be to provide an alternative input channel for needed
@@ -256,7 +262,7 @@ properties.
 =item *
 
 Discount sources were implemented as a copy of the prices with slightly
-different semantics. Need to do a real design. A requirement is, that a sinle
+different semantics. Need to do a real design. A requirement is, that a single
 source can provide both prices and discounts (needed for price_rules).
 
 =item *
@@ -280,8 +286,43 @@ benefits from sales, or general ALLOW, DENY order calculation.
 
 =item *
 
-Composing price sources are disallowed for clarity, but all price sources need
-to be aware of units. This is madness.
+Composing price sources is disallowed for clarity, but all price sources need
+to be aware of units and price_factors. This is madness.
+
+=item *
+
+The current implementation of lastcost is useless. Since it's one of the
+master_data prices it will always compete with listprice. But in real scenarios
+the listprice tends to go up, while lastcost stays the same, so lastcost
+usually wins. Lastcost could be lower priority, but a better design would be
+nice.
+
+=item *
+
+Guarantee 1 states that price sources will never change prices on their own.
+Further testing in the wild has shown that this is desirable within a record,
+but not when copying items from one record to another within a workflow.
+
+Specifically when changing from sales to purchase records prices don't make
+sense anymore. The guarantees should be updated to reflect this and
+transposition guidelines should be documented.
+
+The previously mentioned linked prices can emulated by allowing price sources
+to set a new price when changing to a new record in the workflow. The decision
+about whether a price is eligable to be set can be suggested by the price
+source implementation but is ultimately up to the surrounding framework, which
+can make this configurable.
+
+=item *
+
+Prices were originally planned as a context element rather than a modal popup.
+It would be great to have this now with better framework.
+
+=item *
+
+Large records (30 positions or more) in combination with complicated price
+sources run into n+1 problems. There should be an extra hook that allows price
+source implementations to make bulk calculations before the actual position loop.
 
 =back