Neu Emailadresse zum Zentralen Rechnungseingang

Litho

Gut bekanntes Mitglied
17. Juni 2017
311
20
folgende Email erreichen mich zunehmend mehr und mehr von Verwaltungen der öffentlichen Hand und größeren Firmen. Daraus resultiert für mich das Problem, dass ich ein weiteres Datenfeld für eine Rechnungsemailadresse benötige. An diese Adresse darf auch nur die Rechnung gehen und sie muss von mir kommen. Eine Weiterleitung des bestellenden Sachbearbeiters ist nicht möglich (warum auch immer). Würde er aber beim Bestellprozess im Shop diese Rechnungs Emailadresse als seine "absender Adresse" nutzen käme zwar die Rechnung richtig an, aber die Tracking infos und AB und Lieferscheine auch. Die braucht aber der bestellende Sachbearbeiter.

Hat jemand eine Lösung für mich? kann ich einfach ein weiteres Datenfeld bei der Adresse anlegen?? Klappt dass dann auch mit dem Shop und über den Connector?

Gruß
Litho

Sehr geehrte Damen und Herren,

Die elektronische Realisierung von Geschäftsprozessen und –abläufen hat zunehmend an Bedeutung gewonnen.
Die „Digitalisierung“ betrifft alle Lebensbereiche. Nicht nur die private Kommunikation sondern auch die Arbeitswelt ist von diesen Veränderungen betroffen.
Dadurch ergeben sich völlig neue Herausforderungen. In diesem Zusammenhang müssen Prozesse und die Organisation optimiert bzw. neu entwickelt werden.

Die Stadtverwaltung XXX hat daher seit August 2018 mit der Umstellung auf einen zentralen Rechnungseingang und zukünftig die Annahme von elektronischen Rechnungen begonnen.

Für den zentralen Rechnungseingang in der Stadtverwaltung XXXX wurde eine einheitliche Rechnungsanschrift für alle Rechnungsdokumente geschaffen, um Rechnungen schneller der zuständigen Organisationseinheit zuzuordnen und bearbeiten zu können.

Ab sofort gilt für ausnahmslos alle Rechnungsdokumente in Papierform folgende neue Rechnungsanschrift:
...
Elektronische Rechnungen oder Rechnungen beispielweise als PDF senden Sie bitte an folgende Rechnungsadresse:

rechnung@stadt-XXXX.de

Bitte verwenden Sie für Rechnungsdokumente nicht mehr die Ihnen bekannten Anschriften.

Dokumente, welche keine Rechnungen sind, versenden Sie bitte auch weiterhin an die Ihnen bekannten Adressen.

Vielen Dank für Ihre Unterstützung.
usw...
 

Litho

Gut bekanntes Mitglied
17. Juni 2017
311
20
Ok ich pushe das Thema in der Hoffnung, dass mir mal jemand sagt, dass man eventuell schon daran arbeitet oder es auf dem Plan hat ein solches Datenfeld in der Wawi anzulegen, oder selbst anzulegen, oder eine separate Lösung dazuzuinstallieren...
Man hat mir nun Mitgeteilt, das die EU-Richtiline 2014/55/EU verpflichtet öffentliche Auftraggeber, zukünftig E-Rechnungen im Sinne der Richtlinie und der ausgestaltenden Bundes- und Landesgesetze, sowie Verordnungen, empfangen und verarbeiten zu können. Soweit zum Hintergrund. In der Praxis richten die Verwaltungen halt alle ein separates Emailkonto ein. Um das mit PDF-Rechnungen bedienen zu können bedarf es halt eines Datenfeldes von der Wawi bis hin zur Shopsoftware um die Workflows auch weiterhin und im Sinne des Bestellers beliefern zu können.
 

sventimo

Gut bekanntes Mitglied
7. Juli 2010
134
1
Ok ich pushe das Thema in der Hoffnung, dass mir mal jemand sagt, dass man eventuell schon daran arbeitet oder es auf dem Plan hat ein solches Datenfeld in der Wawi anzulegen, oder selbst anzulegen, oder eine separate Lösung dazuzuinstallieren...

Hallo, ich schließe mich dem an. Auch wir haben das Problem. Hat jemand bereits eine Lösung gefunden?

Hallo JTL
ist dieses Problem bekannt und in Arbeit oder gibt es einen Workflow dafür?
 

Shopworker.de

Offizieller Servicepartner
SPBanner
4. Januar 2011
4.114
542
Arnsberg, Sauerland
Hallo,

das Problem/Wunsch ist glaube ich seit der 1.4 gelöst; gibt auch schon einige Threads und Anleitungen dazu.

Du legst beim Kunden einen Ansprechpartner mit Abteilung z.B. "Buchhaltung" oder "Rechnungsempfänger" an
und kannst dann in den Formularvorlagen per DotLiquid abfragen ob es diesen gibt; wenn nicht soll die "normale" Rechnungsanschrift genommen werden ...
 

sventimo

Gut bekanntes Mitglied
7. Juli 2010
134
1
Hallo,

das Problem/Wunsch ist glaube ich seit der 1.4 gelöst; gibt auch schon einige Threads und Anleitungen dazu.

Du legst beim Kunden einen Ansprechpartner mit Abteilung z.B. "Buchhaltung" oder "Rechnungsempfänger" an
und kannst dann in den Formularvorlagen per DotLiquid abfragen ob es diesen gibt; wenn nicht soll die "normale" Rechnungsanschrift genommen werden ...
Wir hatten schon reichlich gesucht, aber nur diesen Thread gefunden.
Wir werden noch einmal auf die Suche gehen.
Vielen Dank für die Antwort.
Andreas
 

sjk

Sehr aktives Mitglied
16. Januar 2019
364
130
Moin Andreas,

Bei uns habe ich das seit der 1.4 so gelöst:
  1. Betreffende Kunden bekommen einen Ansprechpartner für die Buchhaltung eingetragen. Wichtig: Ins Feld Abteilung "Buchhaltung" eintragen, E-Mail-Adresse der Buchhaltung eintragen und ggf. Vor-/Nachname, falls Ihr das benötigt.

  2. Workflow anlegen unter dem Trigger, der für euch Sinn macht. (Bei uns Versand>Lieferscheine>Versendet, weil die Buchhaltung die Rechnung erhalten soll, sobald die Ware raus ist und nicht zwingend wenn die Rechnung erstellt wurde)

    Als Bedingung legst du eine Erweiterte Eigenschaft mit folgenden Inhalt an und lässt auf "ist nicht leer" prüfen:
    {% for ansprechpartner in Vorgang.Auftrag.Kunde.Ansprechpartner -%}{% if ansprechpartner.Abteilung == 'Buchhaltung' -%}{{ ansprechpartner.EMail }}{% endif -%}{% endfor -%}
    (Das ist eine Schleife, die durch alle Ansprechpartner im Kundenkonto geht, bis er bei einem Ansprechpartner Abteilung="Buchhaltung" findet. Dann gibt sie dessen E-Mail-Adresse aus)
    Weitere Bedingungen legst du nach euren Anforderungen an, z. B. auf eine bestimmte Kundengruppe einschränken oder nur wenn ein Auftrag komplett ausgeliefert ist o.ä.

    Aktion: Ausgabe>Mailen>Rechnung, in das Feld "Alternativer Empfänger" trägst du nochmal den Code aus der Erweiterten Eigenschaft ein. "Auf Ausgabe warten" anhaken (z. B. 500ms)

Funktioniert so einwandfrei bei uns.
 
  • Gefällt mir
Reaktionen: NewBuy

Litho

Gut bekanntes Mitglied
17. Juni 2017
311
20
das Problem/Wunsch ist glaube ich seit der 1.4 gelöst; gibt auch schon einige Threads und Anleitungen dazu.

Du legst beim Kunden einen Ansprechpartner mit Abteilung z.B. "Buchhaltung" oder "Rechnungsempfänger" an
und kannst dann in den Formularvorlagen per DotLiquid abfragen ob es diesen gibt; wenn nicht soll die "normale" Rechnungsanschrift genommen werden ...

Nun an die Suche werde ich mich auch noch dranhängen, aber selbst wenn es so gelöst ist wie beschrieben und ich verstanden habe, kann es der Kunde im Onlineshop noch nicht selbst bei der Bestellung einpflegen oder? Es ist immer händisches Nacharbeiten in Wawi von nöten. Richtig?? Dann wäre die "Lösung" eine "Behelfsmöglichkeit" oder?

Gruß
Litho
 

sjk

Sehr aktives Mitglied
16. Januar 2019
364
130
Moin Litho,

Dass Ihr das direkt über den Shop abwickeln wollt habe ich überlesen. Da du nichts anderes geschrieben hast gehe ich mal von einem JTL-Shop aus.

Hast du dir schon mal die "Selbstdefinierbaren Kundenfelder" im JTL-Shop angesehen? Damit könntest du bei der Registrierung oder im Bestellvorgang ein separates Feld für eine Rechnungsemail anzeigen lassen, welches dann soweit ich weiss als "Eigenes Feld" im Kundenaccount in der Wawi landet. Hab ich leider noch nie benutzt, da müsstest du mal testen wie das im Detail funktioniert.
In den Versandworkflows kannst du meines Wissens nicht auf die Eigenen Kundenfelder zugreifen. Der Workflow wäre in diesem Fall unter Rechnung>Erstellt am einfachsten.
Da prüfst du in Rechnung>Auftrag>Kunde>EigeneFelder>DeinFeld auf nicht leer und als Aktion nimmst du wie oben Ausgabe>Rechnung>Mailen und im Alternativen Empfänger wählst du die Variable Rechnung>Auftrag>Kunde>EigeneFelder>DeinFeld.

Die Alternative "dirty-Lösung" mit der Shop-Standardkonfig: Du schreibst in die Sprachvariable für das Kommentarfeld, dass man falls gewünscht eine Rechnungsemail-Adresse bitte in das Kommentarfeld schreiben soll. Die könntest du dann mit einem Regex rausfiltern.
 
Ähnliche Themen

Ähnliche Themen