Revision 7801c6c2
Von Sven Schöling vor fast 9 Jahren hinzugefügt
| SL/PriceSource.pm | ||
|---|---|---|
| 92 | 92 |
=head1 BACKGROUND AND PHILOSOPHY |
| 93 | 93 |
|
| 94 | 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.
|
|
| 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 | 97 |
|
| 98 | 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
|
|
| 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 | 101 |
available price from the database, and when to leave the user entered price. |
| 102 | 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 |
|
|
| 103 | 106 |
Unrelated to that, users asked for more ways to store special prices, based on |
| 104 | 107 |
qty (block pricing, bulk discount), based on date (special offers), based on |
| 105 | 108 |
customers (special terms), up to full blown calculation modules. |
| 106 | 109 |
|
| 107 | 110 |
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
|
|
| 109 |
offer changed.
|
|
| 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.
|
|
| 110 | 113 |
|
| 111 |
Price sources put that together by making some compromises: |
|
| 114 |
Price sources now extend the previous pricing by attaching a source to every |
|
| 115 |
price in records. The information it provides are: |
|
| 112 | 116 |
|
| 113 | 117 |
=over 4 |
| 114 | 118 |
|
| 115 | 119 |
=item 1. |
| 116 | 120 |
|
| 117 |
Only change the price on creation of a position or when asked to.
|
|
| 121 |
Where did this price originate?
|
|
| 118 | 122 |
|
| 119 | 123 |
=item 2. |
| 120 | 124 |
|
| 121 |
Either set the price from a price source and let it be read only, or use a free
|
|
| 122 |
price.
|
|
| 125 |
If this price would be calculated today, is it still the same as it was when
|
|
| 126 |
this record was created?
|
|
| 123 | 127 |
|
| 124 | 128 |
=item 3. |
| 125 | 129 |
|
| 126 |
Save the origin of each price with the record so that the calculation can be |
|
| 127 |
reproduced. |
|
| 130 |
If I want to price an item in this record now, which prices are available? |
|
| 128 | 131 |
|
| 129 | 132 |
=item 4. |
| 130 | 133 |
|
| 131 |
Make price calculation flexible and pluggable. |
|
| 134 |
Which one is the "best"? |
|
| 135 |
|
|
| 136 |
=back |
|
| 137 |
|
|
| 138 |
=head1 GUARANTEES |
|
| 139 |
|
|
| 140 |
To ensure price source prices are comprehensible and reproucible, 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. |
|
| 132 | 162 |
|
| 133 | 163 |
=back |
| 134 | 164 |
|
| ... | ... | |
| 137 | 167 |
trying to be smart. The second and third one ensure that later on the |
| 138 | 168 |
calculation can be repeated so that invalid prices can be caught (because for |
| 139 | 169 |
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. |
|
| 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. |
|
| 142 | 184 |
|
| 143 | 185 |
=head1 INTERFACE METHODS |
| 144 | 186 |
|
| ... | ... | |
| 198 | 240 |
|
| 199 | 241 |
=item * |
| 200 | 242 |
|
| 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. |
|
| 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 inpout normally taken from |
|
| 251 |
records (like qty defaulting to 1). |
|
| 205 | 252 |
|
| 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.. |
|
| 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 sinle |
|
| 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. |
|
| 211 | 274 |
|
| 212 | 275 |
=item * |
| 213 | 276 |
|
| ... | ... | |
| 215 | 278 |
prices. Potential scenarios include credit limit customers which do not receive |
| 216 | 279 |
benefits from sales, or general ALLOW, DENY order calculation. |
| 217 | 280 |
|
| 281 |
=item * |
|
| 282 |
|
|
| 283 |
Composing price sources are disallowed for clarity, but all price sources need |
|
| 284 |
to be aware of units. This is madness. |
|
| 285 |
|
|
| 218 | 286 |
=back |
| 219 | 287 |
|
| 220 | 288 |
=head1 AUTHOR |
Auch abrufbar als: Unified diff
PriceSource: Doku Update