Listenansicht filtern nach verknüpftem Datensatz

klemenb

Liebe Forumsmitglieder!
Vielleicht habe ich etwas übersehen, jedenfalls stehe ich etwas an.
Bin gerade dabei von Ninox zu R3 zu wechseln. Erste Versuche fallen vielversprechend aus.

Jedenfalls habe ich gerade eine kleine Zeiterfassung für meine Freundin erstellt.

Dabei sei gesagt, dass es in aller Linie Aufgaben gibt, die zuerst erstellt werden.
Danach können Arbeitszeiten erfasst werden und mit diesem Aufgaben verknüpft werden.

Das kann dann so aussehen:
Halskette entwerfen ("Aufgabe")

Vorentwurf ("Zeiterfassung 1")
Wachsmodell ("Zeiterfassung 2")
Guss und Nachbearbeitung ("Zeiterfassung 3")
Versand und Abrechnung ("Zeiterfassung 4")

Wenn ich auf das Formular zur Erstellung bzw. Bearbeitung von "Aufgaben" gehe, würde ich gerne in einer Listenansicht darunter sämtliche Zeiterfassungen aufgezählt sehen, die mit dieser Aufgabe verknüpft wurden.

Bis jetzt habe ich es nur geschafft, sämtliche Zeiterfassungsdatensätze anzuzeigen, was mich noch nicht zufriedenstellt.

Was mache ich falsch, wie muss ich vorgehen?

Ganz lieben Gruß und Chapeau ans R3 Team!

PS: Ich habe gesehen, dass in der Version 3.12 die PDF Funktion ausgebaut wird - weiß man schon, wann sie erscheinen soll?

gabriel

Hallo und willkommen im Forum, klemenb 🙂

Um die Filterung der Liste auf dem Aufgabenformular durchzuführen, muss es eine Beziehung zwischen aufgabe & tätigkeit geben. Das wäre klassischerweise ein n:1-Attribut auf der Relation der tätigkeit welches auf aufgabe zeigt. Ich vermute, dass es dieses schon gibt.

Wenn die Beziehung existiert, kann man diese als Filter im Listenfeld nutzen:

Filter: Attribut X (das n:1-Beziehungsattribut tätigkeit->aufgabe) = Aktuelles Formular->Datensatz-ID

Das funktioniert, weil du im Aufgabenformular einen konkreten aufgaben-Datensatz öffnest, auf welchen das Beziehungsattribut aller Tätigkeiten verweist.

Zu deiner Frage zum PDF-Feature: Du kannst jetzt schon per HTML komplexe PDFs erstellen - Organisationen nutzen es täglich bspw. um Rechnungen zu erzeuge.

Der neue grafische Editor ist mitten in der Entwicklung. Es wird sicher noch ein paar Monate dauern, bis REI3.12 mit allen geplanten Features dann öffentlich verfügbar sein wird.

klemenb

gabriel

Vielen Dank für deine rasche Antwort während der Festtage! Ich werde es gleich einmal versuchen.

Noch eine anderer Frage - gibt es eurerseits Ansätze für die Entwicklung einer Beispielanwendung, die strukturierte Rechnungen erzeugen kann (wie ZUGFeRD, e-Rechnung, etc.)?

gabriel

klemenb gibt es eurerseits Ansätze für die Entwicklung einer Beispielanwendung, die strukturierte Rechnungen erzeugen kann (wie ZUGFeRD, e-Rechnung, etc.)?

Mit unserer akt. Lösung (PDF-Generierung im Frontend per HTML) ist das, soweit ich weiß, nicht möglich; für reguläre PDF-Rechnungen findest du hier eine Beispiel-App.

Im Zuge der Entwicklung des visuellen PDF-Editors für REI3.12, haben wir uns das Thema angeschaut. Die Anzahl an brauchbaren Libraries, die wir für unsere Zwecke nutzen können, ist sehr eingeschränkt - und keine davon hat bisher direkten Support für PDF-3A und eingebundene Dateien, die wir für sowas wie ZUGFeRD bzw. e-Rechnung brauchen.

Es ist u. U. möglich, eine entsprechende XML-Datei nachträglich per Ghostscript in die erzeugte PDF einzubinden - erste Versuche sahen nicht schlecht aus. Diese Art von Lösung wäre aber bastelig und wir haben uns noch nicht entschieden, ob wir diesen Weg gehen möchten.

Die Idee von e-Rechnung ist, dass man sie digital verarbeitet. Eine e-Rechnung wird bspw. als XML machinell erzeugt und eingelesen - das kann man natürlich mit r3 machen. Diese XML zusätzlich bzw. stattdessen in ein PDF zu tun ist für die Erfüllung der rechtlichen Anforderungen nicht notwendig, soweit ich das auf dem Schirm habe - und erfordert mehr Speicherplatz. Es ist natürlich schön für die Menschenlesbarkeit und wenn man mit der Migration noch Schwierigkeiten hat - eigentlich ist der Sinn hinter e-Rechnung, dass man von solchen Dokumenten wegkommt.

klemenb

Für mich ist das Thema e-Rechnung noch ein Mysterium, welches ich noch nicht ganz durchblickt habe. Soweit ich aber verstanden habe, wären auch zwei separate Dokumente je Rechnung (1x Pdf, 1x XML Datei) möglich.

gabriel

klemenb
Der Grund für das ganze e-Invoice Thema ist, dass Rechnungen als Dokumente ineffizient sind - Menschen machen Fehler beim Erstellen aber auch beim Einlesen. Das kostet Kohle. Systeme sollen das automatisieren; Sprich Produktkatalog -> Angebot -> Rechnung -> Erzeugung & Versand von e-Invoice -> Einlesen auf der Gegenseite -> Matching mit Beauftragung - alles automatisch.

Das Gesetz, soweit ich es verstanden habe, will erreichen, dass man Dokumente gar nicht mehr braucht. Dementsprechend sind auch die Auflagen gesetzt: Ab Jahr X, muss man Rechnungen als e-Invoice verschicken und entgegennehmen. Es gibt Feinheiten, welche Organisationen ab wann wie viel machen muss - aber am Ende sollen Dokumente (aktuell fast immer PDFs) für Rechnungen sterben und nur noch e-Invoices versendet werden.

e-Inovice XMLs in PDFs einzubinden existiert, weil Menschen Veränderungen nicht mögen oder ihren IT-Systemen nicht vertrauen - scheint zumindest so für mich :)