SL/PriceSource.pm

   1 package SL::PriceSource;
   2
   3 use strict;
   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) ],
   8 );
   9
  10 use List::UtilsBy qw(min_by max_by);
  11 use SL::PriceSource::ALL;
  12 use SL::PriceSource::Price;
  13 use SL::Locale::String;
  14
  15 sub init_all_price_sources {
  16   my ($self) = @_;
  17
  18   [ map {
  19     $_->new(record_item => $self->record_item, record => $self->record)
  20   } SL::PriceSource::ALL->all_enabled_price_sources ]
  21 }
  22
  23 sub price_from_source {
  24   my ($self, $source) = @_;
  25   my ($source_name, $spec) = split m{/}, $source, 2;
  26
  27   my $class = SL::PriceSource::ALL->price_source_class_by_name($source_name);
  28
  29   return $class
  30     ? $class->new(record_item => $self->record_item, record => $self->record)->price_from_source($source, $spec)
  31     : empty_price();
  32 }
  33
  34 sub discount_from_source {
  35   my ($self, $source) = @_;
  36   my ($source_name, $spec) = split m{/}, $source, 2;
  37
  38   my $class = SL::PriceSource::ALL->price_source_class_by_name($source_name);
  39
  40   return $class
  41     ? $class->new(record_item => $self->record_item, record => $self->record)->discount_from_source($source, $spec)
  42     : empty_discount();
  43 }
  44
  45 sub available_prices {
  46   map { $_->available_prices } $_[0]->all_price_sources;
  47 }
  48
  49 sub available_discounts {
  50   return if $_[0]->record_item->part->not_discountable;
  51   map { $_->available_discounts } $_[0]->all_price_sources;
  52 }
  53
  54 sub best_price {
  55   min_by { $_->price } max_by { $_->priority } grep { $_->price > 0 } grep { $_ } map { $_->best_price } $_[0]->all_price_sources;
  56 }
  57
  58 sub best_discount {
  59   max_by { $_->discount } max_by { $_->priority } grep { $_->discount } grep { $_ } map { $_->best_discount } $_[0]->all_price_sources;
  60 }
  61
  62 sub empty_price {
  63   SL::PriceSource::Price->new(
  64     description => t8('None (PriceSource)'),
  65   );
  66 }
  67
  68 sub empty_discount {
  69   SL::PriceSource::Discount->new(
  70     description => t8('None (PriceSource Discount)'),
  71   );
  72 }
  73
  74 1;
  75
  76 __END__
  77
  78 =encoding utf-8
  79
  80 =head1 NAME
  81
  82 SL::PriceSource - mixin for price_sources in record items
  83
  84 =head1 DESCRIPTION
  85
  86 PriceSource is an interface that allows generic algorithms to be plugged
  87 together to calculate available prices for a position in a record.
  88
  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.
  91
  92 =head1 BACKGROUND AND PHILOSOPHY
  93
  94 sql ledger and subsequently Lx-Office had three prices per part: sellprice,
  95 listprice and lastcost. When adding an item to a record, the applicable price
  96 was copied and after that it was free to be changed.
  97
  98 Later on additional things were added. Various types of discount, vendor pricelists
  99 and the infamous price groups. The problem was not that those didn't work, the
 100 problem was 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.
 102
 103 The result was that the price of an item in a record seemed to change on a
 104 whim, and the origin of the price itself being opaque.
 105
 106 Unrelated to that, users asked for more ways to store special prices, based on
 107 qty (block pricing, bulk discount), based on date (special offers), based on
 108 customers (special terms), up to full blown calculation modules.
 109
 110 On a third front sales personnel asked for ways to see what price options a
 111 position in a quotation has, and wanted information available when prices
 112 changed to make better informed choices about sales later in the workflow.
 113
 114 Price sources now extend the previous pricing by attaching a source to every
 115 price in records. The information it provides are:
 116
 117 =over 4
 118
 119 =item 1.
 120
 121 Where did this price originate?
 122
 123 =item 2.
 124
 125 If this price would be calculated today, is it still the same as it was when
 126 this record was created?
 127
 128 =item 3.
 129
 130 If I want to price an item in this record now, which prices are available?
 131
 132 =item 4.
 133
 134 Which one is the "best"?
 135
 136 =back
 137
 138 =head1 GUARANTEES
 139
 140 To ensure price source prices are comprehensible and reproducible, some
 141 invariants are guaranteed:
 142
 143 =over 4
 144
 145 =item 1.
 146
 147 Price sources will never on their own change a price. They will offer options,
 148 and it is up to the user to change a price.
 149
 150 =item 2.
 151
 152 If a price is set from a source, it is read only. A price edited manually is by
 153 definition not a sourced price.
 154
 155 =item 3.
 156
 157 A price should be able to repeat the calculations done to arrive at the price
 158 when it was first used. If these calculations are no longer applicable (special
 159 offer expired) this should be signalled. If the calculations result in a
 160 different price, this should be signalled. If the calculations fail (needed
 161 information is no longer present) this must be signalled.
 162
 163 =back
 164
 165 The first point creates user security by never changing a price for them
 166 without their explicit consent, eliminating all problems originating from
 167 trying to be smart. The second and third one ensure that later on the
 168 calculation can be repeated so that invalid prices can be caught (because for
 169 example the special offer is no longer valid), and so that sales personnel have
 170 information about rising or falling prices.
 171
 172 =head1 STRUCTURE
 173
 174 Price sources are managed by this package (L<SL::PriceSource>), and all
 175 external access should be by using it's interface.
 176
 177 Each source is an instance of L<SL::PriceSource::Base> and the available
 178 implementations are recorded in L<SL::PriceSource::ALL>. Prices and discounts
 179 returned by interface methods are instances of L<SL::PriceSource::Price> and
 180 L<SL::PriceSource::Discout>.
 181
 182 Returned prices and discounts should be checked for entries in C<invalid> and
 183 C<missing>, see documentation in their classes.
 184
 185 =head1 INTERFACE METHODS
 186
 187 =over 4
 188
 189 =item C<new PARAMS>
 190
 191 C<PARAMS> must contain both C<record> and C<record_item>. C<record_item> does
 192 not have to be registered in C<record>.
 193
 194 =item C<price_from_source>
 195
 196 Attempts to retrieve a formerly calculated price with the same conditions
 197
 198 =item C<discount_from_source>
 199
 200 Attempts to retrieve a formerly calculated discount with the same conditions
 201
 202 =item C<available_prices>
 203
 204 Returns all available prices.
 205
 206 =item C<available_discounts>
 207
 208 Returns all available discounts.
 209
 210 =item C<best_price>
 211
 212 Attempts to get the best available price. returns L<empty_price> if no price is found.
 213
 214 =item C<best_discount>
 215
 216 Attempts to get the best available discount. returns L<empty_discount> if no discount is found.
 217
 218 =item C<empty_price>
 219
 220 A special empty price, that does not change the previously entered price, and
 221 opens the price field to manual changes.
 222
 223 =item C<empty_discount>
 224
 225 A special empty discount, that does not change the previously entered discount, and
 226 opens the discount field to manual changes.
 227
 228 =back
 229
 230 =head1 SEE ALSO
 231
 232 L<SL::PriceSource::Base>,
 233 L<SL::PriceSource::Price>,
 234 L<SL::PriceSource::Discount>,
 235 L<SL::PriceSource::ALL>
 236
 237 =head1 BUGS AND CAVEATS
 238
 239 =over 4
 240
 241 =item *
 242
 243 The current model of price sources requires a record and a record_item for
 244 every price calculation. This means that price structures can never be used
 245 when no record is available, such as calculation the worth of assembly rows.
 246
 247 A possible solution is to either split price sources into simple and complex
 248 ones (where the former do not require records).
 249
 250 Another would be to have default values for the input normally taken from
 251 records (like qty defaulting to 1).
 252
 253 A last one would be to provide an alternative input channel for needed
 254 properties.
 255
 256 =item *
 257
 258 Discount sources were implemented as a copy of the prices with slightly
 259 different semantics. Need to do a real design. A requirement is, that a single
 260 source can provide both prices and discounts (needed for price_rules).
 261
 262 =item *
 263
 264 Priorities are implemented ad hoc. The semantics which are chosen by the "best"
 265 accessors are unintuitive because they do not guarantee anything. Better
 266 terminology might help.
 267
 268 =item *
 269
 270 It is currently not possible to link a price to the price of the generating
 271 record_item (i.e. the price of a delivery order item to the order item it was
 272 generated from). This is crucial to enterprises that calculate all their prices
 273 in orders, and update those after they made delivery orders.
 274
 275 =item *
 276
 277 Currently it is only possible to provide additional prices, but not to restrict
 278 prices. Potential scenarios include credit limit customers which do not receive
 279 benefits from sales, or general ALLOW, DENY order calculation.
 280
 281 =item *
 282
 283 Composing price sources is disallowed for clarity, but all price sources need
 284 to be aware of units and price_factors. This is madness.
 285
 286 =item *
 287
 288 A common complaint is that prices from certain vendors are always negotiated
 289 and should use a default value but must be editable (like free prices) by
 290 default. This should be orthogonal for all prices.
 291
 292 =item *
 293
 294 The current implementation of lastcost is useless. Since it's one of the
 295 master_data prices it will always compete with listprice. But in real scenarios
 296 the listprice tends to go up, while lastcost stays the same, so lastcost
 297 usually wins. Lastcost could be lower priority, but a better design would be
 298 nice.
 299
 300 =back
 301
 302 =head1 AUTHOR
 303
 304 Sven Schoeling E<lt>s.schoeling@linet-services.deE<gt>
 305
 306 =cut