wir sind bei der Implementierung der Seiten einen guten Schritt weiter gekommen. Da die Information in der Versandtabelle nicht vorlag, musste dieser (ziemlich aufwendige) Schritt zuerst erfolgen. Als nächstes müssen wir die Funktion noch implementieren.
Beiträge von Tobias Bambullis
-
-
Alles anzeigen
Um die Kosten in der Guthaben-Übersicht komplett nachvollziehen zu können, ist die genaue Aufschlüsselung jedes einzelnen Briefes notwendig, mit dem Bezug zu eurer Preisliste.
Beispiel 23. September:
61 x E-Post à 1 Seite Duplex Farbe = 61 × 0,81 € = 49,41 € * 1,19 = 59,17 €
5 x E-Post à 2 Seiten Duplex Farbe = 5 × 1,42 € = 7,10 € * 1,19 = 8,55 €Ich denke übrigens immer noch, dass die E-Post falsch abgerechnet wird.
Beispiel: Der Klassiker, das Erstanschreiben mit Zugangsdaten für die KundenApp.
Laut Preisliste kostet 1 Seite Duplex Farbe 0,81 € zzgl. USt.Ich verschicke 10.000 solcher Briefe:
10.000 × 0,81 € = 8.100 € zzgl. USt. × 1,19 = 9.639 €
Ihr rechnet ab:
10.000 × 0,97 € = 9.700 € inkl. USt.
Die Differenz beträgt hier also 61 € und irgendjemand zahlt zu viel oder zu wenig Umsatzsteuer …tatsächlich runden wir die dritte Stelle nach dem Kommata immer auf. Kostet ein Brief 0,913 Cent, so wird daraus 0,92 Cent in der Abrechnung. Das mag nicht ganz korrekt sein, allerdings sagen wir auch nicht, dass wir die Kosten der Post 1:1 durchreichen können, sondern aktuell nur zwischen 0.991:1 und 0.999:1 genau. Die Gründe dahinter sind rein technischer Natur. Aufladungen des Guthaben finden nur brutto statt, da wir in den Anfangsjahren von diesem Modul mit Kritik überlaufen wurden, das eine Aufladung über 100€ nicht 119€ bedeuten könnte. Rückwirkend gesehen war es ein Fehler auf diesen Wunsch unserer Kunden zu hören. Dies löst genau an dieser Stelle Probleme aus, da Rundungsfehler entstehen.
Wir haben das bisher aus zwei Gründen nicht korrigiert: 1) wir sind die einzige Plattform am Markt, die nicht zwischen 10 und 20 Cent pauschal bei Briefen aufschlagen. 2) der Umbau auf reine Nettopreise sowie die damit verbundene Kommunikation würde ein fünfstelliges Budget erfordern. Bei der Umsetzung und Fokusierung der Entwicklungsteams würde es zwangsweise zu der Frage kommen, warum facilioo keine Aufschläge durchführt. In dem Modul entstehen pro Jahr über 300 Supportfälle, in denen wir mit der deutschen Post sprechen müssen, wo Brief xy abgeblieben ist. Dies ist der größte Bereich des facilioo Supports. Die meisten dieser Supportfälle entstehen nicht bei uns, sondern bei der Post selbst. Trotzdem zahlen wir seit Jahren dieses Guthaben wieder aus, obwohl wir zumeist nicht der Verursacher sind und dies als Verlust auf unserer Seite einbuchen.
Die Situation ist für beide Seite (facilioo und für uns unsere Kunden) nicht zufriedenstellend. Wir diskutieren seit über einem Jahr, wie wir mit der Situation zukünftig umgehen wollen. Ideen sind: a) Kunde richtet sich selbst ein Konto bei der Post ein und zahlt Rechnungen direkt an die Post b) Einbindung andere Unternehmen wie E-PIN um die Fehlerquote zu senken c) Umstellung auf netto Beträge d) Erhöhung der Kosten für den Postausgang, um Teile des Supports zu entlasten e) Maßnahmen zum Abbau von Postsendung fokusieren (Änderungen von Gesetzen mit Hilfe von Verbänden, damit mehr digital gesendet werden darf). Hier wird es eine Lösung geben, allerdings nicht mehr in 2024. Das Ziel ist eine saubere Lösung, die möglichst keine Mehrkosten bei unseren Kunden verursacht und unsere Kosten senkt. Übrigens: steuerlich ist das korrekt. Aber es ist richtig, dass facilioo zwischen 0,1 und 0,9 Cent pro Brief fakturiert, je nachdem, wie groß die Rundungsabweichung bei der Steuerumrechnung ist.
Zu dem zweiten Post: das überprüfen wir intern im nächsten Sprint. Eine so große Abweichung wäre in den Unternehmenszahlen aufgefallen, irgendwas kann dort nicht 100%ig stimmen.
-
wir schauen, dass wir dieses Thema in einen unserer nächsten Sprints mit aufnehmen können.
-
Umlaufbeschlüsse Online über Facilioo aus dem Vorgang abzubilden würden wir uns auch sehr wünschen
ja, dieses Feature wird zeitnah kommen.
-
Guten Tag,
generell stellen diese Vorgangs-Adressen eine Erweiterung da. Wird auf eine von facilioo erzeugte E-Mail genantwortet, so wird diese E-Mail immer eingelesen (egal ob diese Funktion aktiviert ist oder nicht).
In den Einstellungen kann man unter Integrationen eine E-Mail Absender erlauben. Dieser kann zum Beispiel "meine-hausverwaltung.de" sein. Im Prinzip geht es um alles, was hinter dem @-Zeichen in Ihrern E-Mail Adressen steht. Ist Ihr Absender erlaubt, blenden wir die Vorgangs-Adressen ein.
Sie können ab diesem Zeitpunkt in jede E-Mail (selbst wenn Sie aus Outlook irgendjemanden schreiben) die Vorgangs-Adresse CC nehmen. facilioo kennt nun Ihren Absender und wird die E-Mail wie eine Antwort einlesen.
-
Für uns ist diese Liste momentan auch relativ nutzlos. Ich weiß nicht wie es den anderen geht, aber wir berechnen bei einer WEG die Portokosten generell pro Objekt und nicht pro Nutzer oder Einheiten etc...
Es muss doch möglich sein die Portokosten einer einzelnen WEG herauszufiltern?! Selbst wenn alle Nutzer einzeln aufgelistet sind, wäre es ok. Dann kann man sich wenigstens die für einen selbst benötigten Daten herausfiltern.
Bitte Bitte
die Liste ist nach Objekt sortiert, damit man genau diese Auswertung pro Objekt machen kann. Rechnet man die Werte pro Objekt zusammen, so müsste der richtige Wert rauskommen, wenn man nicht folgendes Szenario dabei hat:
in diesem Beispiel hat Ulrich Stuke Porto gespart, da er in einem Brief für zwei Objekte informiert wurde. Das ist genau der Fall, den wir nicht auseinander rechnen können. Wenn dies allerdings für die meisten kein Problem ist, sollte die Liste nützlich sein.
Könnte sich bitte jemand dazu äußern? Andernfalls werde ich meine Verträge auf die tatsächlichen Kosten umstellen müssen, was zu einem Umsatzverlust führt. Derzeit finde ich allerdings keine andere Möglichkeit, die Portokosten seitenbezogen zu erfassen. Vielen Dank für Ihre Unterstützung.
Wir speichern aktuell die Seitenzahlen nicht bei dem Versand ab, sondern nur den Preis pro Brief (hier an den Nutzer). Das können wir aber bei Zeiten nachrüsten.
-
heute Abend ist ein Export im Deployment mit enthalten (gegen 22:00 Uhr), um erstmal zu prüfen, wir nah wir damit an eine Lösung kommen. Bitte den Hinweistext beachten.
-
nachdem das Thema Berechnung von Porto pro Einheit, etc ja offensichtlich noch nicht auf der Zielgerade ist.
Bitte einen Quickwin bereitstellen:
wir wollen die Guthabenliste zum Download als csv. dann können wir wenigstens ohne Bleistift und Taschenrechner das Porto selbst ermitteln. Bitte bei der Guthabenübersicht einen Downloadbutton bereitstellenBitte einmal so nochmal an den Support schicken - das sollten wir kurzfristig hinkriegen.
Darum geht es aber nicht. Die anschließende Berechnung im Bereich "Guthaben" ist korrekt, und auch Albert hat das auch so beschrieben. Die eigentliche Frage ist doch: Was bringt mir die Vorschau, wenn sie nicht korrekt berechnet wird? Ich hatte genau das gleiche Problem. Der Support hat zu meinem Ticket wieder nur Rückfragen gestellt, und erst durch Alberts Beitrag habe ich verstanden, warum es zu den unterschiedlichen Berechnungen kommt: Es sind die manuell hinzugefügten Seiten, die nicht erfasst werden. Das ist doch eindeutig ein Bug, der behoben werden sollte. Oder liege ich da falsch?
- Notiz Administration: gekürzt, da persönliche Meinung -
Der Bug wurde behoben. Sollten manuell hochgeladene Dateien bei Ihnen nicht gezählt werden, bitte die Datei an den Support melden. -
Auf eine systemseitige brauchbare Auswertung warten wir ja schon seit 2022, aber offensichtlich funktioniert jetzt auch unser "manueller Workaround" mit der Excel-Tabelle nicht mehr. Denn bei den hinzugefügten Dokumenten (hier: Tagesordnung) werden die Seiten nicht erkannt und berechnet ("undefined Seiten") und entsprechend stimmen die ausgewiesenen Zahlen nicht mehr. Ist uns gerade erst aufgefallen, wir haben in den vergangenen Wochen also schlimmstenfalls mehrere tausend Seiten ohne Be-/Abrechnung verschickt...
Die Seitenzahl im Frontend ist nur zur Information. Die eigentliche Berechnung findet nachträglich im Backend statt. Das heisst für diesen Fall, dass dieser 'undefined' Fehler keine Auswirkung haben wird. Im Postausgang lässt sich zusätzlich rausfinden, dass die Seiten dabei waren.
-
haben Sie eine Ticketnummer zur Hand?
-
bitte einmal dem Support melden - das Forum wird nicht aktiv vom Support bearbeitet, sondern es wird für Anregungen in die Entwicklung mit eingeschlossen.
-
die einzigen beiden Stellen, an denen es jetzt noch nicht funktioniert sind:
1) Nutzer:innen informieren -> Stapel erzeugen
2) wenn bei Dokumente versenden kein Objekt in der Suche gewählt wird.
Wir arbeiten zur Zeit daran, dass die Umweltbenachrichtung aus den Projekten in die Einstellungen umzieht und damit pro Account gilt, nicht mehr pro Projekt. Danach geht dann alles.
-
sobald wir wieder deployen können (wahrscheinlich morgen Abend), wird dieser Bug in ca. 90% aller Fälle (wenn es objektbezogen ist) behoben sein. Ich antworte dann nochmal, wann die Umweltbenachrichtigung nicht gesendet wird bzw. wie wir das in Zukunft umbauen.
-
Hmmmm, jetzt komme ich nicht mehr mit.
Also mal so:
1. Fall:
Ich möchte eine Abrechnung versenden.2. Fall:
ich möchte ein allgemeines Rundschreiben versenden (Absender ist noreply@...., dafür brauche ich eine spezielle Signatur).
Wie kann ich nun die Vorlagen wählen? Jedes Mal in den Einstellungen die globalen Vorlagen zu ändern, macht doch keinen Sinn. Gut wäre es, die Vorlagen direkt im "Versand-Dialog" auswählen zu können. Dort kann ich nur den E-Mail Absender sowie eine Signatur auswählen...okay, in dem Fall geht es nicht. Wieso weicht die Signatur bei Rundschreiben ab?
-
wäre ja eine Lösung. Geht aber nicht im Modul "Nutzer informieren"/"Dokumente versenden".
doch, mittlerweile schon - wir haben letzte Woche "individueller Mailversand" und "Nutzer:innen informieren" korrigiert, dass diese Bereiche auch die globale Vorlage verwenden.
-
der Branch ist schon seit einiger Zeit fertig, fällt aber durch Skalierungsprobleme durch die Deploymentbedingung. Ich denke aber, dass der Fix diese Woche dabei sein wird.
-
Wir lösen das so:
- in der Signatur des Mitarbeiters steht nur
"MFG Name"
- Die eigentliche Signatur hinterlegen wir im Standardmailtemplate (Projekte & Objekte -> Projekte -> Briefvorlage ändern - E-Mail)
ja, das ist auch eine sehr gute Idee. Die Standardsignatur, die am Anfang von facilioo generiert wird, ist auch einfach "mit freundlichen Grüßen Name". Unser internes Ticketsystem macht das auch genauso. Vielleicht schulen wir das zeitnah dann so als Standard.
-
danke für die ganzen Rückinfos. Nachdem heute die Versandoptimierung (siehe Dashboard morgen früh) deployed wird, schauen wir uns das Thema hier nochmal an.
-
ich mache einmal deutlich, wo das Problem genau liegt: welches Objekt hat nun wieviel Versandkosten?
BerlStra => 0,85 Cent
Haef6 => auch 0,85 Cent?
Oder BerlStra 42,5 Cent und Haef6 auch 42,5 Cent? (diesen Fall können wir aktuell nicht im Ansatz in der Datenbank abbilden)
Richtig extrem wird es, wenn man die Kosten nur in eine WEG packt. Werden z.B. 84 Seiten versendet, dann zahlt eine WEG alles, die andere nichts, obwohl viele Seiten zur anderen WEG gehören. Selbst wenn man das pro Seite abrechnet, stimmen die E-Post Kosten danach nicht, da sie gestaffelt sind (2x42 Seiten kosten 3,02+3,02, also 6,04 Euro, einmal 84 Seiten kosten 4,70 Euro). Das ist der Grund, warum wir das bisher nicht gebaut haben. Die Daten sind zwangsweise falsch und lösen Support Tickets und Eskalationen bis hin zu Schadenersatz gegen facilioo aus, egal wie wir es angehen.
Im Grunde liegt es an der Optimierung, die facilioo betreibt: sende Briefe nicht objektweise, sondern baisert auf Nutzer, damit keine Dopplungen entstehen und Kosten gesenkt werden. Dadurch entstehen diese Art von Problemen. Um die Kostenseite zu realisieren, müsste Rudi Müller im Beispiel oben zwei Briefe bekommen. Dieses Problem zieht sich auch durch alle Funktionen durch, egal ob Stapelversand oder normaler Versand.
Deswegen war meine Idee, dass wir die Informationen nutzerweise anzeigen und dahinter die Objekte anzeigen, die er gekauft hat. Wir verschieben zwar nur den schwarzen Peter von uns zum Kunden, aber der Kunde hat vielleicht mehr Infos, um die Kosten richtiger aufzuschlüsseln.
Ein Schlusssatz: wir könnten eine Option "für jede Einheit / Objekt bekommt ein Nutzer einen eigenen Brief" einbauen. In diesem Modus wäre das Feature hier möglich.
-
Grundsätzlich ist es großartig, wenn es hier weitergeht. Aber die Zielsetzung muss(!) unbedingt sein, eine praktikable - sprich möglichst einfache - Auswertung auf Objektebene erzeugen zu können. Wir rechnen die Druck- und Versandkosten ja ausschließlich und vollständig mit der WEG ab, die Verteilung von darin enthaltenen Individualkosten erfolgt dann gegebenenfalls über die jährliche Abrechnung. Wenn die geplante Funktion das bieten kann (Exportdatei für Objekt X mit Kosten/Seiten/Name Versandvorgang und Versanddatum), wenn vorher - entsprechend der "Duplikate zusammenführen"-Funktion - bei den recht wenigen "Mehrfachkunden" mit Einheiten in unterschiedlichen Liegenschaften eine einfache und einmalige manuelle Zuordnung der Versandvorgänge erfolgt, dann bringt es uns den gewünschten Mehrwert. Hatten sie sich das so vorgestellt?
das verstehe ich, allerdings kennt facilioo diese Daten nicht. Es ist nicht ganz klar, wie ein Brief, der über Nutzer informieren rausgesendet wurde, 3 Seiten lang ist und an einen Eigentümer ging, der in zwei WEGs eingetragen ist, berechnet werden soll (werden dann bei beiden Objekten 1,5 Seiten berechnet? Und wie ist der Preis dazu, Preise für halbe Seiten führt die Post nicht). Wir geben die Daten daher pro Objekt aus, ja. Allerdings kann hinter einem Nutzer noch ein Objekt stehen, dadurch wird das Ganze mehr bezogen auf die Nutzer eines Objekts. Wir müssen dann am Beispiel schauen, wie das zu trennen ist. Somit wären die Daten in facilioo aber erstmal faktisch richtig, nur evtl. schwer weiterzugeben, aus genau dem Grund von oben.
