Domino 9 und frühere Versionen > Entwicklung

Werte aus Spalten abfragen und prüfen, aber wie??

<< < (2/3) > >>

Belgarion:
ui is das kompliziert!

ich krieg das net hin....

Gibt es keine andere Möglichkeit?


Belgarion

Rob Green:
1. Weg:

1.1. Lege für jeden MA ein "Stammblatt" an.
Dieses Stammblatt identifizierst Du über dessen Personalnummer oder Name+Vorname+Geburtsdatum oder oder....

1.2. Dann legst Du einen weiteren Doctypus an, der als Response zum Stammblatt erstellt wird. In der Responsemaske kommt Dein Produkt 1-2-oder 3 und die ZE hinein

1.3. beim Speichern des Response-Docs zwingend über den Aktions-Button "Speichern" wird über
@SetDocField( Dokument-ID ; Feldname ; neuerWert )
und
@GetDocField( DokumentUNID ; Feldname )
gearbeitet.

GetDoc holt sich die Info aus dem Stammdoc des MA, SetDoc schreibt etwas rein. Und zwar was?

1. Info: aktl. Datum (damit die ZE nur zu einem Tag verrechnet werden)
2. Info: ZE
beide Infos kommen in 2 separate Felder.

also
_checktag:=@GetDocField( DokumentUNID des Stammdocs ; "Datum" );
_ZE:=@GetDocField( DokumentUNID des Stammdocs ; "ZE" );
und nun Check, ob die Infos von heute oder nicht von heute sind:
_weiche=@if(@today<>@texttotime(_checktag);"yes";"no");
wenn die neue ZE nicht auf den gleichen Tag fällt, wie die bisherigen Einträge im Stammdoc, dann...sonst...
_ZEAdd:=@if(_weiche:="yes";<FeldausaktuellemProduktDoc>;_ZE+<FeldausaktuellemProduktDoc>);
Kontrolle, ob ZE nun 6 Einheiten überschritten hat:
@if(_ZEAdd>6;@return(@prompt([ok];"ACHTUNG";"DU KAPITALISTENAUSBEUTER!!!!));@success);
wenn Test bestanden, nun neue ZE im Stammdoc setzen und ggbfl. neues Datum:
@if(_weiche="yes";@do(@SetDocField( Dokument-ID des Stammdocs ; Datum ; @today );@SetDocField( Dokument-ID des Stammdocs ; ZE ; _ZEAdd ));@SetDocField(Dokument-ID des Stammdocs ; ZE ; _ZEAdd ));
FileSave noch
und
FileCloseWindow

soweit einigermaßen klar, was ich meine?
Einzigstes Problem ist, wie Du an die DocID des Stammds rankommst. Nun, das lät sich regeln, entweder Du erstellt ein echtes Response zum MA Stammdoc, wenn Du eine neue ZE meldest (@SetDocField($Ref;"Field on Parent Doc";"Value") = $REF enthält die ID des Parents). Oder, Du liest über einen dblookup die ID des MA Docs aus.

Soweit das in Kurzform. Auch wenn die Produkte mit unterschiedlichen Laufzeiten nicht drin sind, ist das ja letztlich fast egal, da Du die Regel hast, nicht mehr als 6 ZE.  Man muß vorher nur einen kleinen Zwischenstep einlegen, da man nicht mehr das ZE Feld direkt auslesen kann. Einfach einen Multiplikator setzen...am besten als Schlüsselwortfeld mit Alias
Produkt 1 | 1
Produkt 2 | 2
Produkt 3 | 3
und da Notes den Alias liefert, diesen einfach per texttonumber in eine Zahl umwandeln, dann haste Deine effektive ZE für diesen gegebenen Auftrag.
also leicht variierte Formel zu oben:
_ZEAdd:=@if(_weiche="yes";@texttonumber(<FeldausaktuellemProduktDoc>);_ZE+@texttonumber(<FeldausaktuellemProduktDoc>));

Belgarion:
Hi,

hab 3 Probleme:

1. Wenn ich mit $REF das Stammdokument abfrage, dann sagt er mit keine 32-Zeichen Hex-Code (oder so). Wie kann ich das beheben? Habe das Dokument Mitarbeiter als Dokument und das Dok Auftrag als Antwort.

2. Was passiert wenn ein Auftrag vor Fertigstellung storniert wird? Kann diese Formel das beachten?

3. Sehe ich das richtig das ich für jeden Auftrag dann 2 Dokumente anlegen muß? Also außer dem Stammblatt des Mitarbeiters? Oder wird in den beiden Feldern alle Daten gespeichert. Ich dachte immer nur ein Wert...


MfG Belgarion

Belgarion:
Mein Code sieht wie folgt aus:


_checktag:=@GetDocField($Ref; "Datum" );
_ZE:=@GetDocField( $Ref; "ZE" );
_weiche=@If(@Today!=@TextToTime(_checktag);"yes";"no");
_ZEAdd:=@If(_weiche="yes";Erg;_ZE+Erg);
@If(_ZEAdd>6;@Return(@Prompt([OK];"ACHTUNG";"DU KAPITALISTENAUSBEUTER!!!!"));@Success);
@If(_weiche="yes";@Do(@SetDocField( $REF; Datum ; @Today );@SetDocField( $REF ; ZE ; _ZEAdd ));@SetDocField($REF ; ZE ; _ZEAdd ))


Und gibt beschriebenen Fehler aus.

Belgarion

Rob Green:
1. Wenn ich mit $REF das Stammdokument abfrage, dann sagt er mit keine 32-Zeichen Hex-Code (oder so). Wie kann ich das beheben? Habe das Dokument Mitarbeiter als Dokument und das Dok Auftrag als Antwort.

= solange das response nicht gespeichert wurde, existiert kein $REF. Daher im Parent ein hidden Field einrichten, daß dessen Documentuniqueid speichert. Dann im Response bei Eigenschaften "Formeln übernehmen Werte..." anhaken. Dazu ein hidden Field, das als Vorgabewert oder Berechnet beim Anlegen das Feld mit der ID namentlich aus dem Parent anspricht. SO hast Du von Anfang an die Info, die auch $REF enthält. Nämlich die ID des Parents wie gesagt.
Dann einfach eine Formel hinzufügen:
_ID:=@if(@isvalaible($REF);$REF;FeldausParent)
und
@getdocfield(_ID.....)
Das ist deswegen praktisch, da sich ja die $REF durch Kopieren der DB verändert und wenn Du nur das selbst berechnete Feld ansprichst, hast Du einen veralteten Bezug und mußt händisch die Bezüge wiederherstellen.
Das bezieht sich natürlich nur auf gespeicherte ZE Meldungen, wenn die warum auch immer - weil Pferde eben k... - neu berechnet werden müßten.


2. Was passiert wenn ein Auftrag vor Fertigstellung storniert wird? Kann diese Formel das beachten?
schau mal in der Help nach @isdocbeingsaved.
Das kannst Du als Eintrittsbedingung für die Ausführung der Formel nehmen. Nur wenn gespeichert wird, triggert die ganze Formel los. Mit @return brichst Du ab.
Also:
@if(@isdocbeingsaved;@success;@return(void));
und Rest der Formel


3. Sehe ich das richtig das ich für jeden Auftrag dann 2 Dokumente anlegen muß? Also außer dem Stammblatt des Mitarbeiters? Oder wird in den beiden Feldern alle Daten gespeichert. Ich dachte immer nur ein Wert...

Das war wie gesagt ein Weg von vielen möglichen Wegen. Welchen Weg Du wählst, hängt von dem exakten Procedere ab, die Deine User durchgehen und welcher Weg Dir am schnellsten, stabilsten, ... erscheint. Mußt schon selbst wissen. Momentan hast Du die Mitarbeiterdocs (als quelle für die aktuelle ZE Berechnung) und die ZE Meldungen, also 2 Doctypen.
Ich hätte nur 1 Doc genommen und dort die Berechnungen ganz simpel vorgenommen.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete