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>
4 Réponses :
Avez-vous remarqué que le ReadyTimeMestamp Code> dans l'exemple
<q0:ReadyTimestamp>2011-08-02T08:00:18.282Z</q0:ReadyTimestamp>
<q0:CompanyCloseTime>17:00:00</q0:CompanyCloseTime>
Pas sûr de ce que vous voulez dire. J'utilise origindetail / ReadyTimeMestamp Code> dans la demande de prise en charge et
packagereadyTime code> 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 B> Tableau 32 code>, mais vous utilisez des éléments de Demande de disponibilité de ramassage b>
Tableau 26 < / code>
Vérifié votre demande sur le pastebin code>, 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 CODE> pour une raison quelconque, mais tous les autres horodatages sont spécifiés pour contenir des informations TZ. shiptimestamp b>
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 CODE>
J'ai essayé différentes combinaisons et j'ai toujours eu aucun résultat. Essayé 2013-04-08t15: 00: 00-07: 00 code>, également le même format dans UTC:
2013-04-08t22: 00: 00 + 00: 00 code>, et Le format de la table en PDF Vous m'avez rappelé avant:
2013-04-08T22: 00: 00.000Z code>. 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 code> erreur? S'il vous plaît pastebin la demande et la réponse de
2013-04-08T22: 00: 00.000Z code> 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 code>,
2013-04-08t11: 00: 00.000z code> et même
2013-04-08T11: 00: 00 code> mais renvoie
Temps prêt non valide code> pour
2013-04-08t04: 00: 00-07: 00 code>. Ainsi, on dirait que TZ Info n'a pas vraiment d'importance mais compensé qu'ils utilisent est étrange.
Vous définissez le ReadyTimeStamp CODE> à
2013-04-08T04: 00: 00-07: 00 Code> signifie que vous voulez le ramassage à
4am code>? 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 code> ou
2013-04-08T16: 00: 00.000Z code>. Notez que i>
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. Code>
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 code>. 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 code> message d'erreur?
C'est ce qui est écrit sur ReadyTimeStamp CODE> Le temps doit être au plus tard que la curedoftime, qui peut être découverte avec le pickupavailabilityRequest. I> 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. Code>
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
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);
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é. P>
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. P>
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. P>
J'espère que cela aide. P>
ReadyTimestamp dans la demande de CreatePickUp prend l'horodatage comme valeur p>
Exemple: 'ReadyTimetamp': '1404891463' P>
Cela fonctionnera p>
Le temps que vous envoyez dans la demande est-il correctement formaté? J'ai vu 2013-04-02T13: 00: 00 NS1: ReadyTimetamp> code>, 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. Code>
@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 B> Le ramassage peut être programmé pour le la prochaine journée d'activité i> ou tout jour ouvrable jusqu'à 2 semaines avance. Un pick-up a FedEx Ground ne peut pas être programmé B> pour le jour actuel i>.
OK, il existe deux types de
pickupRequestType code> dans la requête PickUpUpAvailabilité B>. Type de demande Les valeurs valides sont:
même_day code>
futur_day code>. Avez-vous essayé de demander la disponibilité de ramassage avec un
Valeur code>? Je pense que le
cutofftime code> pourrait différer.
@fitheflow Vous avez raison, pour
Future_day Code> 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 code> et
idem_day code> car cela n'affecte pas la demande de prise en charge.
même_day code> 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 code> 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? I> Oui, vous avez raison et, comme il est indiqué que vous ne pouvez planifier que le pick-up au sol b> pour le Le lendemain, vous devriez essayer d'utiliser le CUTOFFTIME B> GENTÉ DE LA DEMANDE DE DISPONIBILITÉ DE PICKUPT AVEC LA VALUE CODE> PICKUPREQUESTYPE CODE> SET TO
Future_Day code>.
Accesstime Code> 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 code>).