Hallo, um eine Lösung zu finden müsste man erst mal das Problem verstehen. Dazu wäre (zumindest in meinem Fall) etwas mehr Kontext erforderlich.

 

Wie sind die Daten strukturiert? Wo soll wann welches Feld aus welcher Tabelle automatisch abgefragt werden?

Danke für die Erläuterung. Was mir persönlich zum Verständnis noch fehlt, sind Informationen zur Datenstruktur. Reden wir über eine einzige Tabelle, in der bspw. jeweils Gewerk, Rechnungsnummer, Datum und Betrag gespeichert werden? Oder gibt es verschiedene Tabellen, die miteinander verknüpft sind (z. B. eine für Rechnungen und eine für Zahlungen)? 

 

Last not least: Wie sieht der Code aus, der die Fehlermeldung erzeugt, und wann wird er wo ausgeführt (Trigger, Funktionsfeld, Schaltfläche)?

 

Aber okay, gehen wir mal beispielhaft von einer einzigen Tabelle namens RECHNUNGEN mit folgenden (relevanten) Datenfeldern und Summenbildung nach Gewerk aus:

 

Gewerk (Auswahlfeld; z.B.: Dach | Sanitär | Elektro | ... o.ä.)

Bereits gezahlt (Funktionsfeld)

RechNr (Textfeld)

RechDatum (Datumsfeld)

Betrag (Zahlenfeld)

Status (Auswahlfeld; z.B.: eingegangen | geprüft | bezahlt | ... o.ä.)

 

Dann könnte man beim Erfassen einer neuen Rechnung (= Anlegen eines neuen Datensatzes) die Summe früherer Zahlungen zum jeweiligen Gewerk im Funktionsfeld 'Bereits gezahlt' wie folgt ermitteln:

 

let myGewerk := Gewerk;
let myNr := number(Nr);
sum((select Rechnungen where Gewerk = myGewerk and number(Nr) < myNr).Betrag)

 

Der Filter ließe sich auch noch um ein weiteres Kriterium wie den Status erweitern:

 

let myGewerk := Gewerk;
let myNr := number(Nr);
sum((select Rechnungen where Gewerk = myGewerk and number(Nr) < myNr and text(Status) =  "bezahlt").Betrag)

 

Nur so als Idee. Das Beispiel ist jetzt natürlich von mir konstruiert, aber vielleicht hilft es ja trotzdem auf die Sprünge. Ansonsten einfach noch mal konkret nachfragen.

Auf die Schnelle: Ursache des Syntaxfehlers in Zeile 3 ist sehr wahrscheinlich das Komma. Und auch die Klammern sind augenscheinlich nicht richtig gesetzt. Ich sehe da zwei öffnende und drei schließende. Abgesehen von den sonstigen Angaben sollte die Grundstruktur der "sum"-Funktione so aussehen:

 

sum((select TABELLE where BEDINGUNG).DATENFELD)

 

Den Rest schaue ich mir später noch mal genauer an (sofern nicht vorher jemand anderes tut und das Problem löst).

Alsooo ... Das ist für mich echt schwierig zu interpretieren, aber wenn ich mal davon ausgehe, dass in der Tabelle RECHNUNG im Funktionsfeld 'Bereits gezahlt' automatisch alle vorherigen Werte des Feldes 'Forderung' zu diesem Auftragnehmer summiert werden sollen, dann könnte die Formel im Feld 'Bereits gezahlt' so aussehen:

 

let myNr := number(Nr);
let myAN := Auftrag.Auftragnehmer;
sum((select Rechnung where Auftrag.Auftragnehmer = myAN and number(Nr) < myNr).Forderung)

 

Die verschiedenen Feld-Varianten für Netto, Brutto usw. habe jetzt mal außen vor gelassen, das sie für die Logik keine Rolle spielen. Man müsste ggf. also in der sum()-Funktion den Feldnamen 'Forderung' noch durch den Namen des tatsächlich zu summierenden Feldes austauschen (z. B. 'Bezahlt inkl. Skonto [brutto] ').

 

Grundsätzlich würde ich empfehlen, Feldnamen nicht zuuu lang zu machen (Alternativen zur Erläuterung: Die Gestaltungslemente "Überschrift" und "Freitext") und Felder gleichen Inhalts auch gleich zu benennen ("Auftragnehmer" vs. "Auftrag"). Sonst blickt man selbst irgendwann nicht mehr durch, geschweige denn andere.

Prinzipiell sieht die Formel für mich richtig aus. Allerdings scheint 'Rechnungsbetrag [netto]' selbst ein Formelfeld zu sein und zeigt im Screenshot ein leeres Ergebnisfeld. Wie sieht denn die Formel/der Code in diesem Feld aus? Vielleicht steht da wieder eine Verknüpfung drin, die Ninox in der Summe überfordert?

 

Versuche doch mal testweise die sum()-Funktion mit irgend einem anderen Feld, in das du direkt einen Wert geschrieben hast, z. B. 'Forderung [netto]'. Nur um zu sehen, ob es an dem Bezugsfeld liegt oder ob der obige Code generell falsch ist.

 

Ansonsten bin ich da jetzt auch überfragt. Vielleicht hat noch jemand anders eine Idee oder sieht was, was ich nicht sehe?

Okay, dann sind wir ja schon mal einen Schritt weiter. Offen gestanden blicke ich aber auch bei den unzähligen Berechnungsfeldern ähnlicher Bedeutung nicht mehr ganz durch. Kann es sein, dass es dir ähnlich geht?

 

Ursprünglich ging es ja darum, beim Anlegen einer neuen Rechnung alle bisherigen Zahlungen(!) an diesen Auftragnehmer zu summieren. Dazu muss man halt schauen, wo, also in in welcher Tabelle und in welchem Feld dieser zu summierende Zahlungsbetrag steht.

 

Das betreffende Feld kann zwar prinzipiell auch ein Berechnungsfeld sein, aber wenn dessen Formel 

 

'Rechnungsbetrag geprüft [netto]' - 'Bereits gezahlt [netto]'

 

lautet, dann kommen mir starke Zweifel, dass das Ergebnis für die eigentliche Berechnung der Gesamtsumme aller bisherigen Zahlungen überhaupt relevant sein kann.

 

Nehmen wir an, 'Rechnungsbetrag geprüft' wäre 1000 Euro, 'Bereits gezahlt' 800 Euro. Dann wäre das Ergebnis der Formel 200 Euro. Und diese 200 würden auch zur Summierung herangezogen. Das kann ja nicht richtig sein. Oder soll doch ganz was anderes berechnet werden?

 

Kurzum: Ich sehe hier weniger ein technisches Problem, sondern mehr ein inhaltlich-strukturelles. Vielleicht sollte man das ganze Konstrukt noch mal sachlich überdenken, alles rauschmeißen, was nicht unbedingt erforderlich ist, und dann erst mal die Basisfunktionalität aufbauen. Mit eindeutigen Feldnamen und klarer Struktur. Erweitern und verschönern kann man hinterher immer noch.

 

Mehr kann ich im Moment leider nicht dazu sagen, tut mir leid. Aber vielleicht wäre es sinnvoll, das Problem mal "live" im Webinar zu behandeln. Das findet immer mittwochs ab 16 Uhr statt. Anmelden kann man sich hier:

https://zoom.us/webinar/register/WN_Asq34-biQxGS93h03BmyfQ