Fehler #263
geschlossenEmailadresse der Stammdaten wird nicht mehr übernommen, wenn Belege als Email verschickt werden sollen
Von Werner Hahn vor mehr als 7 Jahren hinzugefügt. Vor mehr als 7 Jahren aktualisiert.
100%
Beschreibung
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.
Von Jan Büren vor mehr als 7 Jahren aktualisiert
- Zielversion wurde auf 3.5 gesetzt
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
Von Sven Schöling vor mehr als 7 Jahren aktualisiert
- Status wurde von Neu zu Gelöst geändert
- % erledigt wurde von 0 zu 100 geändert
Status geändert durch Changeset kivitendo-erp|commit:c476418e8c5de987f1d53ecd167066c00b484119.
Von Sven Schöling vor mehr als 7 Jahren aktualisiert
- Status wurde von Gelöst zu In Bearbeitung geändert
- Priorität wurde von Dringend zu Normal geändert
- Zielversion
3.5wurde gelöscht - % erledigt wurde von 100 zu 50 geändert
(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.
Von Moritz Bunkus vor mehr als 7 Jahren aktualisiert
- Status wurde von In Bearbeitung zu Erledigt geändert
- % erledigt wurde von 50 zu 100 geändert
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.
Von Jan Büren vor mehr als 7 Jahren aktualisiert
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.
Von G. Richardson vor mehr als 7 Jahren aktualisiert
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.
Von Moritz Bunkus vor mehr als 7 Jahren aktualisiert
Stimmt auch wieder, ja… Sollte aber trivial anzupassen sein.
Von Jan Büren vor mehr als 7 Jahren aktualisiert
Gut. Im Einkauf haben wir klar Konsens (makemodel ist das Killerargument).
Wie ist die Tendenz für den Verkaufs-Lieferschein?
Von Moritz Bunkus vor mehr als 7 Jahren aktualisiert
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.