Сметные программы / Единый формат загрузки-выгрузки данных  

Просили. Сделали. Добавим в формат.
Импорт ССР никто не просил. Если хотите - добавьте тег <ssr></ssr> в головной тег и распишите его.
Начнем с ННР-2012. Получиться - сделаем и РСН-2007. Больших отличий там не будет.

тут просто нормативку поменяли. теперь нет общего процента на транспорт. надо это учитывать. Скорее всего придется писать % по каждому материалу.
Предложите свою. За основу структуры взял бумажный вариант сметы - СТРОЙКА - ОБЪЕКТНАЯ СМЕТА - ЛОКАЛЬНАЯ СМЕТА - ПТМ - РАСЦЕНКА - ЦЕНА НА ЕДИНИЦУ и СТОИМОСТЬ.
К "естественным" атрибутом (npp, obosn, naim и т.д.) добавлял атрибуты, которые требовались в СМР-Про (tip, tr_zak  и т.п.).
Структура tip - минимум, который нужен СМР-Про. Мне Татарникова больше нравиться

Здравствуйте всем!
Хочу высказаться по поводу коэффициентов, как в исходных данных так и в самих расценках. p5, p4_ohr, p4_pp - что это? Завтра нашим законодателям как обычно влетит в голову - Постановление Х + Приказ Y. Будем добавлять новые теги? pX, pX_emim, pY_trt...?
Есть коэффициент, который применяется к зарплате, трудозатратам, материалам, транспорту, ЭМИМ, к ОХР (к накладным), к плановым. Все остальное - Приказ 5, Постановление 666, стесненные условия труда - это бла, бла, бла и может использоваться не более как описание (примечание). Поэтому как вариант могу предложить:
 - в исходных данных <kzp value="" description="" />, <kohr value="" description="" />, <kpp value="" description="" /> и т.д.
 - в расценках либо аналогично, либо <kt zp="1.2" emim="1.2" trud="1.2" trudm="1.2" description="стесненные условия труда">, <kt zp="1.27" description="постановление №5"> и т.д.

Да, будем добавлять.
Проблема в том, что Приказ 5 не на все расценки может относиться.

не надо их смешивать. коэффициенты по приказам особенные. Они при расчете ОХР и ПП не учитываются.

И при каждом выходе очередной ереси менять формат и переписывать процедуру импорта/экспорта. Что за ... затратно.

Без комментариев.

Они не особенные. Они ИЗБРАННЫЕ.
Учет в ОХР и ПП можно регулировать также каким-нибудь атрибутом, например
<kt zp="1.2" emim="1.2" trud="1.2" trudm="1.2" acc_ohr="true" description="стесненные условия труда">
<kt zp="1.27" acc_ohr="false" description="постановление №5">
Мне вот интересно, если завтра выйдет Приказ ПИ, в котором обяжут применять коэффициент 3,14 на заработную плату и учитывать его при расчете ОХР и ПП, к какой касте избранных коэффициентов вы его отнесете?
Я за то, чтобы сделать простой и универсальный механизм, а не лепить горбатого.

к обычным, как и на стесненность.

 Это лучше чем переписывать на каждую новую версию CiC.

Хорошое предложение. Кто за?

Я за.

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

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

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

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

Ок. Вечерком постараюсь сообразить.

т.е. acc_ohr регулирует учитывать ли в расчете ОХР и ПП? а зимние, а временные и т.д.? поэтому предлагаю ввести тип коэффициента, а дескрипшен выкинуть
<kt ktype="1" zp="1.2" emim="1.2" trud="1.2" trudm="1.2">
<kt ktype="2" zp="1.27">
т.е. 1 - стандартный коэффициент, 2 - по Постановлению №5 и т.д. . А сметные программы по типу уже сами разберутся куда этот коэффициент поставить и как его обработать.
Да и при добавлении нового "особенного" коэффа всего лишь добавится новый тип. В остальном поддерживаю.

Хороший вариант, наверно даже оптимальный.

Хорошо, только дискрипшен нужен все-таки (для типа 2 (по Постановлению №5) он конечно не нужен).

Перезаписал файл с учетом пожеланий.
Красным цветом выделил спорные теги.
Надо их расписать.
Ждем от Татарникова полный вариант тега <tip>. Убрал 2 узла <nabor_kf> и <prikaz_kf>
<cena> и <stoimost> убирать не стал. И так перегружен тег <rascenka>. Да и стоимость можно самому высчитать не считывая из xml. Поэтому можно игнорировать при ИМПОРТЕ.
Или все-таки убрать как предлагал Татарников?

Не увидел транспорта в материалах расценки.
Можно добавить в коэффициенты - коэффициенты на ЗП, ЗП машинистов и на транспорт.
В остальном вроде гуд.

Думаю, что убирать не стоит. Округления такие разные бывают

Добавил тэг ssr. Доработки формата минимум - пользы масса (по крайней мере для нас ).

Может быть я что-то упустил по форуму ... Подскажите пожалуйста, как приблизительно будет выглядеть структура согласно вашему описанию, если я хочу экспортировать следующую информацию:
стройка
    объект 1
        локальная смета 1
        локальная смета 2
    объект 2
        локальная смета 1
        локальная смета 2
Что-то мне подсказывает, что придется городить двухуровневый 3D забор.

вообще-то я предполагал отдельный тег на одном уровне с исходными дынными и объектной смете. А так, действительно, двухуровневый 3D забор.

в "объект 1" и "объект 2" одни и те же сметы?
"объект 1" и "объект 2" это "объектные сметы" или физические объекты?
Вот поэтому я и предлагаю структуру: см. сообщение за 10 января

Посмотрел сообщение за 10 января. Полностью одобряю и ЗА эту структуру. Хотелось бы теперь в детальной разработке отталкиваться именно от этого формата. Особенно хорошо прикручивается объектная смета. По такому же механизму можно в дальнейшем доработать формат добавлением ССР, на том же уровне что и объект. Удобно тем что есть СРР - добавляй, или не добавляй если нету. Есть объектная смета - добавляй ...

Ок. Добавлю еще один уровень. Стройка-Объект-Объектная смета.
Не по теме: Как вы в своих программах ССР считаете и  акты, если сметы (объекты) выполнены в разном уровне цен и одни сметы с НДС другие без НДС?

Не уровень! Ты не понял.
Стройка
    Объект
        Объектная смета - 1
        ...
        Объектная смета - n
        Локальная смета (акт) - 1
        ...
        Локальная смета (акт) - n

Т.е. Объектные и локальные сметы (акты) лежат на 3-м уровне. А в объектных сметах указаны только ссылки на сметы.

Для ССР и объектных смет при их создании указывается набор "исходных данных": Месяц ставок, зона, область, льгота по НДС, ставка НДС. Аналогичный набор есть и у локальных смет. Если хоть что-то из этого набора не совпадает - программа не даст включить локальную смету в объектную или объектную (локальную) в ССР.
ССР с разным НДС - это ещё та засада! Пока никак.
Со слов одного из экспертов (в смысле из "экспертизы") в СиС сейчас сделали так: В ССР включается две обектные сметы с указанием на какую объектную начислять НДС, а на какую нет. При этом, если объект с разным налогообложением (встроенные помещения), то в две разные объектные сметы включаются одни и те же ЛС с указанием процентного соотношения жилой/нежилой части. Хотя по уму сами ЛС должны быть пересчитаны по-разному (с НДС и без). Короче, похоже само РНТЦ не знеает как это разруливать.

Это как? Смысл тогда в чем? Локальная смета не может или может быть привязана к 2-3-n объектным сметам?
Распишите с это с параметрами. Не понятен смысл без визуального представления.

Распишу завтра. Сегодня уже крыша едет.
Смысл в том, что:
1. Локальная смета может быть не привязана к объектной
2. Локальная смета может использоваться в 2-х разных объектных сметах
3. Локальная смета может чудесным образом стать актом выполненных работ. Суть актов и смет одинакова: там тоже есть ПТМ-ы, расценки, ресурсы и т.д. Разница лишь в том как ты их обозвал: "Смета" или "Акт"

Понял. Оставляем как есть. В естественном виде. Стройка-ОС-ЛС.
 
Это понятно. При экспорте "свободной сметы" создадите еще одну ОС (параметры вытащите из ЛС). После импорта пользователь сможет отвязать.
В СМР-Про такого нет. ЛС строго привязана к ОС. Такой вариант скорее всего не подойдет.

Вопрос не по теме - акт состоящий из нескольких ЛС создать невозможно или есть возможность?
Просто в СМР-Про Стройку можно превратить в акт. Акт содержит ОС-ЛС-ПТМ-расценки.

А как насчёт демократии? Подчинения меньшинства большенству и всё такое?

Почему Стройка-ОС-ЛС это естественный вид? Вы надеюсь понимаете что объектная смета строиться по локальным? И зачем мне для экспорта данных создавать объектные сметы, если у меня их нет? Надо правильно выделять сущности и взаимоотношения между ними.

В бумажном виде так. Поэтому и естественный В СиС, кстати,  тоже так. L1 состоит из списка L2, L2 состоит из L3... И это не мешает всем импортировать из СиС, а некоторые еще и экспортируют в СиС.

Понимаю. ОС - это по сути объединение ЛС в одно целое. Поэтому и предлагаю структуру
<stroyka>
... <ob_smeta>
... ... <loc_smeta>

Надо сделать так, чтобы всем формат всем подходил. СМР-Про скорее всего такое не подойдет.

Это будет уже не XML. Так можно и ресурсы из расценки вытащить, а в расценке хранить ссылки на ресурсы. Такой подход правилен для организации БД, но не для XML. Не путайте этих вещей.

P.S. Tatarnikow, жду подробное описание тега tip.  
P.S.S. Я вот не совсем понимаю, как ЛС может быть в 2-х ОС. Допустим есть 2 ОС и 1 ЛС которая и там и там. Сметчик решил удалить ОС-2 из стройки, так как не выполняют такие работы. Что произойдет с ЛС?
P.S.S.S. mike, какую организацию представляешь?

Я так понимаю объект1/объект2 - это просто названия реальных объектов?
Давайте определимся можно ли в один хмл пихать несколько строек,  объектов, сср-ов и прочих объектов сметного дела? Т.е. могут быть 2 тэга stroyka в одном хмл? Если нет, то описанное выше реализовать одним хмл-ем не получится.
Mike мучит вопрос, а что делать если надо заимпортить, например, только одну ЛС и все, так? Вариант, предложенный г-ном Татарниковым, вполне неплох и можно им воспользоваться. Меня смущает только то, что формат хмл предполагает древовидную структуру, без безусловных переходов типа goto, чем и являются ссылки на локальные сметы в тэгах объектных смет. Аналогично можно построить и ССР. И да, действительно это можно сделать позже, т.к. тэги ЛС и ОС он не затронет. Поэтому, если это всех устраивает, давайте так.
В структуре, предложенной мной, при необходимости создания только, например, ЛС  можно пойти 2 путями:
1. Пропускать тэги ssr и ob_smeta и к объекту сразу цеплять тэг loc_smeta, ну и далее по написанному...
2. Создавать тэг ssr, как некую пустышку, и к нему создавать тэг ОС, также пустышку, и уж потом нужную ЛС.
Может, это чуть сложнее с точки зрения реализации, но зато все однозначно, прямолинейно и исключаются нарушения целостности в виде объявленных, но неописанных ЛС или еще чего. И, кстати, повторяет логику составления ПСД, что тоже неплохо. Но здесь, если в сметной программе ЛС входит в две ОС(а у нас такое, например, возможно), то после экспорта/импорта подобного хмл, будут созданы все равно 2 ЛС, по одной в каждую ОС, хотя и полностью идентичных. Но подумайте, часто ли вы будете выгружать для другой сметной программы подобную ситуацию?
Cooper, сорри, не совсем понял какая структура имеется под фразой  "отдельный тег на одном уровне с исходными данными и объектной сметой", и каким образом главы будут связываться с ОС...

И да и нет. Главный тег должен быть 1. Можно более высокий уровень придумать. Но зачем? Проще 2-3 файла просто сформировать. Файл и так достигает больших объемов.
И правильно, что смущает. Так делать не надо.
Так лучше.
Взглянул на вариант от smetaby еще раз. Неплохо, только возникло пару вопросов. Что делать со сметами, которые не входят в первые 7 глав. Например,  ПНР, сметы на временные? У первой главы есть несколько строк, как там сметы делить?

Насчет ССР - неужели кто-то просил импортировать ССР? Меня еще ни разу не просили.

smetaby, если внимательно посмотреть на формат в данном виде. То по сути ваша структура там реализована. У каждой объектной сметы есть номер главы. просто надо добавить тег <ssr>. Примерно так
<stroyka>
...<ob_smeta>
...</ob_smeta>
...<ssr>
... ...<glava nomer={***} zp={***} em={***} и другие параметры>
... ... ... <stroka nomer={***} zp={***} em={***} и другие параметры>
... ...</glava>
... </ssr>
</stroyka>

Но еще раз повторю. Пока без ССР.

Уважаемый Cooper, мы обсуждаем не возможности отдельно взятых программ, а ОБЩИЙ формат. Становиться в позу типа «У меня это не предусмотрено – поэтому НЕТ!» мягко говоря не корректно. Я в 3-й раз напоминаю со ссылкой на Инструкцию, что в ССР МОГУТ включаться не только объектные сметы, но и локальные. В этом случае они (ЛС) НЕ являются частью ОС. То, что СМР-Про не в состоянии это делать – это не означает что это низззя. Можно! Затачивайте саму программу под инструкцию, а не формат под возможности (вернее НЕвозможности) СМР-Про.
Сама предложенная Вами структура не логична. Если следовать Вашей логике, по которой передаётся пакет СМЕТНОЙ ДОКУМЕНТАЦИИ, то должно быть так: ССР (а не стройка!) – ОС – ЛС.
Я же предлагаю принять за основу НЕ структуру иерархии бумажек, а структуру физических объектов: Стройка – Объект. Теперь смотрим какие документы могут быть на каждый элемент:
На Стройку: ССР. Или ССР-ы. Их может быть несколько (первоначальный, с замечаниями экспертизы, правильный, самый правильный и т.д.)
На Объект: Объектные сметы, локальные сметы, акты, наряды и т.д. (список зависит от границ воображения)
Ну создам я пустой узел ОС ради того, чтобы включить туда локальную смету, которая у меня ни к какой объектной смете не относится. Это не сложно. Тебе от этого легче станет? Ты подумал как ты его у себя будешь обрабатывать???

И давайте договоримся: "У меня не так!" - не является аргументом.

Ну, дык, показал же. Единственное, можно добавить пунктом, например, 110 - расценка фиксированными суммами. Хотя с другой стороны любая строка может быть фиксироанной суммой. Поэтому, второй вариант - пометку "фиксированные цены" вынести отдельным тегом (да/нет).

Поддерживаю.

Подумав еще раз больше нравится вариант: 1. Пропускать тэги ssr и ob_smeta и к объекту сразу цеплять тэг loc_smeta, ну и далее по написанному...
Это дает необходимую гибкость. Т.е. из цепочки Стройка->Объект->CCР->Объектная смета->Локальная смета, тэги ССР и Объектная смета могут выкидываться.
И вот это
тоже этим вариантом покрывается.

В тэге статьи/пункта главы ССР(главы 9,10) могут быть тэги ЛС. Я про это не подумал, когда писал структуру.

В другую программу и меня не просили. Но у меня есть задумка убрать наш собственный внутренний формат импорта/экспорта и заменить его единым универсальным механизмом. И вот для этого нужен ССР, т.к. пользователи файлы импорта/экспорта используют для обмена между локальными рабочими местами(филиалами, подразделениями и т.д.).
Поэтому давайте решим, делаем ССР сейчас или нет. Если нет, то и обсуждать не будем, сосредоточимся на ЛС. Я, как понятно из вышеописанного - за

Поддерживаю.
 

Не видно как ОС входит в главу ССР. Ссылкой как в предложенном выше варианте? В такой структуре вижу только так, т.к. тэги ОС и ССР параллельные, т.е. находятся на одном уровне.

Смотрите какая ситуация с ЛС без ОС. В одних программах можно включать ЛС в Стройку, в других нельзя.
Можно пойти 2-я путями. Усложнить экспорт или усложнить импорт.
Усложнить экспорт - Строгая структура. ЛС находятся только в ОС. В программах, в которых ЛС могут быть без ОС - формировать ОС для каждой "свободной" ЛС. И в ОС добавить параметр free=1. При обратном импорте -  "локалка" по этому объекту должна включаться в Стройку, а объект не формироваться.
Усложнить импорт - Сделать что в стройке могут быть ЛС И ОС. ВСЕМ придется не только проходится по узлам ОС в стройке, но и по узлам ЛС.  Программы, которые не могут ЛС привязать к стройке, просто будут создавать ОС для "свободных" ЛС.
Можно выбрать любой из вариантов. Проблемы нет. Пишется это 1 раз.

Главное определиться со структурой. Давайте так - xml передает ЛС и 2 уровня выше. Причем верхний уровень существует в единственном экземпляре.
Объект->Объектные сметы->локальные сметы.
Вся проблема началась из-за названий. То что в СМР-Про называется стройка, у Татарникова называется Объект. Вот и все разногласия.
Объект состоит из ОС, а ОС состоит из ЛС.
<obekt><ob_smeta><loc_smeta>...</loc_smeta></ob_smeta></obekt>.

Более высокий уровень и ССР потом. В версии 2.0 формата.

Где? что 521 тип обозначает?

2000 добавил с такой формулировкой.

Вот мое видение структуры
<stroyka>
... <object>
... ... <loc_smeta></loc_smeta>
... ... <loc_smeta></loc_smeta>

... <ob_smeta glava_ssr=""> если есть
... каким-то образом перечислить уникальные номера лок. смет, учавствующих (как предлагал Татарников)
... </ob_smeta>

... <ssr> если есть
... </ssr>
</stroyka>

я бы так оставил.

По сути вы убрали объектные сметы и сср из предложенной. На первое время я бы тоже остановился на таком виде. Потом объектные и сср в любой момент можно прикрутить.

Цены на свалки РНТЦ доводит табличкой - см. прикрученный файл. Там разделено на регионы и в каждом регионе - полигоны ТБО.
Тип 521 = "2" - второй регион (Витебск), "1" - 1-й пунк в списке на Витебскую область (т.е. "ГП «Спецавтобаза г. Витебска»)

Вообще, предлагаю неделю перемирия. На сегодня вполне достаточно данных для работы.
В понедельник сделаю и выложу свой вариант XML в соответствии с тем, о чём договорились. В атрибутах сметы и ПТМ-а добавлю расчитанные суммы (зарплата, механизмы, материалы и т.д.)

По поводу ОС-пустышки, чтобы не городить отдельный атрибут, указывается glava = 0.

Вот, собственно...

дополнения в формат
==в "исходные данные"
'tip_vrem' - тип временных как указано в НРР:  "4.2.", "3.5.а)"
'prc_vrem' - % временных
'vrem_k' - коэфициент к временным

'stesn'  - коэф. стеснённости
'stesn_e46'  - коэф. стеснённости для сборника Е46
'stesn_pnr' - коэф. стеснённости для пусконаладки

'zu_kf1' - коэфициент к норме зимнего удорожания (при реконструкци, реставрации и т.д.)
'zu_kf2' - коэфициент к норме зимнего удорожания (не полный месяц)

'kf_oxr_rekonstr' - коэф. к нормам ОХР при реконструкции
'kf_oxr_selo_sant' - коэф. к нормам ОХР на сантехнические работы для села

==в смету
'vidsmety' - дополнить: 10 - акт на подряд (генподряд), 20 - акт на субподряд, 100 - расчёт контрактной цены, 200 - акт по контракту

'trud_r' - трудозатраты рабочих
'trud_m' - трудозатраты машинистов
'zrp' - зарплата рабочих
'emm' - сумма машины
'zrp_m' - зарплата трактористов
'mat' - материалы (с материалами заказчика)
'tr'- транспорт
'mat_zak' - материалы заказчика
'oborud' - оборудование
'tr_to_oborud' - транспорт на оборудование
'ohr' - сумма ОХР
'pp' - сумма плановой прибыли
'zu' - сумма зимнего удорожания
'zu_zrp' - сумма зарплаты в зимнем удорожании
'vrem' - сумма временных
'vrem_mat' - сумма возврата от временных
'smr' - СМР
'soc' - соцстрах
'full_proch' - сумма прочих
'smr_proch' - СМР + прочие
'nalogi_to_sebestoim' - налоги на себестоимость
'statistika' - сумма для статистики
'nalog_usn' - налог при УСН
'full_bez_nds' - итого без НДС
'nds'- сумма НДС
'full_s_nds' - всего с НДС
'to_oplata' - к оплате

==В ПТМ
'trud' - трудозатраты (можно разделить на рабочих и трактористов но смысла не вижу)
'zrp' - зарплата
'emm' - сумма машины
'zrp_m' - зарплата трактористов
'mat' - сумма материалов
'tr' - сумма транспорта
'pryam' - прямые затраты
'oborud' - сумма оборудования
'tr_to_oborud' - сумма транспорта на оборудование
'ohr' - сумма ОХР
'pp' - сумма плановой прибыли
'zu' - сумма зимнего удорожания
'zu_zrp' - сумма зарплаты в зимнем удорожании

== в "rascenka"
'musor' - лишний атрибут. Что везётся - определено классом груза.

уже писал ранее:
атрибуты
'prc_ohr'
'prc_pp'
'prc_zu'
'prc_zu_zrp'
из "cena" перенести в "rascenka". Не логично смотрится: 'tip_ohr_pp' - в "rascenka", а их же проценты в "cena". То же и с зимними.

Остались следующие вопросы:
1. Нормы накладных/плановых пишем "голыми" или расчётные (т.е со всеми навороченными коэффициентами)? Мне больше нравятся "голые" (как в приказе). Хоть можно догадаться откуда они взялись в случае чего.
2. Что показывать в расценке в "cena" и "stoimost" в части 5-го постановления? Полную сумму с учётом удорожания? На мой взгляд надо разделить стоимость зарплаты на основную и удорожание по постановлению (или показать стоимость удорожания "в том числе"). Иначе запутаемся с числами.
3. Так и не врубился зачем атрибут 'vid_ohr_pp' для каждой расценки??? В ОДНОЙ локальной смете НЕ МОГУТ быть часть расценок на "Новое строительство (село)", а часть на "Реставрация в Минске". Если этот атрибут так уж необходим - то вынести его в "исходные данные". Но его смысла в каждой расценке не вижу.

Скачал пример - Газоснабжение, смотрю и недоумеваю ... А зачем тег <ishodnye_dannye> с одними и теми же атрибутами в <stroyka>, <object> и <loc_smeta>? И зачем в смете трудозатраты рабочих, трудозатраты машинистов, зарплата рабочих, эксплуатация ... и все остальное, что вы добавили и что в состоянии посчитать каждая программа самостоятельно? Зачем передавать расчетные значения, если их можно самостоятельно посчитать по исходным?

Мне "исходных данных" достаточно только для сметы. Расчётные значения - не принципиальные (убрать всегда проще). Я их тоже никак не обрабатываю при чтении (пока).
Но есть дурная идея передавать в этом формате выполнения (суммы) от субподрядчиков генподрядчику для формирования общей справки С-3. Представляешь, когда в месяц у генподрядчика проходит 50 субчиков и надо свести общие С-3 по каждому объекту...

Передавать готовые суммы - действительно дурная идея... хотя и не обделена смыслом. Просто на данном этапе, когда договорились "ниочем", попытки охватить сразу все не приведут к быстрому единому согласию. Мы не можем даже сойтись в едином подходе, что бы просто локальную смету экспортировать/импортировать.
Исходные данные считаю должны быть только в смете. Причем атрибут baza необходимо отнести к стройке. Что-то я сомневаюсь, что есть разработчики, у которых в одной стройке могут быть сметы, составленные по разным базам, хотя могу ошибаться.
Не увидел в расценке межразрядного коэффициента. Или атрибута с разрядом будет достаточно, дальше по разряду каждый сам вытянет межразрядный?

Согласен.

Хорошо. Пусть будет так.

Что такое vup_mec в локальной смете?
Не понимаю зачем в исходных данных коэффициенты на стесненность и коэффициент по 5 постановлению.
В механизмах атрибуты - cena_0, stm_0, cena_1, stm_1, сena_zrp, stm_zarplata. Последние два предлагаю переименовать в cena_zpm и stm_zpm. Не принципиально конечно, но будет в одном стиле что-ли.

"vup_mec" - месяц выполнения, если передавать акт.
Да не заморачивайся ты на мелочах! Тут основная проблема - чтобы структура дерева совпадала. А если встречается "лишний" атрибут (не описанный в структуре) - ну, дык, игнорируй его! Например, те же "исходные данные". Да хай они будут (дублируются) и в стройке и в объекте! Откуда тебе удобней их выковыривать при чтении - оттуда и бери! Остальное - пропускается.
Стеснённость прописал и в "исходных данных" и в расценках. Кому откуда удобней брать - пусть оттуда и читает. То же и с 5-м пост. Тебе они чем-то мешают в "исходных данных"?
Стоимости в ресурсах, на мой взгляд, - лишнее. Цену на количество умножить каждый в состоянии. Но раз в структуре описано - значит прикрутил. А как их обозвать: "stm_zarplata" или "stm_zpm" или ещё как - это мелочь, которую можно изменить в течении 2-х минут.
Блина! Да займитесь вы уже наконец чтобы хоть основную структуру могли читать/писать!

Так наверно уже со структурой определились, или нет?

Разработчик Tatarnikow при экспорте данных пишет коэффициент К5 в теги Т1 и Т2. Разработчику mike удобней брать его из тега Т1, соответственно и ложит он его в ту же полочку. Разработчику Cooper все равно откуда читать К5, но бросает он его только в тег Т2. В конечном счете Tatarnikow и Cooper успешно обмениваются информацией, а mike уперся, потому что видит большую беду в дублировании информации и разном подходе при создании Единого формата. Но это его позиция и он пока затрудняется объяснить, чем это (дублирование информации и раздутие структуры) чревато в дальнейшей работе.

Поддерживаю, только ЗА если уберем.

Здравствуйте всем!
Предлагаю посмотреть, что получилось у меня на сегодня. Пока без свода ресурсов (и без еще не малой кучи данных, которые могут использоваться в расчете).

Ведь можете если на самолюбие надавить
Только внимательней с именами атрибутов: не "zp" а "zrp", не "zp_m" а "zrp_m", и т.д.
Транспорт в ресурсах ("tr") в описании - значение в рублях, а не процент. Если нужен % - то другим атрибутом.
Ну и "tip_ohr_pp", "tip_zu", "koef tip" - и вполне адекватно можно будет прочитать смету.
Во всяком случае у тебя уже структура есть, а заполнить её - это уже технический вопрос.

Ну и почему месяц ставок = 01.11.2013, а проценты накладных/плановых для 2014г.?
И догадаться откуда эти проценты появились можно только владея даром ясновидения.
Это так, информация к размышлению...

Тогда наверно надо другим атрибутом. Я думал так, для базы 2006 - стоимость, для базы НРР - процент, что обусловлено еще и последними приказами.
"koef tip" понятно, а вот с "tip_ohr_pp" и "tip_zu" есть трудности. А напомните мне, зачем эти атрибуты?
А зачем догадываться? Может вы еще размышляете, зачем инженер ПТО использовал расценку E00-0-0? вот глупый, ведь расценка E00-1-0 выгоднее! Если у вас при этом реализован алгоритм анализа и рекомендаций пользователю - вы мой кумир! Мы же не контролируем связь между используемыми ставками и процентами накладных/плановых. Какие инженер пожелает, такие данные и использует. Это касается всего - индексов, цен, накладных и плановых, зимних, коэффициентов (договорился я с заказчиком и прописал в договоре коэффициент 10 к зарплате). Конечно, эта свобода может сопровождаться ошибками в процессе составления сметной документации, но данный контроль мы возлагаем на плечи самих пользователей. В противном случае может пострадать гибкость программы. Да и пользователей надо держать в тонусе

Ты проценты накладных, плановых и зимних сам с потолка придумываешь, или руководствуешься каким-то документом? Это номер пункта соответствующего документа.
Вроде же договорились уже об этом.
В твоём случае (для 1-й расценки) "tip_ohr_pp" = "1.1." (номер пункта таблицы 46-го приказа), "tip_zu" = "4.1.а)" (номер пункта НРР 8.01.103-2012 ч2).
Тогда остальные могут понять, что расценка относится к виду работ "Общестрой в гор. черте" и вид зимних = "Монолитные бетонные и железобетонные конструкции зданий, сооружения --> 4.1. Конструкции жилых, гражданских и промышленных зданий --> 4.1 а) фундаменты"
И не надо демагогии, что сметчик может поменять, это гибкость программы и т.д. Если сметчик поменял и поставил своё - тогда не указывай.

Принимается!

Ааа... Вы выстрелили мне в живот. Отпишусь, когда приду в себя.

Я думал так: база 91 или 2006 - значение в рублях, база НРР - процент. Пока не переделывал, но если надо будет - не проблема.
Пока это тоже не сделано. Надо немного поменять базу программы. Тоже думаю не проблема, вопрос времени.
Попытался вывести свод ресурсов, посмотрите пожалуйста в аттаче. Есть некоторые вопросы. Что такое dop_resurs, wid_norm_tr?. По транспорту так же предполагал выгружать либо процент для базы НРР, либо стоимость для других, но под одним тегом. А сделал как у вас. Если материал подрядчика принципиально ли присутствие тегов mat_zak = "0" и tr_zak = "0"? Я же пока вывожу mat_zak = "1" и tr_zak = "1" только если материал и транспорт заказчика.

С большего всё читается, если не обращать внимание на то, что по умолчанию расценки отнесены к виду "общестроительные работы" и с зимними - каша.
Но нарисовалась ещё одна маленькая проблемка. У тебя разделитель целой и дробной части числа - точка, а в моём варианте - запятая. Вероятно, зависит от настройки системы. У себя сделал чтобы читала с любым разделителем. Это чтобы имели в виду.

Вот и год минул...

Вот почти и 2-й год прошёл...

Как я понял никто кроме меня форматом не занимается и перспектив не видит? Всех устраивает лучший в мире формат СиС?
Самое удивительное что "в принципе" все согласны и с большинством принципиальных вопросов нашли согласие.

Поэтому беру тему в свои руки.

В прикрученном архиве:
1) обобщённое, незначительно переработанное и оформленное в подробном виде описание формата
2) тестовый XML-файл с двумя сметами (актами), которые включают в себя расценки на разные виды работ, неучтённые материалы, оборудование, перевозку, затраты на захоронение
3) эти же сметы в печатном виде в формате PDF.

Предлагаю следующий вариант дальнейшей работы:
1) Это описание формата считать как у депутатов "в первом чтении"
2) Всем разработчикам (я надеюсь все сюда заглядывают) до середины мая внимательно рассмотреть предложенный вариант и переслать мне (tatarnikow(собака)yandex.ru) со своими корректировками. Просьба пометки (корректировки, предложения) делать другим цветом чтобы проще было ориентироваться. Если ничего не указано - значит согласны.
3) Все полученные от вас исправленные (откорректированные) описания размещу на сайте и дам ссылки на каждый.
4) Окончательный вариант будет сформирован с учётом предложений, одобренных большинством.

Уважаемые, большая просьба:
1) не лезть в амбиции, типа "а мне надо вот так и пошли все нах...!". Если Вас это утешит, то мне тоже пришлось вносить в программу ряд дополнений и изменений, чтобы заточить под предложенную структуру.
2) не пытаться запихнуть туда ВСЁ возможное - это не реально. Основная цель - передача ИСХОДНЫХ данных в понятном всем виде, с которыми потом можно полноценно работать.

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

P.S. У меня в программе функция как экспорта в XML-файл, так и импорта из него работает с 2013 года и в ближайшее время будет реализована возможность для генподрядчиков получать суммы выполнения субподрядчиков в электронном виде именно через этот формат. "В ближайшее время" - это в ближайших 2 недели

Итак, ссылка на описание "в первом чтении":
http://belstroyka.by/PublicFiles/XML/xml_1.zip

❗️Пора! Набор на 2-ой сезон Телеграм-битвы проектных команд! 
Зачем это нужно?! Сплотить проектную команду и показать вашу компанию изнутри для кандидатов на открытые вакансии!