Любое хорошее дело начинается с:
1) острого желание заказчика сделать нечто качественно и минимальными издержками (это по сути отсутствует, никто в министерстве финансов персонально за это направление не отвечает)
2) назначения ПМа, и предоставления ему серьезных полномочия (ну например он может в любой момент позвонить министру финансов и решать любые вопросы с ним)
3) ПМ находит толкового Архитектора (данный чел должен быть в первую очередь финансово независим от поставщиков решений)
В данном конкретном случае нужен еще грамотный Методолог, с опытом работы у фискальщиков, аудиторов, казначеев. Крайне желателен опыт работы в серьезной западной компании. Обязательно тонкое понимание современных мировых тенденций в области бухучета.
Эти три товарища, плюс заказчик являются ключевым фактором успешности, качественности и стоимости проекта.
(ну это все и так очевидно
, и также очевидно что в КЗ невозможно на данный момент выполнение данных условий)
Здесь проскальзывали мысли об использовании тех или иных платформ. На самом деле это не очень важно. .NET, Java, Oracle, MSSQL или что то еще - не принципиально. Главное чтобы технология была промышленной, и разработчики были в ней асами. Все остальное рюшечки.
Были осторожные посты про архитектуру. Безусловно это должно быть две подсистемы - фронт и бэк. Причем крайне желательна минимальная зависимость между ними, общение только через стандартизированный API. Как следствие, каждая из подсистем может разрабатываться разными командами на разных платформах.
С бэком, на мой взгляд, все более-менее ясно. Основное хранилище - промышленная БД. Бизнес-логика с использованием либо средств самой БД, либо средств тесно интегрированных с БД. Обязательно - поддержка кластеризации (хотя на сегодня нельзя назвать средство промышленнымб без поддержки оного).
С фронтом тоже, на мой взгляд, без особенных альтернатив. Главное требование к фронту - принимать файлы/данные от клиентов, способность держать пиковые нагрузки (насколько я понимаю, со сдачей налоговой отчетности есть определенные сроки, соответственно все стараются сдать к этому сроку. плюс, клиенты подключаются как правило, все в одно время. думаю, с после обеда до вечера. все наемные люди работают в рабочее время, прежде чем сдавать отчетность, ее нужно подготовить, поэтому до обеда готовим данные, после обеда сдаем).
Поэтому используемые средства - берем из мировой практики, из больших высоконагруженных веб-проектов. Очереди, статика, прегенерация - наше все.
Имеем, толстый клиент, который готовит данные, сливает их в файл, файл сжимается, подписывается. И по https заливается на веб-сервер. Веб-сервер файлы просто тупо складывает в очередь (ну может быть с минимальными процессорными издержками проверяется только целостность файла после заливки).
Дальше, бэковый агент последовательно (возможно в несколько потоков) обрабатывает принятые файлы - проверяет структуру, парсит, извлекает данные, проверяет данные на логику, перерабатывает их, ложит в БД. В общем делаеют всю черную процессорнотребовательную работу. Результат обработки каждого файла обработчик пишет опять же в файл, и опять же ложит на веб-сервер.
Дальше, толстый клиент, время от времяни после заливки обращается к веб-серверу за результатами обработки. Т.е. пытается тупо получить определенный файл с веб-сервера (тот самый который генерится обработчиком файлов).
Т.о. фронт - это веб-сервер оптимизированный на работу со статикой, с минимальным скриптингом на серверной стороне, и минимальной (приближающейся к нулю) бизнес-логикой, с поддержкой кластериции. Как следствие, веб-сервер сможет легко прокачивать пиковый трафик от налогоплательщиков.
Бэк же сможет обрабатывать файлы круглосуточно, а т.к. бэк процессорнотребователен, то процессорная нагрузка размазывается во времени, что позволяет более рационально использовать ресурсы. Результаты обработки в особо тяжелые периоды могут даваться и на следующий день, думаю это лучще чем пытаться отправить файл в течении нескольких дней изза недоступности принимающих серваков.
Вполне возможно на веб-сервере наличие веб-интерфейса. Опять же с минимальным серверным скриптингом. Как опция, но сопуствующем веб-сервере можно запустить аналог толстого клиента, но с сильно упрощенной функциональстью. Основная идея такая (тут важно отметить следующее, с текущим программами по сдаче налогоотчетности не знаком вообще, кроме того что за кружкой пива обсуждал наболевшее с ребятами тесно контактировавшими с сим продуктом). Думаю, что сложность налоговой отчетности разная. Уверен, что малый бизнес и ИП заполняют не более нескольких цифр. Вот им то и нужно дать инструмент для максимально простого заполнения данных, без установки софта, обучения и прочего. Т.о. сопуствующий веб-сервер должен генерить те же файлы что и толстый клиент. Предполагаю, что количествено, налогоплательщиков сдающих "простую" отчетность, больше. А потому им будет интереснее генерить файлы для сдачи через сайт. Если налогоплательщик вырос до уровня что требуется заполнить "много" цифр, то тут уж будь добр переходи на толстого клиента.
Войти
Регистрация
Наверх
