| » | Казахстанский Бухгалтерский форум www.balans.kz | Технические аспекты функционирования СОНО клиента |
|
Показать сообщения: Начиная со старых .::. Начиная с новых |
|||
| Автор: | Технический |
| Добавлено: | #1 Вт Июл 21, 2009 13:47:02 |
| Заголовок сообщения: | Технические аспекты функционирования СОНО клиента |
Что то долго рожаете. Все просите просите и не решаетесь. Обычные бухи, сюда можете не заходить, тут будут слова по выворачиванию и исследованию формата данных, базы и прочее. Нужно будет разделим ветку, глянем как эта пойдет. Сюда можно перенести уже существующие сообщения. Обратитесь к нашим в личку что надо перенести, сделают. Обычным бухам потом обычным языком в других ветках объяснят, с какой стороны косяк курить. Добавлено спустя 1 минуту 53 секунды: Обычный бух сюда напишет "Где моя форма?", меня расстроит, я хочу покоя и мира. Не надо меня расстраивать. |
|
| Автор: | Sergsen |
| Добавлено: | #2 Вт Июл 21, 2009 14:07:42 |
| Заголовок сообщения: | Технические аспекты SONO-клиента - Предложение по созданию отдельной ветки конференции |
Вношу предложение по созданию отдельной ветки конференции по обсуждению технических вопросов, связанных с функционированием SONO клиента для IT-специалистов, с целью освободить бухгалтеров от восприятия ненужных им технических подробностей и выработке, возможно, более консолидированных рекомендаций. |
|
| Автор: | Sergsen |
| Добавлено: | #3 Ср Июл 22, 2009 02:13:54 |
| Заголовок сообщения: | |
По предложению Witch`ka обратил внимание на описание XML для МОП. Не думаю, что структура XML и методы взаимодействия с ними будут сильно отличаться в других формах. Что удалось заметить при беглом просмотре "Памятка по формам БВУ.xls" и "XMLrukovodstvo_MOP.doc" 1. Структурных тэгов 4: fno, form, field, row. Причем row на страницы не бьется как в СГДС. 2. Те же самые именования некоторых существенных атрибутов тэгов, например уже обсуждавшиеся: dt_main, dt_regular, dt_additional, dt_notice, dt_final (вид формы, один должен быть истиной); rating_auth_code (Код налогового органа); rnn РНН iin ИИН/БИН period_quarter Налоговый период: квартал period_year Налоговый период: год 3. Для импорта XML принудительно устанавливается formatVersion – зарезервированный служебный атрибут, значение которого должно быть равно 2 :( 4. iin, слава Богу, является везде необязателен, но в рядах проходит валидацию. 5. rnn - обязателен в формах, в рядах не везде, валидацию проходит только в рядах. 6. Условий неотправки формы весьма немного, так что после импорта проверка, проверка и еще раз проверка. |
|
| Автор: | victor1682 |
| Добавлено: | #4 Ср Июл 22, 2009 11:51:14 |
| Заголовок сообщения: | |
Отправил запрос на Службу поддержки пользователей программного обеспечения НК МФ РК, получил памятку - расшифровку xml-формата 300 формы, т.е. в какое поле что ложится. Выкладываю файл. З.Ы. Получение данной информации - вещь случайная, формат 200 формы мне не дали :( . |
|
| Автор: | DotNetCoder |
| Добавлено: | #5 Сб Июл 25, 2009 19:36:30 |
| Заголовок сообщения: | |
Посмотрел на препарированные описатели формы. Здесь то, с помощью чего это можно сделать. Утилита для распаковки архивов СОНО *.tar.bz2 Хотел поделиться некоторыми мыслями. Внутри лежат 3 файлика. Для примера возьмем файл form_300_00_v9_r8.tar.bz2. form_300_00_v9_r8.xml Описатель формы - идет перечисление элементов формы. Т.е. поля ввода, чекбоксы, радиобаттоны и т.п. Каждый элемент содержит размеры и положение на страницы (x, y, width, height). Содержатся ссылки на подпись и подсказку в hintCode, labelCode, где внутри число, ссылка на xml файл с локализацией form_300_00_v9_r8_loc.xml. Также по именам видны имена полей для будущей выгрузке в xml с данными (fieldName, originalFieldName). Редактируемость поля editable. Возможности авторасчета? - autocalc. Длина, видимость поля, обязательность, выравнивание, минимальное и максимальное значение. Там же для перечисленных ограничений (обязательность, мин, макс, длина) идут текстовые сообщения, типа "Значение должно быть не больше 2009". Хм, непонятно, что они делают здесь, а не в *loc.xml файле. form_300_00_v9_r8_chr.xml Хм, смахивает на правило разноски: КБК, период. Хотя может какие то дополнительные проверки. form_300_00_v9_r8_loc.xml Файл с локализацией. Структура чуть усложнена. Ну что мешало в entry добавить kazItem и rusItem одновременно...зачем лишний тег, дублирование key и messageCode?! Ну да ладно. entry - содержит код, на который ссылаются из form_300_00_v9_r8.xml, внутри идет нужный текст в полях для элементов формы и сообщений об ошибках. 1. По идее, на этих описателях должен работать и кабинет НП. Только если в клиенте СОНО рендер написан на JAVA, то в кабинете - HTML(DHTML). Т.е. чисто гипотетически - можно сделать заколотушку форм на чем угодно, например 1C, .NET или Flash. 2. Зная формат и его правила - можно создавать новые формы, либо модифицировать существующие. 3. Если все сообщения будут находиться в loc файлах (пока почему то часть есть в основных xml) - то можно легко осуществлять переводы на казахский или другие языки. p.s. добавил xml файлы во вложении к сообщению. |
|
| Автор: | Технический | ||||
| Добавлено: | #6 Сб Июл 25, 2009 22:26:45 | ||||
| Заголовок сообщения: | |||||
Да. Добавлено спустя 5 минут 20 секунд:
Описаны условия валидности зависимости полей. |
|||||