[Gelöst] Verkauf an Kontaktnr. - Auswahlfenster

Hallo Forum!

Ich möchte gern folgendes realisieren.
Beim Anlegen eines Auftrages wird automatisch das Feld "Verkauf an Kontaktnr.", mit dem, mit dem Debitor in Verbindung stehenden Unternehmenskontakt vorbelegt. Nachträglich kann man das Feld dann ändern.
Ich möchte gern dass, nach dem die "Verkauf-an Deb.-Nr." vom User ausgewählt wurde, die Kontaktübersicht aufgeht und man dann einen von den zum Debitor gehörenden Kontakten auswählen muss. Es soll also nicht standardmäßig vorbelegt werden.
Ich hab an sämtlichen Stellen versucht, das Kontaktübersichtsfenster zu plazieren, aber so richtig will das nicht laufen. Einmal sind Runmodal-Aufrufe in Schreibtransaktionen nicht erlaubt, ein anderes Mal wird gleich Rechnung an Kontaktnr. geändert ohne mich zu fragen usw...
Ich hab das Gefühl ich drehe mich im Kreis. Vielleicht habt ihr eine Idee.

Gruß und Danke.

Zuletzt geändert von svr am 29. September 2009 11:29, insgesamt 1-mal geändert.

Nur so´ne Idee:
Schau mal auf den Validate-Trigger des Feldes "Verkauf-an Deb.-Nr." im Tabellen-Design nach.
Da könnte ich den Code dazu vermuten. Den auskommentieren und einen "manuellen"-Lookup hinzufügen.

Hallo Mikka,
Danke für deinen Tip.
An der Stelle hab ich mal nachgesehen. Ich will auch nicht zuviel vom Standard auskommentieren. Meine nächste Idee wäre das ganze standardmäßig so vorbelegen zu lassen, wie Navision das eben macht: Auftragsnummer ziehen, Verkauf an Debitornr. eintragen (dabei von mir aus auch den Kontakt vorbelegen) und danach sollte dann das Auswahlfenster, so wie im OnLook-Up Trigger des Felders "Verkauf an Kontaktnr.", kommen. Aber irgendwie klappt das noch nicht so ganz. Ich finde nicht die passende Stelle wo praktisch das "Verkauf an Debitornr." - Eintragen und Validieren abgeschlossen ist. Am Ende des "Verkauf an Debitornr."-Triggers kann ich das nicht eintragen, da kommt dann die Meldung das der Form-Runmodal Aufruf während einer Schreibtransaktion nicht möglich ist.

Setz deine Funktion doch einfach auf die Form->Feld "Verkauf an Deb.-Nr."->OnAfterValidate. Dann wird "Verkauf an Kontaktnr." zwar erst einmal durch den Standard belegt, aber immerhin hast du es von selbigem fein getrennt.

Am Ende des "Verkauf an Debitornr."-Triggers kann ich das nicht eintragen, da kommt dann die Meldung das der Form-Runmodal Aufruf während einer Schreibtransaktion nicht möglich ist.

Ja die Meldung ist iriitierend, aber logisch (habe ich gestern nicht vor "den Augen" gehabt). Wenn der Kontakt ausgewählt wurde und der "Verkauf an Debitornr" Validiert wird, gibt es einen neuen Aufruf der Auswahlform "Kontaktübersicht" (dabei ist der bestehende Prozess noch garnicht beendet) -->Das macht wenig Sinn

Warum eigentlich erst einen Debitor auswählen, und dann einen Kontak wählen (der das Feld mit einem evtl. neuen Debitoren Validiert)?
Wäre eine direkte Auswahl über Kontakt nicht viel besser?

Ich fand die Idee richtig gut, allerdings ist der Vorschlag abgelehnt worden, weil leider nicht praktikabel.
Erst muss der Debitor her -> dann dazu die Kontakte auswählen.
Das so eine "simple" Anforderung, so ein Kopfzerbrechen bereitet, hätte ich nicht gedacht.

Ich frag mich, was gegen meine Lösung einzuwenden ist

Ich frag mich, was gegen meine Lösung einzuwenden ist

Ich habe diese nicht gesehen, klar geht das.

Finde ich aber total unpraktisch vom Arbeitsablauf.
Erst Form A. öffnen, auswählen, dann Form B. nochmal auswählen.
(Wenn der Mitarbeiter z.B.200 Aufträge am Tag eingibt, muß er 400 Auswahlen treffen)

Ich würde folgendes Vorschagen (zwei Fliegen auf einen Streich):
1. Form 5061 um die Felder "Nr." und "Kontaktname" erweitern
2. Filter auf Debitor setzten, wenn Form im Lookup geöffnet wird
3. Diese Form im Auftrag als Lookup im Feld "Verk.an Kontaknr." hinterlegen

Falls Felder fehlen (z.B. aus Debitor) einfach hinzufügen, oder alternativ eine neue Form erstellen.

Eine andere Idee die ich hätte währe:
Die Debitorkarte zu modifizieren, in dem "Ihr" eine Subform "Kontakte" angehängt wird. Wenn im Auftrag ein Kontakt doppelgeklickt wird, werde die entsprechenden Daten übernommen. (Ich wüste zwar noch nicht wie ich die Auswahl der Subform in den Auftrag bekomme, ab ist ja halt auch ne Idee!)

Erst Form A. öffnen, auswählen, dann Form B. nochmal auswählen.

Form B öffnet sich automatisch, menno

Erst Form A. öffnen, auswählen, dann Form B. nochmal auswählen.

Form B öffnet sich automatisch, menno

Das öffnen der Form allein finde ich schon überflüssig, und noch schlimmer das erneute auswählen.

Wenn ich an meine Kollgen in den bisherigen Firmen denke, wurde oft darüber gestöhnt, wieviele Fenster in Navision "auf und zu gehen" (das ist unproduktiv und zerrt an den Nerven)

Kennst Du Warenausgang und Kommissionierung? Das schlecht umgesetzt von MS und nicht wirklich praxisnah.
(Wäre ich noch in der letzten Firma, hätte ich den Kollegen eine 22" Monitor gegeben und die Forms "verheiratet", das alles in einer Form bearbeitet werden kann.)

Zuerst einen Debitor wählen muss ja wohl sein, und dann noch den Kontakt anklicken - nunja, wem das zu viel ist

Außerdem besteht mein Weg aus ca. 5 Zeilen und nicht aus mehreren angepassten Forms. Es sollte doch nah am Standard sein, oder hab ich mir das nu falsch gemerkt?

Hallo,

gebe ich auch mal meinen Senf dazu.

Mein Vorschlag:

• Normale Debitorenauswahl.
• im OnAfterValidate der Debitorennr. auf dem Form wird der Lookop der Verk. an. Kontaktnr. eingebaut.
• zusätzlich kann man noch prüfen, ob es nur einen Kontakt zu Debitor gibt und das Kontakt- Form unterdrücken.

Gruß, Fiddi

Womit Fiddi und ich schon mal 2:1 führen. Spielt noch wer mit?

Womit Fiddi und ich schon mal 2:1 führen. Spielt noch wer mit?

Ich, ich
Durch eine Unaufmerksamkeit des Torwarts ehöhe ich auf 3:1.

Durch eine Unaufmerksamkeit des Torwarts ehöhe ich auf 3:1.

Ich fand den von hier aus unhaltbar

Ok, ich merke schon Freitag nachmittag und keine will meine super Ideen haben
(Trotzdem ist es Käse, wie teilweise in Nav gearbeitet werden mus. Natürlich gibt es auch ganz viel was toll ist, sonst wäre ich ja kein Nav Fan)


BTW: Der Schiri hat ein Abseits und ein Foul gesehen (Fiddi hat dazwischen gegrätscht und Natalie hat verbotener Weise den Platz betreten *fg* )
Es ist nach einem 1:1Spielende und die Gäste gehen nach Hause
In dem Sinne Euch allen ein schönes WE

Es ist nach einem 1:1Spielende und die Gäste gehen nach Hause

Du hast die Verlängerung verpasst

Zuerst einen Debitor wählen muss ja wohl sein, und dann noch den Kontakt anklicken - nunja, wem das zu viel ist

Debitor wählen muss ja wohl sein?
Der Debitor würde in einem "Zuge" mit dem Kontakt ausgewählt werden (also wäre die Vorauswahl überflüssig).

Wem das zuviel ist?
-->Ich gehe davon aus, das du bei Euch schon in (fast) jeder Abteilung mehrere Tage mitgearbeitet hast. Dann wirst du wissen wie wichtig gut durchdachte Lösungen sind (bzw. viele Missstände entdeckt haben, die gelöst werden wollen).
Und Ja, klar gehen andere Lösungen auch (ich zeige hier nur meine persönliche Meinung. Ist ja hier schließlich kein Wettbewerb, oder (der beste möge Gewinnen)? (Fiddis Lösung würde genauso wie auch Deine Funktioneren)

Und, ja mir ist das zuviel und vielen anderen Anwendern auch.
Was leider oft vergessen wird, ist die Softwareergonmie. Die ist glaube ich genauso unbeliebt wie die Arbeitsplatzergonmie. Dabei ist es so leicht eine hohe Produktivtät (und vor allem Akzeptanz) beim Anwender zu erreichen, einfach mal mit den Kollegen (der, der damit arbeiten muß) zusammensetzen und besprechen bzw. mal mitarbeiten (sofern möglich).

Außerdem besteht mein Weg aus ca. 5 Zeilen und nicht aus mehreren angepassten Forms. Es sollte doch nah am Standard sein, oder hab ich mir das nu falsch gemerkt?

Wenn es der Arbeit förderlich ist (und der Aufwand es rechtfertigt), sind auch 50 oder 500 Zeilen Code nicht zuviel.
Dicht am Standard?
Nein, SVR hat nur geschrieben, er möchte im Standard nicht zuviel auskommentieren (kann ich verstehen, es kann auch schnell zuviel auskommentiert werden).

Meine Angehängte Form (Muster in Rohform!), darf gerne benutzt werden (ID 50000 und 50001). Das Ding war in 15 Minuten fertig, ich denke das ist doch wohl OK oder?
(Den Beitrag hier schreiben dauert länger!). Anbei ein Screenshot der Form.

Debitoren_Kontakt_Karte.jpg

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Also in meiner Firma stört der NAV-Standard zur Auswahl eines Debitors/Kontakts niemanden. Das mag auch daran liegen, wie man sich die MA erzieht

In der Sache habe ich wohl etwas missverstanden, sorry.

Hallo!
Danke für eure zahlreichen Ideen.
Ich habe mal versucht die Lösung von McClane umzusetzen.
Das ist der Weg in die richtige Richtung. Fast am Ziel, aber:
Jetzt kommt noch die verständliche Frage ob man den Verkauf an Kontakt Nr. ändern will -> Das sollte nicht erscheinen, sondern mit "Ja" intern beantwortet werden.
Ähnliches gilt für die Frage ob man die "Rechnung an Kontakt-Nr." ändern will: Die Frage soll ebenfalls nicht erscheinen und mit "Nein" intern irgendwie beantwortet werden.
Wie kann ich jetzt, ohnen große Umwege die Confirms vorbelegen und "verschwinden" lassen?
Wenn wir das noch zusammenkriegen, dass wäre super.

Edit: Im Prinzip aber gelöst! Danke!!!!!!

Jetzt kommt noch die verständliche Frage ob man den Verkauf an Kontakt Nr. ändern will -> Das sollte nicht erscheinen, sondern mit "Ja" intern beantwortet werden.
Ähnliches gilt für die Frage ob man die "Rechnung an Kontakt-Nr." ändern will: Die Frage soll ebenfalls nicht erscheinen und mit "Nein" intern irgendwie beantwortet werden.

Beides müsste sich in den jeweiligen OnValidates in der Tabelle finden.

Das noch dazu ...

Und, ja mir ist das zuviel und vielen anderen Anwendern auch.
Was leider oft vergessen wird, ist die Softwareergonmie. Die ist glaube ich genauso unbeliebt wie die Arbeitsplatzergonmie. Dabei ist es so leicht eine hohe Produktivtät (und vor allem Akzeptanz) beim Anwender zu erreichen, einfach mal mit den Kollegen (der, der damit arbeiten muß) zusammensetzen und besprechen bzw. mal mitarbeiten (sofern möglich).

Mal ganz davon abgesehen, dass der Anwender bei dir immer drei Mal anstatt im besten Fall zwei Mal klicken muss - schließlich muss er ja immer bis zur Karte durch, es sei denn, dass du auch noch die Übersicht anpasst -, sehe ich keine besondere Ergonomie darin, ein Auswahlverfahren zu ändern, während alle anderen weiterhin dem Standard entsprechen. Da kommt doch eher die Frage auf, wieso es mal so und mal anders gelöst wurde.

Ich finde es besser, die Anwender an den NAV-Standard anzupassen als andersrum, und habe damit auch gute Erfahrunge gemacht. Das erleichtert auch die Updates um Einiges.

Das mag daran liegen, dass ich das so gelernt habe. Und es ist ja auch nur meine Meinung. Zwar etwas diametral zu deiner, aber naja