Егрюл точка налог точка ру: Предоставление сведений из ЕГРЮЛ/ЕГРИП в электронном виде

Работа на портале ФНС nalog.ru — Удостоверяющий центр СКБ Контур

Вопросы и ответы

    • Популярные вопросы
    • Электронные торговые площадки
    • Государственные порталы
    • Работа с Электронной подписью
    • Неквалифицированные электронные подписи
    • Технические вопросы и ошибки при работе
    • Личный кабинет

Работа на портале ФНС nalog.

ru

Если у вас уже есть квалифицированная электронная подпись (в дальнейшем КЭП), полученная у нас, то с ней можно работать на портале ФНС без сдачи бухгалтерской и налоговой отчетности. На nalog.ru есть Личные кабинеты для физических лиц, ИП и ЮЛ.

Для работы в Личном кабинете физического лица КЭП должен быть выдан на физическое лицо, в Личном кабинете ИП и ЮЛ — на ИП и ЮЛ, соответственно. Для юридических лиц в сервисе «Личный кабинет налогоплательщика» первичную регистрацию можно выполнить только с КЭПом, выданным на руководителя, указанного в ЕГРЮЛ, как лицо, имеющее право действовать без доверенности.

Для сдачи бухгалтерской и налоговой отчётности через nalog.ru вам понадобится идентификатор, который входит в состав тарифного плана «Налог.ру». Информация о тарифном плане на сайте УЦ размещена в полном прайсе.

Примечание: на портале nalog.ru нельзя отчитываться по НДС. Мы рекомендуем Вам сервис для сдачи отчетности Контур.Экстерн.

Настройка рабочего места, ошибки при работе

Для обеспечения работы сервисов ФНС достаточно пройти диагностику и выполнить рекомендуемые действия.

Если при работе на портале у вас возникают технические ошибки, воспользуйтесь статьей «Ошибки при работе на портале nalog.ru»

Контакты nalog.ru

По вопросам работы на портале и ошибкам, не связанным с настройкой рабочего места и электронной подписью, обратитесь в службу поддержки портала ФНС:

— Телефон: 8 (800) 222-22-22

— Форма обращения в техподдержку ФНС

Смотрите также

Что делать, если на ЭТП или портале не отображается нужный сертификат?

С какими ЭТП вы работаете?

Получение идентификатора налогоплательщика для подачи отчётности через сайт ФНС nalog.ru

Как получить сертификат? В каких сервисных центрах можно получить сертификат?

Ошибки при работе на портале ФНС nalog.ru

Была ли полезна информация?

 

Не нашли ответ? 
Задайте вопрос специалисту

Спасибо за ответ

Как подать жалобу в ФНС \ Акты, образцы, формы, договоры \ КонсультантПлюс

  • Главная
  • Правовые ресурсы
  • Подборки материалов
  • Как подать жалобу в ФНС

Подборка наиболее важных документов по запросу Как подать жалобу в ФНС (нормативно–правовые акты, формы, статьи, консультации экспертов и многое другое).

  • Налоги:
  • 303 счет
  • 852 КВР
  • Адреса ифнс
  • Акт сверки с налоговой
  • Апелляционная жалоба в вышестоящий налоговый орган образец
  • Ещё…

Судебная практика: Как подать жалобу в ФНС

Зарегистрируйтесь и получите пробный доступ к системе КонсультантПлюс бесплатно на 2 дня

Открыть документ в вашей системе КонсультантПлюс:
Подборка судебных решений за 2021 год: Статья 89 «Выездная налоговая проверка» НК РФ
(Юридическая компания «TAXOLOGY»)Решением регистрирующего органа от 08.10.2018 была приостановлена регистрация изменений, вносимых в учредительные документы налогоплательщика в связи с изменением адреса. Налоговый орган принял решение от 20.12.2018 о назначении выездной налоговой проверки по действующему адресу местонахождения налогоплательщика. Налогоплательщик обратился в ФНС России с жалобой на решение налогового органа в порядке, установленном п. 2 ст. 139 НК РФ, поскольку полагал, что налоговый орган знал о принятии им активных действий по смене адреса регистрации и, принимая решение о назначении выездной налоговой проверки по старому адресу, умышленно причинил вред налогоплательщику. ФНС России не рассмотрела жалобу налогоплательщика и направила ее в управление. Налогоплательщик обжаловал бездействие ФНС России. Суд отказал в удовлетворении требований налогоплательщика в связи с отсутствием у налогоплательщика правовых оснований для подачи жалобы в ФНС России, так как в соответствии с абз. 1 и 3 п. 2 ст. 139 НК РФ прежде налогоплательщику следовало соблюсти досудебный порядок оспаривания решения и обратиться с жалобой в вышестоящий налоговый орган (управление). При этом, руководствуясь ст. ст. 83, 84, 89 НК РФ, суд признал решение налогового органа о назначении проверки законным, указав, что при смене места нахождения юридического лица налоговый орган до момента внесения записи в ЕГРЮЛ о снятии его с учета по прежнему адресу вправе принять решение о проведении выездной налоговой проверки. Суд отклонил ссылку налогоплательщика на решение суда, которым приостановление регистрации признано незаконным, поскольку в силу п. 2 ст. 11 Федерального закона от 08.08.2001 N 129-ФЗ «О государственной регистрации юридических лиц и индивидуальных предпринимателей» моментом государственной регистрации признается внесение регистрирующим органом соответствующей записи в реестр.

Зарегистрируйтесь и получите пробный доступ к системе КонсультантПлюс бесплатно на 2 дня

Открыть документ в вашей системе КонсультантПлюс:
Подборка судебных решений за 2020 год: Статья 198 «Право на обращение в арбитражный суд с заявлением о признании ненормативных правовых актов недействительными, решений и действий (бездействия) незаконными» АПК РФ
(Юридическая компания «TAXOLOGY»)Общество обратилось в суд с заявлением об оспаривании решения, вынесенного по итогам проверки, а также с ходатайством о восстановлении пропущенного срока на обжалование. В обоснование ходатайства общество указало, что в связи с подачей жалобы в ФНС России не обращалось в суд до вынесения данной Службой решения, поскольку досудебный порядок предполагает исчерпание сторонами всех способов урегулирования спора на досудебной стадии, в том числе и обращение в центральный аппарат. Суд не усмотрел оснований для восстановления срока, поскольку досудебный порядок признается соблюденным уже после рассмотрения апелляционной жалобы на решение инспекции Управлением ФНС России по региону.

Статьи, комментарии, ответы на вопросы: Как подать жалобу в ФНС

Нормативные акты: Как подать жалобу в ФНС

Большие данные для бизнеса: опыт Purrweb

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

Боль больше, чем выгода

О клиенте, пришедшем к нам с заданием, рассказать не можем — мы подписали NDA. Допустим, заказчик — служба безопасности «крупной государственной организации».

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

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

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

Деликатное начало

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

Клиенту необходимо:

  • получить работающее решение для работы с большими данными
  • сократили количество человеко-часов благодаря решению
  • упростить поиск связей между соискателями и действующими работниками (по закону о госслужбе таких конфликтов интересов быть не должно — это официальное ограничение)

Когда к нам пришел клиент, мы договорились есть слона по кусочку и начать с прототипа. С одной стороны, это ограничивает риск для клиента: он видит, за что платит, и знает, чего ожидать. С другой стороны, нам удобно выяснить, сможем ли мы разработать такое приложение для данных о ставках. Обычно мы не предлагаем прототипы, но ситуация сделала это обязательным. Приложение требовало реализации функции, над которой мы никогда раньше не работали: графики для визуального отображения отношений между людьми.

Прототип показал, что мы можем разработать систему, поэтому мы продолжили наш обычный сценарий:

  1. Прикинули проект
  2. Разработана система
  3. Предполагаемая разработка
  4. Разработано приложение для работы с большими данными
  5. Подписан контракт на техническое обслуживание

Я руковожу проектом. Вместе со мной над проектом работали UI/UX-дизайнер, 4 разработчика и QA-инженеры.

Технический стек проекта — React + Ruby on Rails. Мы выбрали Ruby, потому что он лучше работает с базами данных, а этого проекта требовалось много (баз данных много, слишком много). Кроме того, у него были готовые решения для Apache Solr, поисковая платформа для полнотекстового поиска, готовые библиотеки для Neo4j (графовая система управления базами данных), воркеры и надежные фоновые процессы.

Ruby on Rails предоставляет вам ActiveModel, который является мощным инструментом для интеграции с базой данных, и ActiveRecord, который является настоящим швейцарским ножом ORM. Мы использовали энергичную и ленивую загрузку, проверки, области видимости, префиксы, наследование, обратные вызовы и другие приемы.

Тимлид проекта

Кодовое название, которое мы дали проекту — Большой Брат. Кстати, прототип мы завалили киллер-фичей: нашли и использовали лазейку в системе безопасности vk.com. Эта функция позволила нам убедить клиента в том, что он попал к нужному подрядчику. 🙂

Прототип и лазейка в безопасности Вконтакте

Мы начали с автоматизации таблиц Excel. Конечно, клиент и раньше пользовался таблицами Excel, но потратил огромное количество времени на заполнение всех данных вручную: нужно было создать документ, ввести имеющуюся информацию, добавить номер паспорта, погуглить ИНН — после этого идите искать пени и долги, вводите их в таблицу от руки.

Чтобы упростить обработку больших данных, мы интегрировали Xneo и некоторые другие сторонние сервисы в таблицы. Благодаря этому информация собиралась и хранилась там автоматически. Когда мы закончили, это работало следующим образом: аналитик вносит в таблицу имеющуюся информацию → система запрашивает услуги и забирает нужные данные → система дополняет таблицу.

Работая над прототипом, мы нашли лазейку в безопасности социальной сети Вконтакте. Эта лазейка позволила нам найти личные аккаунты в vk.com только по номеру телефона.

Открытый API vk.com не позволяет это сделать, но мы нашли способ: использовали приватный API, прокси и имитировали реальную активность пользователя в мобильном приложении. Вконтакте запросил доступ к списку контактов пользователя, чтобы уведомить, когда кто-то из его друзей зарегистрируется, — поэтому мы просто воспользовались этой возможностью.

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

Однако «ВКонтакте» в итоге нашел эту лазейку и залатал ее — это произошло уже после старта проекта. Конец истории, озорство не удалось.

Нет отзывов, нет предпочтений

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

Итак, мы начали углубляться в проект. Да, это заняло много времени на старте, но помогло правильно все спроектировать. Наш ведущий дизайнер с головой погрузился в разработку пользовательских сценариев: потратил уйму времени на поиск своих знакомых и незнакомых людей в интернете и изучение геотегов на их фотографиях, копался в открытых источниках и даже обращался к базам данных налоговой инспекции и ГИБДД. . Он пытался понять, где эти люди работали, жили, отмечали праздники. Сегодня это легко, потому что людям нравится делиться каждым моментом своей жизни.

Спроектировать систему больших данных не проще, чем программировать систему больших данных

Исследование помогло понять, какая информация будет доступна клиенту на старте: паспорт, полис личного страхования, номера телефонов — их можно заполнить в ручную. Вот так мы придумали форму для настройки профиля. Мы намеревались сгруппировать подмножества профилей в логические категории. Так как особых пожеланий со стороны клиента не было, мы не столкнулись с существенными правками, но были некоторые режиссерские корректировки, которые звучали как «лучше разместить это поле здесь, потому что нам так удобнее». Мы никогда не спорим о таких исправлениях: удобство пользователя на первом месте, и в данном случае клиент и пользователь — одно и то же лицо. В конце концов, это разработка больших данных для бизнеса.

Когда мы закончили с центральной частью, мы приступили к проектированию визуализации графа. Это казалось сложнейшей задачей из-за ограничений, установленных библиотекой D3: мы не могли привнести что-то новое, только настроить то, что дала библиотека. Было тяжело, но мы справились. 🤘🏻

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

Ваша жизнь в наших руках

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

  • КРОИНФОРМ: обеспечивает доступ к ЕГРЮЛ, ЕГРН, Федеральной налоговой службе, Федеральной службе судебных приставов и другим интернет-источникам
  • Xneo: позволяет найти открытые данные из аккаунтов в социальных сетях, объявлений, размещенных на avito.ruhttps://www.avito.ru/, cian.ruhttps://omsk.cian.ru/ и других торговых площадках C2C. Кроме того, он может найти информацию о владении транспортным средством

    • .

  • Открытый API vk.comhttps://vk.com/
  • Авинфобот: обнаруживает объявления о продаже автомобилей, размещенные на drom.ruhttp://drom.ru/ или avito.ruhttps://www.avito.ru/ , информацию обо всех парковочных талонах
  • Бот ЕГРЮЛ: информирует если человек зарегистрирован в качестве индивидуального предпринимателя
  • MNP-бот: находит информацию об операторе связи и регионе, в котором зарегистрирована SIM-карта
  • ФСИН России: проверяет, находится ли человек в розыске
  • МВД России: проверяет паспорт
  • ГУБДД России: позволяет проверить парковочные талоны и узнать, были ли штрафы
  • Реестр Залогов: поиск объявлений о залоге имущества
  • КонтурФокус: сервис интегрирован еще с 26 источниками. Позволяет искать контрагентов, корпоративную принадлежность и находить информацию по ИНН (предпринимательская деятельность, доли участия в юридических лицах).

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

Аналитик службы безопасности может создать профиль человека, получить все возможные связи между этим человеком и сотрудниками, а затем выгрузить данные в таблицу Excel. Профили автоматически обновляются — поэтому даже если вы поменяете паспорт, организация будет об этом знать.

Когда источники на шестерках и семерках

Трудно интегрироваться с таким большим количеством источников. Конечно, у некоторых из них был полноценный API, а вот другие можно было реализовать только хитростью. Например, иногда нам приходилось отслеживать запросы, отправляемые фронтенд-сервисом, и пытаться их повторить.

Периодически какие-то сервисы выходили из строя, какие-то — меняли свои API. Поэтому приходилось постоянно следить за стабильностью каждого из них. Кроме того, иногда мы отправляли в сервис слишком много запросов и превышали лимиты, поэтому система выдавала ошибки. В этом случае половину списка удалось обработать, а половину найти не удалось. Чтобы система работала безотказно, мы запрограммировали паузу: обрабатывает одного человека → возвращает данные о нем → ждет определенное время в зависимости от сервиса → начинает обрабатывать следующего. И так до окончания установленной аналитиком очереди.

Было бы здорово, если бы проблема заключалась только в интеграции. Просто интегрировать систему с сервисами недостаточно: данные нужно найти и правильно записать. При этом учет у всех ведется по-разному: у одного сервиса формат даты типа «день/месяц/год», у другого «день. месяц.год» или даже «день-месяц-год». Человек легко с этим справится, но для системы это непосильная задача, поэтому нам пришлось как-то адаптировать информацию из всех источников самостоятельно.

Для решения проблемы необходимо было нормализовать данные. Итак, мы подключили приложение к системе управления MongoDB. Теперь все работало так: мы получили информацию → поместили ее в MongoDB (другими словами, заполнили базу сырыми данными) → нормализовали данные → сохранили структурированные данные в PostgreSQL (т.е. почистили и довели до совершенства). Таким образом, все отображалось корректно, и разные форматы данных, получаемых от внешних сервисов, перестали быть проблемой для нашей системы.

Битва титанов

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

Библиотека D3 не так проста. Отложив в сторону сложную терминологию, он дает вам набор инструментов. Скажем, это молоток, гвозди и доски. Что бы вы ни построили — первоклассный дом или сельский туалет — всегда зависит от вас.

Руководитель проекта 

Мы остались довольны библиотекой, но поняли, что внедрить ее в код будет сложно. Нам нужно было создать библиотеку D3 со своими принципами структурирования документа в React, которая управляла DOM-структурой самого документа. Было 2 сущности, конфликтующие друг с другом и борющиеся за независимость — и нам нужно было вложить их одну в другую. Вот почему мы решили поискать что-то еще, что уживалось бы с React.

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

улица Ленина в каждом городе

Для фронтенда мы взяли библиотеку D3, а для бекенда Neo4j. Neo4j — это система управления базой данных на графах — она отлично подходит для выстраивания отношений между разными узлами (а клиенту это было нужно именно так).

В системе «узел» — это человек. У каждого узла есть куча «отношений», которые представляют собой место работы, место жительства и так далее. Но вот проблема: допустим, мы создаем профиль человека. Человек проживает по адресу Ленина ул. Вы знаете, сколько таких адресов в России? Практически в каждом городе есть улица Ленина. Какие отношения будут в этом случае? Верно, неправильно. Это будет просто набор точек, которые невозможно разобрать. Система просто не понимала, как связывать людей.

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

Поиск учебных заведений в вк: выбрать страну → выбрать город → выбрать школу

Разные школы, одна история. Для поиска уникального ID мы использовали открытый API vk.com. Они устанавливают идентификаторы в соответствии с подходом от общего к конкретному. Благодаря ему наша система всегда понимает, какая школа из ста школ нужна.

Оптимизировать то, это и одно из этих

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

Изначально мы добавили оперативной памяти. Neo4j задушил большим количеством запросов, в результате приложение стало работать медленно. Мы увеличили лимиты системы по умолчанию до максимума и запретили «мусорщику» сервера Puma убивать тяжелые процессы. По умолчанию он сбивал процесс преобразования больших графиков, потому что они требовали много памяти. Таким образом нам удалось перестать отклонять запросы. Но мы хотели стать лучше.

Мы начали копаться в предметах, которые мы получили от Неоджа, и нашли узкое место. Дело в том, что Neo4j для работы нужен определенный набор данных: мьютекс, идентификаторы, параметры и множество дуалов и удвоений. Однако системе это было не нужно для построения графиков. Мы сделали так, чтобы в конвертацию JSON отправлялись только необходимые единицы, что повысило производительность на 20%.

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

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

Frontend-разработчик проекта

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

Чтобы решить проблему бесконечной прокрутки, мы сгруппировали все поля ввода и переработали дизайн — теперь все данные хранятся в специальных вкладках

Поисковик

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

Мы выбрали Apache Solr, потому что нам нужен был инструмент для полнотекстового поиска и группировки результатов поиска. Наш опыт показал, что лучше всего с этими задачами справляется Solr.

Тимлид проекта

Внедрить поисковик не составило труда. Трудно было понять, как сортировать результаты поиска. Решили добавить параметры для поиска по ним — пришлось повозиться с индексацией, потому что каждый параметр нужно было индексировать по-разному. Например, если мы знаем фамилию, мы можем запустить:

  • поиск с точным соответствием
  • поиск по первым буквам
  • поиск по вхождению

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

Выглядит так: если пользователь вводит «rtx», система предложит несколько разделов для специализации поиска — например, здесь пользователь может продолжить поиск в графических картах или корпусах ПК.

Вот как мы это сделали: допустим, пользователь вводит «Джон» → система показывает самые достоверные результаты по всем профилям — будь то имя, фамилия или название компании → пользователь может выбрать параметр, который он ищите и продолжайте искать там. Это удобно, когда мы говорим о таких массивных данных.

Мы также добавили Edge N-граммы, чтобы включить поиск в реальном времени. Например, мы хотим найти компанию под названием «Purrweb» 🙃 — начинаем вводить и видим результаты, начинающиеся с «p…», «pu…», «pur…», «purr…» и так далее.

Клиент одобрил то, как мы реализовали поиск, но вскоре придумал, как его улучшить. Департамент безопасности хотел, чтобы было как в Google: пользователь вводит поисковый запрос, а система выдает вам все, что касается — не только результатов, но и предложений («Вы имели в виду…?» или «Люди также ищут…» ). Пользователь может согласиться с предложением или нет — если нет, система запускает поиск по всем профилям. Однако мы сохранили возможность применять параметры.

Чемпионы в тяжелом развитии

Работа над таким проектом интересна сама по себе. Работа с таким клиентом — государственной организацией — добавляет пикантности. На каждом звонке присутствовало по 5-7 человек с серьезными лицами и серьезными вопросами. Каждый — со своим видением проекта. Стратегические решения и договоренности утверждались еще более серьезными людьми. Однако мы были готовы к переговорам: именно так обстоят дела при разработке больших данных для бизнеса.

Мы работали на основе фиксированной цены (в конце концов, это тендер), и нам нужно было добавить миллиард новых функций. Если это были небольшие изменения, мы сделали их бесплатно. Если большой — потратил 3-4 часа на звонок, чтобы объяснить, почему мы не можем взять его в работу.

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

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

Результат

‘В отставании еще остались некоторые фичи. Однако наши сотрудники уже пользуются системой. Приложение, которое обрабатывает большие данные, помогло нам оптимизировать рабочий процесс — теперь большинство задач выполняются в 20 раз быстрее.