Как написать ответ на требование налоговой?
Ответить на требование налоговой инспекции о представлении документов (пояснений) необходимо в установленный срок. Как правило, срок исполнения требования указан в тексте самого документа. А какие дни – рабочие или календарные брать для исполнения требования? Как говорит нам пункт 6 статьи 6.1 НК РФ, срок, определенный днями, исчисляется в рабочих днях, если срок не установлен в календарных днях. При этом рабочим днем считается день, который не признается в соответствии с законодательством Российской Федерации выходным и (или) нерабочим праздничным днем.
Ваша компания получила требование о представлении документов или пояснений в ходе проведения, например, камеральной проверки. Как правильно реагировать и отвечать на это требование – об этом пойдет речь в моей статье.
Сразу обращаю ваше внимание на то, что такой документ, как «требование», он не может быть произвольным, написанным «как попало» – это документ, форма которого утверждена приказом ФНС России от 08.
05.2015 г. № ММВ-7-2/189@.
Итак, требование может быть о представлении документов (информации) и о представлении пояснения (мы сейчас не рассматриваем требование об уплате налога). И в каждом виде требования должно быть указано:
– основание для выставления требования;
– если требование о представлении пояснений, то обязательно указывается причина выставления данного требования. То есть, прочитав данное требование, компания или ИП должны понимать, что от них требуется;
– если требование о представлении документов (информации), тогда обязательно указываются: какие документы и за какой период они нужны;
– срок исполнения требования.
Перейдем сразу к примеру, чтобы было понятно, какие действия надо совершить при получении требования.
Компания получила требование о представлении документов в отношении проводимой налоговой проверки контрагента. Согласно требования, следует представить:
1. Договоры за период с 01.01.2015 по 31.
12.2017;
2. Акты за период с 01.01.2015 по 31.12.2017;
3. Счета-фактуры за период с 01.01.2015 по 31.12.2017.
Срок исполнения требования – пять дней со дня получения требования.
Компания вела активное сотрудничество со своим контрагентом, и поэтому накопилось много документации. Подготовить в срок пять дней все копии, заверить их должным образом, не представляется возможным.
Как продлить срок представления документов
Самое главное в этом случае – дать ответ в установленный срок. Если у вас не хватает времени (как в нашем примере) для подготовки всего пакета документов, то вы можете собрать частично из списка документы, сделать с них копии и написать сопроводительное письмо.
Само сопроводительное письмо будет являться ответом на требование. Допустим, компания смогла найти и подготовить только акты и договоры, а счета-фактуры нет. Как мы напишем сопроводительное письмо?
Как мы видим из письма (это пример), мы частично подготовили уже документы и сдаем их, а на вторую часть просим продлить срок представления документов.
Мы вправе объединить наши действия в одном сопроводительном письме (оно служит ответом на требование).
На практике я часто сталкивалась с тем, что приходя в кабинет инспектора, можно увидеть огромные коробки в узких проходах между их столами. Как рассказывают работники инспекции, это могут быть документы, которые компания принесла в ответ на требование.
То есть, вы понимаете, что компания «перегнула» палку – принести несколько коробок бумаги, которую перебрать просто нереально… Достаточно все оформлять реестром. Например, у вас тысячи накладных и счетов-фактур только за один год, а надо за три года.
Советую в сопроводительном письме написать и уточнить, что вы представляете не конкретно поштучно сами накладные в адрес покупателя, а реестр выписанных счетов-фактур и накладных. Для того, чтобы инспектор мог увидеть воочию сам документ, приложите копии пары документов из каждого года.
Главное – отразить информацию в сопроводительном письме по каждому документу. И можно спросить – за какой месяц или какую дату лучше всего предоставить дополнительно документ, потому что из-за большого объема документации, не представляется возможным физическая доставка документов.
И уже, когда вы принесете документы к инспектору, спросите у него лично – как ему лучше, может он проверить определенную сделку и все. Инспекторы тоже люди и не автоматы, они «пугаются», когда видят, что им несут «контейнеры» бумаг.
В ответе на требование советую внизу слева указать исполнителя и его телефон, чтобы инспектор мог оперативно связаться с тем бухгалтером, который работал по этому требованию.
Если вам так будет удобно, конечно. Я так всегда делала, что было очень удобно.
Итог – запомните, ответить на требование или собрать документы (информацию) надо в тот срок, который указан в самом требовании. И если вы не успеваете собрать документы, не переживайте, это не конец света, вы просто успейте в установленный срок написать ответ на требование – в котором просите продлить срок представления документов (информации) по причине большого объема документации.
Не упустите никакой документ. Например, в требовании указано 6 видов документов, три из которых вы подготовили, на два из которых вы просите дать вам время, а про один забыли – проверьте, упомянули ли вы все виды документов в своем ответе на требование или нет.
Это важно, чтобы потом вы не забыли про этот вид документа.
Сопроводительное письмо (ответ на требование) распечатать надо в трех экземплярах (если вы несете документы вручную). Почему три? Возможно, что у вас достаточно будет двух, но в моей практике, в кабинетах налоговой «оседает» два документа, а третий с отметкой о принятии идет мне.
Не забывайте брать свой экземпляр с отметкой о принятии. На отметке будет стоять дата приема документов (ответа на требование) и ФИО инспектора, его подпись. В том случае, если в будущем у вас попросят повторно предоставить документы, вы всегда сможете поднять ваш «сопровод», сделать с него копию и написать – что такой-то документ был уже ранее подан такого-то числа.
Какой срок ответа на требование налоговой
Есть два срока – пять дней и десять дней.
10 дней – в случае, если вне рамок проведения налоговых проверок у налоговых органов возникает обоснованная необходимость получения документов (информации) относительно конкретной сделки.
5 дней – если идет проверка в отношении вашей компании или ИП.
Основание – пункт 5 статьи 93.1 НК РФ.
А какие дни – рабочие или календарные брать для исполнения требования?
Как говорит нам пункт 6 статьи 6.1 НК РФ, срок, определенный днями, исчисляется в рабочих днях, если срок не установлен в календарных днях. При этом рабочим днем считается день, который не признается в соответствии с законодательством Российской Федерации выходным и (или) нерабочим праздничным днем.
Как сформировать и отправить ответ на требование? | Отправка и получение отчетности
Для того чтобы ответить на требование от ФНС, произведите следующие действия.
Перейдите в пункт меню Администрирование → Журнал обмена с контролирующими органами (Отчеты → Регламентированные отчеты → Настройки → Журнал обмена с контролирующими органами).
В открывшемся окне Журнал обмена с контролирующими органами перейдите на вкладку ФНС → Требования и уведомления.
Здесь отображаются все полученные вами требования. В случае получения требования от ФНС необходимо подтвердить его прием и подготовить ответ (если необходимо), либо отказать в приеме, нажав на соответствующую кнопку в самом требовании. Для перехода к требованию дважды щелкните по нему левой кнопкой мыши.
Для формирования ответа на требование нажмите кнопку Ответить внутри требования.
При создании ответа на требование ФНС, Вы можете добавить группу документов (как из ПО 1С, так и сканированные документы). Для добавления документов в ответ на требование нажмите кнопку Добавить, и выберите один из вариантов выпадающего меню
При выборе пункта Книги покупок/продаж, журналы счетов-фактур вы можете добавить книги покупок/продаж и журналы счетов-фактуры, сформированные в данной базе1С.
При выборе пункта Документы из другой базы (файл обмена) вы можете загрузить книги покупок/продаж и счет-фактуры, подготовленные и выгруженные архивом из другой базы 1С, в разделе Администрирование →Архив ЭДО.
При выборе пункта Документы, перед вами откроется окно, предназначенное для подбора и формирования данных, отправляемых в ответ на требование, а также краткая инструкция по работе с формой.
Если в базе имеются документы для ответа на требования, нажмите кнопку для перемещения их в нижний список Отобранные документы.
Для формирования нового документа нажмите
В открывшемся окне добавьте изображения и заполните реквизиты документа. К одному документу можно прикрепить несколько изображений.
Примечание.
Если в строке Вид документа отсутствует вид отправляемого Вами документа, то отправить такой документ необходимо будет исходящим письмом, обязательно уведомив об этом ФНС.
Добавляемые документы должны соответствовать требованиям. Список требований можно посмотреть, нажав на гиперссылку Требования к файлам.
После того как документ будет подготовлен, нажмите кнопку Записать и закрыть.
Если все данные документа для отправки заполнены, он отображается в списке отобранных документов со статусом Готов к отправке.
В случае если некоторые из отобранных документов не готовы к отправке, нажмите кнопку Подготовить в столбце Готовность, или кнопку Подготовить все.
Когда все документы в списке Отобранные документы будут готовы к отправке, можно закончить отбор документов, нажав кнопку Перенести в ответ на требование.
Появится небольшое окно, в котором необходимо выбрать пункт требования, которому соответствует подготовленный документ. Выберите номер пункта требования и нажмите
Сформируйте ответы по каждому пункту требования, и отправьте ответ на требование, нажав кнопку Отправить.
После отправки ответа на требование, исходящий файл будет отображен на вкладке Ответы на требования.
9 советов по составлению более качественных требований
Одной из основных причин провала проекта является плохое управление требованиями в командах.
Неэффективное управление требованиями часто приводит к расширению объема работ, что, в свою очередь, может привести к перерасходу средств или задержкам проекта.
Эффективный процесс управления требованиями имеет решающее значение для успеха продукта или проекта и включает в себя сбор, документирование, анализ, уточнение и определение приоритетов требований, построение сквозной прослеживаемости, предоставление средств для отслеживания изменений требований и содействие коммуникации между заинтересованными сторонами. Цель каждого шага в этом процессе — помочь обеспечить успешное достижение целей разработки продукта или проекта.
Первым шагом в управлении требованиями является документирование требований или создание журнала невыполненных требований. Хороший документ с требованиями или репозиторий может помочь вашей организации сэкономить состояние, обеспечивая четкую связь между разработчиком и другими заинтересованными сторонами.
В этой статье я поделюсь некоторыми полезными советами, которые помогут вам написать четкие и понятные требования.
1. Понимание потребностей пользователей
Понимание потребностей ваших пользователей и умение определить формулировку проблемы — это первый шаг к написанию более качественных требований. Хорошая стратегия для четкого понимания потребностей пользователей состоит в том, чтобы найти ответы на 9 вопросов.0013 «три W»:
- Что – Что мы делаем?
- Почему – Почему мы это делаем?
- Кому – Кто выиграет от того, что мы делаем?
Поиск ответов на «трех W» может очень помочь вам лучше понять проблемы и потребности клиентов и, в конечном итоге, то, как вы можете уменьшить или устранить их болевые точки.
2. Требования должны быть однозначными
При документировании требования обязательно примите меры, чтобы свести к минимуму любую неясность или двусмысленность. Неоднозначные требования могут привести к неправильному толкованию, что, в свою очередь, может привести к большим затратам денег и энергии без удовлетворения потребностей ваших клиентов.
Вот несколько советов, которые помогут сделать ваши требования однозначными:
- При написании требований следует использовать согласованную терминологию.
- По возможности избегайте использования жаргона или специальных терминов. Если они используются, не забудьте определить их в глоссарии, чтобы избежать путаницы.
- Следует избегать использования наречий. Использование таких слов, как быстро, обычно, часто и т. д., может сбивать с толку, поскольку их нельзя измерить, и разные люди могут по-разному интерпретировать эти слова.
- Следует избегать использования расплывчатых и не поддающихся определению терминов, таких как гибкий, удобный для пользователя и т. д.
- Избегайте отрицательных требований, которые указывают, что делать не следует. Вместо этого сформулируйте их, чтобы указать, что следует сделать. Например, вместо того, чтобы писать требование как «Приложение не должно разрешать клиентам доступ к внутренним заявкам в службу поддержки», требование можно сформулировать так: «Приложение должно разрешать только сотрудникам доступ к внутренним заявкам в службу поддержки».
- Использование сокращений, таких как, например. и т. е. следует избегать.
3. Требования должны быть простыми, конкретными, краткими и исчерпывающими.
Убедитесь, что требования по существу, четкие и краткие, но в то же время должны быть в состоянии передать всю потребность. Краткие формулировки упрощают организацию требований, а также повышают удобочитаемость.
4. Требования должны поддаваться тестированию.
Должна быть возможность для отдела обеспечения качества или группы тестирования проверить правильность выполнения требования. Тест должен либо пройти, либо провалиться.
Для этого при написании требований следует также определить, как они будут проверяться и каковы будут критерии приемлемости.
5. Требования должны быть отделены от проектирования и реализации.
При написании требований следует избегать объяснений того, как система чего-то достигнет, и следует сосредоточиться только на том, чего система должна достичь.
Вы должны сосредоточиться на том, «что» в системе, а не на том, «как».
Вам следует воздержаться от проектирования системы или упоминания конкретных технологий, языков программирования и т. д. для реализации требований.
6. Требования должны быть достижимыми.
Реализовать требование в рамках выделенного бюджета и сроков должно быть технически возможно.
Поскольку вы живете не в идеальном мире, требования, которые вы пишете, должны быть реалистичными и достижимыми.
Требование является достижимым, если оно может быть практически реализовано вашей командой в рамках заданного графика и бюджета.
Например, такое требование, как «Приложение должно позволять 20 000 пользователей работать одновременно с временем отклика менее секунды», может быть практически выполнимо, но вам нужно понять, может ли это быть достигнуто вашей командой за заданное время. и бюджет.
Возможно, такое требование не может быть достижимо для вашей команды. Следовательно, при написании требования важно обращать внимание и проверять, достижимо оно или нет.
7. Требования должны быть правильно классифицированы.
Требования должны быть соответствующим образом классифицированы как бизнес-требования, функциональные требования, нефункциональные требования, системные требования и т. д. (в соответствии с потребностями вашей организации). Это помогает заинтересованным сторонам определить и сосредоточиться на требованиях, которые имеют отношение к ним.
8. Требования должны иметь приоритет.
Приоритизация требований — это процесс их ранжирования в порядке их относительной важности для заинтересованных сторон.
Приоритизация требований служит двум важным целям:
- Определение области применения
- Планирование реализации.
Это помогает убедиться, что команда сначала фокусируется на обязательных требованиях, а затем на требованиях, которые «приятно иметь».
Ниже приведены некоторые приемы, которым можно следовать при определении приоритетности требований:
- Группировка или ранжирование: В этом подходе вы можете назначить ранжирование или индикатор приоритета для различных требований.
- Ограничение времени/Бюджетирование: Этот подход можно использовать при наличии фиксированных сроков и бюджета для достижения контрольных точек проекта. Этот подход основан на принципе своевременного выпуска MVP или базового продукта с необходимыми функциями, а не выпуска продукта со всеми функциями позже.
- Переговоры или голосование: Этот подход включает достижение консенсуса между заинтересованными сторонами и определение приоритетности требований на основе нескольких голосов или предложений.
9. Требование должно быть прослеживаемым.
Отслеживаемость требований относится к способности документировать и отслеживать весь жизненный цикл требования (т. е. его происхождение, дизайн, спецификацию, реализацию, проверку, развертывание и использование) как в прямом, так и в обратном направлении, а также его связь с другими объектами.
Целью прослеживаемости требований является обеспечение согласованности требований и связанных объектов друг с другом и управление последствиями изменения одного требования для связанных объектов или наоборот.
Прослеживаемость помогает:
- Анализ воздействия
- Упрощение выявления несоответствий и пробелов в требованиях
- Определение объема и сложности изменения
- Оценка выполнения требований
- Отслеживание статуса проекта или выпуска
Хорошее требование всегда должно иметь уникальный идентификатор, а его источник всегда должен быть известен.
Пример плохого требования: «Уведомление по электронной почте от Jira Service Management должно содержать соответствующую информацию».
Пример хорошего требования: «Уведомление по электронной почте от Jira Service Management должно включать идентификатор запроса, сводку, имя клиента, правопреемника, статус и приоритет».
В заключение я хотел бы сказать, что овладение искусством написания хороших требований требует большого терпения и практики.
Я надеюсь, что приведенные выше советы помогут вам составить более качественные требования и помогут вашей организации заложить прочную основу для процесса управления требованиями, что, в свою очередь, способствует успеху ваших проектов или продуктов.
Confluence и Jira от Atlassian — отличные инструменты для создания требований и управления ими. Свяжитесь с одним из наших экспертов Atlassian, если вы хотите узнать больше о том, как вы можете создавать требования и управлять ими с помощью этих инструментов, или если вам нужна помощь в процессе управления требованиями. Мы будем рады помочь вам и вашей команде в управлении вашими требованиями, а также в процессе обучения Atlassian.
Как правильно составить требование
При покупке корпоративной технологии правильно написанные требования имеют решающее значение для правильного выбора при оценке технологий.
Выполните эти требования правильно, и вы станете героем, который сэкономил всем время и деньги. Сделаете это неправильно, и вы получите тендеры, поставщиков и решения, которые ничего не делают, кроме потери денег.
Специальная документация по требованиям (RSD) или Спецификация требований к программному обеспечению (SRS) сообщает потенциальным поставщикам или разработчикам о ваших конкретных потребностях в программном обеспечении для бизнеса. Они должны быть точными и тщательно написанными, потому что они могут трансформировать ваш бизнес, решить давние проблемы и повысить производительность.
Не становитесь еще одним примером компании с ‘Никогда не хватает времени, чтобы сделать это правильно, но всегда достаточно времени, чтобы сделать это заново.
Наше руководство поможет вам составить краткие, четкие и недвусмысленные требования, которые напрямую связаны с вашими всеобъемлющими потребностями и целями бизнеса и ведут вас по пути к успеху.
Передовой опыт написания хорошего требования
1. Понимать разницу между «потребностью» и «требованием»
Международный институт бизнес-анализа (IIBA) определяет «требование» как условие или возможность, требуемую заинтересованная сторона для решения проблемы или достижения цели.
«Потребность» — это высокоуровневое представление необходимого требования. Потребность – это конечный результат или цель. Это «почему мы это делаем».
Мохамед Эльгенди Иллюстрирует разницу ниже;
«Деловые потребности определяют и определяют, почему требуется изменение организационной системы или возможностей».
«Требования — это то, что необходимо сделать для достижения потребности или цели».
BABOK
Требования не должны быть слишком сложными. Мы часто чувствуем потребность быть эмоционально выразительными или многословными, чтобы сообщить о важности, но поставщики нуждаются в абсолютах и определениях.
2. Используйте шаблоны требований
Хорошие требования ориентированы на четкий результат для конечного пользователя. Если вы решите использовать шаблоны требований, придерживайтесь проверенных шаблонов, к которым привыкли поставщики. Одним из наиболее распространенных является «Программное обеспечение должно сделать «X», чтобы получить формат «Y».
3. Используйте правильную терминологию требований
Не добавляйте формулировки, которых там быть не должно, и придерживайтесь терминологии требований. Используйте термин:
- «Должен» для формулировки требования.
- «Воля» за констатацию фактов.
- «Должен» для постановки целей.
4. Убедитесь, что в каждом требовании нет двусмысленности
Требования должны быть четкими, определенными и недвусмысленными. Хорошее требование выражает одну потребность и не может быть истолковано иначе.
Избегайте использования таких слов, как «и/или». Если вам это нужно или требование сложное, разбейте его.
Удобно для кого и что означает доступность?
Хороший пример: «Команда обслуживания клиентов должна иметь удаленный доступ к программному обеспечению».5. Требования должны быть краткими.
Длинные требования редко бывают достаточно краткими, чтобы быть ясными. Если ваши утверждения будут краткими и содержательными, у вас будет очень мало места для неверного истолкования.
6. Понимать разницу между функциональными и нефункциональными требованиями
Функциональные требования определяют, что должна делать система.
Например: Программное обеспечение должно отправить запрос на подтверждение при создании учетной записи. Нефункциональные требования описывают, как система будет выполнять функцию, и ожидаемые ограничения. Они основаны на ваших ожиданиях относительно того, что должно делать новое программное обеспечение.
Большинство требований содержат как функциональные, так и нефункциональные элементы.
7. Избегайте лингвистических ловушек в ваших требованиях
Делать лингвистические допущения в требованиях — не лучшая идея.
Делайте все возможное, чтобы избежать следующего:
- Неоднозначные и субъективные термины: универсальный, удобный, индивидуальный, простой в использовании, надежный, удобный, хороший и приблизительный.
- Жаргон. Если это говорит только ваша компания или отрасль, другим это непонятно.
- Пункты. например. Кроме, если необходимо, но, если возможно…
- Аббревиатуры, акронимы, наречия, бессвязные и модные словечки.
- Разделение одного требования на другие. Если это важно, оно должно быть явно указано само по себе, а не выведено из других требований.
- Отрицательные требования. Не говорите: «Мы не хотим, чтобы это делало X». Что ты хочешь?
8. Просмотрите свои требования
Передайте требование команде и спросите их, что, по их мнению, оно означает. Если заинтересованные стороны не уверены, вам нужно переписать ваше требование.
Соображения по написанию требований
Твердые требования создают взаимопонимание и согласие между заинтересованными сторонами в отношении того, что программное обеспечение должно уметь делать, как оно должно это делать, и дают вам согласованную основу для оценки успеха программного обеспечения. Написание требований не является универсальным подходом, но есть определенные аспекты, которые вы всегда должны учитывать:
Необходимо ли это требование?
Является ли ваше требование важной функцией, не подлежащей обсуждению? Вы должны ранжировать свои требования от низкого приоритета до обязательных (хорошо, должно или должно быть).
Можно ли проверить это требование?
Должна быть возможность проверки, тестирования и демонстрации требования.
При тестировании ваша команда должна быть в состоянии сказать, работает ли это и правильно ли оно реализовано. Плохо написанные требования неясны и не дают уверенности при проведении тестирования.
Выполнимо ли требование?
Мы все за большие мечты, но действительно ли возможно сделать то, о чем вы просите? Если у вас нет технологии, бюджета или графика для поддержки требования, требования не должно существовать.
Не стоит недооценивать важность хорошо написанного требования
Написание хороших требований важно, но это требует практики, и всегда полезно иметь руководство. Думайте об этом как о потере и наличии достаточного количества данных, чтобы отправить одно короткое сообщение о помощи любимому человеку. Будет ли получатель сообщения знать, что делать, когда он получит сообщение? Или вы застрянете в окопах устаревшего программного обеспечения?
Если вам не хватает времени или уверенности, Олив придет вам на помощь. Мы предоставляем вам библиотеки утвержденных поставщиком требований, которые помогут вам сформулировать именно то, что вам нужно.