что такое мониторинг и как он проводится

Что такое налоговый мониторинг и как он проводится

С 2016 года в России появилась новая форма налогового контроля — налоговый мониторинг. До сих пор это было доступно только крупным налогоплательщикам, но с 2022 года к мониторингу могут присоединиться и некоторые представители среднего бизнеса. Рассказываем в чём заключается налоговый мониторинг, какие преимущества даёт и как стать его участником.

Что такое налоговый мониторинг

Суть мониторинга в том, что налоговые инспекторы получают доступ к учётной базе организации и контролируют правильность начисления и уплаты налогов. Взамен организацию освобождают от камеральных и выездных проверок за этот период, но есть исключения.

Порядок проведения мониторинга прописан в разделе V.2 НК РФ. Чтобы участвовать в налоговом мониторинге, нужно подать заявление в инспекцию ФНС по месту регистрации организации.

Участники налогового мониторинга

На 2021 год приём заявлений на налоговый мониторинг уже завершён. Чтобы привлечь к мониторингу больше организаций, с 2022 года требования будут снижены, изменения внесены Федеральным законом от 29.12.2020 № 470-ФЗ.

Плюсы и минусы налогового мониторинга

Чем выгодно добровольно раскрывать свои карты налоговикам:

Если организация, участвующая в мониторинге не представит в срок декларации, ответственность будет та же, что и для всех остальных.

К недостаткам можно отнести постоянный налоговый контроль со стороны ИФНС, риск утечки конфиденциальной информации и большие требования к системе внутреннего контроля в организации.

Как стать участником мониторинга

Организации, которая хочет участвовать в мониторинге и соответствует его критериям, нужно подать заявление в налоговую инспекцию по месту регистрации.

Нельзя заявиться на мониторинг только по отдельным налогам.

ФНС России утвердила официальную форму заявления приказом № ММВ-7-15/323 от 21.04.2017, но лучше использовать форму рекомендованную Письмом ФНС России №БВ-4-23/13939@ от 31.08.2020.

Срок подачи заявления — до 1 июля года, который предшествует периоду мониторинга. К заявлению нужно приложить следующие документы:

Рекомендованные формы этих документов можно найти в письме ФНС России № БВ-4-23/13939@ от 31.08.2020. Весь пакет документов нужно отправить в электронной форме.

До 1 ноября налоговая инспекция рассматривает полученные материалы и в течение пяти рабочих дней принимает решение:

Отказать могут из-за несоответствия критериям, либо несоответствия системы внутреннего контроля или информационного взаимодействия установленным требованиям.

При положительном решении мониторинг начинается с 1 января следующего года. Если организация не захочет продолжать мониторинг в течение второго года, нужно подать в налоговую заявление об отказе не позднее 1 декабря контролируемого года. Если такого заявления не будет, мониторинг автоматически продлевается ещё на два календарных года. То есть если компания заявилась в 2020 году и в течение 2021 года является участником мониторинга, то чтобы в 2022 году мониторинга не было, нужно подать заявление об отказе до 1 декабря 2021 года. Если заявления не будет, мониторинг продлится в 2022 и 2023 годах.

Период мониторинга

Мониторинг охватывает один календарный год: с 1 января по 31 декабря. Налоговая инспекция должна завершить его до 1 октября следующего года.

Например, в компании налоговый мониторинг будет проводиться с 1 января по 31 декабря 2022 года. Инспекция ФНС в срок до 1 октября 2023 года обязана завершить проверку деятельности этой компании за 2022 год и предоставить все необходимые документы.

Если организация нарушает регламент взаимодействия, не предоставляет документы или даёт недостоверные сведения, мониторинг могут прекратить досрочно. Инспекция ФНС письменно сообщит об этом организации в течение 10 рабочих дней после возникновения обстоятельств, но не позднее 1 сентября следующего за контрольным года.

Как проходит мониторинг

Налоговая инспекция проводит его на своей территории на основе деклараций и учётных данных из базы, куда организация даёт доступ.

Налоговики имеют право:

Документы или информацию по запросам нужно отправлять в налоговую инспекцию в виде заверенных копий:

На подготовку документов у организации есть 10 дней. Если этого времени недостаточно, можно попросить отсрочку. Повторно запрашивать одни и те же документы налоговики не могут.

Если инспекторы находят недочёты или ошибки, они отправляют организации мотивированное мнение. Это можно сделать максимум до 1 июля года, следующего за периодом мониторинга. Если у организации нет возражений, она обязана исполнить предписания налоговиков.

Если возражения есть, нужно направить их в течение месяца, откуда их перешлют в ФНС РФ для проведения взаимосогласительной процедуры. В результате мнение налоговой либо изменят, либо оставят в силе и его нужно будет исполнить.

Мотивированное мнение налоговиков может запросить и сама организация, если в чём-то сомневается, и тоже не позднее 1 июля года, следующего после периода мониторинга.

Если налоговики обнаружат несоответствия по исчислению или уплате налогов и сборов — они отправляют мотивированное мнение в течение 5 рабочих дней. Когда сомнения есть у самой организации, она запрашивает мотивированное мнение у налоговой инспекции. Если у организации остались не исполненные мотивированные мнения, не позднее 1 декабря следующего за контрольным года налоговики должны об этом сообщить.

Источник

Что такое мониторинг и как он проводится

Статья 96. Мониторинг

1. Под мониторингом в целях настоящего Федерального закона понимается режим дистанционного государственного контроля (надзора), заключающийся в целенаправленном, постоянном (систематическом, регулярном, непрерывном), опосредованном получении и анализе информации о деятельности граждан и организаций, об объектах контроля с использованием систем (методов) дистанционного контроля, в том числе с применением специальных технических средств, имеющих функции фотосъемки, аудио- и видеозаписи, измерения, должностными лицами контрольного (надзорного) органа в целях предотвращения причинения вреда (ущерба) охраняемым законом ценностям.

2. Мониторинг основан на добровольном участии контролируемых лиц и осуществляется в случаях, установленных положением о виде контроля, по заявлению контролируемого лица на условиях соглашения между контролируемым лицом и контрольным (надзорным) органом.

3. Требования, которым должно соответствовать контролируемое лицо для осуществления мониторинга, устанавливаются положением о виде контроля.

4. Порядок организации и осуществления мониторинга устанавливается положением о виде контроля, соглашением между контрольным (надзорным) органом и контролируемым лицом.

5. Положение о виде контроля регулирует порядок подключения контролируемого лица (объекта) к автоматизированным информационным системам сбора и обработки данных, работающим в автоматическом режиме, специальным техническим средствам, имеющим функции фотосъемки, аудио- и видеозаписи, измерения, иным средствам сбора или фиксации информации, порядок доступа к указанным информационным системам и иным средствам сбора или фиксации информации, порядок обмена документами и иной информацией, а также характеристики автоматизированных информационных систем сбора и обработки данных, средств сбора или фиксации информации, места их установки, их количество, требования к необходимому программному обеспечению и при необходимости иные условия.

6. Форма соглашения о мониторинге утверждается контрольным (надзорным) органом и не может предусматривать преимущества для отдельных контролируемых лиц или оказание предпочтения отдельным контролируемым лицам.

7. Техническое оснащение и сопровождение мониторинга на объектах контролируемого лица производятся за счет контролируемого лица, если иное не установлено положением о виде контроля или соглашением о мониторинге.

8. Мониторинг осуществляется на основании решения контрольного (надзорного) органа, выпускаемого по результатам проведения оценки соответствия контролируемого лица требованиям, предъявляемым к нему для осуществления мониторинга, технической готовности контролируемого лица и контрольного (надзорного) органа к информационному взаимодействию в рамках мониторинга и заключения соглашения о мониторинге.

9. Соглашением о мониторинге между контролируемым лицом и контрольным (надзорным) органом может предусматриваться срок осуществления мониторинга, который не может быть менее одного года.

10. Уполномоченное должностное лицо контрольного (надзорного) органа принимает решение о прекращении осуществления мониторинга в одном из следующих случаев:

1) выявление несоответствия контролируемого лица требованиям, предъявляемым к нему для осуществления мониторинга, в том числе к технической оснащенности и сопровождению мониторинга;

2) неисполнение контролируемым лицом положений соглашения о мониторинге между контролируемым лицом и контрольным (надзорным) органом;

3) подача контролируемым лицом заявления о прекращении осуществления мониторинга;

4) иные случаи, установленные положением о виде контроля.

11. Контрольный (надзорный) орган уведомляет контролируемое лицо о прекращении мониторинга в течение десяти дней со дня принятия решения о прекращении осуществления мониторинга.

12. Федеральным законом о виде контроля может быть предусмотрено осуществление обязательного мониторинга в отношении контролируемых лиц, соответствующих критериям, установленным федеральным законом о виде контроля.

13. Порядок организации и осуществления обязательного мониторинга устанавливается положением о виде контроля.

14. Техническое оснащение и сопровождение обязательного мониторинга производятся за счет средств соответствующего бюджета бюджетной системы Российской Федерации, если иное не установлено федеральным законом о виде контроля.

15. Обязательный мониторинг осуществляется без ограничения срока его проведения.

16. Контролируемые лица, в отношении которых осуществляется обязательный мониторинг, освобождаются от плановых контрольных (надзорных) мероприятий в отношении соблюдения обязательных требований, являющихся предметом такого мониторинга.

17. В случае получения в ходе мониторинга, в том числе обязательного мониторинга, сведений о фактах нарушения обязательных требований контрольный (надзорный) орган принимает решения в соответствии с частью 2 статьи 90 настоящего Федерального закона.

Источник

Значение слова «мониторинг»

Мониторинг — система сбора/регистрации, хранения и анализа небольшого количества ключевых (явных или косвенных) признаков/параметров описания данного объекта для вынесения суждения о поведении/состоянии данного объекта в целом. То есть для вынесения суждения об объекте в целом на основании анализа небольшого количества характеризующих его признаков.

Мониторинг параметров — наблюдение за какими-либо параметрами[уточнить]. Результат мониторинга параметров представляет собой совокупность измеренных значений параметров, получаемых на неразрывно примыкающих друг к другу интервалах времени, в течение которых значения параметров существенно не изменяются.

Мониторинг веб сайтов — процесс проверки работоспособности и тестирования параметров доступности сайта или веб сервиса в сети Интернет. Специальные сервисы мониторинга сайтов имитируют действия тысяч посетителей для того, чтобы посмотреть, как ресурс реагирует на посещаемость и использование различной функциональности. При обнаружении какой-либо неисправности сервис посылает веб-мастеру сигнал, благодаря чему специалист сможет в короткие сроки восстановить работоспособность собственного ресурса. Использование мониторинга доступности сайтов обладает массой дополнительных преимуществ.

Мониторинг состояния — наблюдение за состоянием объекта для определения и предсказания момента перехода в предельное состояние. Результат мониторинга состояния объекта представляет собой совокупность диагнозов составляющих его субъектов, получаемых на неразрывно примыкающих друг к другу интервалах времени, в течение которых состояние объекта существенно не изменяется. Принципиальным отличием мониторинга состояния от мониторинга параметров является наличие интерпретатора измеренных параметров в терминах состояния — экспертной системы поддержки принятия решений о состоянии объекта и дальнейшем управлении.

Мониторинг систем слежения и охранно-пожарной сигнализации — процесс непрерывного, автоматизированного сбора информации поступающей от охранно-пожарной сигнализации и систем слежения ГЛОНАСС/GPS, установленных на объектах всех видов собственности. Целью мониторинга систем слежения и охранно-пожарной сигнализации является своевременное доведение поступивших сигналов «Тревога» должностным лицам соответствующих частных организаций и государственных служб (охрана, полиция, МЧС, медицина, техническим специалистам и пр.), для осуществления необходимых действий и плановых мероприятий по защите, как жизни и здоровья работников (клиентов), так и сохранности имущества находящегося на объекте.

Мониторинг критически важных и опасных объектов — процесс инструментального автоматизированного круглосуточного наблюдения за отдельными параметрами объектов. Целью мониторинга является предупреждение чрезвычайных ситуаций и повреждения или разрушения объектов. Основным отличием этого вида мониторинга является то, что в процессе мониторинга отслеживаются деформации и сдвиги объекта и отдельных его элементов, что позволяет предотвратить наступление негативного события, а не проинформировать экстренные службы о случившемся ЧП. Мониторинг осуществляется с помощью оптических, лазерных и геофизических методов и инструментов.

Мониторинг в маркетинге — это систематическое и плановое наблюдение за состоянием рынка с целью его оценки, изучения трендов (тенденций), исследования конкурентной среды. Маркетинговый мониторинг необходим для эффективного ведения бизнеса. Результаты мониторинга дают возможность вносить корректировки в маркетинг, в управление. Наиболее близкий русский эквивалент понятия «мониторинг» — отслеживание.

Мониторинг — систематический сбор и обработка информации, которая может быть использована для улучшения процесса принятия решения, а также, косвенно, для информирования общественности или прямо как инструмент обратной связи в целях осуществления проектов, оценки программ или выработки политики. Он несёт одну или более из трёх организационных функций:

выявляет состояние критических или находящихся в

Источник

Организация системы мониторинга

Мониторинг — это главное, что есть у админа. Админы нужны для мониторинга, а мониторинг нужен для админов.

За последние несколько лет поменялась сама парадигма мониторинга. Новая эра уже наступила, и если сейчас вы мониторите инфраструктуру как набор серверов — вы не мониторите почти ничего. Потому что теперь «инфраструктура» — это многоуровневая архитектура, и для мониторинга каждого уровня есть свои инструменты.

Кроме проблем типа «упал сервер», «надо заменить винт в рейде», теперь надо понимать проблемы уровня приложения и уровня бизнеса: «взаимодействие с микросервисом таким-то замедлилось», «в очереди слишком мало сообщений для текущего времени», «время выполнения запросов к бд в приложении растет, запросы — такие-то».

У нас на поддержке около пяти тысяч серверов, в самых разных конфигурациях: от систем из трех серверов с кастомными докеровскими сетками, до больших проектов с сотнями серверов в Kubernetes. И за всем этим надо как-то следить, вовремя понимать, что что-то сломалось и быстро чинить. Для этого надо понять что такое мониторинг, как он строится в современных реалиях, как его проектировать и что он должен делать. Об этом и хотелось бы рассказать.

Как было раньше

Лет десять назад мониторинг был гораздо проще, чем сейчас. Впрочем, и приложения были попроще.

Мониторились, в основном, системные показатели: CPU, память, диски, сеть. Этого вполне хватало, потому что там крутилось одно приложение на php, и ничего больше не использовалось. Проблема в том, что по таким показателям обычно мало что можно сказать. Либо работает, либо нет. Что именно происходит с самим приложением, выше уровня системных показателей понять сложно.

Если проблема была на уровне приложения (не просто “сайт не работает”, а “сайт работает, но что-то не так”), то клиент сам писал или звонил, сообщал, что есть такая-то проблема, мы шли и разбирались, потому что сами мы такие проблемы заметить не могли.

Как сейчас

Сейчас совсем другие системы: с масштабированием, с автоскейлингом, микросервисы, докеры. Системы стали динамичными. Часто никто толком не знает, как именно все работает, на скольких серверах, как именно оно развернуто. Оно живет своей жизнью. Иногда даже неизвестно, что и где запущено (если это Kubernetes, например).

Усложнение самих систем, конечно, повлекло за собой большее количество возможных проблем. Появились метрики приложений, количество запущенных тредов у Java application, частота garbage collector pauses, количество событий в очереди. Очень важно, чтобы мониторинг также следил за масштабированием систем. Допустим, у вас Kubernetes HPA. Надо понимать, сколько запущено подов, и с каждого запущенного пода должны идти метрики в систему мониторинга приложения, в apm.

Все это нужно мониторить, потому что все это отражается на работе системы.
И сами проблемы стали менее очевидными.

Условно, проблемы можно поделить на две большие группы:
Проблемы первого рода – не работает основная, “пользовательская функциональность”.
Проблемы второго рода – что-то работает не так, как должно, и может куда-то не туда привести.

То есть теперь надо мониторить не только дискретное “работает/не работает”, а гораздо больше градаций. Что, в свою очередь, позволяет ловить проблему до того, как все рухнет.

Кроме того, теперь надо следить и за бизнес-показателями. Бизнес захотел иметь графики о деньгах, о том как часто идут заказы, сколько времени прошло с последнего заказа и так далее — это теперь тоже задача мониторинга.

Правильный мониторинг

Проектирование и вообще

Представление о том, что именно надо будет мониторить, должно быть заложено в момент разработки приложения и архитектуры, и речь даже не столько про серверную архитектуру, сколько про архитектуру приложения в целом.

Разработчики/архитекторы должны понимать какие части системы критичны для функционирования проекта и бизнеса, и заранее думать о том, что их работоспобность надо проверять.

Мониторинг должен быть удобным для админа, и давать представление о том, что происходит. Цель мониторинга – вовремя получить оповещение, по графикам быстро понять, что именно происходит и что именно нужно чинить.

Метрики и оповещения (алерты)

Алерты должны быть максимально понятными: админ, получив алерт, даже если он не знаком с системой, должен понять, о чем этот алерт, в какую документацию смотреть, или хотя бы кому позвонить. Должны быть четкие инструкции, что именно нужно делать, и как именно решать проблему.

Когда возникает проблема, очень хочется понять, из-за чего она возникла. Получая алерт о том, что у вас не работает приложение, вам очень хотелось бы знать, какие еще смежные системы ведут себя не так, какие еще есть отклонения от нормы. Должны быть понятные графики, собранные в дашборды, из которых сразу будет видно, где отклонение.

Для этого надо точно понимать, что нормально, а что не нормально. То есть должна быть достаточная историческая справка о состоянии системы. Задача заключается в том, чтобы покрыть алертами все возможные отклонения от нормы.

Когда админ получает алерт, он либо должен знать что с ним делать, либо кого спросить. Должна быть инструкция как именно нужно реагировать, и ее надо регулярно обновлять. Если у вас все работает через систему оркестрирования, то, наверное, у вас все хорошо, если все изменения происходят только через нее, в том числе и мониторинг. Система оркестрирования позволяет адекватно следить за актуальностью мониторинга.

Мониторинг должен расширяться после каждой аварии — если внезапно возникла какая-то проблема, которая проскочила мимо мониторинга, то, очевидно, надо замониторить эту ситуацию, чтобы в следующий раз проблема не была внезапной.

Бизнес-показатели

Полезно мониторить время с последней продажи, количество продаж за период. Если выложили релиз, то что изменилось: есть ли просадки по бизнес-показателям? На это отвечает, конечно, A/B тестирование, но графики тоже хотелось бы иметь. И надо мониторить действия конечного пользователя: писать скрипты на phantomjs, которые повторяют покупку, проходят по всем этапам основного бизнес-процесса.

Также вам, наверное, интересно знать, работает ли сервис логистики, или не свалился ли в очередной раз IpGeoBase. (Комментарий редактора: IpGeoBase — сервис, который использует большое число интернет-магазинов на 1С-Битрикс для определения местоположения пользователя. Чаще всего это делается непосредственно в коде загрузки страницы, и когда падает IpGeoBase — у нас перестают отвечать десятки сайтов. Кто-нибудь пожалуйста, скажите программистам, что это надо обрабатывать и делать таймаут, и кто-нибудь — пожалуйста попросите IpGeoBase не падать).

Нужно понимать, зависит ли просадка по бизнес-показателям от вашей системы, или от внешней.

Мониторинг мониторинга

Сам мониторинг тоже должен хоть как-то мониториться. Должен быть какой-то внешний кастомный скрипт, который будет проверять, что мониторинг работает нормально. Никому не хочется проснуться от звонка, потому что ваша система мониторинга упала вместе со всем дата-центром, и вам об этом никто не сказал.

Основные инструменты

В современных системах, которые масштабируются, у вас наверняка используется Prometheus, потому что аналогов в принципе нет. Для того, чтобы просматривать удобные графики от Prometheus нужна Grafana, потому что в Prometheus графики так себе. Нужен также какой-то APM. Либо это самописная система на Open Trace, jaeger и или что-то подобное. Но это редко кто делает. В основном используется либо New Relic, либо специфичные системы для стеков, типа Dripstat. Если у вас не одна система мониторинга, не один Zabbix, вам еще нужно понимать, как собирать эти метрики, и как раздавать алерты; кого оповещать, кого поднимать, в каком порядке, к кому какой алерт относится, и что с ним вообще делать.

Zabbix — не самая удобная система. Есть проблемы с кастомными метриками, особенно, если система масштабируется, и вам нужно определить роли. И хотя можно строить очень кастомные графики, алерты и дашборды, все это не очень неудобно и нединамично. Это статичная система мониторинга.

Prometheus — отличное решение для сборки огромного количества метрик. У него примерно те же возможности, что у Zabbix по кастомным алертам. Можно выводить графики и строить алерты по любым диким сочетаниям нескольких параметров. И это все очень здорово, но очень неудобно смотреть, поэтому к нему добавляется Grafana. Grafana очень красивая. Но сама по себе не очень помогает для мониторинга систем. Зато по ней удобно все читать. Лучше графиков, наверное, и нет.

ELK и Graylog — для сбора логов по событиям в приложении. Может быть полезно для разработчиков, но для подробной аналитики обычно не достаточно.

New Relic — APM, тоже полезный для разработчиков. Есть возможность понять, когда у вас в приложении прямо сейчас что-то идет не так. Понятно, какие из внешних сервисов не очень хорошо работают, или какая из баз медленно отвечает, либо какое системное взаимодействие просаживается.

Свой APM — если вы написали свою систему на Open Tracing, zipkin или jaeger, то, наверное, вы знаете, как именно это должно работать, и что именно, и в какой части кода идет не так. New Relic тоже позволяет это понять, но это не всегда удобно.

Заключение

О том какие показатели надо мониторить лучше думать в время проектирования системы, заранее подумать о том какие части системы критичны для ее работы и о том, как проверять их работу.
Алертов не должно быть слишком много, алерты должны быть актуальными. Должно быть сразу понятно, что сломалось и как это чинить.
Чтобы правильно замониторить бизнес-показатели, надо понять как устроены бизнес процессы, что нужно вашим аналитикам, хватает ли инструментов чтобы замерить нужные показатели, и как быстро можно узнать, если что-то пойдет не так.

В следующем посте мы расскажем как правильно спланировать мониторинг современной инфраструктуры, на всех уровнях: на уровнях системы, приложений и бизнеса.

Источник