Beiträge von Tobias Bambullis

    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.

    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 bereitstellen

    Bitte 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.

    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?

    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.

    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.

    Ich habe mir vorgenommen, in diesem Jahr am Thema dran zu bleiben. Denn der Leidensdruck nimmt bei solchen Dauerthemen mit der Zeit nicht ab....
    Tobias Bambullis Bekommt Facilioo das jetzt noch (kurzfristig) irgendwie hin oder muss ich weiterhin parallel eine Excel-Tabelle führen?

    wir werden die Lösung, die ich oben beschrieben habe, zeitnah in die Sprints bringen

    Okay... "Objekt" bedeutet bei uns Liegenschaft und nicht Einheit oder Wohnung.
    Und bei mehreren Einheiten innerhalb einer WEG erhält der Nutzer natürlich nur einen Umschlag. Das läuft aber bereits über die Stapel, wo der Nutzer auch nur einmal im "Anschreibenstapel" vorkommt und ihm dann die zusätzlichen Dokumente aus den "Abrechnungsstapeln" zugeordnet werden. Aber auch hier liegt die exakte Information über die Anzahl der Seiten des Empfängers ja noch vor dem Versandvorgang vor.

    E-Post über Nutzerinfo ist z.B. ein Szenario. Wir können das ganze nicht halb lösen, da es sonst zu Fehlern kommen wird, in denen Zahlen nicht stimmen. Pro Nutzer können wir es anzeigen (und in Klammern dahinter können wir die Objekte anzeigen und diese alphabetisch sortieren). Dann würde die facilioo Ansicht stimmen und der Hausverwalter müsste entscheiden, zu welchem Objekt er die Kosten zählt. Stehen z.B. zwei Liegenschaften hinter dem Nutzer, so müsste man für sich selbst eine Verrechnung bestimmen. Vielleicht funktioniert das so für Sie?

    ....nach 3 (!) Jahren immer noch keine brauchbare E-Post-Auswertung ist wirklich nicht nachvollziehbar.
    Es kann doch kein großes Problem sein, die paar Daten sinnvoll strukturiert in eine CSV-Datei zu packen. Bitte jetzt umgehend umsetzen.

    das ist leider ein riesiges Problem; wir können aktuell nicht genau bestimmen, welche E-Post Kosten auf ein Objekt fallen, da es Nutzer gibt, die Sendungen für zwei Objekte erhalten, in einem Brief. Das tritt auch ziemlich häufig auf. Eine Splittung an der Stelle verlangt ein ganz anderes Speichern von diesen Informationen. Daher liegt hinter dieser Aufgabe 1-2 Monate Arbeitszeit für einen Mitarbeiter. Eine so große Lücke ist noch nicht entstanden, aber wir haben das Thema auf dem Schirm, sobald diese Zeit am Stück frei wird.

    Pro Nutzer wäre es natürlich einfacher - wenn das reichen würde, könnten wir dies in den Sprint einplanen (dann haben Sie Recht, dann sind wir bei 3-5 Tagen Entwicklungszeit)