When liquidating a subsidiary of a foreign corporation in Japan, you need to be careful about the timing of giving up loans by the parent company. It may cause a tax issue. You will need to forgive your loan to the liquidating company because it has to be positive in net asset for voluntary liquidation … Read More “Company liquidation debt waiver and corporate tax” »
Year: 2017
Some people still believe that it would be a wise idea to buy a zombie company with NOL (Net Operating Loss) and use it to offset against his business income in future. It seems a good idea because you will be able to reduce the tax burden by using NOL when your business turns profitable … Read More “NOL (Net Operating Loss) not allowed to be used under certain situations” »
朝の5時18分の中央線に乗って、途中高尾で6時13分に到着。1分で乗り換えて、7時20分過ぎに塩山に到着しました。 7時30分発のバスで大弛峠に8時50分に到着しました。JRが山手線から1900円くらい、バスが途中の柳平での乗り換えを含めて1800円です。バスの席に限りがあるので、予約が必要です。 マイカーでも行けますが、大弛峠に駐車場がほとんどないので、多くの人が路上駐車をかなり離れたところまでしています。車で行く人は最低でも8時前にはつかないと、駐車の場所探しに苦労しそうです。 金峰山は天気が晴れると、富士山から、八ヶ岳や南アルプス、北アルプスまで見える事があり、最高です。今回はお天気に恵まれました。日頃の行いが評価されたと思われます。 こちらは北方向に見える八ヶ岳。 西には南アルプスもくっきり見えました。 明るい森の中の道を2時間歩きます。途中一度下りを挟んで尾根道を登って行くと突然視界がひらけて、頂上付近です。頂上付近は大きな岩が多く歩きづらいです。 金峰山の標高は2599メートルであと1メートル2600メートルに足りません。でも、奥秩父の山も金峰山や甲武信岳、国師岳など2500メートル超えがいくつもあるようで、知りませんでした。北アルプスや八ヶ岳に比べても同じ高さでも地味な印象なのは森林限界が高いからかもしれません。今回の金峰山も頂上の下50メートルが森林限界です。国師岳や奥千丈岳は本当に頂上の周辺だけギリギリ視界がひらけます。 私はバスの時間まで時間が余ったので(帰りも予約が必要)、大弛峠から反対側の奥千丈岳に登ってきました。ここは奥秩父の最高峰で2601メートルです。こちらは往復で2時間かかりません。 こちらは奥千丈岳から見た金峰山。五丈岩がはっきり見えます。 下りの途中にかなり植物に詳しいおじいさんに希少な高山植物のレクチャーを受けました。こちらの花はヒメイチゲと言うそうで、オオサンショウウオ並みに希少なそうです。世の中色々な分野に詳しい方がいらっしゃいます。 14時半には大弛峠に戻って、14:50のバスに間に合いました。
This post is about claiming refund of Japanese Consumption Tax. The rule about Japanese consumption tax is complex at first glance. If you are not a law person or accounting person, you may want to leave this matter to your accountant. But there are not that many that you need to know. Actually, you only … Read More “Ex-work is not what you want for consumption tax refund” »
どのような時に恒久的施設(PE)があると認定されるか その昔の話ですが、PEが日本にあるのではないかと税務当局より指摘があったことがありました。 私のそのお客様は日本とヨーロッパの両方に会社(それぞれJ社とE社)を持っていて、日本で機械を仕入れて、ヨーロッパのお客様に販売していました。私は当時知らなかったのですが、お客様は日本の会社の社長であるばかりでなく、ヨーロッパの会社の社長も兼ねていました。 ビジネスの仕組みはいたって簡単で、日本で購入した特殊な機械を、ヨーロッパで販売すると言うものでした。まずJ社がE社に商品を販売し、E社はそれなりのマージンを抜いて、E社のお客様に売ると言う仕組みです。 緑の線が形式上の取引の流れで、赤線が実際の物の流れです。 ここに税務調査が入りました。そこで問題になったのが、E社が何者かと言うことでした。J社とE社は名前が似ていたので、関係があるらしいことは伺い知れました。税務調査では、この会社がどんな会社であるのかが調べられました。どこに所在するのか、社員は何人くらい居るか、資本規模はどれくらいか、売り上げはどれくらいで、つまり実体はあるのか。また、E社ではどれくらいのマージンが形状されて、その先のヨーロッパのお客様に売られているのかが調べられました。 その過程で、E社は社長が保有して居る会社で、他にあまり(もしくはほどんど)ビジネスはしていないこと、従業員はいないこと、J社の社長はE社の社長でもあること、本社はとある会計事務所に登録されて居ることがわかりました。 一連の取引は仮装ではないかとの主張も当局からされましたが、E社が金融機関からJ社のための資金調達をして居ることや、J社のウェブサイトを運用して居ることから、ファナンスとマーケティングの機能は少なくともやって居るとの納税者側からの主張はなんとか認めていただく事ができました。 ただ、J社の社長がE社の恒久的施設(PE)になるのではないかとの指摘があり、これは受け入れざるを得ませんでした。 PEは、租税条約によって異なるので、外国会社の日本の拠点がPEに該当するかは、相手国によって異なる可能性があります。ただ大枠は国際的にコンセンサスが取れていて、情報収集を目的とする駐在事務所や、外国にある本社のために仕入れをするための商品倉庫などは該当しないことになっています。他方、登記の有無関わらず支店はもちろん、自社の製品やサービスを契約できる代理人もほとんどの租税条約でPEに該当することになっています。 国税局などの実際の税務調査での確認事項を見ると、実務上では、契約を締結できる権限があるかどうかの判定として、見積もりは誰が作成して居るか、契約の受注は誰が受けて居るかが重要視されて居るように思います。つまり、本社が日本に人(本社の社員ではなく、業務委託料をもらって居る場合で)が置くのは、最終的には本社の製品を日本人のお客様に売るためですが、その人が実際に見積もりを本国に依頼して作ってもらって、日本のお客様に渡して居るのか、それとも実はその人が作ってしまって居るのか、メールなどの証拠の提出を求められる事がほとんどです。 メールなどで、日本の担当者が見積もりや契約を締結していて、本社にはその報告して居るだけのようなメールが出てきてしまうと、PE認定一直線になってしまうので注意が必要です。 その他に、外国会社がインターネットを通して日本に物品を販売する場合に、日本にインターネット・サービス・プロバイダーのサーバーにホストされてイるウェブサイトを通じて、物品を販売しても、日本にPEがあるとは通常認定されません。日本で自前で場所を借りてサーバーを設置して居るような場合は、恒久的サービスがあることになります。 PEと認定された場合にどのように所得を計算するか この話は、本社のPEが日本にあるかどうかの話なので、PEの所得をどのように計算するかと言う話とは別なので注意が必要です。 PEで課税される所得は通常、そのPEに帰属する帰属主義に基づいて計算されます。つまり、外国の本社が直接にやって居る取引は、日本のPEに帰属しないので、日本での所得ではありますが、PEに納税義務は発生しないと言う事です。さっきの例でいうと、日本のPEとは別に本社が直接にインターネットサイトかなんかで販売している商品の利益はPEに帰属しないので、日本で法人税の納付は必要がないことになります。 ただし消費税については、PEの有無に関係なく納税義務が発生するので注意が必要です。
Herokuを使ってサービスを作ると、どうしてもストーレッジの問題にぶつかります。Herokuはいいと思うのですが、ストーレッジがないのです。実は知られているようで、結構な数の人が知らなかった落とし穴でもあるようなのですが、Herokuでは画像が保存できません。OSとPythonやRubyなどの言語とデータベースは提供してくれるのですが、画像は保存できないのです。私はこれを知らなかったので、かなりびっくりしてしまいました。。 そこで仕方がなくAWSを始めることにしたのですが、このAWSのs3というサービスがかなり良いので、かえってよかったと思っているところです。 ご存知の方も多いと思いますが、HerokuはPaaSと呼ばれるWebサービスの一種で、ハードディスクのサーバーと、UbuntuなどのOS、それにデータベースやPythonなdの言語、各種のライブラリをまとめて提供してくれます。 私は開発環境がMacなので、自分のところのサーバーもMacでやれば、本番と開発環境が一緒なのでやりやすいのではないかと、色々迷っていました。パーミッションなどの扱いやすさは、手元で実際にいじれる実機のサーバーの方がわかりやすいですし、コストも実際にサーバー機を買ってしまってもそれほどのものではありません。ですが、Herokuなどのクラウドを使うと、12factor.netなどに書いてある設計上のデザインパターンに自動的に従うことになると言うのに惹かれてHerokuでやってみることにしました。やはりサービスが段々大きくなっていった時にメンテナンスが楽な方がいいですものね。それとやっぱり自己流でやるよりは、信頼性と実績の面からもで世の中で通用しているものでやってみる方が良いのかなと思いました。 s3の良いところは、まず、値段です。1GBあたりの料金は一月で約3円。データが100GBでも月300円です。私の事務所では領収書の画像データを仕訳データに翻訳して、画像と仕訳を一緒に整理して保存するサービスを提供しようと思っていますが、iPhoneで撮影した写真だとデータのサイズは約3MBです。ですので300枚保存してこれでやっと1GBで、これで、3円です。100GB使おうと思ったら、30,000枚の写真データを保存することが出来ますが、これで小さい会社なら20社分は行けるのではないでしょうか? 次に、信頼性。これは、Amazonの説明によると99.999999999%の信頼性があるのだそうです。 小数点以下に、9が9個つくので、データが消失する可能性は、1000万分の1と言うことでしょうか。自分のところでサーバーを持ってデータを保存するより、よほど高い信頼性です。使わない手はないですね。 その他、Pythonのboto3をはじめ、RubyやJava、.NETなどの他、おそらく、ほとんどの言語でファイルや閲覧権限等を簡単に操作できるモジュールが用意されています。プログラムの側から簡単にファイルをアップしたりダウンロードできたりするのです。ここだけ見ても、自分でファイルの保存や権限の設定をプログラム的に作るよりよほど簡単で確実です。ソフトウェアの世界に限りませんが、「巨人の肩に乗る」と言う言葉があります。 こう言う新しいもの(全然新しくないけど)はお金を出してもどんどんやってみる方がいいですね。
PyCharmは買う価値があるでしょうか。 使って1ヶ月くらいが経ちますが、私は買ってよかったです。多分、この1ヶ月でも十分に元は取れています。その前は、3−4ヶ月はAtomを使っていたのでよくわかります。やっぱり効率性が劇的に上昇しています。もう、PythonをやるのにAtomには戻れません。どうせプログラミングをするなら、良いツールを使うほうがいいです。効率性が素晴らしい。 Atomとは色々違うのですが、まず、デバッグが出来るようになるのが大きいです。Atomで作った場合は、Atomはエディタですから、直接実行することは出来ません。ターミナルから実行して、エラーが出たら、エラーのログをみて何が悪かったかを解析しなくてはいけません。 PyCharmならブレークポイントを設定できます。エラーが出る場所で、ブレークポイントで実行を停止して、各変数にどのような値が入っているかを確認できます。私が知っている範囲では、Atomのプラグインでは逆立ちしてもそんなことは出来ません。 PythonやRubyなどのスクリプト言語は静的型付け言語に比べて、文法チェックが事前にないところが弱点だと思っているのですが、PyCharmはインスタンスが割り当てられていない変数などに赤の波線を引いてくれます。これで実行する前にある程度のバグの元は潰してくれるんですね。 名前をまとめて変えてくれるリファクタリングの機能もあります。個人的に気に入っているのは、ある変数にマウスのポインタをあてると、同じスペルの変数が全部ハイライトされます。これが、コードの流れを追う時にとても楽になるので助かります。 この他にもテストなど、まだわかっていない機能が色々ある様です。 確かに、最初は有料のツールは躊躇すると思います。なので、最初の数ヶ月をAtomでやって、PythonやらDjangoなどのフレームワークをやっぱり自分ががちゃんと使うと言うことがわかってから買うのでも遅くはないと思います。それに、Atomなどのエディタで開発すると、その手作り感で、どの様に動くのかわかリます。それからPyCharmなどのIDEに移行するのでも遅くはないと思います。 ちなみに私は、もう、Atomに戻ることはなさそうです。
Herokuを使ってWebサービスを作るのは手軽にできると宣伝されていますが、実はかなり高度な知識が必要です。Herokuのアカウント自体は簡単に開けられるかもしれないけど、実際にサービスを公開するには、Linuxやデータベース、RubyやPythoなどの言語で一通りのコードがかけること、HTMLやCSS,JavaScripなど、広範囲の知識が必要です。これをさらに、iPhoneやAndroidなどの端末で使えるようにしようとすると、SwiftやAndroidなどの端末側のプログラミング言語の知識も必要になります。 さらに、Herokuの場合は、解説がほとんど英語なので、英語が結構得意でないと、解説を読むこと自体が億劫になってしまいます。もしくは、それを上回る熱意とか根性が必要でしょう。 最近、Herokuでは画像ファイルが保存できないことを発見したと書きましたが、Herokuでやることで、ソフトウェアが他の環境にデプロイしやすくなるなど、設計上のメリットがあることがわかったので、最近の定番っぽいAWSのS3(Amazon Web Serviceの中のストーレッジの機能)ではどうやるのかを調べてみました。 ジャジャーン。 A file is selected for upload by the user in their web browser; JavaScript is then responsible for making a request to your web application on Heroku, which produces a temporary signature with which to sign the upload request; The temporary signed request is returned to the browser in … Read More “HerokuとAWSのS3を使ってWebサービスを作るには” »
Djangoでアプリを作りましたが、これを公開するのにローカルのマシンを使うか、クラウドを使うかで迷いました。 そこで、どちらが良いのかメリットとデメリットをそれぞれあげて、有利不利を検討してみようと思います。 まず、コスト ローカルでやる場合には、開発と同じ環境の方が楽です。私はmacのノートで開発しているので、Mac Miniサーバーを考えています。ツールを入れる手順などが、開発環境と全部一緒にできるので、かなり楽だと思うのです。値段も、一番安いもので5万円くらい、CPUがいいものでも7万円ちょっとです。他のことにも使えますから、それほど高い買い物とは言えないと思います。 次に、クラウドです。今回のアプリは領収書の画像を保存するのでデータの保存量がだんだん大きくなっていきます。一枚の領収書のデータサイズを1MBとして、1000枚で1Gです。1年に1,000枚として、お客様1件で1GBという計算になります。 簡単な計算ですが、100件のお客様に使用していただくとすると、100ギガですが、アマゾンのS3の料金表を見ると最初の 最初の50TBまでは、1GBあたり月$0.025ドルだそうです。つまり、1件につき月3円、100件で300円、年間でも3,600円です。べらぼうに安いですね。 ソフトウェアの設計の良さ 次にソフトウェア自体の作り方ですが、クラウドを使うことによる大きなメリットがあります。このメリットはある文章を読むまで私も意識していませんでした。 Herokuでサービスを公開する場合、色々面倒くさい設定が必要になります。例えば、まず本番環境に展開する場合には、Githubを通してpushする必要があります。また、依存関係のあるモジュールをあらかじめリストアップして置く必要があります。また、Hrokuでは画像ファイルを保存することができないので、AmazonのS3などの外部ストーレッジを利用する必要があります。 かなり面倒くさいのですが、Herokuで展開する過程で、Herokuの提唱するソフトウェアを効率的に開発するための12の提言に自動的に準拠することになります。この12提言は12factors.netとサイトで公開されています。この12提言がいいのです。 例えばですが、以下の通りです。 1.) セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 2.) 下層のOSへの 依存関係を明確化し、実行環境間での 移植性を最大化する。 3.) モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 4.) 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイを可能にする。 5.) ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップできる。 この観点からはクラウドでやる方が圧倒的によさそうです。 簡単さ 短期的にはローカルの方が簡単かもしれません。ディレクトリ構造は自由に変更できるし、DBなどのインストールも自由です。開発と本番環境も、例えばサーバーでmac miniを使えば同じになります。使い慣れている環境の方が、学習コストも少ないのでツールなどは使いこなしやすいです。 上記の比較からは、クラウドの方がよほど有利に見えます。私は、新しいサービスは、とりあえずローカルではなく、クラウドで始めてみようと思いました。
ヤマト運輸の中興の祖である小倉昌男の「経営学」という本を本棚から取り出して、久しぶりにパラパラとめくってみました。その中で、小倉昌男が牛丼の吉野家の経営で、商品を牛丼一本に絞り込んだ話に感銘を受けたことが書いてありました。 商品を一本に絞り込むことで、仕入れ単価も下がるしバイトでも簡単にメニューが作れるようになり、吉野家は利益が出る体質になったというのです。 そこで、ヤマトもそれまでの企業向けの大口の物流から一般消費者向けなどの小口の宅配に大きく舵を切り事業を。そして、事業が大きく成長したと言います。 ですが、世の中みんなが知っている通り、実際には、今日の吉野家もヤマトも事業を一本に絞っていないように見えます。吉野家には牛丼だけではなく、牛鍋定食も豚丼もあリます。一体、事業を一つに絞るのがいいのでしょうか、それとも、関連する範囲で、または、関連しなくても、利益が出るのであれば色々やる方がいいのでしょうか? 私の思うこの問いに対する解答は、一人なら1種類に絞るべき。複数人でやっていて、既存のお客さんからのニーズで自分の本業以外の問い合わせがあった時に、誰かにお願いできるなら、それを受けてもいいということでしょうか。 やはり、一般論としては、事業規模が少人数の場合、特に自分一人とアシスタントと二人のような場合には色々と手を出すべきではないということでしょう。自分や自分の会社があえてやらなくても、世の中には自分たちよりその事をうんと上手に出来る人達がいます。他の誰かがより上手く出来ることは、その他人の会社に任せてしまって良いのです。世の中は広いので、自分が得意でないことは、あえて自分がやる必要性は世の中の道理としてもありません。 例えば、私どもの事務所でビザの事をよく聞かれるので、自分たちでやってもいいのではないかとも思ってしまったりもします。でも、待てよ。よく考えると、ビザのことは自分たちより上手に出来るところは沢山あります。そこが儲かってて、それをみて参入するならともかく、そうでないなら、経験が足りなくて、効率も知識も足りない自分たちがやる必要はないのではないか、と思うに至りました。