Projekt

Allgemein

Profil

« Zurück | Weiter » 

Revision 30a5c527

Von Sven Schöling vor mehr als 8 Jahren hinzugefügt

  • ID 30a5c527c0feec009aed9e6915eb37fa1fdd9401
  • Vorgänger 4e8e85fc
  • Nachfolger 086e9880

PriceSource: doku update

Mehrere Anforderungen die sich über die Zeit gesammelt haben

Unterschiede anzeigen:

SL/PriceSource.pm
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
......
=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 *
......
=item *
Composing price sources is disallowed for clarity, but all price sources need
to be aware of units. This is madness.
to be aware of units and price_factors. This is madness.
=item *
A common complaint is that prices from certain vendors are always negotiated
and should use a default value but must be editable (like free prices) by
default. This should be orthogonal for all prices.
=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.
=back

Auch abrufbar als: Unified diff