[Gelöst] Ohne Designer Lizenz - am Bsp. Gueltigkeit Angebot

Hallo!

Für die Vertriebsangebote gilt es einen Gültigkeitstext für das Angebot zu erstellen.

Die Frage ist jene, was im Rahmen OHNE Designer-Lizenz Sinn macht?

(1) Am meisten Sinn macht eine Tabelle 50000 "Gültigkeit", in denen die Bedingungen als Textfeld stehen, bedeutet aber dass ja nicht nur die Tabelle Verkaufskopf um einen Code, sondern auch archivierter Verkaufskop, etc... ergänzt werden müssen, und ich geh mal nicht davon aus dass die Information des Zusatzfelds mit dem Code überall mitübertragen wird.

(2) Dann wäre noch der übliche Tabellenmissbrauch: Ich nehm zum Beispiel "Verkehrszweig", welchen niemand braucht und Pflege dort den Code und ergänze die Tabelle um eine Spalte: Hier habe ich die Sicherheit, dass es überall mitkommt, aber das Risiko, dass die Portierbarkeit der Datenbank eingeschränkt wird, denn: Standardtabellenänderung: Zweckmissbrauch und zusätzliche Spalten.

(3) Standardtext scheidet aus, weil die Lead Time am Ende gesondert steht und nicht in den Artikelzeilen. Bleiben also die Bemerkungszeilen, die dann so genutzt werden, dass die Bemerkungszeile mit dem Code LD die betreffende Lead-Time enthält.

Keine der Lösungen begeistert so wirklich, aber es wäre mal ein einheitliches Prinzip langsam sinnvoll.

Zuletzt geändert von tortelinski am 17. August 2010 16:27, insgesamt 1-mal geändert.

Hallo!

Für die Vertriebsangebote gilt es einen Gültigkeitstext für das Angebot zu erstellen.

Die Frage ist jene, was im Rahmen OHNE Designer-Lizenz Sinn macht?

(1) Am meisten Sinn macht eine Tabelle 50000 "Gültigkeit", in denen die Bedingungen als Textfeld stehen, bedeutet aber dass ja nicht nur die Tabelle Verkaufskopf um einen Code, sondern auch archivierter Verkaufskop, etc... ergänzt werden müssen, und ich geh mal nicht davon aus dass die Information des Zusatzfelds mit dem Code überall mitübertragen wird.

(2) Dann wäre noch der übliche Tabellenmissbrauch: Ich nehm zum Beispiel "Verkehrszweig", welchen niemand braucht und Pflege dort den Code und ergänze die Tabelle um eine Spalte: Hier habe ich die Sicherheit, dass es überall mitkommt, aber das Risiko, dass die Portierbarkeit der Datenbank eingeschränkt wird, denn: Standardtabellenänderung: Zweckmissbrauch und zusätzliche Spalten.

(3) Standardtext scheidet aus, weil die Lead Time am Ende gesondert steht und nicht in den Artikelzeilen. Bleiben also die Bemerkungszeilen, die dann so genutzt werden, dass die Bemerkungszeile mit dem Code LD die betreffende Lead-Time enthält.

Keine der Lösungen begeistert so wirklich, aber es wäre mal ein einheitliches Prinzip langsam sinnvoll.

(0) Was stört dich an der Tabelle 44, Sales Comment Line? Welche Felder fehlen ihr, damit der Vertriebler in ein VK-Angebot seine Gültigkeitstexte reinkloppt?

(1) Nunja, schau mal welche Felder von VK-Kopf per CU 5063 "ArchiveManagement" in den archivierten VK-Kopf mitgenommen werden, falls deine Lizenz es zuläßt reinzuschauen? Auf jeden Fall wird nix selbstgestricktes automatisch übernommen, sondern muss programmiert werden.

(2) Feld Verkehrszweig des VK-Angebots hernehmen? Wofür? Willst du etwa die 9 Codes löschen und mit deinen eigenen versehen und dann im archiv. VK-Angebot eine Seitenansicht etc. einbinden, damit die zweckentfremdeten Codes als Ausdruck auftauchen?

1 Seeverkehr
2 Eisenbahnverkehr
3 Straßenverkehr
4 Luftverkehr
5 Postverkehr
7 Festinstallierte Transporteinrichtungen
9 Eigener Antrieb

=> Überführung in

1 bis Ende 2010 gültig
2 bis Ende des LM gültig
3 bis St. Nimmerleinstag gültig
4 abgelaufenes VK-Angebot etc. etc.

(3) Funktion, Textbausteine einfügen scheidet aus, weil die Lead Time? Was genau ist das, ich bin kein Experte für NAV Marketing&CRM. Ist das etwa ein Feld, das nicht im arch. VK-Angebot auftaucht? Ich finde im arch. VK-Ang. nur das Feld "Time Archived", wo die Zeit z.B. 12:36 Uhr drin steht.

Nur mal laut gedacht:
Wenn du wg. der eingeschränkten Lizenz keine "gute" Lösung erreichst, dann wäre das evtl. ein Argument ggü. der Geschäftsleitung eine App.Builder- oder gar die große Entwicklerlizenz anzuschaffen, damit du in Zukunft Klimmzüge vermeiden kannst?

EDIT: das VK-Angebot wird bei euch automatisch in VK-Auftrag überführt oder wird der Auftrag manuell angelegt? Diese Codes 1-9 sind doch bei Intrastat wichtig, oder nicht?
Wenn man sie im Angebot umbiegt und dieses automatisch in einen Auftrag und später in eine Rechnung übernommen wird und keiner ändert die Codes, dann könnte die Intrastatmeldung falsch werden?

EDIT2: unter Verwaltung, A & E, Fin, Intrastat, Verkehrszweige taucht die Tabelle auf, deren Codes du zweckentfremden möchtest. Frag mal bei deinem Vorgesetzten nach, ob ihr Intrastat macht, bevor du anfängst die Codes zu ändern.

Aha danke.

(0) Was stört dich an der Tabelle 44, Sales Comment Line? Welche Felder fehlen ihr, damit der Vertriebler in ein VK-Angebot seine Gültigkeitstexte reinkloppt?

Ja, die Sales Comment Line ist wirklich die beste Lösung, nur verwende ich die Sales Comment Line vom Header dazu den Freitext zu erfassen, ohne Code.

Dann müsste die "Lead Time" / "Gültigkeit" in der ersten / letzten Angebotszeile erfasst werden im Zeilenkommentar, oder die Comments werden mit Codes versehen und entsprechend ausgewertet.

Aber dann werden die Beschwerden kommen, warum man in zig separaten Comment Fenstern Freitext eingeben muss oder warum man jeden Comment mit nem Code versehen muss, man möchte ja, so der Anwenderwunsch schon in der Form den Beleg eigentlich sehen.

Hallo!

jetzt ist das Problem effektiv da:

Ich hab mir testweise erlaubt Einladehafen (Tabelle: Hafen) um eine Spalte zu ergänzen, die da heißt "Job Title", die Bezeichnung firmierte als Beschreibung/Name

Im Beleg Verkaufsauftrag ist eigentlich nichts geschehen, außer der Auswahl eines Codes.

Doch rückgängig gemacht, T282 geleert, die alte T282 eingespielt (welche bei uns noch leer war), bringt er jetzt die Meldung auf der Form:

Die Beziehung zu dem Teil "Job Title" der Variable konnte nicht gelöst werden.

Das ist ja übel, hat er mit dem Erzeugen der Spalte die Programmlogik verändert?

Hallo!

jetzt ist das Problem effektiv da:

Ich hab mir testweise erlaubt Einladehafen (Tabelle: Hafen) um eine Spalte zu ergänzen, die da heißt "Job Title", die Bezeichnung firmierte als Beschreibung/Name

Im Beleg Verkaufsauftrag ist eigentlich nichts geschehen, außer der Auswahl eines Codes.

Doch rückgängig gemacht, T282 geleert, die alte T282 eingespielt (welche bei uns noch leer war), bringt er jetzt die Meldung auf der Form:

Die Beziehung zu dem Teil "Job Title" der Variable konnte nicht gelöst werden.

Das ist ja übel, hat er mit dem Erzeugen der Spalte die Programmlogik verändert?

Die Fehlermeldung kommt nur, wenn du T282 um das Feld 50.000 "Job Title" erweiterst, dann in die Form gehst, unter Reiter Außenhandel, Einladehafen die Form der Häfen aufrufst, dann mit Strg+F2 die Spalte / d.h. das Feld "Job Title" einblendest, das Ganze kompilierst. Dann wenn du in T282 das Feld 50.000 entfernst oder das alte FOB einspielst, wo es noch nicht da war und danach die Form aufrufst, dann zeigt sie ins Nirvana (die Form sucht nach einem eingeblendeten Feld 50.000, dieses ist aber nimmer in der Tabelle drin) und daher die Fehlermeldung. Programmlogik hast du noch nicht zerschossen!

Und zu deinem: "...die Beschwerden kommen, warum man in zig separaten Comment Fenstern Freitext eingeben muss oder warum man jeden Comment mit nem Code versehen muss, man möchte ja, so der Anwenderwunsch schon in der Form den Beleg eigentlich sehen."
=> entweder du sagst den Anwendern stumpf, so tickt Navision, da ist nix zu machen, es sei denn wir investieren fett.
=> oder du baust dir eine zweite Subform, die aber als Source nicht die VK-Angebot Lines sondern direkt die Kommentare anzeigt, d.h. auf Tab 44 geht, aber im Kopfbereich angezeigt wird. Du hast doch bestimmt die Bücher zu Development 1 + 2 als PDF rumliegen, da ist sowas beschrieben. Aber evtl. brauchst du die kleine Entwicklerlizenz.

Ich würde dir empfehlen, dir mit Bleistift und Papier aufzuschreiben was du machen willst und iterativ vorzugehen, nach der Kausalkette:
Kleines Ziel definieren => Plan mit allen Schritten aufstellen => implementieren => checken ob Ergebnis tut / tut nicht => Anwenderergonomie berücksichtigen ja/nein <=> Lizenz aufstocken ja/nein bzw. den NAV-Partner beauftragen ja/nein.
Falls das Ergebnis funktional tut, aber die Ergnonomie suboptimal ist UND du es selber nicht lösen kannst, dann frage beim NAV-Partner, was die Lizenzerweiterung kostet, bzw. was es kostet die gewünschte Ergonomie für die Fachbereichsuser herzustellen.

Schätzen und Anbieten seitens eines NAV-Partners ist meistens kostenlos.
Aus dieser Schätzung machst du eine kleine .pptx Entscheidungsvorlage für die Entscheider, also was zu tun ist.
Wichtig ist für dich einfach zu zeigen, du hast es versucht, es hat geklappt / nicht geklappt / teilweise geklappt, die Ursachen fürs Nichtklappen / Teilklappen eingekreist und deren Beseitigung auf X € bzw. Y Manntage geschätzt.

Die Fehlermeldung kommt nur, wenn du T282 um das Feld 50.000 "Job Title" erweiterst, dann in die Form gehst, unter Reiter Außenhandel, Einladehafen die Form der Häfen aufrufst, dann mit Strg+F2 die Spalte / d.h. das Feld "Job Title" einblendest, das Ganze kompilierst. Dann wenn du in T282 das Feld 50.000 entfernst oder das alte FOB einspielst, wo es noch nicht da war und danach die Form aufrufst, dann zeigt sie ins Nirvana (die Form sucht nach einem eingeblendeten Feld 50.000, dieses ist aber nimmer in der Tabelle drin) und daher die Fehlermeldung. Programmlogik hast du noch nicht zerschossen!

Aha, danke. Dann sehe ich hier 2 Lösungen:

(a) Die Spalte wird nochmal erzeugt und alle Nutzer sollen diese ausblenden.

(b) Alle ZUP-Dateien werden zurückgesetzt.

(c) Bessere Lösung von mir noch nicht erkannt - ...

Die Fehlermeldung kommt nur, wenn du T282 um das Feld 50.000 "Job Title" erweiterst, dann in die Form gehst, unter Reiter Außenhandel, Einladehafen die Form der Häfen aufrufst, dann mit Strg+F2 die Spalte / d.h. das Feld "Job Title" einblendest, das Ganze kompilierst. Dann wenn du in T282 das Feld 50.000 entfernst oder das alte FOB einspielst, wo es noch nicht da war und danach die Form aufrufst, dann zeigt sie ins Nirvana (die Form sucht nach einem eingeblendeten Feld 50.000, dieses ist aber nimmer in der Tabelle drin) und daher die Fehlermeldung. Programmlogik hast du noch nicht zerschossen!

Aha, danke. Dann sehe ich hier 2 Lösungen:

(a) Die Spalte wird nochmal erzeugt und alle Nutzer sollen diese ausblenden.

(b) Alle ZUP-Dateien werden zurückgesetzt.

(c) Bessere Lösung von mir noch nicht erkannt - ...

Die Lösung für die Zukunft wäre IMHO am besten:
Falls du ein Feld >= 50.000 hinzufügst und in einer Form einblendest, dann ist der Weg um das ganze rückgängig zu machen:
1. in der Form Strg+F2, dann markieren und entfernen
2. im Objektdesigner auf die Tabelleneigenschaften gehen Alt+D und dann das Feld >= 50.000 löschen.

Ich erkenne wenig Sinn, die Spalte (das Feld) in der Tabelle nochmals zu erzeugen und dann die Nutzer zu bitten, diese Spalte auf der Form auszublenden.
Auch ergibt es wenig Sinn die ZUP-Dateien zu löschen.

Hoffe, dass ich dir weiterhelfen konnte?

Ja ist klar, zuerst die Tabelle zurückzusetzen vor der Form ist demnach reichlich dumm, weil damit die Form zwangsverändert wird mit diesen unschönen Seiteneffekten.