Сообщений в теме: 97

[litePhreon]

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

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

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

ну вот как то так

Сообщение отредактировал litePhreon: 24.07.2009, 12:20:07

[v04bvs]

А со своим форматом можно прийти и автоматизировать этих крупных налогоплательщиков за денежку. И никуда не денутся.

[Joop!-A]

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

[Zulkar]

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

Ух ты как круто! Нужно заставить всех работать только в этом формате, а формат будет поддерживаться только одной глючной и конйликтующей со всем остальным софтом программой, сделанной на откате какой-нибудь фирмой. Естественно он будет нерасширяемым, неудобным, костыльным и т.п. - потому что у нас Казахстане нет специалистов достаточного уровня, чтобы разработать формат. А самое главное зачем? Чем вам soap/http(s) как формат передачи данных не нравится, и html как формат описания веб-интерфейсов?

[Besto4ka]

Ребята здрасти! Я наверно вообще не в тему спрошу...а как на мой комп установить эти чертовые налоговые программы, хотя бы для проверки уведомлений...не буду сильно вас грузить, но попытка миллион неизвестная не проходит. Они (НК) на флэш скидывают яко бы программы которые работают, но...ответьте пжлста! Или в какую тему лучше обратиться? сенкс.

[Zulkar]

Ребята здрасти! Я наверно вообще не в тему спрошу...а как на мой комп установить эти чертовые налоговые программы, хотя бы для проверки уведомлений...не буду сильно вас грузить, но попытка миллион неизвестная не проходит. Они (НК) на флэш скидывают яко бы программы которые работают, но...ответьте пжлста! Или в какую тему лучше обратиться? сенкс.

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

[Besto4ka]

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

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

[Zulkar]

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

Установка СОНО стоит не так дорого. Зайдите на ту же alfa.kz и найдите кто вам поставит.

[Besto4ka]

Установка СОНО стоит не так дорого. Зайдите на ту же alfa.kz и найдите кто вам поставит.

Огромное спасибо за правильное направление. Уже созвонилась и установят без проблем.

[yedyge]

Чем вам soap/http(s) как формат передачи данных не нравится<...>?

тем, же, чем не нравится tcp/ip и rs232.
это не того уровня протокол.

[Zulkar]

тем, же, чем не нравится tcp/ip и rs232.
это не того уровня протокол.

tcp/ip это вообще транспотрный протокол. Хорошо, даже soap over http это протокол не того уровня, слишком низкого. Назовите пример протокола нужного вам уровня, чтобы представить что именно вам нужно.

[T. Anre]

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

+1, ждем-с ответа

[Gloomy]

Zulkar и T.Andre - а можно я?

Ответ: Ну _DSL_ же!

Ну гляньте на IMAP чтоли
А уж в каком туннеле оно пойдет - дело X-цатое ...
Подтверждено мировой более чем 30-летней практикой

[Zulkar]

Zulkar и T.Andre - а можно я?

Ответ: Ну _DSL_ же!

Вы имеете в виду xDSL?

Ну гляньте на IMAP чтоли
А уж в каком туннеле оно пойдет - дело X-цатое ...
Подтверждено мировой более чем 30-летней практикой

Простите мне мое невежество, я с IMAP не работал, а чем он более высокоуровнен чем SOAP, или тот же XML-RPC? Тем что он менее универсален?

[litePhreon]

началось меряние пиписьками...

доступных технологий и архитектур, проверенных временем, по сути пруд-пруди. конкретные детали неважны (soap, imap, xml, etc), важно соблюдать некоторые принципы. эти принципы не являются ноу-хау, как уже отметили отдельные ораторы.

кстати, идея с imap (и как более простой вариант - smtp, pop3) довольно интересная.
все что крутится вокруг http, имеет один небольшой недостаток - "односторонняя" связь, т.е. если на сервере произошли изменения, то клиент об этом узнает только тогда когда сам обратится к серверу. т.к. клиентов много и обращаться к серверу НК они будут скорее в небольшой промежуток времени - время сдачи отчетов.

в случае почтовых протоколов в качестве транспорта, связь становится "двусторонней". клиент отправляет данные по почтовому адресу. сервер НК обработав данные высылает в ответ клиенту ответ, с результатом загрузки.
разница между 1-м и 2-м вариантом в том что клиент для получения результата загрузки обращается не к серверу НК, а к своему почтовому серверу.

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

[litePhreon]

еще один плюс почтовых протоколов.

в качестве локального хранилища на pc клиента можно использовать традиционные почтовые форматы mbox или maildir. плюсы этого шага - наличие готовых библиотек, неплохая производительность с большими объемами неструктурированных данных.

[Zulkar]

началось меряние пиписьками...

да нет пока...

доступных технологий и архитектур, проверенных временем, по сути пруд-пруди. конкретные детали неважны (soap, imap, xml, etc), важно соблюдать некоторые принципы. эти принципы не являются ноу-хау, как уже отметили отдельные ораторы.

О чем и речь Но тут заявляют, если вы заметили, идет о том, что SOAP слишком низкоуровнен и поэтому надо разрабатывать собственный протокол.

кстати, идея с imap (и как более простой вариант - smtp, pop3) довольно интересная.
все что крутится вокруг http, имеет один небольшой недостаток - "односторонняя" связь, т.е. если на сервере произошли изменения, то клиент об этом узнает только тогда когда сам обратится к серверу. т.к. клиентов много и обращаться к серверу НК они будут скорее в небольшой промежуток времени - время сдачи отчетов.

И в этом случае клиент узнает об измениях на сервере только когда захочет с ним соединиться. Здесь http принципиально ничем не отличается. Здесь не нужна двусторонняя связь "real-time" - это же не онлайновый шутер. Или клиент будет постоянно висеть в соединении с сервером? По моему это не самая удачная идея, превращать систему сдачи отчетов в подобие IM.

в случае почтовых протоколов в качестве транспорта, связь становится "двусторонней". клиент отправляет данные по почтовому адресу. сервер НК обработав данные высылает в ответ клиенту ответ, с результатом загрузки.
разница между 1-м и 2-м вариантом в том что клиент для получения результата загрузки обращается не к серверу НК, а к своему почтовому серверу.

А разница?

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

Это если у клиента стоит почтовый рилэй. А если не стоит? Или имеется в виду, что клиент будет отправлять свой отчет на какой нибудь мэйл.сру, а отттуда он будет уходить на сервер НК?

И да, где говорится что smtp гарантирует доставку сообщений, а то я что-то не помню такого.

Ну и по поводу хранения. Готовых библиотек кучи, для любого формата. Почтовые не являются чем-то выделющимся...

Сообщение отредактировал Zulkar: 03.08.2009, 10:14:22

[litePhreon]

Zulkar
агрессию не на меня, а на ваших опонентов, противников soap.
заметьте, я ни слова не говорил против вашего предложения.
я лишь говорил о потенциальных плюсах imap, smtp, pop3 (для простоты общения объединим все в один термин imap)

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

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

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

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

[denmak]

Использовать почтовые протокола - не безопасно(вся защита - логин и пароль). Кроме того, если делать отправку почтой, придется шифровать сообщение отдельно, чтоб, на почтовом сервере не дай бог не лежало сообщение доступное к прочтению...
Имхо, в таких проектах допустим только асинхронный алгоритм работы, думаю наилучший вариант - открытый протокол (именно собственный протокол и ни как иначе) на базе soap via https (естественно с минимальной первичной логикой на стороне веб сервера) строго говоря всякие RMI/DCOM/COBRA и тому подобная ботва пригодна на уровне предприятия, но не в масштабах государства... (ну либо железо как у НАСА надо). Примерно, то как реализован открытый интерфейс можно глянуть тут http://www.govtalk.gov.uk/ В британии электронное правительство развернуто так, как нам и не снилось.
для Zulkar: сам по себе SOAP - можно рассматривать в качестве транспорта, но не как не язык для описания бизнес-данных. при стандартизации протокола обмена сообщениями с НК в любом случае основной проблемой встанет именно стандартизация бизнес части, т.е. непосредственно форматы форм, вот их открыть, да потом еще поддерживать версионность (в связи с нашим "гибким" законодательством) будет оччень сложно.
Конкретно про клиента вообще молчу... считаю что в первую очередь важен протокол, а клиенты должны быть коммерческими (ну хотя в силу нашего законодательства бесплатный клиент всеже должен быть, но он может быть уныл, как бесплатные дороги рядом с автобаном...)

[lupus007]

Так нельзя перейти к реализации не зная что делать.
А я бы да кабы. Территориально-административный справочник, а точнее его отсутствие - трабла №1. И всем пофиг - хотя его надо делать в первую очередь и он должен быть единим для всех систем - причем это отдельный проект по факту.

1) Государственный классификатор административно-территориальных объектов (КАТО) уже отменили? Если интересно - зайдите на сайт Агентства РК по статистике www.stat.kz потом в раздел "Классификаторы" и будет Вам счастье.

2) КАТО имеет свои проблемы, поэтому даже создали отдельную систему "Адресный регистр" (ИС АР). О результатах внедрения пока ничего не известно.