Erstellt vor 5 Jahren
Geschlossen vor 5 Jahren
#1200 closed Fehler (fixed)
Verzehnfachung der einfachen EK-Preise nach Abspeichern der EK-Rechnungen
| Erstellt von: | roman.karuschka@… | Verantwortlicher: | s.schoeling@… |
|---|---|---|---|
| Priorität: | sehr hoch | Meilenstein: | |
| Komponente: | kivitendo ERP | Version: | 2.6.2 unstable |
| Schweregrad: | kritisch | Stichworte: | Einkauf |
| Beobachter: | hli@…, s.schoeling@…, mike.constabel@…, roman.karuschka@… |
Beschreibung
Artikel A in EK-Rechnung gespeichert mit "26,50 EUR, 3 Stk. Macht 79,50.
Soweit, so gut...
Rechnung ueber Berichte wieder aufgerufen: Alle Artikelpreise sind mit zehn multipliziert worden, sogar bei Altrechnungen, die im verg. Monat angelegt wurden. Sprich Artikel A steht da jetzt mit 265 EUR/Stk. Aua.
Anhänge (1)
Änderungshistorie (13)
comment:1 Geändert vor 5 Jahren durch roman.karuschka@…
- Beobachter roman.karuschka@… hinzugefügt
comment:2 Geändert vor 5 Jahren durch hli@…
- Beobachter hli@… hinzugefügt
Ich kann das bei mir nicht nachvollziehen.
Hast Du vielleicht versehentlich mit Preisfaktor o.ä. rumgespielt?
comment:3 Geändert vor 5 Jahren durch roman.karuschka@…
Preisfaktoren nutzen wir bei keinem Mandanten, die wiederum bei keinen Kunden und bei keinen Lieferanten.
Hier mal ein paar gescannte Drucke die das Verhalten belegen. Alles von gerade eben.
comment:4 Geändert vor 5 Jahren durch roman.karuschka@…
Habe mir gerade nochmals die Preisfaktorenmaske aufgerufen. Leer und jungfraeulich...stand noch nie etwas drin
comment:5 Geändert vor 5 Jahren durch roman.karuschka@…
Ein einziger Arttikel - die zweite Position der Liste - ist nicht verzehnfacht worden im Preis.
In den Stamdaten hat der Artikel aber die gleichen Eintragungen wie die Anderen auch, nur eine einzige Abweichung: unten in den Stammmdaten ist ein Lieferant fuer den Artikel angegeben worden, die Anderen Stammdaten sind diesbezueglich leer. Das kann natuerlich auch Zufall sein und nichts mit dem Problem zu tun haben, fiel nur auf.
comment:6 Geändert vor 5 Jahren durch s.schoeling@…
- Beobachter s.schoeling@… hinzugefügt
ich kann das auch nicht nachstellen.
Warum hat deine Rechnung in der ersten Maske eine 8-stellige NUmmer und in der zweiten die gleiche Nummer wie der Auftrag?
comment:7 Geändert vor 5 Jahren durch s.schoeling@…
ach, Zeile verrutscht, das war das Rechnungsdatum...
comment:8 Geändert vor 5 Jahren durch roman.karuschka@…
8-stellige Nummer?
Der Lieferant da ist ein Kleingewerbetreibender, sprich keine Steuerausweisung
bei den rechnungen. Ausserdem liefert der immer nur mit der Rechnung wie ich
erfahren habe, daher entsprechen Auftrags- und Lieferscheinnummer auch immer
der Rechnungsnummer.
Habe mir gerade mal vom Kunden die Altrechnungen geben lassen, die scheinen
doch nicht betroffen zu sein, soweit ich das bislang im Abgleich sehen kann.
Ist also vermutlich irgendein Bug aus juengerer Zeit.
Der Workflow beim Mandanten ist so: Auftrag -> Lieferschein -> Rechnung. Er hat
heute wohl eine Rechnung aus August nacherfasst, sprich die alle der Reihe nach
eingegeben bzw immer einen aus dem Anderen erzeugt. Das Problem tritt erst in
der Rechnung auf, Auftrag ist sauber, Lieferschein ist auch ok, auch wie auf
den Drucken zu sehen die Rechnungserstellung zuerst, aber beim Buchen geht dann
anscheinend etwas schief. wegen der Steuereinstellungen? Wegen der Artikel?
Haette ich das nicht so schwarz auf weiss vor mir, wuerde ich an einen
Eingabefehler glauben, aber ich bin es eben in dem noch offenen Browser mit den
Navigationstasten eben des Browsers nochmal abgegangen. Die Eingabe war
korrekt. :-/
comment:9 Geändert vor 5 Jahren durch s.schoeling@…
perfekt. stell das mal irgendwo nach, damit man das bisecten kann.
comment:10 Geändert vor 5 Jahren durch mike.constabel@…
- Beobachter mike.constabel@… hinzugefügt
Derselbe Fehler bei mir.
Ich lege neue Waren an, Einkaufspreis ist korrekt wenn ich mir die Waren in den Stammdaten ansehe.
EK-Rechnung angelegt, die Einkauspreise der Positionen sind ok.
EK-Rechnung gespeichert.
Die EK-Rechung ist um Faktor 100 zu hoch, öffne ich diese sind die Einkaufspreise um 100 zu hoch.
Sehe ich mir jetzt in den Stammdaten die Waren an, sind dort auch die Einkaufspreise um 100 zu hoch...
Ich bin im GIT rückwärts gegangen un zu dem Punkt gelangt wo alles noch korrekt funktioniert.
Der commit 29b7a6417d94d11e0f07c595fafa1cc93aff362b funktioniert, demnach wurde dieser Bug mit commit 61ab3c630bf655d54cb44f70f871eed5879f9693 vom 07.10 eingeführt.
comment:11 Geändert vor 5 Jahren durch s.schoeling@…
- Status von new nach assigned geändert
- Verantwortlicher von p.reetz@… nach s.schoeling@… geändert
wunderschön. ein bisect im bugreport, das weihnachten für den bugfixer. :)
gleich mal reinschauen.
comment:12 Geändert vor 5 Jahren durch s.schoeling@…
- Lösung auf fixed gesetzt
- Status von assigned nach closed geändert
Bug wurde von Jan Büren schon mit a9c324b2fb9bfe074c4f3ee6a55f36aa83227ed5 gefixt.

Hmm, das tritt pro Lieferant durchgaengig, aber nicht bei allen Lieferanten auf..