Revision 8cf8798d
Von Sven Schöling vor mehr als 8 Jahren hinzugefügt
| SL/PriceSource.pm | ||
|---|---|---|
| 297 | 297 |
usually wins. Lastcost could be lower priority, but a better design would be |
| 298 | 298 |
nice. |
| 299 | 299 |
|
| 300 |
=item * |
|
| 301 |
|
|
| 302 |
Guarantee 1 states that price sources will never change prices on their own. |
|
| 303 |
Further testing in the wild has shown that this is desirable within a record, |
|
| 304 |
but not when copying items from one record to another within a workflow. |
|
| 305 |
|
|
| 306 |
Specifically when changing from sales to purchase records prices don't make |
|
| 307 |
sense anymore. The guarantees should be updated to reflect this and |
|
| 308 |
transposition guidelines should be documented. |
|
| 309 |
|
|
| 300 | 310 |
=back |
| 301 | 311 |
|
| 302 | 312 |
=head1 AUTHOR |
Auch abrufbar als: Unified diff
Doku: PriceSource Verhalten für Belegumwandlungen
Wie beschrieben in redmine#199:
Wenn ein Kunde einen Kundenrabatt hat, und man aus einem Auftrag einen
Lieferantenauftrag macht, wird die active_discount_source der Artikel
(z.B. "customer_discount/1162") mit auf die Einkaufsseite des Workflows
übernommen, und das fliegt einem dann bei der EK-Rechnung um die Ohren.
Wahrscheinlich wäre es aber besser, beim Wechsel von VK zu EK die
Kundenrabatte und Kundenpreisregeln herauszufiltern, da diese nichts mit
den Vereinbarungen mit dem Lieferanten zu tun haben. Und dann sollten
bei den Positionen die Lieferantenregeln vorbelegt werden, so als ob man
den Auftrag händisch eingegeben hätte.