9
votes

Services Web FedEx (SOAP): Service de ramassage

J'essaie de planifier le ramassage en utilisant un service de ramassage. D'abord, j'envoie une demande de disponibilité de ramassage pour obtenir le temps de coupure, puis utilisez le résultat que je reçois la demande de prise en charge. Mais après cela, je reçois une erreur "Temps prêt après coup de coupure" pour le moment qui est évidemment avant le temps de coupure. Dans mon exemple de coupure de coupure renvoyé est 16h00 mais la dernière fois que je peux planifier le ramassage pour IS 11h00. PARTIE DE LA DISPONIBILITÉ DE PIGNÉE Réponse:

<v3:ScheduleDay>SAME_DAY</v3:ScheduleDay>
<v3:Available>true</v3:Available>
<v3:PickupDate>2013-04-09</v3:PickupDate>
<v3:CutOffTime>16:00:00</v3:CutOffTime>


12 commentaires

Le temps que vous envoyez dans la demande est-il correctement formaté? J'ai vu 2013-04-02T13: 00: 00 , c'est comment ils veulent le recevoir? Désolé, je n'ai jamais travaillé avec l'API de FedEx, mais je pensais que je ferais un peu de creuser, car vous n'avez pas eu beaucoup d'action sur cette question.


@ZJD Bonjour, merci de votre attention sur ma question. Je n'ai pas beaucoup d'expérience avec le savon et je vois que le champ Date-Time doit être formaté de cette façon ou peut également contenir des millisecondes. Je pense d'abord que les millisecondes ne sont pas pertinents dans cette situation. Et ils envoient également la demande horodatage dans la réponse et il est formaté de la même manière. Pour être 100% sûr, j'ai essayé toute combinaison possible, je vais essayer avec des millisecondes en ce moment.


Oui, même chose avec date "2013-04-02T14: 00: 00.000Z"


Pourrait-il potentiellement être un problème de fuseau horaire?


@ZJD Je ne pense pas, selon la documentation, toutes les dates des demandes et des réponses sont fournies dans le fuseau horaire de l'adresse de ramassage. Donc, même si j'ai quelque chose qui ne va pas avec le fuseau horaire de mon côté, les dates des demandes et des réponses devraient correspondre aux autres.


À quel jour planifiez votre ramassage? Il a noté que FedEx Express Le ramassage peut être programmé pour le jour ouvrable actuel ou suivant.


@fitheflow J'utilise FedEx Ground. Le résultat est en fait la même chose pour différents jours à partir de la journée en cours.


Je vois .. Juste pour vérifier que tout ce que vous faites est correct, car FedEx Ground Le ramassage peut être programmé pour le la prochaine journée d'activité ou tout jour ouvrable jusqu'à 2 semaines avance. Un pick-up a FedEx Ground ne peut pas être programmé pour le jour actuel .


OK, il existe deux types de pickupRequestType dans la requête PickUpUpAvailabilité . Type de demande Les valeurs valides sont: même_day futur_day . Avez-vous essayé de demander la disponibilité de ramassage avec un Valeur ? Je pense que le cutofftime pourrait différer.


@fitheflow Vous avez raison, pour Future_day Il retourne 13h00 en tant que coupure de coupure. Il existe également un champ "temps d'accès" qui est également différent pour différents types de demande (4 heures pour la journée future et 2 heures pour le même jour), mais je ne peux toujours pas mettre toutes ces choses ensemble pour comprendre la façon dont cela fonctionne. BTW Je ne suis pas sûr de comprendre vraiment la différence entre fule_day et idem_day car cela n'affecte pas la demande de prise en charge. même_day signifie que je veux planifier la prise en charge du jour où j'envoie créer une demande de prise en charge? Si oui, toutes les demandes que j'essayent ont un délai de coupure pour futur_day qui est 16h00


même_ay signifie que je veux planifier la prise en charge du jour où j'envoie créer une demande de prise en charge? Oui, vous avez raison et, comme il est indiqué que vous ne pouvez planifier que le pick-up au sol pour le Le lendemain, vous devriez essayer d'utiliser le CUTOFFTIME GENTÉ DE LA DEMANDE DE DISPONIBILITÉ DE PICKUPT AVEC LA VALUE PICKUPREQUESTYPE SET TO Future_Day .


Accesstime est la fenêtre TIME minimale qui doit être attribuée au Courrier FedEx pour faire le pick-up. La différence entre le temps de fermeture de l'entreprise (ou le "temps de coupure local" si elle est plus tôt que la fermeture de la Business Ferme) et que le package prêt à l'emploi doit être égal ou supérieur à l'heure d'accès. ( Accesstime <= CompanyClosetime-PackagerAgereadime ).


4 Réponses :


3
votes

Avez-vous remarqué que le ReadyTimeMestamp Code> dans l'exemple CreatePickUPRequest strong> sur Page 76

<q0:ReadyTimestamp>2011-08-02T08:00:18.282Z</q0:ReadyTimestamp>
<q0:CompanyCloseTime>17:00:00</q0:CompanyCloseTime>


15 commentaires

Pas sûr de ce que vous voulez dire. J'utilise origindetail / ReadyTimeMestamp dans la demande de prise en charge et packagereadyTime dans la demande de disponibilité de capture. Semble bien selon le docteur PDF.


Vous avez mentionné que vous voulez faire une demande de disponibilité de ramassage Tableau 32 , mais vous utilisez des éléments de Demande de disponibilité de ramassage Tableau 26 < / code>


Vérifié votre demande sur le pastebin , oui vous avez raison, vous utilisez des éléments corrects


Vient de voir votre commentaire sur le code temporel. J'ai vu TZD là-bas avant, mais vous m'avez fait regarder plus attentivement. Je remarquais donc d'abord que la demande de disponibilité ne doit pas contenir d'informations et de la date de TZ devrait être dans la TZ locale. Donc je l'ai fait dans les deux demandes. Maintenant, j'ai vérifié et voyez que ce n'est pas correct car la demande de ramassage n'a pas que ce commentaire et TZD est inclus. Il semble donc que la demande de ramassage devrait contenir une date dans UTC contrairement à la demande de disponibilité qui a une date de TZ locale. Le TZ local est PST, donc je devrais probablement le vérifier à nouveau. Merci.


Ce n'est pas explicitement spécifié pour ReadyTimestamp pour une raison quelconque, mais tous les autres horodatages sont spécifiés pour contenir des informations TZ. shiptimestamp Le format de date doit être aaaa-mm-ddthh: mm: SS-XX: XX. Le temps doit être au format: HH: MM: SS utilisant une horloge de 24 heures. La date et l'heure sont séparées par la lettre T, telle que 2009-06-26T17: 00: 00. Le décalage UTC indique le nombre d'heures / minutes, par exemple XX: XX de UTC, telle que 2009-06-26T17: 00: 00-05: 00 est défini comme le 26 juin 2009 à 17h00. Heure de l'Est. Voir l'annexe L: «Zones horaires» pour plus d'informations sur les zones de temps


J'ai essayé différentes combinaisons et j'ai toujours eu aucun résultat. Essayé 2013-04-08t15: 00: 00-07: 00 , également le même format dans UTC: 2013-04-08t22: 00: 00 + 00: 00 , et Le format de la table en PDF Vous m'avez rappelé avant: 2013-04-08T22: 00: 00.000Z . Tous les exemples pour 15h00 TPS (notre TZ local), qui est 22:00 UTC. Est-ce que je manque toujours quelque chose?


Est-ce toujours réagissant avec prêt à l'heure de coupure erreur? S'il vous plaît pastebin la demande et la réponse de 2013-04-08T22: 00: 00.000Z exemple.


Oui, le message d'erreur est toujours identique et d'autres champs sont également similaires, donc je ne la collage pas. BTW la plus ancienne heure que je puisse planifier le ramassage pour IS 11h00 UTC. Mes expériences montrent que cela fonctionne de la même manière pour 2013-04-08t11: 00: 00 + 00: 00 , 2013-04-08t11: 00: 00.000z et même 2013-04-08T11: 00: 00 mais renvoie Temps prêt non valide pour 2013-04-08t04: 00: 00-07: 00 . Ainsi, on dirait que TZ Info n'a pas vraiment d'importance mais compensé qu'ils utilisent est étrange.


Vous définissez le ReadyTimeStamp à 2013-04-08T04: 00: 00-07: 00 signifie que vous voulez le ramassage à 4am ? Peut-être essayez peut-être de définir le temps à l'intérieur du jour ouvrable. Par exemple 2013-04-08T09: 00: 00-07: 00 ou 2013-04-08T16: 00: 00.000Z . Notez que pour calculer l'UTC Time One doit soustraire le décalage de l'heure locale, par exemple. Pour "15: 00-03: 30" DO 15:00 - (-03: 30) pour avoir 18h30 UTC.


Désolé, j'ai écrit "plus tôt" au lieu de "Dernières". Donc, j'ai eu la durée de coupure 16:00 en PST (notre TZ local selon la doc), c'est 23h00 UTC. Maintenant, j'essaie de planifier le ramassage pour, disons, 14h00 PST, qui est 21h00 UTC. Mais en fait seulement 04:00 PST (11h00 UTC) fonctionne, tout ce qui est plus tard indique prêt après coup de coupure . On dirait que 11h00 UTC est un temps de coupage réel et je ne comprends pas comment ils calculent le décalage TZ pour mon TZ local.


> Mais en fait seulement 04:00 PST (11h00 UTC) fonctionne. Voulez-vous dire que votre demande est réussie, ou si vous obtenez Distribution non valide message d'erreur?


C'est ce qui est écrit sur ReadyTimeStamp Le temps doit être au plus tard que la curedoftime, qui peut être découverte avec le pickupavailabilityRequest. Peut-être essayez-vous juste avant le temps de coupage si vous le refusez 'T Déjà (je ne peux pas savoir exactement qu'est-ce que vous essayez, essayant de compter sur vos mots faisant référence à la pâtebine)?


D'ailleurs. Vous utilisez le (PHP FedEx API Wrapper) [ Github.com/jeremydunn/php- FedEx-Api-Wrapper] , non?


Comme dit en classe L'heure est l'heure locale du ramassage en fonction du fuseau horaire de l'expéditeur. La composante Date doit être au format: AAAA-MM-DD (E.G. 2006-06-26). Le composant TIME doit être au format: HH: mm: SS en forme de 24 heures. Les pièces de date et d'heure sont séparées par la lettre T (par exemple 2006-06-26T17: 00: 00). Parce que c'est une heure locale, aucun TZD ne devrait être inclus. Si un TZD est inclus, il sera ignoré et le temps traité comme local sur le code postal de ramassage.


Mon anglais est loin d'être parfait et peut-être que c'est pourquoi tous mes commentaires sont clairs. J'ai mis à jour la question pour vous donner une description plus détaillée de ce que j'ai fait. Non, je n'utilise pas d'emballage, peut-être que c'est une bonne idée d'essayer. Devis que vous montrez semble être à propos de l'horodatage prêt à la demande de disponibilité de ramassage et du même texte que nous avons déjà trouvé dans le Guide de développeur FedEx. P.s. Merci pour votre temps



1
votes

Si vous souhaitez passer la date dans la demande de service Web, l'heure date code> Type de données pour WSDL est

class DateTime2 extends DateTime {
    function __toString() { 
        return $this->format("Y-m-d\TH:i:s.000\Z");
    }
}

$date = new DateTime2();

$client = new SoapClient(
    "http://www.myos.it/sp/smartphonelayer.asmx?wsdl", 
    array("trace" => 1)
);

$result = $client->SetReservation(array("RDescription"=>"Giuseppe Silvestri",
                                        "RNumber"=>2,
                                        "RPhoneNumber"=>"3286026817",
                                        "RDate"=>$date.""));

echo "REQUEST:".$client->__getLastRequest()."<br>"; 

print_r($result);


0 commentaires

0
votes

Vous devez avoir une différence entre: A- quand le paquet est prêt B- temps de coupure C- Heure de fermeture de la société.

Par conséquent, si votre code postal a une heure de coupure de 16h00, votre colis doit être prêt avant cette heure et votre entreprise doit être ouverte à quelques heures plus tard.

Ma suggestion. Placez la Heure de la société à 19h00, le dernier temps de pick-up FedEx est généralement à 17 heures pour tous les codes postaux. Ceux-ci 2 sont parce que lorsque vous demandez une pick-up, le Van Courier dispose de 2 heures pour aller à cet endroit, si le temps de votre entreprise est à seulement 1 heure de la demande de prise en charge, vous rencontrerez des problèmes.

J'espère que cela aide.


0 commentaires

1
votes

ReadyTimestamp dans la demande de CreatePickUp prend l'horodatage comme valeur

Exemple: 'ReadyTimetamp': '1404891463'

Cela fonctionnera


0 commentaires