none
CRM 2011 phonecall directioncode Änderung wird nicht erkannt

    Frage

  • Moin!

    Ich habe ein Problem mit der Richtung von Telefonanrufen in CRM 2011:

    Der User legt einen neuen Telefonanruf an, trägt seine Daten ein, das "from"-Feld wird per Javascript mit dem aktuellen Benutzer gefüllt und in dem gleichen Script wird der directioncode, also die Richtung auf Null gesetzt.

    Wenn der User nun die Richtung auf ausgehend setzt, ist alles in Ordnung.

    Setzt der User die Richtung aber auf eingehend, erscheint beim Speichern eine MessageBox "Sie müssen einen Wert für 'Richtung' angeben". Gleichzeitig ist der Punkt im "Eingehend"-Feld vorhanden und bleibt auch dort. Wenn man nun einmal auf "ausgehend" ändert und wieder zurück, so dass auch die from- und to-Felder zweimal getauscht werden, kann man "Eingehend" speichern.

    Es ist auch egal, ob zwischendurch noch etwas anderes geändert wird oder ob man nach dem Klick auf "Eingehend" direkt auf Speichern klickt.

    Ein benutzerdefiniertes onChange-Event für das Feld haben wir nicht.

    Woran kann das liegen, dass der Wert anscheinend nicht gesetzt wird, wenn er vorher auf Null stand? In CRM 4 hat das funktioniert und auch bei den Tests in CRM 2011 hat es funktioniert. Erst seit wir mit 2011 live sind, tritt dieser Fehler auf.


    • Bearbeitet der Jörg (Wanders) Donnerstag, 19. Juni 2014 06:11 Überschrift Schreibfehler korrigiert
    Freitag, 13. Juni 2014 10:24

Antworten

  • Hallo Jörg,

    eventuell wäre ja diese CTI-Schnittstelle (www.crmtapischnittstelle.de) eine Lösung.

    Sie ist eine integrierte Applikation, die dem Nutzer ein- und ausgehende Telefonie-Funktionen in Microsoft CRM zur Verfügung stellt. Die Telefongespräche sind komplett in das Aktivitäten-Management sowie in die Kontaktformulare von Microsoft Dynamics CRM eingebettet.

    Somit wäre dein Problem mit dem „directioncode“ für eingehenden und ausgehende Telefonate gelöst.


    Ich hoffe das bringt weiter. Andreas(a)Donaubauer.com www.crmfaq.de

    Dienstag, 24. Juni 2014 11:23

Alle Antworten

  • Hallo,

    verwendet ihr im JavaScript eventuell noch den CRM 4 Code? Wenn ja, würde ich den in CRM 2011 umschreiben und es dann erneut versuchen.

    Welchen RU Stand hat euer System?


    Viele Grüße

    Michael Sulz
    MVP für Microsoft Dynamics CRM
    Blog
    Website XING LinkedIn Facebook Twitter

    Montag, 16. Juni 2014 06:09
    Moderator
  • Moin!

    aktuell ist RU 14 installiert, heute Abend will ich auf RU 16 updaten. Mit 17 warte ich noch ein wenig, es sei denn, mir kann jemand bestätigen, dass das gut läuft.

    Die Funktion zur Richtungsumkehr ist ja vom System vorgegeben, das auf Null setzen ist neu erzeugt für CRM 2011. Was mich irritiert, ist, dass es bei Tests funktioniert hat. Die Tests haben auf dem jetzigen SQL-Server und dem jetzigen CRM-Server stattgefunden und auch die Übernahme der Datenbank habe ich auf dem gleichen Weg vorgenommen (Kopiesicherung auf dem alten SQL-Server, verschoben, auf dem neuen SQL-Server wiederhergestellt, Organisation importiert und aktualisiert).

    Grüße aus dem Norden,

    Jörg

    Dienstag, 17. Juni 2014 06:55
  • Hallo,

    ich habe das System inzwischen doch auf RU17 aktualisiert, was ein paar kleinere andere Probleme beseitigt hat, das hier beschriebene Verhalten ist allerdings gleich geblieben. Es hat sich sogar gezeigt, dass etwas ähnliches an anderer Stelle ebenfalls auftritt: bei Firmen und Kontakten gibt es die Kontaktmethoden. Der Punkt "Massen-E-Mail" wird ebenfalls beim Form_OnLoad per Script auf Null gesetzt und verursacht beim Setzen auf "Nicht zulassen" (donotbulkemail = true) das gleiche Bild. Es scheint also tatsächlich entweder am Script oder an dem Umstand, dass wir es auf Null setzen zu liegen. Auch hier: wird zuerst false und dann true ausgewählt, funktioniert alles wie gewünscht.

    Der dazu verwendete Code

      if (Xrm.Page.ui.getFormType() == 1) {
            Xrm.Page.getAttribute("donotbulkemail").setValue(null);
        }

    sollte das Problem nicht sein.

    Any ideas?

    Donnerstag, 19. Juni 2014 06:41
  • Hallo Jörg!

    Statt auf null musst du mit deinem Script den Wert des Optionfeldes auf true oder false setzen. z.B.
    Xrm.Page.getAttribute("donotbulkemail").setValue(false);
    oder im Telefonanruf:
    Xrm.Page.getAttribute("directioncode").setValue(false);




    Ich hoffe das bringt weiter. Andreas(a)Donaubauer.com www.crmfaq.de



    Freitag, 20. Juni 2014 12:36
  • Hallo Andreas,

    leider nein, genau das soll ja vermieden werden, dass die Richtung vorgegeben ist. Die User sollen explizit auswählen müssen, in welche Richtung telefoniert wurde. In den Tests vor dem GoLive hat es ebenso wie im CRM 4 funktioniert. "False" ist ja die Voreinstellung, wenn es so sein sollte, könnte ich es so lassen. Leider machen User nicht immer das, was man von ihnen erwartet. Bei donotbulkemail wäre das noch nicht so das Problem, bei der Richtung der Telefonanrufe ist das schon etwas heikler, weil es da teilweise um die Berechnung geht.

    Montag, 23. Juni 2014 06:04
  • Hallo Jörg,

    eventuell wäre ja diese CTI-Schnittstelle (www.crmtapischnittstelle.de) eine Lösung.

    Sie ist eine integrierte Applikation, die dem Nutzer ein- und ausgehende Telefonie-Funktionen in Microsoft CRM zur Verfügung stellt. Die Telefongespräche sind komplett in das Aktivitäten-Management sowie in die Kontaktformulare von Microsoft Dynamics CRM eingebettet.

    Somit wäre dein Problem mit dem „directioncode“ für eingehenden und ausgehende Telefonate gelöst.


    Ich hoffe das bringt weiter. Andreas(a)Donaubauer.com www.crmfaq.de

    Dienstag, 24. Juni 2014 11:23
  • Hallo Andreas,

    wir setzen zwar Estos ein und haben gerade erst eine aktuellere Version lizenziert, aber für zukünftige Aktualisierungen sage ich mal: die Optionen sehen gut aus, gefällt mir. Mal sehen, was die GL zu den Preisen sagt.

    Bis dahin werde ich mir wohl mit einem Workaround behelfen, zumal ich inzwischen erfahren habe, dass dieses Verhalten offensichtlich by design so ist. Anscheinend haben wir das nicht ausgiebig genug getestet und darüber zu sinnieren, warum es im CRM 4 funktioniert hat, ist jetzt müßig.

    Danke trotzdem für die Mühe!

    Jörg

    Dienstag, 24. Juni 2014 12:09