Project

General

Profile

Fehler #263

Emailadresse der Stammdaten wird nicht mehr übernommen, wenn Belege als Email verschickt werden sollen

Added by Werner Hahn about 3 years ago. Updated almost 3 years ago.

Status:
Erledigt
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
05/30/2017
Due date:
% Done:

100%

Estimated time:

Description

Es wird nur die emailadresse der Ansprechperson übernommen, falls eine Ansprechperson ausgewählt wurde.
Vorher bis 3.4.1 wurde wenn keine Ansprechperson ausgewählt war, die emailadresse der Stammdaten im Formular angezeigt.

Associated revisions

Revision c476418e (diff)
Added by Sven Schöling almost 3 years ago

belege email dialog: Ohne Ansprechpartner Email aus Stammdaten verwenden

behebt #263

Revision 103d03fb (diff)
Added by Moritz Bunkus almost 3 years ago

E-Mail-Dialog: Vorbelegung vom Kunden/Lieferanten, wenn Ansprechperson keine E-Mail hat

Siehe #263.

Revision 20e572be (diff)
Added by Moritz Bunkus almost 3 years ago

E-Mail-Dialog: keine Vorbelegung bei Lieferantenauftrag/-lieferschein

Siehe #263.

Revision a9866c42 (diff)
Added by Moritz Bunkus almost 3 years ago

E-Mail-Dialog: bei Einkaufsaufträgen Standardvorbelegung

Siehe #263.

History

#1 Updated by Jan Büren almost 3 years ago

  • Target version set to 3.5

Das ist etwas unschön.
Das hätte ich gerne noch sauber in der 3.5

IRC:
<kivijan> @opendynamicbot: kann einer von euch prüfen, ob #263 bei der umstellung des mailversands für dokumente geschreddert wurde und ggf. kurzfristig fixen?
<gorash> das klingt sehr nach ner auswirkung von actionbar/mailpopup umstellung. ich schau mir das mal an, es sei denn mosu meldet sich dazu
<kivijan> ich hab es auch gerade gesehen, das ist mosu-code in common/_send_email_dialog.html
<kivijan> wahrscheinlich nur eine zeile pro belegaufruf im alten code

#2 Updated by Sven Schöling almost 3 years ago

  • Status changed from Neu to Gelöst
  • % Done changed from 0 to 100

Status geändert durch Changeset kivitendo-erp|commit:c476418e8c5de987f1d53ecd167066c00b484119.

#3 Updated by Sven Schöling almost 3 years ago

  • Status changed from Gelöst to In Bearbeitung
  • Priority changed from Dringend to Normal
  • Target version deleted (3.5)
  • % Done changed from 100 to 50

(12:48:59) gorash: allerdings gibt es da noch eine randbedingung: abweichende lieferadressen werden nicht berücksichtigt. ich verstehe mosus code da nicht, und ausserdem muss das für einkauf und verkauf unterschiedlich sein (email im verkauf geht an den mit der lieferadresse, im einkauf steht da meine email und email geht an den lieferanten)

Wenn ich das richtig sehe muss das in kivi.show_email_dialog mit übergeben werden, und irgendwo muss auf das confirmed geprüft werden. Mosu, bitte mal reinschauen.

#4 Updated by Moritz Bunkus almost 3 years ago

  • Status changed from In Bearbeitung to Erledigt
  • % Done changed from 50 to 100

Ich habe eben zwei kleine Fixes gepusht und betrachte diesen Issue nun als erledigt.

Der Algorithmus ist relativ einfach:

1. Bei Lieferantenaufträgen und Einkaufslieferscheinen gibt es schlicht keine Vorbelegung.
2. Andernfalls: ist eine Ansprechperson gewählt und hat diese eine E-Mail-Adresse, so wird diese genommen.
3. Andernfalls: es wird die E-Mail-Adresse aus der Rechnungsadresse des Kunden bzw. Lieferanten genommen.

Warum 1. und warum keine Ausnahme beim Verkaufslieferschein?

Zu 1.: Lieferantenaufträge und Einkaufslieferscheine sind Dokumente, die ich vom Lieferanten erhalten habe. Diese verschicke ich nur ganz selten überhaupt mal wieder. Und falls ja, an wen denn? Vielleicht mal eine Kollegin oder so. Hier gibt es schlicht keine sinnvolle Vorbelegung, und mit Daten des Lieferanten vorzubelegen ist im Gegenteil sogar schädlich.

Zum Verkaufslieferschein: es kann sein, dass man einen Verkaufslieferschein per E-Mail an die Adresse der Lieferadresse schicken möchte. Genau so kann es aber auch sein, dass zwar die Liefereung selber an eine abweichende Adresse geht, aber die Belege per E-Mail an die Zentrale (Rechnungsadresse) geschickt werden soll. Auch hier gibt es somit keine Adresse, die allgemeingültig vorbelegt werden soll. Ich erachte daher den oben beschriebenen, allgemeinen Algorithmus für Verkaufslieferscheine ebenfalls geeignet. Der Vorteil ist auch, dass man kivitendo-Benutzer*innen einen relativ leicht zu merkenden Algorithmus beschreibt und nicht drei Varianten davon.

#5 Updated by Jan Büren almost 3 years ago

Zu 1.

Ohje, dass hab ich dann wohl immer falsch benutzt und unsere Kunden auch.
Lieferantenauftrag ist immer der Beleg gewesen, denn wir an den Lieferanten geschickt haben, um eine verbindliche Bestellung dort auszulösen.

Vielleicht können wir noch einen weiteren Workflow-Schritt einführen: Lieferantenbeauftrag und den Lieferantenauftrag dann besser in Auftragsbestätigung des Lieferanten umbenennen, dann ist das sprachlich besser abgegrenzt.

Bei Einkaufslieferschein und Einkaufsrechnung stimme ich Moritz zu, da gibt es keine Doppeldeutigkeit.

Zum Verkaufslieferschein: Da kann man leider auch nicht so exakt eine Bestimmung machen. Es kommt wirklich darauf an, wie der Mandant diesen Workflow-Schritt lebt. Ich würde den Standard eher an das Verhalten der Druckvorlage anpassen.
Diese definiert:
1. Falls abweichende Lieferadresse definiert -> dorthin liefern
2. Falls keine abweichende Lieferadresse -> an Rechnungsadresse liefern

Pragmatischerweise sollten die Optionen einfach konfigurierbar sein und der Standard eher wie in der 3.4.1, dann sind alle Seiten zufrieden.

#6 Updated by G. Richardson almost 3 years ago

Im Einkaufsworkflow gibt es doch zwei Arten von Dokumenten, die ich an den Lieferanten schicke: das Einholen eines Angebots und die Auftragsbestätigung. Den Lieferantenauftrag kann ich ausdrucken, unterschreiben, und als verbindliche Bestellung an den Lieferanten schicken, genauso wie den RFQ für die Anfrage.
Deshalb gibt es doch auch die makemodels, daß man die mit den Artikelnummern des Lieferanten ausdrucken kann. Ich sehe keinen Grund, warum man das nur beim Angebot und nicht auch beim Auftrag nutzen sollte, und habe das auch immer so verwendet. Gibt es einen Grund im Code warum man das nicht machen sollte? Wenn der Lieferant die Auftragsbedingungen einseitig ändert und zurückschickt, und man mit den Änderungen einverstanden ist, müßte man streng genommen den alten Auftrag anpassen oder löschen/schließen und einen neuen Auftrag generieren, damit das synchron ist, aber ansonsten sollte meine Bestellung doch maßgeblich sein.
Außerdem will ich doch auch meine Auftragsnummer für den Bestellprozeß vorgeben (es gibt ja extra auch einen Lieferantenauftragsnummernkreis), damit der Lieferant die wiederum als "seine Kundenauftragsnummer" verwenden kann. Das geht nur, wenn ich die auch mit dem Auftrag an den Lieferanten schicke.

#7 Updated by Moritz Bunkus almost 3 years ago

Stimmt auch wieder, ja… Sollte aber trivial anzupassen sein.

#8 Updated by Jan Büren almost 3 years ago

Gut. Im Einkauf haben wir klar Konsens (makemodel ist das Killerargument).

Wie ist die Tendenz für den Verkaufs-Lieferschein?

#9 Updated by Moritz Bunkus almost 3 years ago

Ich habe nicht vor, den Workflow für den Verkaufslieferschein anzupassen, weil ich schlicht der Meinung bin, dass eine abweichende Lieferanschrift für den E-Mail-Versand größtenteils irrelevant sein wird (oder nicht relevant genug). Wenn ihr anderer Meinung seid und das selber anpassen wollt: have at it.

Also available in: Atom PDF