Dokumentation aktualisiert (html und pdf)
[kivitendo-erp.git] / SL / PriceSource.pm
index 470182c..c8cdc6c 100644 (file)
@@ -4,19 +4,20 @@ use strict;
 use parent 'SL::DB::Object';
 use Rose::Object::MakeMethods::Generic (
   scalar => [ qw(record_item record) ],
+  'array --get_set_init' => [ qw(all_price_sources) ],
 );
 
-use List::UtilsBy qw(min_by);
+use List::UtilsBy qw(min_by max_by);
 use SL::PriceSource::ALL;
 use SL::PriceSource::Price;
 use SL::Locale::String;
 
-sub all_price_sources {
+sub init_all_price_sources {
   my ($self) = @_;
 
-  return map {
+  [ map {
     $_->new(record_item => $self->record_item, record => $self->record)
-  } SL::PriceSource::ALL->all_price_sources
+  } SL::PriceSource::ALL->all_enabled_price_sources ]
 }
 
 sub price_from_source {
@@ -26,7 +27,7 @@ sub price_from_source {
   my $class = SL::PriceSource::ALL->price_source_class_by_name($source_name);
 
   return $class
-    ? $class->new(record_item => $self->record_item)->price_from_source($source, $spec)
+    ? $class->new(record_item => $self->record_item, record => $self->record)->price_from_source($source, $spec)
     : empty_price();
 }
 
@@ -34,8 +35,17 @@ sub available_prices {
   map { $_->available_prices } $_[0]->all_price_sources;
 }
 
+sub available_discounts {
+  return if $_[0]->record_item->part->not_discountable;
+  map { $_->available_discounts } $_[0]->all_price_sources;
+}
+
 sub best_price {
-  min_by { $_->price } map { $_->best_price } $_[0]->all_price_sources;
+  min_by { $_->price } max_by { $_->priority } grep { $_->price > 0 } grep { $_ } map { $_->best_price } $_[0]->all_price_sources;
+}
+
+sub best_discount {
+  max_by { $_->discount } max_by { $_->priority } grep { $_->discount } grep { $_ } map { $_->best_discount } $_[0]->all_price_sources;
 }
 
 sub empty_price {
@@ -59,19 +69,19 @@ SL::PriceSource - mixin for price_sources in record items
 PriceSource is an interface that allows generic algorithms to be plugged
 together to calculate available prices for a position in a record.
 
-Each algorithm can access details of the record to realize dependancies on
+Each algorithm can access details of the record to realize dependencies on
 part, customer, vendor, date, quantity etc, which was previously not possible.
 
-=head1 BACKGROUND AND PHILOSOPY
+=head1 BACKGROUND AND PHILOSOPHY
 
 sql ledger and subsequently Lx-Office had three prices per part: sellprice,
 listprice and lastcost. At the moment a part is loaded into a record, the
-applicable price is copied and after that free to be changed.
+applicable price is copied and after that it is free to be changed.
 
-Later on additional things joined. Various types of discount, vendor pricelists
+Later on additional things were added. Various types of discount, vendor pricelists
 and the infamous price groups. The problem is not that those didn't work, the
-problem is, that they had to guess to much when to change a price with the
-available price from database, and when to leave the user entered price.
+problem is, that they had to guess too much when to change a price with the
+available price from the database, and when to leave the user entered price.
 
 Unrelated to that, users asked for more ways to store special prices, based on
 qty (block pricing, bulk discount), based on date (special offers), based on
@@ -111,7 +121,7 @@ trying to be smart. The second and third one ensure that later on the
 calculation can be repeated so that invalid prices can be caught (because for
 example the special offer is no longer valid), and so that sales personnel have
 information about rising or falling prices. The fourth point ensures that
-insular calculation processes can be developed independant of the core code.
+insular calculation processes can be developed independent of the core code.
 
 =head1 INTERFACE METHODS