Moin planox. , 

ich war so frei mich ebenfalls an deiner Formel zu bedienen und muss sagen, dass diese mir schon eine Menge arbeitet erspart hat! 
Allerdings komme ich bei kleinen Abwandlungen nicht weiter... Zum einen habe ich 2 Tabellen mit Rechnungspositionen; bei der ersten funktioniert die Schleife wunderbar und kopiert die Positionen als Minus-Positionen in die neue "Storno-Rechnung". Bei der zweiten Tabelle funktioniert das leider nicht. 

Außerdem würde ich bei der zu stornierenden Rechnung in dem Zuge auch gerne ein Storno-Datum eintragen und den Status auf "storniert" ändern, wenn ich das aber in die Formel einbaue, funktioniert der Rest nicht mehr

Hast du vielleicht noch einen guten Tipp für mich? 

Hier mal mein kläglicher Versuch, meine Wünsche in die bis dato gut funktionierende Formel zu integrieren. 

let Antwort := dialog("Storno", "Wollen Sie diese Rechnung wirklich stornieren?", ["Ja", "Nein"]);
if substr(Antwort, 0, 1) = "J" then
            let oldRe := this;
            let newRe := duplicate(this);
            oldRe.(Status := "Storniert");
            oldRe.('Storno Datum' := today());
            newRe.('RG-Nr.' := last(((select Rechnung) order by 'RG-Nr.').'RG-Nr.') + 1);
            newRe.('RG-Datum' := today());
            newRe.(Status := "Stornobeleg");
            newRe.(Bezug := "zu Rechnung " + oldRe.'RG-Nr.' + " vom " + oldRe.'RG-Datum');
            for i in newRe.'A. Zeitaufwand (§§8,9)' do
                        i.(Menge := i.Menge * -1);
                        for p in newRe.'B. Auslagen- und Aufwendungsersatz (§§5-7,9)' do
                                   p.(Menge := p.Menge * -1)
                        end
            end;
            openRecord(newRe)
end

Gruß, Ines

Ines  

Hallo Ines, es freut mich, dass dir mein Script geholfen hat. Zu deinem aktuellen Problem:

Wenn ich es richtig sehe, dann sind 'A. Zeitaufwand (§§8,9)' und 'B. Auslagen- und Aufwendungsersatz (§§5-7,9)' quasi "gleichberechtigte" Untertabellen von 'Rechnungen'. Sie müssten dann auch auf die gleiche Weise abgearbeitet werden. Also jeweils in einer eigenen Schleife. Ich würde es mal so versuchen:

[...]
   for i in newRe.'A. Zeitaufwand (§§8,9)' do
      i.(Menge := i.Menge * -1)
   end;
   for p in newRe.'B. Auslagen- und Aufwendungsersatz (§§5-7,9)' do
      p.(Menge := p.Menge * -1)
   end;
   openRecord(newRe)
end

planox. pro 

Genau, das sind zwei gleichberechtigte Tabellen. Trotz der kleinen Änderungen, funktioniert die Formel nur bei 'A. Zeitaufwand (§§8,9)'. Selbst wenn ich diese Schleife lösche und nur die für die zweite Tabelle 'B. Auslagen- und Aufwendungsersatz (§§5-7,9)' laufen lassen, funktioniert sie nicht mehr. 
Das ist doch ziemlich merkwürdig. 

Ines 

Sehr merkwürdig, in der Tat. Ich habe die Konstellation gerade auf die Schnelle mal in einfacher Form nachgestellt. Und bei mir funktioniert es jetzt gar nicht, weder mit TabelleA noch mit TabelleB. Jedenfalls nicht, wenn ich auf die ID in 'newRE' Bezug nehme:

newRE.PositionenA.(Menge := Menge * -1);

Bei direkter Adressierung im Datensatz hingegen funktioniert es:

PositionenA.(Menge := Menge * -1);

Mit for-Schleife genau dasselbe. Ich bin im Moment offen gestanden auch etwas ratlos. Vielleicht habe ich gerade Tomaten auf den Augen und übersehe irgendwas. Kommt ja vor. Muss ich mir später noch mal in Ruhe ansehen.

Ines Manchmal dauert's etwas länger (das Alter, die Hitze) ...

Wenn man den Wert von 'Menge' in eine Variable schreibt und die Rechenoperation dann mit dieser ausführt, funktioniert's:

for i in newRE.'A. Zeitaufwand (§§8,9)' do
    let myM := i.Menge;
    i.(Menge := myM * -1)
end;
for i in newRE.'B. Auslagen- und Aufwendungsersatz (§§5-7,9)' do
    let myM := i.Menge;
    i.(Menge := myM * -1)
end;

Warum das andere nicht funktioniert hat, bzw. bei dir nur mit einer Tabelle, kann ich leider nicht genau sagen. Dem muss ich noch mal auf den Grund gehen. Aber wie gesagt: Der obige Code sollte eigentlich auch bei dir sicher funktionieren.

Guten Morgen planox. ,
erstmal vielen Dank für deinen Einsatz und deine Mühe. 

Es ist wirklich wie verhext, aber es funktioniert nach wie vor nur mit der ersten Tabelle. 
Grundsätzlich ist das ja nicht wahnsinnig schlimm und ich muss die Daten dann eben händisch nachtragen, aber verstehen tue ich das nicht... 
Hast du vielleicht aber noch eine Idee, wie ich gleichzeitig in dem "alten Datensatz" 2 Änderungen vornehmen kann? Ich würde gerne den Status (einfaches Auswahlfeld) und das Storno-Datum eintragen. 
Wenn ich das relativ an den Anfang der Formel setze, greift diese nicht mehr bezüglich des neuen Datensatzes.

Wenn ich das nach den beiden for Schleifen einsetze, passiert gar nichts... 
Vielleicht liegt es ja bei mir auch nur an der Hitze...

Ines  "Wie verhext" trifft es gut ...

Ich sehe da keinen Fehler. Das, was du erreichen willst, sollte mit dem Code auch funktionieren. Sowohl die Zuweisungen in 'oldRe' als auch die Minus-Berechnungen in den 'newRe'-Untertabellen. Und in meinem nachgestellten Szenario funktioniert es auch.

Ich würde die oldRe-Zuweisungen für Status und Storno-Datum zwar vor dem "duplicate" platzieren, aber nur der Übersichtlichkeit halber. Technisch spielt die Reihenfolge keine Rolle. Wenn die Variablen mit den IDs einmal definiert sind, kann man darüber innerhalb des Scriptes jederzeit auf die betreffenden Datensätze zugreifen.

Insofern habe ich so aus der Ferne gerade keine Idee mehr, was man noch probieren könnte. Um der möglichen Ursache des Problems evtl. auf die Spur zu kommen, müsste man mal direkt in die Datenbank schauen. Vielleicht kannst du ja eine Kopie mit ein paar Demodaten machen und sie hier hochladen. Oder mir per E-Mail an post@planox.pro zukommen lassen Dann schaue ich gerne mal rein.

Ansonsten bliebe nur der Support. Es sei denn, jemand anderes, der hier mitliest, hätte noch eine Idee.

planox. proInes Auch ich habe in diesem Fall keine Lösung, aber manchmal hat mir die zeilenweise Analyse mit debugValueInfo() geholfen einem Fehler auf die Spur zu kommen. Vielleicht erkennt man dann, wo fehlerhafte Bedingungen bestehen, die dann weitergegeben werden. Das Array aus einer Schleife kann auch einzeln geprüft werden z.B. debugValueInfo(newRe.'A. Zeitaufwand (§§8,9)' . Aber ominös bleibt es allemmal. Oder Scripte funktionieren doch temperaturabhängig... Gruß Mirko

Mirko Hallo Mirko, danke für deinen Tipp! Ich bin dem Fehler aber schon auf der Spur. Auflösung in Kürze.

planox. pro Mirko Vielen Dank euch beiden für die Unterstützung! Ich bin wirklich gespannt auf die Lösung. 

Ines hatte mir ihre Datenbank zukommen lassen. Und so ließ sich die Ursache des Problems recht schnell finden: Es waren nämlich nicht wie angegeben zwei "gleichberechtigte Untertabellen ", sondern lediglich zwei unterschiedlich benannte Verknüpfungen auf ein und dieselbe Untertabelle namens 'Positionen'. Das ist natürlich ein großer Unterschied.

Wobei Ninox es ja zulässt, dass man eine Tabelle mehrfach mit einer anderen verknüpft. Insofern hätte man durchaus erwarten können, dass dies dann auch beim duplicate() berücksichtigt wird. Es ist aber so, dass in einem solchen Fall - auch anders als auf Rückfrage angegeben - die zweite Verknüpfung offenbar gar nicht in den duplizierten Rechnungs-Datensatz übernommen wird (gilt auch für die "Duplizieren"-Schaltfläche in der Ninox-Menüleiste oben rechts) . Man kann das m. E. in gewisser Weise durchaus als Bug bezeichnen. Der wahrscheinlich bisher nur noch nicht aufgefallen war, weil solche Konstellationen eher selten vorkommen.

Jedenfalls: Wenn die Verknüpfung leer ist, gibt es natürlich auch keine Mengen, die ins Minus gesetzt werden könnten. Die zweite for-Schleife für Tabelle 'B.' lief also praktisch ins Leere.

Nahe liegende Lösung: Aus der einen Untertabelle einfach zwei machen. Zwillinge quasi, mit denselben Datenfeldern. Für den Nutzer macht das keinen Unterschied, Ablauf und Bedienung bleiben exakt gleich. Nur, dass die Positionen dann eben in zwei verschiedenen Untertabellen gespeichert sind. Was u. U. ja sogar von Vorteil sein kann (gefilterte Auswahl der Artikel/Leistungen). Ob es auch praktische Nachteile hat, hängt wohl vom Einzelfall ab. Ich sehe aber erst mal keine.

Man könnte aber wohl auch bei einer Untertabelle bleiben und in dieser ein Merkmal zur Unterscheidung zwischen A- und B-Positionen einbauen (z. B. mittels Auswahlfeld). Dann ließen sich die Typen innerhalb der einen (1) Verknüpfung unterscheiden. Im Drucklayout könnte man die Verknüpfung dann wieder zwei mal abbilden und jeweils entsprechend filtern, so dass in der einen nur Einträge vom Typ A angezeigt würden und in der anderen nur Typ B.

So oder so: Da es in den Positionen aktuell offenbar noch kein Merkmal zur Unterscheidung nach A oder B gibt, dürfte eine nachträgliche, automatisierte Zuordnung der betreffenden, bereits vorhandenen Datensätze schwierig werden. Man müsste dazu wohl ein Script erstellen, das prüft, ob die Verknüpfung in A oder B vorgenommen wurde und ggf. neu verknüpfen.

PS: Ach so, die Zuweisung von Status = "Storniert" und Storno-Datum in der alten Rechnung hat einwandfrei funktioniert. Keine Ahnung, warum das bei Ines nicht geklappt hat. Vielleicht war das aber auch ein Missverständnis.

PPS: Meine Hinweise auf falsche Angaben bei der Problembeschreibung sind nicht als Vorwurf an Ines zu verstehen, sondern als Hinweis auf die entscheidende Bedeutung der Antworten auf Rückfragen. Anders gesagt: Je genauer der Input, desto größer die Wahrscheinlichkeit, dass ein Problem zeitnah gelöst werden kann.

planox. pro Vielen Dank für deine ausführliche Beschreibung und sorry für die missverständliche Problembeschreibung. 
Ich hab jetzt mich für deinen ersten Lösungsvorschlag entschieden und eine zweite Untertabelle erstellt. Damit klappt es jetzt auch!!
Allerdings habe ich nach wie vor das Problem, wenn ich die Änderungen für den "alten Datensatz" in die Formel einbaue, wird dieser zwar wie gewünscht geändert, in dem neuen Datensatz erscheint dann aber nur noch die neue Rechnungsnummer und alle anderen Felder bleiben leer. 

Ines Hm ... Poste doch bitte noch mal das Script, so wie es jetzt ist.

planox. pro bei diesem Script, wird der Status in dem alten Datensatz auf "Storniert" gesetzt und ein Storno Datum eingetragen. Allerdings wird danach nur ein neuer Datensatz geöffnet, die Rechnungsnummer eingetragen und das wars, alle anderen Felder (Kunde, Projekt, Rechnungspositionen, Datum, etc.) bleiben leer.

bei diesem Script bleibt der alte Datensatz eben unverändert, dafür funktioniert das kopieren in den neuen Datensatz mit den auf Minus gesetzten Positionen hervorragend. 

Ines Ah, okay. Schau doch bitte mal, ob bei den Feldern 'Status' und/oder 'Storno Datum' Änderungstrigger hinterlegt sind, und entferne sie testweise. Danach probiere es noch mal mit dem oberen Script. Falls es dann funktioniert, solltest du prüfen, ob die Trigger tatsächlich erforderlich sind bzw. wie die entsprechenden Aktionen alternativ ausgeführt werden könnten (z. B. im Storno-Script).

planox. pro Perfekt, das war's!! Ich hatte noch einen Änderungstrigger für den Schreibschutz hinterlegt. Den habe ich jetzt einfach in das Script mit eingebaut und es läuft!!

Nochmal vielen vielen Dank! Das hätte ich alleine so nie hinbekommen!