Вот интересная штука: была у них там якобы благая мысль «помочь внутренним рекламным площадкам».
Но как быть тем компаниям, которые ориентируются на зарубежный рынок и зарубежных потребителей? А об этом не подумали.
PS. Не удивлюсь, если в реальности мысль звучала так: как бы под благим предлогом заставить платить больше налогов.
Размер 03, после него идет негативный (7F) ответ "запрос принят, требуется время для ответа" (код 78).
В принципе в вашем логе если посмотреть другие ответы от ЭБУ, они совпадают с этой схемой:
10 00 02 1A 9B: 10=опкод+счетчик, 00 = некий флаг + 4 бита размер, 02 = длины данных KWP Payload, 1A 9B сами данные
10 00 03 7F 1A 11: 10=опкод+счетчик, 00 = флаги+4 бита размер, 03 = длина данных KWP Payload, 7F 1A 11 — сами данные (негативный ответ: сервис 1A не поддерживается)
На самом деле вполне реальная ситуация. Не про MAC адреса конечно, но про IP — очень даже часто такой довод налоговыми используется как доказательство взаимозависимости налогоплательщиков.
Откуда они берут IP?
Тут разные варианты:
1) привлечь органы внутренних дел
2) запросить у банков логи доступа к банк-клиенту по нескольким лицам
3) запросить данные у операторов документооборота, через которые сдается отчетность.
Кстати, в налоговой никто не слышал про NAT, про то, что один IP не обязательно конкретный ПК, но это им и не надо. Никто и никогда не будет использовать это как единственный довод. А вот как один из множества — будут.
Сегодня успешно продлил, оплату списали с карты примерно через пару часов. Потом пришло письмо от Apple, что аккаунт продлен и на сайте developer.apple.com информация обновилась.
Очень хорошо, что я сначала продлил, а потом только прочитал эту новость :)
PS. Использовал карту российского райффайзена в долларах. С нее же успешно списываются деньги в Apple Search Ads.
Мне вот интересно, а как будут обстоять дела с iOS?
Ведь там по умолчанию предустановлены только приложения Apple.
Вообще, есть в мире аналогичная практика?
А чем вам так не нравится дефолтное EULA от Apple?
Его предмет вполне соответствует предмету лицензионного договора. В большинстве случаев этого достаточно.
Тогда вопрос — зачем такой громкий заголовок, не очень относящийся к содержанию? :)
Я то думал, вы отразите ваше мнение относительно перспектив «налога на гугл» с 01.01.2019, который вроде как утрачивает свою актуальность для налоговых агентов (Федеральный закон от 27.11.2017 N 335-ФЗ), а с другой стороны, Apple и Google пока не особо стремятся его платить в бюджет самостоятельно.
PS. Не сочтите за дерзость, но подкину вам еще одну идею для публичного освещения: необходимость и порядок применения ККТ разработчиками, распространяющими ПО через AppStore и Google Play. Лучше, если ответом на этот вопрос будет «не обязаны» :)
PPS. Но в любом случае спасибо за Ваши старания, т.к. характер деятельности разработчиков, публикующихся в Google Play и AppStore является «необычным» для наших налоговых органов, привыкших собирать налоги с «купил-продал».
Мне кажется, что тема именно «налога на гугл» не раскрыта, потому что вся суть этого «налога» сводилась к уплате НДС в качестве налогового агента за услуги, оказываемые иностранным лицом российскому ИП или юр. лицу.
А вы в этой статье раскрыли вопросы налогообложения НДС реализации прав на ПО.
Но в любом случае, интересно почитать ваше мнение относительно In-App purchase. Мне кажется, там есть определенный простор для творчества :)
Но как быть тем компаниям, которые ориентируются на зарубежный рынок и зарубежных потребителей? А об этом не подумали.
PS. Не удивлюсь, если в реальности мысль звучала так: как бы под благим предлогом заставить платить больше налогов.
Эта новость не может не радовать :)
То есть программирование — это использование официального софта, который разрабатывался с учетом среднего юзера-автослесаря?
Размер 03, после него идет негативный (7F) ответ "запрос принят, требуется время для ответа" (код 78).
В принципе в вашем логе если посмотреть другие ответы от ЭБУ, они совпадают с этой схемой:
10 00 02 1A 9B: 10=опкод+счетчик, 00 = некий флаг + 4 бита размер, 02 = длины данных KWP Payload, 1A 9B сами данные
10 00 03 7F 1A 11: 10=опкод+счетчик, 00 = флаги+4 бита размер, 03 = длина данных KWP Payload, 7F 1A 11 — сами данные (негативный ответ: сервис 1A не поддерживается)
Откуда они берут IP?
Тут разные варианты:
1) привлечь органы внутренних дел
2) запросить у банков логи доступа к банк-клиенту по нескольким лицам
3) запросить данные у операторов документооборота, через которые сдается отчетность.
Кстати, в налоговой никто не слышал про NAT, про то, что один IP не обязательно конкретный ПК, но это им и не надо. Никто и никогда не будет использовать это как единственный довод. А вот как один из множества — будут.
Очень хорошо, что я сначала продлил, а потом только прочитал эту новость :)
PS. Использовал карту российского райффайзена в долларах. С нее же успешно списываются деньги в Apple Search Ads.
Ведь там по умолчанию предустановлены только приложения Apple.
Вообще, есть в мире аналогичная практика?
Его предмет вполне соответствует предмету лицензионного договора. В большинстве случаев этого достаточно.
Я то думал, вы отразите ваше мнение относительно перспектив «налога на гугл» с 01.01.2019, который вроде как утрачивает свою актуальность для налоговых агентов (Федеральный закон от 27.11.2017 N 335-ФЗ), а с другой стороны, Apple и Google пока не особо стремятся его платить в бюджет самостоятельно.
PS. Не сочтите за дерзость, но подкину вам еще одну идею для публичного освещения: необходимость и порядок применения ККТ разработчиками, распространяющими ПО через AppStore и Google Play. Лучше, если ответом на этот вопрос будет «не обязаны» :)
PPS. Но в любом случае спасибо за Ваши старания, т.к. характер деятельности разработчиков, публикующихся в Google Play и AppStore является «необычным» для наших налоговых органов, привыкших собирать налоги с «купил-продал».
А вы в этой статье раскрыли вопросы налогообложения НДС реализации прав на ПО.
Но в любом случае, интересно почитать ваше мнение относительно In-App purchase. Мне кажется, там есть определенный простор для творчества :)