Про процесс получения дохода в валюте — это всё понятно. Вопрос вызвала фраза: «можно не подавать никаких деклараций». Как это возможно, если при любом раскладе получается доход, не соответствующий виду деятельности по патенту?
Плюсы. Если ИП не ведет никакой деятельности, кроме той, на которую куплен патент — можно не подавать никаких деклараций. Заплатил взнос и стоимость патента, и на этом все.
А что делать с валютными доходами на патенте? Налог на курсовую разницу при любых обменах начисляется на УСН, даже если платёж получен по патенту. Аналогично про процент, начисленный банком по открытым счетам.
Лично для себя, думаю, что чаще всего буду использовать docopt. По программисткой привычке обычно открываю скрипт, прежде чем запустить. В docopt описание гарантированно будет написано именно так, как оно предлагается пользователю. В прочих случаях описание надо либо дублировать (почти наверняка не будет полностью соответствовать), либо надо читать размазанную таблицу argparse (дублирование документации тоже не исключено). argparse vs docopt — это, скорее, вопрос важности автоматической валидации типов.
У графиков Plotly будут скроллеры, зум и пр. Также DataFrame при выводе в Notebook отображается со скроллерами. Но только первые и последние строки.
На счет статьи по интерактивному интерфейсу, до нового года взяться не готов. У меня по плану в этом году — генераторы статических отчетов и веб-сервисы. Думаю, нам надо заводить клуб джулиистов и распределять интересные темы по авторам :)
Откровенно говоря, пошаговый отладчик — это вопрос привычки. Отладочная печать типа "@show" и "@debug" доступна в любом случае. А если разрабатываете в Atom/Juno, то есть возможность запустить выделенный фрагмент кода. Когда разрабатываете плоский скрипт, где используется минимум вложенных функций, то проблем нет вообще. Просто выделяете кусок кода и запускаете. Или вбиваете код в REPL, который находится тут же в среде разработки. Сессия со всеми переменными сохраняется до тех пор, пока её явно не перезапустите. То есть работает всё очень быстро. Плюс Juno отображает все выставленные переменные. Сложнее, когда надо отлаживать модули с большим количеством функций. Но и тут, вопрос лишь в стиле написания кода и его адаптации под отладку без пошагового отладчика. Например та самая рекомендация, что функции должны быть короткими. А их запуск в любом случае будет прописан из юнит-теста (в норме, все модули обязаны их иметь), который можно запускать из Juno.
Не стоит демонизировать налоговую. Безусловно, область получения зарплаты на иностранные счета — это серая область законодательства. Никто в налоговой не знает что с этим делать. Слишком мала база для этого. Тем не менее:
Гражданам РФ запрещено получать валютные переводы от иностранцев на счета физ. лиц в РФ
Гражданам РФ НЕ запрещено работать за пределами РФ.
Получение зарплаты от иностранных компаний в этом случае возможно лишь на иностранные же счета
Как следствие, доходы, которые похожи на заработную плату, не будут вызывать вопросы у налоговой. И я не знаю случаев, чтобы кому-то наложили штраф именно за получение зарплаты на иностранный счёт, да и как его потом взять с иностранного же банка.
Также формально нигде не сказано, что лицо, которое работает на иностранную компанию, не имеет права делать это с территории РФ. Налоговая не проверяет сроки пребывания за границей, поскольку не связана с миграционной службой. Однако, если доходы есть, а за границей не был, то это может вызвать вопросы. Если же за границей находился, то доказать, что там не работал, уже вряд ли кто-то сможет.
Соответствеено, каким образом налоговая сможет наложить штраф на зарплату, полученную на иностранный счёт (разрешенный тип операции), и как в суде она сможет мотивировать, что это не зарплата? И зачем вообще налоговой ввязываться в это гиблое дело, если можно просто получить 13%? Заметьте, я не рассматриваю неуплату налога. Это уже другая статья, не имеющая отношения к валютному контролю.
Касаемо сроков пребывания за границей, то расчёт очень прост. Зп программиста $150-200к в год, хотя и не является средней, однако реалистична. Соответственно, если находился за границей месяц, то сумма зп по декларации за год 20-40 тыс. вряд ли вызовет у кого-то вопросы. А если и вызовет, то, опять же, доказать обратное в суде налоговая не сможет. Вопрос чисто порядка сумм.
Но в любом случае, ИП обходится дешевле, чем уплата налогов с иностранных счетов. Кроме того, открытие иностранных счетов, сама по себе, не самая простая задача.
У меня личный опыт того, как это делается.
«Мужик в прошлом году» получил штраф при переводах между банками РФ. А тут мы обсуждаем получение заработной платы на себя (первый пункт из той самой 12-й статьи) на личные иностранные счета от иностранных компаний. И это не тот случай нарушения валютного законодательства, когда кто-то хочет получить на валютный счёт физ. лица банка РФ некие валютные переводы от иностранных компаний.
Иностранные банки находятся вне РФ и заморозить что-либо в них по требованию ФНС невозможно. Я согласен с тем, что вопросы возникнуть могут, но, почти уверен, что если суммы более-менее соответствющие заработной плате, претензий у налоговой не будет. Единственное что могут пытаться оспорить — это то, что деньги получены не как заработная плата. Но зачем им это, если Вы добровольно пришли с декларацией доходов.
Если находитесь хотя бы месяц в году за пределами РФ, то основнанием получения денег можно декларировать получение заработной платы. Независимо от совпадения или несовпадения даты пребывания за пределами РФ и получением денег. Впрочем, в качестве дополнительно защиты, не стоит переводить эти деньги на свои счета в РФ в текущем году. Подаёте на следующий год декларацию, уплачиваете налог, после этого делаете что хотите.
1. Возможность удаленной работы (перестаем быть налоговым и валютным агентом)
Для этого надо не находиться ни в одной стране больше 180 дней. Значит как минимум, 3 страны в год. В некоторых странах, для попадания в их налоговые интересы, достаточно и 3 месяца находиться.
2. Возможность получать деньги без соприкосновения с отечественными банковскими структурами.
Дойчебанк на его родине, например, даже счёт без регистрации по месту жительства не откроет. А для того, чтобы её получить, либо придётся селиться в мелком городе, где отсутствует очередь в соответствующее ведомство, либо будете месяц-другой ждать. Потом надо уведомить при отъезде, чтобы через год проблем не было. Да и справки в банк, всё равно придётся приносить. Иначе любые поступления из не задекларированных источников будут заблокированы.
В США без номера социального страхования большинство банков с Вами даже разговаривать не станет. А его, без постоянной работы и визы с разрешением на работу, никто не выдаст.
В целом, везде есть банки, которые согласятся открыть счёт иностранцу без регистрации. Но надежность сохранения денег под вопросом.
3. В конце-концов можно просто переехать и работать в иностранной компании
Деньги получать чемоданами? Иначе будете платить по местному законодательству. И это сильно больше 13% с иностранных счетов физ. лица. И сильно больше, чем у ИП…
Физ. лицо имеет право иметь иностранные счета. Они должны декларироваться, но право их иметь — есть. На них можно получать доход. Этот доход надо декларировать как доход, полученный на иностранные счета. Собственно, подаёте декларацию как физ. лицо. Налог 13% в переводе на рубли на дни начисления. Обоснование причин получения придумываете сами. Лишь бы все месяцы были закрыты, и суммы в валюте соответствовали выписке с банковского счёта. Перевод обоснования не требуется (проверка — это проблема налоговой). Но, по-большому счёту, их интересуют лишь суммы и даты, а не причины получения денег.
Причём самое главное — деньги могут оставаться в том банке, куда были начислены. Переводить в РФ их не требуется.
Недостаток тут только один. 13% в любом случае. Плюс проценты на перевод к нам и потери на конвертации в рубли, если они нужны. В случае ИП, если это не Москва, налог может быть меньше 1% (по патенту).
По-моему Julia уже достигла зрелости. Именно потому, для задач ML и обработки данных мы решили её использовать. Пару лет назад, вероятно, я бы согласился с python, но сейчас смысла его использования уже нет. Да и примеров уже достаточно. Хотя, в большинстве случаев, их надо искать. Иногда, чтобы понять, как сделать что-то для себя, надо смотреть код библиотек. Но тут — лишь вопрос программистской квалификации и способности быстро понять как оно должно работать. В целом, Julia не является каким-то принципиально новым языком программирования. Это просто переосмысление существующих моделей. Потому начать программировать на ней довольно просто.
В DevOps, не знаю где использовать… Но если есть задачи типа конвертировать какие-либо json, csv, прочие данные в другой формат, откуда-то прочитать, что-то куда-то загрузить, то она вполне может пригодиться. По крайней мере подобные скриптики мы тоже пытаемся делать.
Сейчас уже большинство популярных библиотек перенесли на 1.0. К слову, в Julia очень удобно проверять библиотеки при помощи встроенных тестов. Когда устанавливаете новый пакет, надо всего лишь набрать команду test ИмяПакета. Если всё в порядке, то можно использовать.
Касаемо графиков. Я использую Plots / GR. Каких-либо проблем сейчас не замечаю. Из прочих бакендов, см. http://docs.juliaplots.org/latest/examples/plotlyjs/ — интерактивные диаграммы для jupyter notebook. Из известных мне проблем, в plotlyjs поломаны полярные координаты. В остальном, работает.
И относительно того, как рисовать, Yermack написал серию статей, где, как раз, акцент на графику. Собственно, см. хаб https://habr.com/hub/julia/
Благодарю за отзыв! Ваши предыдущие статьи, откровенно говоря, и спровоцировали меня на создание учетной записи здесь и на написание этой статьи. Описание по примерам — это хорошо, но только для тех, кому примеры понятны. Для тех же, кому предметная область далека, весь текст может показаться слишком абстрактным, а возможности языка — какими-то надуманными "фичами", которые нужны только тем, кто понимает эту непонятную предметную область. Имено поэтому я и решил изменить контекст изложения и начать делать его в отрыве от предметной области, но с акцентом на то, как программировать. Впрочем, всего должно быть в меру, потому, безусловно, статьи с конкретными примерами тоже нужны и важны.
Julia — новый язык. На данный момент вряд ли ошибусь, если скажу, что специалистов по ней пока ещё просто нет. Сам я погрузился в Julia в августе, как раз под версию 1.0. До этого только читал обзоры. В следущем году специалисты уже точно будут. Технологии на Julia имеют явный потенциал. Впрочем, как раз сейчас, пытаемся делать сервисы обработки данных именно на Julia.
Кроме того, мы задумались о создании учебного курса для студентов 1-го курса технического университета, где Julia станет первым языком программирования. Она видится хорошим языком для изучения принципов алгоритмизации, а также в качестве языка для решения текущих студенческих задач.
Вопрос про сравнение с pandas я уже слышал… Но главный вопрос — критерии сравнения. Если вопрос про производительность — это сделать можно. Только надо подобрать наборы данных и операции, на которых сравнивать. Если же вопрос про языки запросов типа
x = @from i in df begin
@where i.age>50
@select {i.name, i.children}
@collect DataFrame
end
Касаемо сравнения производительности, почти уверен, что у pandas будет провал в том случае, когда добавляются сложные условия выборки, требующие выполнения питон-кода. У Julia всегда будет выполняться родной код.
Касаемо сравнения с numpy, тот же вопрос о критериях. Если сравнивать производительность прямо, то см. https://julialang.org/benchmarks/ Но вопрос, на сколько это реалистично отражает практические задачи. Если сравнивать чистые вычисления внутри Julia и внутри numpy, думаю, что для numpy не всё плохо. Если же появляются задачи, где данные надо использовать в нескольких библиотеках, которые не понимают numpy, или просто требуется их перепаковка из numpy-объектов в питон-объекты и обратно, получаются точки провала производительности. У Julia их нет, поскольку везде используется native-код.
Идея написать эту статью возникла как результат экспериментов с Julia. Не всем надо решать задачи физики или строить модели машинного обучения, но обработка табличных данных встречается часто. А потому это может стать той самой точкой входа, которая подтолкнёт к исследованию новой технологии.
В целом, жду отзывы, дополнения, замечания. Есть мысли сделать серию небольших заметок про Julia: по созданию скриптов (акцент на обработку аргументов), веб-сервисов, построению отчётов. Возможно, надо пояснить модель системы типов Julia. Поскольку язык новый, не думаю, эти вопросы совсем очевидны.
Если нужна скорость, то на Julia лучше писать сетевые сервисы, которые вообще не выгружаются из памяти и делают что-либо по запросу.
56 символов. И читаемость никуда не пропала.
К вопросу о лёгкой читаемости кода на питоне....
Это Ruby, если что...
А это Julia:
И во всех случаях всё прозрачно. Либо читаем последовательно, либо разворачиваем скобки в порядке вложенности.
А что делать с валютными доходами на патенте? Налог на курсовую разницу при любых обменах начисляется на УСН, даже если платёж получен по патенту. Аналогично про процент, начисленный банком по открытым счетам.
docs.juliaplots.org/latest/examples/plotlyjs, plot.ly/julia, randyzwitch.com/ECharts.jl/box
У графиков Plotly будут скроллеры, зум и пр. Также DataFrame при выводе в Notebook отображается со скроллерами. Но только первые и последние строки.
На счет статьи по интерактивному интерфейсу, до нового года взяться не готов. У меня по плану в этом году — генераторы статических отчетов и веб-сервисы. Думаю, нам надо заводить клуб джулиистов и распределять интересные темы по авторам :)
Откровенно говоря, пошаговый отладчик — это вопрос привычки. Отладочная печать типа "@show" и "@debug" доступна в любом случае. А если разрабатываете в Atom/Juno, то есть возможность запустить выделенный фрагмент кода. Когда разрабатываете плоский скрипт, где используется минимум вложенных функций, то проблем нет вообще. Просто выделяете кусок кода и запускаете. Или вбиваете код в REPL, который находится тут же в среде разработки. Сессия со всеми переменными сохраняется до тех пор, пока её явно не перезапустите. То есть работает всё очень быстро. Плюс Juno отображает все выставленные переменные. Сложнее, когда надо отлаживать модули с большим количеством функций. Но и тут, вопрос лишь в стиле написания кода и его адаптации под отладку без пошагового отладчика. Например та самая рекомендация, что функции должны быть короткими. А их запуск в любом случае будет прописан из юнит-теста (в норме, все модули обязаны их иметь), который можно запускать из Juno.
Как следствие, доходы, которые похожи на заработную плату, не будут вызывать вопросы у налоговой. И я не знаю случаев, чтобы кому-то наложили штраф именно за получение зарплаты на иностранный счёт, да и как его потом взять с иностранного же банка.
Также формально нигде не сказано, что лицо, которое работает на иностранную компанию, не имеет права делать это с территории РФ. Налоговая не проверяет сроки пребывания за границей, поскольку не связана с миграционной службой. Однако, если доходы есть, а за границей не был, то это может вызвать вопросы. Если же за границей находился, то доказать, что там не работал, уже вряд ли кто-то сможет.
Соответствеено, каким образом налоговая сможет наложить штраф на зарплату, полученную на иностранный счёт (разрешенный тип операции), и как в суде она сможет мотивировать, что это не зарплата? И зачем вообще налоговой ввязываться в это гиблое дело, если можно просто получить 13%? Заметьте, я не рассматриваю неуплату налога. Это уже другая статья, не имеющая отношения к валютному контролю.
Касаемо сроков пребывания за границей, то расчёт очень прост. Зп программиста $150-200к в год, хотя и не является средней, однако реалистична. Соответственно, если находился за границей месяц, то сумма зп по декларации за год 20-40 тыс. вряд ли вызовет у кого-то вопросы. А если и вызовет, то, опять же, доказать обратное в суде налоговая не сможет. Вопрос чисто порядка сумм.
Но в любом случае, ИП обходится дешевле, чем уплата налогов с иностранных счетов. Кроме того, открытие иностранных счетов, сама по себе, не самая простая задача.
«Мужик в прошлом году» получил штраф при переводах между банками РФ. А тут мы обсуждаем получение заработной платы на себя (первый пункт из той самой 12-й статьи) на личные иностранные счета от иностранных компаний. И это не тот случай нарушения валютного законодательства, когда кто-то хочет получить на валютный счёт физ. лица банка РФ некие валютные переводы от иностранных компаний.
Иностранные банки находятся вне РФ и заморозить что-либо в них по требованию ФНС невозможно. Я согласен с тем, что вопросы возникнуть могут, но, почти уверен, что если суммы более-менее соответствющие заработной плате, претензий у налоговой не будет. Единственное что могут пытаться оспорить — это то, что деньги получены не как заработная плата. Но зачем им это, если Вы добровольно пришли с декларацией доходов.
Дойчебанк на его родине, например, даже счёт без регистрации по месту жительства не откроет. А для того, чтобы её получить, либо придётся селиться в мелком городе, где отсутствует очередь в соответствующее ведомство, либо будете месяц-другой ждать. Потом надо уведомить при отъезде, чтобы через год проблем не было. Да и справки в банк, всё равно придётся приносить. Иначе любые поступления из не задекларированных источников будут заблокированы.
В США без номера социального страхования большинство банков с Вами даже разговаривать не станет. А его, без постоянной работы и визы с разрешением на работу, никто не выдаст.
В целом, везде есть банки, которые согласятся открыть счёт иностранцу без регистрации. Но надежность сохранения денег под вопросом.
Деньги получать чемоданами? Иначе будете платить по местному законодательству. И это сильно больше 13% с иностранных счетов физ. лица. И сильно больше, чем у ИП…
Причём самое главное — деньги могут оставаться в том банке, куда были начислены. Переводить в РФ их не требуется.
Недостаток тут только один. 13% в любом случае. Плюс проценты на перевод к нам и потери на конвертации в рубли, если они нужны. В случае ИП, если это не Москва, налог может быть меньше 1% (по патенту).
По-моему Julia уже достигла зрелости. Именно потому, для задач ML и обработки данных мы решили её использовать. Пару лет назад, вероятно, я бы согласился с python, но сейчас смысла его использования уже нет. Да и примеров уже достаточно. Хотя, в большинстве случаев, их надо искать. Иногда, чтобы понять, как сделать что-то для себя, надо смотреть код библиотек. Но тут — лишь вопрос программистской квалификации и способности быстро понять как оно должно работать. В целом, Julia не является каким-то принципиально новым языком программирования. Это просто переосмысление существующих моделей. Потому начать программировать на ней довольно просто.
В DevOps, не знаю где использовать… Но если есть задачи типа конвертировать какие-либо json, csv, прочие данные в другой формат, откуда-то прочитать, что-то куда-то загрузить, то она вполне может пригодиться. По крайней мере подобные скриптики мы тоже пытаемся делать.
Сейчас уже большинство популярных библиотек перенесли на 1.0. К слову, в Julia очень удобно проверять библиотеки при помощи встроенных тестов. Когда устанавливаете новый пакет, надо всего лишь набрать команду
test ИмяПакета. Если всё в порядке, то можно использовать.Касаемо графиков. Я использую Plots / GR. Каких-либо проблем сейчас не замечаю. Из прочих бакендов, см. http://docs.juliaplots.org/latest/examples/plotlyjs/ — интерактивные диаграммы для jupyter notebook. Из известных мне проблем, в plotlyjs поломаны полярные координаты. В остальном, работает.
И относительно того, как рисовать, Yermack написал серию статей, где, как раз, акцент на графику. Собственно, см. хаб https://habr.com/hub/julia/
Благодарю за отзыв! Ваши предыдущие статьи, откровенно говоря, и спровоцировали меня на создание учетной записи здесь и на написание этой статьи. Описание по примерам — это хорошо, но только для тех, кому примеры понятны. Для тех же, кому предметная область далека, весь текст может показаться слишком абстрактным, а возможности языка — какими-то надуманными "фичами", которые нужны только тем, кто понимает эту непонятную предметную область. Имено поэтому я и решил изменить контекст изложения и начать делать его в отрыве от предметной области, но с акцентом на то, как программировать. Впрочем, всего должно быть в меру, потому, безусловно, статьи с конкретными примерами тоже нужны и важны.
Julia — новый язык. На данный момент вряд ли ошибусь, если скажу, что специалистов по ней пока ещё просто нет. Сам я погрузился в Julia в августе, как раз под версию 1.0. До этого только читал обзоры. В следущем году специалисты уже точно будут. Технологии на Julia имеют явный потенциал. Впрочем, как раз сейчас, пытаемся делать сервисы обработки данных именно на Julia.
Кроме того, мы задумались о создании учебного курса для студентов 1-го курса технического университета, где Julia станет первым языком программирования. Она видится хорошим языком для изучения принципов алгоритмизации, а также в качестве языка для решения текущих студенческих задач.
Вопрос про сравнение с pandas я уже слышал… Но главный вопрос — критерии сравнения. Если вопрос про производительность — это сделать можно. Только надо подобрать наборы данных и операции, на которых сравнивать. Если же вопрос про языки запросов типа
то это отдельный разговор. См. https://juliadata.github.io/DataFrames.jl/stable/man/querying_frameworks.html
Касаемо сравнения производительности, почти уверен, что у pandas будет провал в том случае, когда добавляются сложные условия выборки, требующие выполнения питон-кода. У Julia всегда будет выполняться родной код.
Касаемо сравнения с numpy, тот же вопрос о критериях. Если сравнивать производительность прямо, то см. https://julialang.org/benchmarks/ Но вопрос, на сколько это реалистично отражает практические задачи. Если сравнивать чистые вычисления внутри Julia и внутри numpy, думаю, что для numpy не всё плохо. Если же появляются задачи, где данные надо использовать в нескольких библиотеках, которые не понимают numpy, или просто требуется их перепаковка из numpy-объектов в питон-объекты и обратно, получаются точки провала производительности. У Julia их нет, поскольку везде используется native-код.
Касаемо синтаксиса с numpy и Matlab, рекомендую посмотреть сравнительную таблицу https://cheatsheets.quantecon.org/
И компактно представленные средства из Julia — https://juliadocs.github.io/Julia-Cheat-Sheet/
То есть ответ касаемо случаев использования Julia такой. Если нет унаследованного кода на Питоне, то следует писать на Julia.....
В целом, жду отзывы, дополнения, замечания. Есть мысли сделать серию небольших заметок про Julia: по созданию скриптов (акцент на обработку аргументов), веб-сервисов, построению отчётов. Возможно, надо пояснить модель системы типов Julia. Поскольку язык новый, не думаю, эти вопросы совсем очевидны.