Beiträge von robert@GREYHOUND

    Hallo,

    der Item-Filter enthält einige Eigenschaften, ohne die man keine Ergebnisse erhält. In "Kinds" wird ein Set der Element-Typen (E-Mail, Brief, Notiz, etc.) angegeben und in "Statuses" ein Set der Element-Status (Offen, Erledigt, etc.). Wenn diese Eigenschaften des Filters leer sind, werden daher keine Elemente gefunden.

    Wenn "SearchFor" verwendet wird, um einen Suchbegriff anzugeben, muss zusätzlich noch die Eigenschaft "SearchFields" gesetzt werden, die angibt, in welchen Feldern gesucht werden soll (Adresse, Betreff, Anmerkungen, etc.).


    Hier ein Beispiel, in dem nach E-Mails mit beliebigem Status gesucht wird, in deren Adressfeldern der Begriff "Test" vorkommt. Die Ergebnisse werden absteigend nach Erstellungsdatum sortiert und es werden nur die Eigenschaften Betreff und Erstellungsdatum der Ergebnisse befüllt:

    Hallo Andreas,


    damit eine Regel in der Auswahlliste zum manuellen Ausführen auftaucht, muss in der Regel selbst der Trigger "Manuelle Ausführung" aktiviert sein.

    Schau mal unter "Einstellungen" > "Regeln" bei der entsprechenden Regel nach. Bei "Trigger" muss die Checkbox "Manuelle Ausführung" aktiv sein, und im Reiter "Freigegebene Benutzergruppen" kannst du dann auswählen, welche Benutzergruppen die Regel manuell ausführen dürfen.

    Hallo Vivien,

    wenn ich das richtig sehe, dann nutzt du node.js, oder?

    Der request-Aufruf scheint nicht ganz korrekt zu sein. Wenn man statt dem .on('response', ...) eine Callback-Funktion mit an den Aufruf übergibt, dann erhält man dort auch den response-Body. Der GREYHOUND Server liefert Exceptions als JSON-Objekt zurück und lässt dabei den HTTP-Code auf 200.

    Die Authentifizierung scheint beim request Paket von node.js über einen "auth" Parameter zu laufen - scheinbar überschreiben die den "Authorization" Header damit.


    Mit folgendem Code funktioniert es bei mir:

    Da der Basic Auth Code nicht mehr per Hand Base-64 codiert werden muss, kannst du dann im Prinzip auch das "btoa" Paket weglassen. ;-)

    Hallo,
    ein kleiner Tipp: wenn Du im GREYHOUND Client einen Filter bearbeitest, dann kannst Du sehen, was da alles an Flags, Stati usw. gesetzt ist. Wenn Du dann beim Abrufen den Filter mit den gleichen Flags usw. versorgst, dann müsste eigentlich das gleiche Ergebnis kommen. Das Flag rpc_itemslib::ifDone dürfte es eigentlich gar nicht geben, bzw. in den Flags des Filters dürfte das nicht vorkommen: rpc_itemslib.RpcItemFlags
    "Erledigt" ist ein Status, kein Flag. Das müsste aber bereits mit dem isOpen State passen. ;-)

    Hallo,
    das Problem liegt darin, dass beim Speichern eines Elements mit "Put" Protokolle und Anmerkungen nicht ersetzt werden, sondern hinzugefügt werden. D.h. wenn man ein Element mit Get holt und anschließend mit Put schreibt, ohne vorher die Eigenschaften Protocol und Remarks zu leeren (auf leere Arrays zu setzen), dann dupliziert man die Protokolleinträge und Anmerkungen des Elements (da die bisherigen dann erneut hinzugefügt werden).


    Das ist zugegebenermaßen etwas unglücklich in der RPC-Schnittstelle gelöst, lässt sich aber leider nachträglich nicht mehr ändern (sonst wäre die Schnittstelle nicht mehr abwärtskompatibel). Generell lassen sich Protokolleinträge und Anmerkungen immer nur hinzufügen und nicht löschen oder ersetzen, da dies dem Konzept der Software widersprechen würde (Protokoll und Anmerkungen sollen nicht rückwirkend manipulierbar sein).


    Also: wenn man ein Element mit Get abruft und später mit Put wieder zurück schreiben möchte, dann immer vorher die Eigenschaften Protocol und Remarks leeren. ;)

    Hallo,
    im Zweifelsfall kannst du natürlich mal XAMPP mit PHP 5.3 versuchen, vielleicht laufen eure Intranetseiten damit besser. Wenn ich das richtig sehe, dann müsste in XAMPP 1.7.7 PHP 5.3.8 enthalten sein.
    Die PHP Version ist zwar schon recht alt, aber für das Intranet ist das ja nicht so dramatisch.

    Hallo,
    die libxml Version bei euch sollte ja hoch genug sein, aber laut PHP Dokumentation wird die LIBXML_PARSEHUGE Konstante in PHP erst ab Version 5.2.12 unterstützt. Wenn ihr also 5.2.9 einsetzt kennt PHP da die Konstante noch nicht. Ihr müsstet dann eure PHP Version zumindest auf Version 5.2.12 updaten. Die PHP Bibliothek von GREYHOUND ist übrigens auch mit den neueren PHP Versionen kompatibel. Ich setze in der Entwicklung z.B. momentan PHP 5.5 ein, generell läuft die Bibliothek aber auch mit PHP 5.2 (bzw. so wie es aussieht dann erst ab PHP 5.2.12).

    Hallo,
    die Zeile, in der der Fehler gemeldet wird ist folgende:

    PHP
    1. if(!$xml->xml($xmlResult, 'UTF-8', LIBXML_PARSEHUGE))
    2. throw new GhRpcException('Could not parse rpc response xml');


    Als dritter Parameter wird hier eine PHP-Konstante verwendet (LIBXML_PARSEHUGE) - warum da der PHP Interpreter meldet, dass angeblich ein String als dritter Parameter übergeben wird, ist mir nicht ganz klar. Welche PHP Version setzt ihr denn ein? Evtl. ist dort ja der XMLReader ein anderer. Das würde mich zwar wundern, denn laut offizieller PHP Dokumentation ist der Aufruf so nach wie vor korrekt, aber eine andere Ursache wüsste ich ehrlich gesagt momentan nicht. ;)

    Ja, die legacy-Daten werden nach wie vor in der URL mitgegeben, allerdings zusätzlich zu dem neuen, offiziellen Mechanismus. Das dient dazu, das Benutzer mit älteren plentymarkets Versionen, bei denen es die neuen URLs noch nicht gab, die Daten noch aufrufen können. Bei dem Link zu den Kundendaten sind diese Daten nicht enthalten, da es nach dem alten Mechanismus keine Möglichkeit gab, Kundendaten aufzurufen. ;)


    Haben Sie einmal getestet, ob Sie in plentymarkets mit die Aufträge denn manuell aufrufen können? Wir hatten neulich den Fall, dass unser Testsystem zurückgesetzt wurde und infolgedessen zunächst einen Benutzer, dem in plentymarkets die Berechtigungen fehlten, die Aufträge und Kunden anzuzeigen. Dadurch wurde dann beim Aufrufen der Links immer eine Fehlermeldung angezeigt - in plentymarkets selbst konnte der Benutzer aber die Aufträge und Kunden auch nicht per Hand aufrufen.


    Falls es daran nicht liegt müssten Sie sich einmal bei unserem Support melden. Ich würde dann die Daten einmal an unseren Kontakt bei plentymarkets weitergeben und nachfragen, warum bei Ihnen die Links nicht funktionieren.

    Hallo,
    besten Dank für die Informationen! Anhand des Links konnte ich herausfinden wie offenbar bei neueren Kundensystemen die Aufträge, Artikel - und jetzt auch Kundendatensätze aufgerufen werden können. Uns lagen bisher nur die offenbar veralteten Links vor, die jedoch in unserem Testsystem noch funktioniert hatten.


    Wir haben gerade eine neue Version des plenty Connect Addons hochgeladen. Nach der Aktualisierung sollten dann auch die Links endlich korrekt funktionieren.

    Hallo,
    ich habe bereits Antwort von Plenty erhalten. Die Links sollten laut Aussage von Plenty in der Version 5.0 (und auch der Version 5.1) so funktionieren - auch wenn das derzeit ein undokumentierter Weg ist, Aufträge direkt aufzurufen. Habt ihr einmal versucht, den Link in die Zwischenablage zu kopieren und dann direkt im Browser aufzurufen (am besten, wenn man in dem Browser bereits in der Plenty-Weboberfläche angemeldet ist, also bereits eine gültige Session hat)? Wenn das bei euch nicht funktioniert, dann müsstet ihr euch einmal an unseren Kundenservice wenden, damit wir uns das im Einzelfall ansehen können (ist eventuell kostenpflichtig).

    Die Suche nach Order-ID war tatsächlich fehlerhaft. Dies wurde nun korrigiert - ich habe eben eine neue Version eingespielt, in der die Suche nach Order-ID jetzt auch Ergebnisse liefert. Die neue Version des Addons lädt der GREYHOUND Server beim nächsten Neustart herunter, alternativ kann dies aber auch im laufenden Betrieb über "Funktionen" -> "Addons aktualisieren" angestoßen werden. Die GREYHOUND Clients erhalten dann die neue Version vom GREYHOUND Server wenn sie einmal neu gestartet werden.


    Die Links zum Auftrag und den Artikeln nutzen eine Funktion von Plentymarkets, die undokumentiert ist. Offiziell wird die URL, die wir dort nutzen, nicht unterstützt, wir haben uns aber damals entschlossen, die Funktion dennoch so einzubauen, da das Addon sonst einen Großteil seines Nutzens verschenkt. Ob die Links funktionieren hängt wahrscheinlich start von der Plentymarkets Version ab. Ich habe das gerade in unserem Testsystem einmal ausprobiert - dort funktionieren die Links. Die Plentymarkets Version, die wir einsetzen ist Version 5.0. Wenn Sie sich in der Webanwendung von Plentymarkets anmelden sollte die "5.0" unten rechts auf dem Anmeldebildschirm erscheinen. Ansonsten kann man die Version offenbar auch im Plentymarkets Service Center einsehen (in der Anwendung erreicht man das über "Start" -> "plentymarkets-Konto" -> "Service Center".


    Die Buttons "Antworten" und "Weiterleiten" im Addon bieten die Möglichkeit, in Textbausteinen Variablen aus dem Auftrags- oder Kundendatensatz zu verwenden: Variablen für Textbausteine (plenty Connect)
    Diese Variablen sind nur an dieser Stelle vom Addon befüllt, für die normale Antworten- oder Weiterleitenfunktion im GREYHOUND Client können wir diese aus technischen Gründen leider nicht verfügbar machen (der GREYHOUND Client weiß ja nichts von dem Auftrag, der im Addon dargestellt wird).


    Zu dem Problem mit VMWare Fusion kann ich momentan leider nichts sagen, ich müsste mir da erst eine Testumgebung besorgen. Der GREYHOUND Client sendet die Links eigentlich zur Anzeige im Standardbrowser an das Betriebssystem.

    Benutzerdefinierte Felder kannst du bei der Erzeugung eines Elements bereits mit angeben. Diese müssen allerdings als entsprechendes Objekt angegeben werden. Die ID des benutzerdefinierten Felds kannst du z.B. über "Funktionen" > "ID Inspect" ermitteln. Das öffnet ein kleines Fenster, in das man quasi alle Objekte aus GREYHOUND hinein ziehen kann, und das dann deren ID anzeigt.


    Hier ein Beispiel für das Anlegen eines Elements inkl. benutzerdefiniertem Feld:


    Den Namen und Typ des benutzerdefinierten Felds kann man hier weglassen, da die ja bereits über die ID im Server bekannt sind. Der Wert wird immer als String angegeben und dann im Server in den entsprechenden Datentyp umgewandelt. Das ist notwendig, da die benutzerdefinierten Felder ja unterschiedliche Typen haben können, die RPC Schnittstelle aber einen festen Datentyp für den Wert braucht.


    Die Priorität des Elements wird hier übrigens explizit auf "Normal" gesetzt, da sonst das Element die niedrigste Priorität erhalten würde. Alle Felder, die nicht angegeben werden, werden als leer oder 0 betrachtet. Und 0 ist der Wert der Konstanten für die niedrigste Priorität. ;)

    Hallo,
    wenn du mit PHP arbeitest, dann empfehle ich unsere GREYHOUND PHP API - dort musst du dich um die technischen Details der Übertragung nicht kümmern und arbeitest direkt mit Objekten. Für die RPC Schnittstelle ist dann der RPC Teil der PHP API zuständig.


    Die PHP API selbst wird übrigens mit GREYHOUND ausgeliefert. Nach der Installation des Clients liegt diese in "C:\Programme (x86)\GREYHOUND\Libraries\php".

    Hallo,
    ein spontaner Tipp wäre, vor der Wiederherstellung den PrinterHelper zu beenden. Der taucht im Windows-Taskmanager auf (bei mir während einer Remote-Desktop-Session auch schon mal zweimal), und kann dort beendet werden. Das Setup (und möglicherweise auch die Wiederherstellung) scheint den nicht immer selbst beenden zu können und meldet dann einen Fehler. Wenn man den PrinterHelper vorher selbst beendet kommt dieser Fehler (zumindest bei der Installation bzw. einem Update des Servers) auf meinem System nicht. Vielleicht hilft das bei euch ja bei der Wiederherstellung auch.

    Hallo,
    zunächst einmal besten Dank für das Feedback!


    Die Artikelnummern haben wir geändert. Es wird nun die Lieferanten-Artikelnummer angezeigt, und nur falls diese nicht vorhanden ist wird auf die internen Nummern zurück gegriffen.


    Was den verfügbaren Lagerbestand angeht, so sollte in dem Feld, das wir bei den Artikeln anzeigen, laut pixi* der tatsächlich verfügbare Bestand stehen. Wenn das bei euch nicht der Fall ist, dann wäre es gut, wenn Du Dich einmal bei unserem Kundenservice meldest, damit wir das genauer eingrenzen können.

    Hallo,
    wenn man die Original-Datei nicht anpassen möchte, dann kann man auch die statische Methode GhGui::setBaseUrl() Klasse dafür verwenden. In Deinem Fall wäre das dann:

    PHP
    1. GhGui::setBaseUrl('//localhost/web');

    Hallo,
    der GREYHOUND Server führt in der aktuellen Version kein PHP mehr aus. Wir haben diesen Mechanismus mittlerweile in den Client verlagert, um bei Erweiterungen eine bessere Performance zu erzielen bzw. die Last besser zu verteilen. Das PHP Hosting im Server war bisher auch eher für Entwicklungszwecke gedacht und nur bedingt für den Produktivbetrieb geeignet.


    PHP Webanwendungen oder Erweiterungen, die bisher zentral über den GREYHOUND Server gehostet wurden, müssen nun also in einem separaten Webserver gehostet werden (z.B. Apache - auch ein Hosting in einem "handelsüblichen" Webhosting-Angebot ist natürlich möglich). Die PHP API kann man weiterhin aus GREYHOUND übernehmen, die wird jetzt bei der Installation des Clients im Ordner GREYHOUND/Libraries/php (PHP Dateien) bzw. GREYHOUND/Libraries/web (CSS und Javascript Dateien) mit ausgeliefert. Wie man die PHP API auf einem separaten Webserver in seinen Code einbindet ist in der Dokumentation der PHP RPC Schnittstelle beschrieben (gilt aber analog genau so für die PHP GUI).

    Hallo,


    ich habe mir die Debug-Daten einmal angesehen. In den Daten, die über die plenty API geliefert wurden, sind auch keine Lieferadressen enthalten, nur die Rechnungsadressen sind befüllt. Eine Länder-ID ist in den Rechnungsadressen auch hinterlegt, allerdings liefert die API offenbar keine Liste der Länder aus (die notwendig ist, um anhand der Länder-ID zu entscheiden, um welches Land es sich handelt).


    Ich habe mir auf Ihrem System einmal die Einstellungen für das plenty Connect Addon angesehen, und dabei ist mir aufgefallen, dass in der API URL hinten /version106/?xml steht. Das adressiert auf Ihrem System offenbar tatsächlich die veraltete API Version 106. Aktuell ist derzeit meines Wissens gerade Version 109, Version 110 soll wohl in Kürze bereit stehen.


    Können Sie in den plenty Connect Einstellungen in der API URL das "/soap/version106/?xml" einmal in "/soap/latest/?xml" ändern, also das "version106" durch "latest" ersetzen? Diese URL verweist immer auf die aktuellste plenty API Version. Das sollte eigentlich das Problem beheben.