amazon.comでの支払いは外貨円貨どっちがお得なのか

amazon.comでの買い物は円貨での支払いが可能だ。

TTSでレートが111.96の日の

amazon.comでのレートが115.57

だったので、amazonの手数料はおおよそ3%。

%e3%83%ac%e3%83%bc%e3%83%88amazon2

 

円貨はやめて、そのまま外貨で購入し、後日カードの請求を見てみたところ

レートは113.52であった。amexの外貨取扱手数料を公表されていないが、今回の結果では1.3%。

%e3%83%ac%e3%83%bc%e3%83%88amex2

amazon上で円貨で払うより、カード会社に円貨精算を任せたほうがお得である。

 

 

TTSは三菱UFJ銀行のものを取っておいた。

%e3%83%ac%e3%83%bc%e3%83%88tts2

 

 

 

 

ebayの役立つツール

https://developer.ebay.com/tools

staticshot_15-07-2018_17-35-54

Solve Problemsの中

①Get eBay Metadata Tool

サイトで使える列挙値を調べられる。例えばオーストラリアにおいてShippingServiceDetailsに使える値はなにかということを調べられる。

アメリカではinternationalのshipping detailで下記を指定できるが、

OtherInternational,  StandardInternational,  ExpeditedInternational

オーストラリアではエラーになる。代わりに指定できるもので近そうなのは下記になる。

AU_IntlEconomyTrackedNoSignature,  AU_IntlStandardTrackedSignature,  AU_IntlExpressTrackedSignature

 

 

②Item Specfics Lookup Tool

categoryごとで要求されるitemspcificを確認できる。またカテゴリー番号をてっとり速く探すことにも適している。

 

 

 

ebay api呼び出し制限

最近ebayの挙動が不安定であり、時々下記メッセージが帰ってくる。

Your application has exceeded usage limit on this call, please make call to GetAPIAccessRules to check your call usage.

これを機に、色々調べてみた。

 

まずはメッセージにある通り、GetAPIAccessRulesを実行。大した情報じゃないんだから普通にwebに掲載しておいてくれればいいのにという内容。

xmlで帰ってくるのだが、単純な構造なので、2次元に整形したのが下記。

CallName CountsTowardAggregate DailyHardLimit DailySoftLimit DailyUsage HourlyHardLimitHourlySoftLimit HourlyUsage Period PeriodicHardLimit PeriodicSoftLimit PeriodicUsage RuleCurrentStatus RuleStatus
ApplicationAggregate TRUE 1,500,000 1,500,000 2 1,500,000 1,500,000 2 -1 0 0 0 NotSet RuleOn
AddItem FALSE 5,000,000 5,000,000 0 5,000,000 5,000,000 0 -1 0 0 0 NotSet RuleOn
LeaveFeedback FALSE 1,500,000 1,500,000 0 1,500,000 1,500,000 0 -1 0 0 0 NotSet RuleOn
RelistItem FALSE 5,000,000 5,000,000 0 5,000,000 5,000,000 0 -1 0 0 0 NotSet RuleOn
GetAPIAccessRules FALSE 1,000 950 0 1,000 950 0 -1 0 0 0 NotSet RuleOn
SetApplication FALSE 5,000 5,000 0 5,000 5,000 0 -1 0 0 0 NotSet RuleOff
GetNotificationPreferences TRUE 10,000 10,000 0 1,000 1,000 0 -1 0 0 0 NotSet RuleOn
SetNotificationPreferences TRUE 1,500,000 1,500,000 0 1,500,000 1,500,000 0 -1 0 0 0 NotSet RuleOn
PasswordAuthenticationLimiter TRUE 0 0 0 0 0 0 -1 0 0 0 NotSet ApplicationBlocked
NonUTF8UsageLimiter TRUE 0 0 0 0 0 0 -1 0 0 0 NotSet ApplicationBlocked
GetNotificationsUsage TRUE 1,000 1,000 0 50 50 0 -1 0 0 0 NotSet RuleOn
LegacyXmlEnforcementSoft TRUE 0 0 0 0 0 0 -1 0 0 0 NotSet ApplicationBlocked
LegacyXmlEnforcementHard TRUE 0 0 0 0 0 0 0 0 0 0 NotSet ApplicationBlocked
GetSearchResultsExpress TRUE 10,000 10,000 0 10,000 10,000 0 -1 0 0 0 NotSet RuleOn

肝心のGetOrdersはなかった。。。

 

次にapiの制限が書かれている下記ページ

https://developer.ebay.com/support/api-call-limits

GetOrdersが所属するTradingApiは1,5百万。制限に引っかかるわけないのだが。内部で細分化されているのか。。。

 

 

最後に自分のapi状態が見える下記ページ

https://developer.ebay.com/my/stats?index=0&env=production&start=2018%2F07%2F13+22%3A00&end=2018%2F07%2F14+22%3A00

staticshot_15-07-2018_17-26-49

時間はPST(カリフォルニア時間)で指定する。

GetOrdersは24時間で4,000以下。大したことはない。。。

 

品質

去年度より進めて来たリリースに至る手順見直しで、本年度前半は大きな障害もなくシステム稼働できた。

また、ユーザの皆様より頂いた、amazonの送料の考え方の変更、amazon_au、ebay_au,motor対応、郵便局集荷見直し対応、輸入、メール管理機能など実装対応することができた。

 

一方webシステム以外のところでは、サーバ代金の支払いのクーポン期限を逸したり、財布を落としたりと、重大なミスが多い前半戦だった。(優しい人のおかげで両方とも大事にはいたらず)

 

なかでも、やってしまったのは、

ネムが必要だったのに、ネモを買ってしまったことだ。

思い返してみれば、物販のお姉さんも「緑で大丈夫ですか」と言っていた。ここでミントグリーンと言わなければならなかったのである。

dav

貼った後気がついた。しばらく唖然としたのち、これはこれで良く、むしろ自分をnemo推しへと変容していくのがいいのではと感じた。

 

2017年はもがを失って大変だったと思うが、今では、色々な葛藤をすべて昇華させているように見える。ちゅるりちゅるりらも歌ってたし。

 

彼女らは前しか向いていないのである。

ebayapiのwsdl

2018/7/10、日本時間午前中より

ebayのfiletransfer apiで下記のエラーが出て、まったくfileを受け付けなくなった。

 

Exception in thread “main” com.sun.xml.ws.streaming.XMLStreamReaderException: XML reader error: com.ctc.wstx.exc.WstxEOFException: Unexpected EOF in prolog
at [row,col,system-id]: [1,0,”http://developer.ebay.com/webservices/file-transfer/latest/FileTransferService.wsdl”]

 

エラーはebayから提供されているLMSClientJobsライブラリの内部で、手が出しづらい。

エラーの内容を素直に読み取るとprologで変なEOFとのことで、wsdl周りを色々試して、試行錯誤すること2時間。

FileTransferService.wsdlをローカルにおいて読み込むようにしたら、上記エラーを回避できた。

proxy使ってないし、なぜ、急にこうなってしまったのか。

ebayapiが不安定

ebayapiが不安定である。

bulkdataexchangeからのfileuploadで、ここ数日エラーが出まくりである。

 

①Please specify a File with Valid Format

謎である。具体的なエラー内容は通知されない。当然xmlとしてはvalidなものである。全く同一のファイルでも時間帯によっては通ったり通らなかったり

 

②There is failure during file upload and post-upload checking

謎である。具体的なエラー内容は通知されない。なおこの後、abort jobをすると下記が出る。

The job is already in terminated states such as completed, failed and aborted

 

③The File Upload is already in progress

謎である。もちろん同じfile reference idを指定するようなことはしていない。

 

④Client received SOAP Fault from server: Error reading from XML stream: Read timed out Please see the server log to find more detail regarding exact cause of the failure.

アップロード中にタイムアウトする。大体リトライすれば2回目は成功する。

 

⑤The file has already been uploaded

どうも④の後に発生するぽい。④でエラーで処理されているが、実はファイルアップロードは完了しているということか。。。

 

maru9としては、とにかくエラーになったら、abort jobして、即リトライ。

これで、大半はうまくいくが、

①だけは、うまくいかない。signの計算方法でもまちがえているんじゃないか。。。