[Gelöst] RTC/WS Auftrag anlegen DebitorName

[elTorito]

hi,

ich versuche gerade unsere in NAV2009 verwendeten WebServices in NAV2018 einzubauen, der WebService ist ein XML Port welcher ein VK Auftrag anlegt.

Bei der Anlage werden diverse Sachen geprüft, unter anderem ob der Debitor schon existiert, wenn nicht wird einer angelegt, dito Rechnung an Debitor, Lieferadresse...

Nun war ich etwas verwundert warum hier/da im Auftrag Rechnung an Debitor irgendein Willkürlicher Datensatz gezogen wurde...
Bis ich dann in der Table 36 (Sales Header) auf den Felder "Verk.-An Name" und "Rechng.-an Name" folgendes gefunden habe:

Code: Alles auswählen

IF NOT IsCashCustomer THEN
       VALIDATE("Sell-to Customer No.",Customer.GetCustNo("Sell-to Customer Name"));
IF NOT IsCashCustomer THEN
  VALIDATE("Bill-to Customer No.",Customer.GetCustNo("Bill-to Name"));

T18 Customer:
[External] GetCustNo(CustomerText : Text) : Text
EXIT(GetCustNoOpenCard(CustomerText,TRUE,TRUE));


Die Funktion GetCustNo in Tabelle 18 (Customer) liefert eine DebitorenNummer, soweit so gut, aber die Funktion scheint auch eine Page zu öffnen wo man sich einen Debitor Rauspickt...
Das passiert beim Webservice nicht, und deswegen wird dort der erste/letzte Debitor gezogen wo der Name übereinstimmt.

Gehört diese Abfrage / Validate nicht eigentlich auf die Page? Anstatt in die Tabelle?

Hmm.

[m_schneider]

Also IsCashCustomer ist schon mal nicht Standard.
Das mit der Debitorenkarte schon. Das dient der Suche eines Kunden über den Namen.
Ich gebe dir den Tipp: Validiere nur notwendige Felder. Es gibt Personen die meinen, man müsse jedes Feld validieren. Dem ist nicht so.


In einer Pager werden nur sachen programmiert, die nirgendwo anders Platz finden. Und das sollte die Ausnahme sein.

[elTorito]

Also IsCashCustomer ist schon mal nicht Standard.
Das mit der Debitorenkarte schon. Das dient der Suche eines Kunden über den Namen.
Ich gebe dir den Tipp: Validiere nur notwendige Felder. Es gibt Personen die meinen, man müsse jedes Feld validieren. Dem ist nicht so.
In einer Pager werden nur sachen programmiert, die nirgendwo anders Platz finden. Und das sollte die Ausnahme sein.

IsCashCustomer ist nicht Standard, richtig. Auch nicht so wichtig.

Das mit der Debitorenkarte und Suche verstehe ich dennoch nicht so richtig. Man kann über das Name Feld suchen, verstehe ich, macht auch Sinn (irgendwo) ...

Ich hab da dennoch meine Verständnisprobleme, z.B. folgende Situation im RTC:

Auftrag wird angelegt, Debitor eingezogen, "Rechn.an" wähle ich "Anderer Debitor", im Feld "Name" kann ich nach einen Debitor suchen, ich wähle einen aus.
Nun kann ich alle "Rechn.-an" Felder überschreiben (Name 2, Adresse, PLZ usw...) nur das Feld "Rech. an Name" kann ich nicht überschreiben weil dann direkt wieder die Suche anspringt, bzw. es ploppt ein Dialog auf der Fragt ob Debitor neu anlegen oder vorhanden auswählen. Ich würde es ja noch verstehen wenn man gar keins der Felder überschreiben dürfte/könnte, und man immer auf die Daten des dahinter liegenden Debitor zugreift. Aber so ?

Und genau diese Situation wird mir zum Verhängnis wenn ich via WebService versuche "Rechnung an" Eigenschaften zu setzen , kommt via WebService "Rechnung an Name" = Karsten an, dann wird automatisch der erste Suchtreffer gezogen als Debitor, und da es mehrere Debitoren gibt die Karsten heißen wird u.U der falsche Debitor gezogen.

Gleiche Verhalten kann man im RTC nachstellen wenn man Automatischen Filter in Lookupfelder auf der Seite deaktiviert. Ich gebe in "Rechn an Name" ein Begriff ein und es wird der erstbeste Debitor gezogen bei dem der Begriff passt.

[fiddi]

Hallo,

wenn du ein aktuelles CU hast, kannst du das pro Debitor/Kreditor ausschalten. .

Früher hatten wir mal die Möglichkeit im OnAfterInput- Trigger eines Form-Feldes den Text abzufangen,zu suchen, und dann die gefundene Nr. im Beleg einzutragen. Ganz einfach und logisch.

Gruß Fiddi

[m_schneider]

...Und genau diese Situation wird mir zum Verhängnis wenn ich via WebService versuche "Rechnung an" Eigenschaften zu setzen , kommt via WebService "Rechnung an Name" = Karsten an, ...

Und deswegen sagte ich: Man sollte nicht alles einfach validieren. Mach eine Zuweisung (:=) und Ruhe ist.

[elTorito]

Ah. Jetzt hat es geklingelt
Danke.

PS: Was die Suche angeht, ist mir(unseren Usern) die Filtersuche zu träge, ganz schlimm wenn es um Artikel geht,
da habe ich zusätzliche Suchfelder eingebaut welche auf eine SQL Storage Procedur zugreifen. Läuft erstens viel schneller, und ich kann die Suche kombinieren,
in dem ich mehrere Felder einbinde wie z.B. karsten , düsseldorf, alle karstens in düsseldorf listet.

Gut wieder ein Mysterium gelöst Danke euch. Aktuelle CU haben wir glaube ich nicht.