1 package SL::PriceSource;
 
   4 use parent 'SL::DB::Object';
 
   5 use Rose::Object::MakeMethods::Generic (
 
   6   scalar => [ qw(record_item record) ],
 
   7   'array --get_set_init' => [ qw(all_price_sources) ],
 
  10 use List::UtilsBy qw(min_by max_by);
 
  11 use SL::PriceSource::ALL;
 
  12 use SL::PriceSource::Price;
 
  13 use SL::Locale::String;
 
  15 sub init_all_price_sources {
 
  19     $_->new(record_item => $self->record_item, record => $self->record)
 
  20   } SL::PriceSource::ALL->all_enabled_price_sources ]
 
  23 sub price_from_source {
 
  24   my ($self, $source) = @_;
 
  25   my ($source_name, $spec) = split m{/}, $source, 2;
 
  27   my $class = SL::PriceSource::ALL->price_source_class_by_name($source_name);
 
  30     ? $class->new(record_item => $self->record_item, record => $self->record)->price_from_source($source, $spec)
 
  34 sub discount_from_source {
 
  35   my ($self, $source) = @_;
 
  36   my ($source_name, $spec) = split m{/}, $source, 2;
 
  38   my $class = SL::PriceSource::ALL->price_source_class_by_name($source_name);
 
  41     ? $class->new(record_item => $self->record_item, record => $self->record)->discount_from_source($source, $spec)
 
  45 sub available_prices {
 
  46   map { $_->available_prices } $_[0]->all_price_sources;
 
  49 sub available_discounts {
 
  50   return if $_[0]->record_item->part->not_discountable;
 
  51   map { $_->available_discounts } $_[0]->all_price_sources;
 
  55   min_by { $_->price } max_by { $_->priority } grep { $_->price > 0 } grep { $_ } map { $_->best_price } $_[0]->all_price_sources;
 
  59   max_by { $_->discount } max_by { $_->priority } grep { $_->discount } grep { $_ } map { $_->best_discount } $_[0]->all_price_sources;
 
  63   SL::PriceSource::Price->new(
 
  64     description => t8('None (PriceSource)'),
 
  69   SL::PriceSource::Discount->new(
 
  70     description => t8('None (PriceSource Discount)'),
 
  82 SL::PriceSource - mixin for price_sources in record items
 
  86 PriceSource is an interface that allows generic algorithms to be plugged
 
  87 together to calculate available prices for a position in a record.
 
  89 Each algorithm can access details of the record to realize dependencies on
 
  90 part, customer, vendor, date, quantity etc, which was previously not possible.
 
  92 =head1 BACKGROUND AND PHILOSOPHY
 
  94 sql ledger and subsequently Lx-Office had three prices per part: sellprice,
 
  95 listprice and lastcost. At the moment a part is loaded into a record, the
 
  96 applicable price is copied and after that it is free to be changed.
 
  98 Later on additional things were added. Various types of discount, vendor pricelists
 
  99 and the infamous price groups. The problem is not that those didn't work, the
 
 100 problem is, that they had to guess too much when to change a price with the
 
 101 available price from the database, and when to leave the user entered price.
 
 103 Unrelated to that, users asked for more ways to store special prices, based on
 
 104 qty (block pricing, bulk discount), based on date (special offers), based on
 
 105 customers (special terms), up to full blown calculation modules.
 
 107 On a third front sales personnel asked for ways to see what price options a
 
 108 position in a quotation has, and wanted information available when a price
 
 111 Price sources put that together by making some compromises:
 
 117 Only change the price on creation of a position or when asked to.
 
 121 Either set the price from a price source and let it be read only, or use a free
 
 126 Save the origin of each price with the record so that the calculation can be
 
 131 Make price calculation flexible and pluggable.
 
 135 The first point creates user security by never changing a price for them
 
 136 without their explicit consent, eliminating all problems originating from
 
 137 trying to be smart. The second and third one ensure that later on the
 
 138 calculation can be repeated so that invalid prices can be caught (because for
 
 139 example the special offer is no longer valid), and so that sales personnel have
 
 140 information about rising or falling prices. The fourth point ensures that
 
 141 insular calculation processes can be developed independent of the core code.
 
 143 =head1 INTERFACE METHODS
 
 149 C<PARAMS> must contain both C<record> and C<record_item>. C<record_item> does
 
 150 not have to be registered in C<record>.
 
 152 =item C<price_from_source>
 
 154 Attempts to retrieve a formerly calculated price with the same conditions
 
 156 =item C<discount_from_source>
 
 158 Attempts to retrieve a formerly calculated discount with the same conditions
 
 160 =item C<available_prices>
 
 162 Returns all available prices.
 
 164 =item C<available_discounts>
 
 166 Returns all available discounts.
 
 170 Attempts to get the best available price. returns L<empty_price> if no price is found.
 
 172 =item C<best_discount>
 
 174 Attempts to get the best available discount. returns L<empty_discount> if no discount is found.
 
 178 A special empty price, that does not change the previously entered price, and
 
 179 opens the price field to manual changes.
 
 181 =item C<empty_discount>
 
 183 A special empty discount, that does not change the previously entered discount, and
 
 184 opens the discount field to manual changes.
 
 190 L<SL::PriceSource::Base>,
 
 191 L<SL::PriceSource::Price>,
 
 192 L<SL::PriceSource::Discount>,
 
 193 L<SL::PriceSource::ALL>
 
 195 =head1 BUGS AND CAVEATS
 
 201 The current simple model of price sources providing a simple value in simple
 
 202 cases doesn't work well in situations where prices are modified by other
 
 203 properties. The same problem also causes headaches when trying to use price
 
 204 sources to compute positions in assemblies.
 
 206 The solution should be to split price sources in simple ones, which do not
 
 207 manage their interactions with record_items, but can be used in contexts
 
 208 without record_items, and complex ones which do, but have to be fed a dummy
 
 209 record_item. For the former there should be a wrapper that handles interactions
 
 210 with units, price_factors etc..
 
 214 Currently it is only possible to provide additional prices, but not to restrict
 
 215 prices. Potential scenarios include credit limit customers which do not receive
 
 216 benefits from sales, or general ALLOW, DENY order calculation.
 
 222 Sven Schoeling E<lt>s.schoeling@linet-services.deE<gt>