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

А зачем состав работ? Лишние, не нужные данные.

Добавил атрибуты rasstoynie, marshrut, class_gruza для С310, С311.

Убираю

Сократил название атрибутов. В скобках старое название
Добавил stavka_nds в <ishodnye_dannye>
Добавил Цена без/с ндс для материалов и механизмов.

Cooper, не надо нам навязывать формат, заточеный "под тебя". Мои пользователи и без него неплохо себя чувствуют: Импорт из СиС-а и Синкевича у меня есть. Из WSMR данные тоже читать получилось, но до ума так и не довёл - руки не дошли. Я не думаю, что СМР-Про далеко убежал - при необходимости расковыряем и его формат. Экспорт в СИС тоже присутствует.
А СМР-Про умеет только читать СиС. Поэтому и вопрос файлообмена на фоне других программ стоит достаточно остро. Я не прав?
Поэтому, (повторюсь) требовать от нас чтобы все подстраивались "под тебя", мягко говоря, некрасиво.

То что я показал - это результат отработки процедуры, состряпаной за 4 часа в соотвествии с классическими требованиями к структуре XML-документа. И отступать от классической структуры не вижу никакого смысла - это только усложнит чтение данных. Многое пропустил - мне была цель построить структуру, а не буквальное её заполнение - это уже дело техники.

Не должно. Вернее, так может быть, но не обязательно. Если я хочу передать только АВР, зачем городить Стройку, Обектную смету и т.д.
Копировал из твоей же структуры. Пиши внимательней и пробелы из некоторых названий удали.

Мне тот пример что скинул Татарников понравился) может пусть он и остается? единственное - состав работ лишнее.

Чем? Вот 2 примера. В каждом 50000 расценок. Создаются они моментально за доли секунды. А вот импортируются не так быстро.
Первый пример импортируется за  0,7 секунды, второй за  40,9 секунды. Разница есть?

- Рабинович, а шо ви думаете о сексе?
 - Ай не морочте мне голову! У меня пятеро детей - мне некогда заниматься теорией!
Если мы стали вести речь об ОБЩЕМ формате, то он должен соответствовать ОБЩЕПРИНЯТЫМ стандартам. Я не думаю, что формат XML разрабатывали люди глупее тебя.
Слово за Синкевичем - и решение будет принято большинством голосов.
А если у тебя файлы примерно одного размера и примерно одной структуры читаются с разницей в скорости в 100! раз - ищи ошибку у себя в скрипте. Это не тема для этого форума.

Прежде чем Синкевича слушать импорт сделайте в своей среде разработке. Что у вас там? Delphi? И о результатах скажите. Может поменяете мнение.
Вечером еще раз код гляну. Там всего строк 10-15 кода на каждую закачку.  Из-за чего тормозит тоже попробую выяснить.  

А почему бы Синкевича не послушать? Ты считаешь его лупее остальных?
С таким отношением так и останетесь в своей песочнице ковыряться.

вы еще подеритесь, горячие финские парни

У меня оба мгновенно обработало 

Не понимаю почему Tatarnikow считает мой образец не соответствующим ОБЩЕПРИНЯТЫМ стандартам?
Читаем Открываем VFP пишем код:
CREATE CURSOR composition CODEPAGE=1251 (amount N(5,2), unit C(25), naim C(25))
INSERT INTO composition (amount, unit, naim ) VALUES (3, 'стакан', 'Мука')
INSERT INTO composition (amount, unit, naim ) VALUES (3, 'грамм', 'Дрожжи')
INSERT INTO composition (amount, unit, naim ) VALUES (3, 'стакан', 'Тёплая вода')
INSERT INTO composition (amount, unit, naim ) VALUES (3, 'чайная ложка', 'Соль')
CURSORTOXML('composition','D:\composition.xml',2,16+512)
Открываем файл D:\composition.xml. И там видим
<?xml version = "1.0" encoding="Windows-1251" standalone="yes"?>
<VFPData>
   <composition amount="3.00" unit="стакан" naim="Мука"/>
   <composition amount="3.00" unit="грамм" naim="Дрожжи"/>
   <composition amount="3.00" unit="стакан" naim="Тёплая вода"/>
   <composition amount="3.00" unit="чайная ложка" naim="Соль"/>
</VFPData>
Microsoft наверное по стандарту всё делал.
Читаем
XML атрибуты, как правильно писать XML атрибуты
Все XML атрибуты вы придумываете самостоятельно(в отличие от HTML атрибутов), семантику и грамматику для XML атрибутов вы придумываете то же самостоятельно, то есть задаете для этих XML атрибутов смысл и правила.
Параметром или значением XML атрибута, может быть все, что угодно, все на что хватит вашей фантазии. А вот синтаксис у XML атрибутов строгий, значение атрибутов всегда должны быть в двойных кавычках, но некоторые парсеры XML допускают вольности и ставить одинарные кавычки, но лучше к данному подходу не привыкать. Как и в случае с XML тегами, XML атрибутов может быть бесконечно много.
Единицы измерения XML. Корневой XML элемент или корень XML документа.
В XML существует очень важное правило, минимальной единицей измерения является документ, один XML элемент это документ, и этот XML элемент является минимальной единицей измерения — всегда! Как это можно понять? XML документ всегда состоит из одного тега или элемента, по буржуйски этот тег называется root или корень XML документа, это означает, что у любого документа должен быть всегда один элемент(один тег), внутри него может быть все, что угодно, но один XML элемент в XML документе должен быть всегда.

Я надеюсь про стандарт или нет споров больше не будет.

Поздравляем, а фокс тупит на строке loNodes2 = loKlv.nextNode() . Замена на loNodes2 = loKlv.item(0) не помогла
Тем меньше переходов по элементам тем лучше.
Поэтому XML на базе элементов нам не подходит, нам подходит XML на базе атрибутов

Сократил объем строк до 1000. Так как больше 1000 расценок в одном ПТМ скорее всего не будет. Стало 0,026 и 0,060. Моментально, но разница в скорости видна.

Вот ведь упёртый!
Ладно, хочещь структуру с атрибутами - пусть будет с атрибутами.
Т.е. чтобы было понятно всем, ты педлагаешь структуру: Группа (нод) --> Вложенная группа (вложений может быть множество) --> Элемент группы --> Атрибуты элемента.
Мой вариант - то же самое только без "атрибутов". Да, мне лень писать дополнительные процедуры для чтения атрибутов элементов. То что мой вариант будет медленней читаться - согласен. Но даже если вся документация на строительство коровника прочитается не за 2 секунды, а за 20, то, я думаю, меня любой сметчик поймёт и простит
Закрыли тему.

Теперь о структуре самого документа.
Твоё предложение:
- Стройка
  - Объектная смета
    - Локальная смета
Слишком "жёсткая" структура. Чтобы передать ТОЛЬКО локальную смету - надо городить всю вышестоящую структуру.

Моё предложение:
- Локальные сметы
  - ЛС-1
  - ЛС-2
  - ...
- Обектные сметы
  - ОС-1
  - ОС-2
  - ...
- ССР-ы
  - ССР-1
    - глава-1
    - глава-2
    - и т.д.

В этом случае, если мне ненадо передавать ССР или объектную смету - просто не заполняется группа. Локальным и объектным сметам необходимо будет присвоить некие ID номера и связь их между собой описывать по ID.
В структуре локальной сметы добавить свод материалов (а у меня их 2: материалы по нормативу и "произвольные" материалы).
И ещё кучи значений не хватает в описани локальной сметы (она же может являться актом). Например: отчётный месяц, процент единого налога для упрощёнки, проценты на пуск и регулирвку для 18-го и 20-го сборников, коэфициенты к накладным и плановым для хозспособа, коэф. к ОХР для сантехники на селе, услуги генподрядчика, стеснённость для Е46, для пусконаладки и т.д.

tip=105 – Транспорт мусора (С310)
tip=106 – Транспорт ПГС (С311)
Этих понятий не существует. Есть "перевозка грузов автомобилями-самосвалами" и "перевозка грузов бортовыми автомобилями" на что и доводятся ежемесячные тарифы с разбивкой по классу груза. Поэтому tip для этих вещей лучше определить так: 3101, 3102, 3103, 3104 - перевозка грузов автомобилями-самосвалами для каждого класса груза, где последняя цифра - класс груза. Аналогично для бортовых машин: 3111, 3112, 3113, 3114
Не понял назначение некоторых элементов, ну да ладно, если это кому-то надо - пусть будет. Например kodcic - это нафиг надо?

если речь идет о 20 секундах, то безусловно
но если речь идет о 20 и более минутах и есть возможность ускорить этот процесс, то было бы очень даже неплохо его ускорить

А мне важнее, чтобы при экспорте не было ошибок и информация передавалась со 100%тной точностью. Стремиться в первую очередь надо к качеству, и учитывать моменты, что иногда сметчики вносят в формулы корректировки, дополнения, примечания и тому подобное...

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

Пересчитаем, пусть только заработает. :-)

Ребят, для этого вы у нас и есть, чтобы скооперироваться и придумать единую логику, я в вас верю

Это СиС. Хотя можно и так.
Апету нравиться первый вариант, Татарникову второй. Синкевичу?

В моем варианте тоже самое. Все что надо написать 2 пустых тега <stroyka><ob_smeta>Здесь локальная смета с заполненными атрибутами</ob_smeta></stroyka>

Своды не передаются. Формируйте сами после перекачки. Хотя по просьбам можем вставить тег <svod_mat>. Только распишите его.

На первом этапе передаем ТОЛЬКО сметы без актов, чтобы у генподрядчика и субчиков были одинаковые сметы.

Пишите. включим.

Согласен, переименуем.

Нет. Для этого уже есть атрибут class_gruza.

Это Апет просил включил, я не совсем понял зачем. Апет, наверное, думал, что может остальные как СиС расценки по типам делят. То есть tip не заполняется, а заполняется kodcic, а Апет в свою программу перекачивает поимерно так- Если kodcic = "+01000000", то tip = 100. Я так понял, что все против этого атрибута. Можете не заполнять его.

Наверное не все поняли как предполагается заполнять и читать атрибуты.
Пример: В программе А есть такое понятие как Краткое наименование стройки. При экспорте заполняется атрибут krat_naim . В программе Б такого понятия нет. При Импоте этот атрибут просто не считывается. И наоборот При экспорте из программы Б этот атрибут даже не пишется (или пишется как пустое значение -""). При импорте в программу А уже пишется такой код
Если krat_naim = NULL или  krat_naim = "", то krat_naim  = naim.
Так или иначе такой код все равно будет написан. Не останавливать же закачку если кто-то забыл заполнить незначительный атрибут.
То есть каждый программист вытягивает из xml-файла, что ему надо и вписывает в свою структуру. Если он не находит нужного атрибута, то заполняет его значением по умолчанию или еще каким-нибудь способом.  Не совсем вижу проблемы. Например сейчас все из СиС перекачивают. У СиС нет  многих атрибутов, которые есть в других программах, например нет такого понятия как материал заказчика. Уверен, что все при перекачки это поле заполняют значением по умолчанию - 0 или FALSE.

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

Хай будет твой вариант.

mat_zak, tr_zak - сами же себе противоречите - если передаются ТОЛЬКО сметы, то тогда зачем это? И что плохого, если субчик принесёт выполнение в электронном виде?

Объясняю зачем свод материалов. Например: где нибудь у тебя определено какой процент транспорта принимается для КАЖДОГО материала? Нет. Транспорт указан суммой. И как другие должны понять как посчитан транспорт на материал - по % или установлен суммой (например в ДСК на ЖБК определён тариф на перевозку 1т. конструкций, который и закладывают в ПСД) или на отдельный материал применён другой процент?.
Как понять какая цена принята в расчёт: республиканская или другая?
Указывать материал заказчика в ресурсах каждой расценки - тоже бред! Если в 50 расценках указана вода и это материал заказчика - в каждой помечать "Материал заказчика"? Не проще ли это сделать 1 раз в своде материалов?
Цены с НДС/без НДС расписывать в ресурсах каждой расценки - я в принципе не против, но тоже не вижу смысла. У меня ПРИ РАСЧЁТЕ программа определяет и подставляет в ресурсы соответствующие цены (с НДС/без НДС, республиканская или фактическая).
Правила хорошего тона при формировании любой базы данных рекомендуют ничего не сохранять дважды.

Пусть будет так. Но какой смысл вводить дополнительный атрибут, если это можно сделать проще?

dopsmeta - заменить на vidsmeta = 0 - локальная смета, 1 - доп смета, 33 - смета на ПНР, 100 - акт генподрядный, 101 - акт субподрядный, 666 - расчёт контракта,  и т.д.
Тогда в последствии не придётся городить дополнительных атрибутов.

ob_smeta --> glava - Номер главы ССР Ну тогда и в локальной смете нужен атрибут "glava", т.к. 18. Сводный сметный расчет стоимости строительства объекта составляется на основе объектных смет (объектных расчетов), локальных смет (локальных сметных расчетов) и других сметных расчетов...

Расчёт контрактов передавать собираемся? Тогда в ptm-ах предусматривать проценты выполнений по месяцам.

sost_fio - ФИО того, кто составил смету
sost_dol - Должность  того, кто составил смету
prov_fio - ФИО того, кто поверил смету
prov_dol - Должность  того, кто поверил смету Они в засекреченной организации работают? Т.е. добавить наименование проектной организации. И подрядной (для актов) с указанием руководителя (кто подписыват) и кто составил.
   
Прямые затраты на единицу измерения и на объём - лишнее. 4 числа сложить, я думаю, каждый в состоянии.

Не понял Тип ОХР и ПП и Тип Зимнего удорожания в расценках? Если это некий ID справочника, тогда давай договариваться о формате. Например для норматива зимнего предлагаю структуру, связанную с пунктами норматива. Т.е.: 12.2 Остекление конструкций профильным стеклом ID=120200,  32.2.5 Крепление откосов стенкой из шпунта ID=320205, 21.2.10 Устройство и разборка переездов и упоров. Установка путевых знаков ID=210210, и т.д. Или лучше указывать пункт норматива в нормальном виде: "21.2.10".
Аналогично можно указывать пункт вида накладных/плановых - так как это указано в приказе. Это чтобы небыло разночтений.

Расширение файла переопределить, например xml --> xmlby, чтобы в другие программы не пытались прикрутить.

В СМР-ПРО в смете можно помечать материал заказчика. Не вижу проблемы не заполняйте этот атрибут при экспорте и не обрабатывайте при импорте.
Ничего. Но на первом этапе делаем передачу СМЕТЫ. ССР, С2 и т.п. потом. Научимся сметы передавать - научимся всё остальное
Да. В Исходных данных. Предлагаете по каждому материалу писать?
Добавим атрибут - tip_ceny (0- республиканская , 1 - другая)
 Нет. Это гибкость. Помню у меня просили при расчете Контрактной цены в РСН-2007 разные цены на материалы в одной смете. Может еще и так быть: половина материалов с одним кодом - заказчика, половина подрядчика.

Согласен. Проблема в том, что цена может не на 20% отличаться. В механизмах, например, почти во всех.

Идея интересная. Обязательно обсудим. Номера только странные

Второй этап. Пока нет.

В СМР-ПРО ССР делается по ОС, так как ЛС всегда внутри ОС. Надо обдумать это предложение.

100 раз писал - на email напишите атрибуты которых Вам не хватает. Обязательно включим.
Согласен. Обсудим потом.

Обязательно договоримся.

Переделаем.

Мы договорились о структуре.
Давайте теперь договариваться о атрибутах.
Начнем со <stroyka>.
Кто какие атрибуты желает добавить?

А как по другому? Часть материалов может быть вообще без транспорта (например, раствор, приготовленный в построечных условиях), на часть применён фактический транспорт (я уже приводил пример ранее - расчитан внутренний тариф на перевозку тонны груза на километр). Как это разруливать? Я же про это и веду речь, что это логичней отразить в своде материалов.

Это тоже элементарно решается в своде, но это уже не по теме.

Номера могут быть любые - это не принципиально.
Кстати, rek [rekonstrukciya] 1 – Смета на реконструкцию, иначе 0 мне тоже не нравится. Логичней заменить на vidstoyki = 0 - новое строительство, 1 - реконструкция, 2 - модернизация, 3 - капитальный ремонт, 4 - текущий ремонт и т.д.

А у меня не всегда. Цитирую ещё раз 18-й пункт Инструкции: Сводный сметный расчет стоимости строительства объекта составляется на основе объектных смет (объектных расчетов), локальных смет (локальных сметных расчетов) и других сметных расчетов.... Т.е. если на объект только 1 локальная смета, то нет никакой необходимости формировать объектную смету и это не противоречит не Инструкции, не здравому смыслу.

Чем формат месяца в читаемом виде не устраивает: ММ.ГГГГ ?
Если это как абстрактное заглавие стройки - то вполне достаточно, но если планируется ССР передавать... Лучше пока не будем о грустном.
И у любой стройки Заказчик (Инвестор) существует.

Писать здесь, иначе одни не знают о чём договариваются другие.

Чтобы было проще, напишите каждый свой файл (аналог smr5.by/xml/data.htm ) общей структуруpы. Я увижу как вы переставляете общую структуру. Мне тогда проще  дальше развивать формат.

атрибуты можно не расписывать .

Ну вот, например, со сводами материалов

Как я понял.
Svod_Res_NRR  - Это список материалов и механизмов, которые встречаются в смете. Так? То есть фактический расход Машин и материалов, так как klv_norm="120,684" klv_fact="120,684" могут не совпадать.
 <Svod_Levyh_Mat>  тоже самое только на материалы, которых в смете нет.
Правильно я понял?

Угу. klv_norm - всегда по норме, klv_fact - может отличаться или =0. Кроме этого в свод могут включаться любые другие материалы (или дублироваться существующие). Тогда klv_norm=0 и dop_resurs <>0

С этим не заморачивайтесь - у вас этого нет. У меня в программе живут параллельно 2 отчёта материалов и в расчёт может быть применён или один, или другой. 2-й вообще не связан с нормативами.

Если tr_fact_bezNDS или tr_fact_sNDS <>0 тогда принимается в расчёт указанная фактическая величина транспорта, иначе считается по %.

Обозначились ли уже какие-то сроки по рабочему формату?

"Товарищи, что-то тихо стало в зале. Есть предложение пригласить вторую бригаду артистов, когда уйдет та бригада, которую мы пригласили в прошлом году..." /М.Жванецкий/

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

stroyka (1)
    - obekt (...)
        - loc_smeta (...)
            - ishodnye_dannye (1)
            - ptm (...)
                - grafik (1)
                - rascenka (...)
                    - cena (1)
                    - stoimost (1)
                    - nabor_kf (1)
                        - koef (...)
                    - prikaz_kf (1)
                        - koef (...)
                    - materialy (1)
                        - resurs (...)
                    - mehanizmy (1)
                        - resurs (...)
          - svody_resursov (1)
              - materialy (1)
                  - resurs (...)
              - mehanizmy (1)
                  - resurs (...)

(1) - один элемент в группе
(...) - может быть множество

Ну и что?
Языком почесали и разбежались?
Или всем СЛАБО оказалось?
У меня функция импорта/экспорта готова. Естественно, возможны некоторые ошибки, которые можно исправить в процессе, но с большего - работает. Догоняйте.
Или "мужик сказал - мужик сделал" не про вас?

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

До меня дошли "слухи", что xml из SXW отлично импортировался в SMR-Pro. Просто в летом начался аврал.  В начале у Сенкевича времени не было, а потом и у нас (С-2а, С-2б, графики, отклонения).

а что за формат файла такой??

Сам в шоке

Значит не из sxw

замечания по формату:
1. Указывать номера пунктов НРР-а на нормы зимнего удорожания по каждой расценке в виде, аналогичном как для накладных/плановых. То же для временных зданий на всю смету (акт).
2. В структуре узел "ob_smeta" заменить на "obekt". Обосновываю: формат должен быть заточен не только для обмена сметной документацией (в понимании проектировщиков), но и обмена актами выполненных работ. Акты не привязаны ни к какой "объектной смете", но всегда относятся к какому-то объекту. Структура "Стройка --> Объект --> Локальная смета(акт)" даёт более гибкую систему.
3. В обекте может быть несколько объектных смет. Например: Жилой дом со встроенными помещениями. В этом случае делается две объектные сметы (с НДС и без НДС). Насколько я знаю в СиС именно по такому пути и пошли. Хотя, тут ещё БОЛЬШОЙ вопрос! Поэтому, чтобы можно было передавать и АВР не привязанные к объектным сметам и объектные сметы следует установить такую структуру:
stroyka (1)
- ishodnye_dannye (1)
    - obekt (...)
        - ob_smeta (...)
            - ishodnye_dannye (1)
            - spisok_ls (...) - перечень локальных смет, включенных в объектную смету с указанием только ID-номера локальной сметы и названия ЛС. Соответственно, каждой смете (акту) присвоить уникальный ID-номер.
        - loc_smeta (...) она же может быть актом
            - ishodnye_dannye (1)
            - ptm (...)
                - grafik (1)
                - rascenka (...)
                    - nabor_kf (1)
                        - koef (...)
                    - materialy (1)
                        - resurs (...)
                    - mehanizmy (1)
                        - resurs (...)
            - svody_resursov (1)
                - materialy (1)
                    - resurs (...)
                - mehanizmy (1)
                    - resurs (...)

(1) - один элемент в группе
(...) - может быть множество

4. Параметры "nachalo" и "mesyac_cen" написал в человеческом виде: "01.2014", а не как предложено: "201401". Вас "человеческий" вид отображения дат чем-то в прошлой жизни обидел??? Может тогда и числа в 16-ричном виде писать будем чтоб никто не догадался...
5. Какой смысл в расценках "cena" и "stoimost" выносить отдельными узлами да ещё с одинаковыми параметрами? Это только усложняет структуру и чтение данных. Проще указать как параметры в в узле "rascenka". Например: "e_zrp" - зарплата на единицу; "w_zrp" - зарплата всего.
6. Узел "prikaz_kf" - лишний. Проще указать параметр "p5" внутри расценки (в узле "rascenka"). Каждый сам в состоянии определить на какие статьи он применяется.
7. Там же в узле "rascenka" указать параметр "stesn" (коэф. на стеснённость). На какие статьи применяется стеснённость тоже каждый сам в состоянии определиться.
8. Народ, шевелиться думаете?
9. Далее следует трактат о формате СиС в грубой матерной форме с упоминанием его родителей и домашних животных...

Судя по всему описанному выше, формат здесь http://smr5.by/xml/data.htm уже далеко не соответствует желаемому. Был бы рад увидеть новое полное описание тегов с атрибутами, а то как-то и шевелиться не понятно в какую сторону.

mike, в плане шевелиться? Формат есть. У меня почти готов web-сервис по обработке xml файлов. Надо его дописать. Там проблема больше в оформлении. Web-дизайнер нужен.

ОК. Добавим такой пункт.
Данный формат предполагает обмен ТОЛЬКО сметами. Если хотите обмениваться актами - делайте новый тег <akty></akty>, описывайте структуру (на 90% совпадет с данным форматом) киньте мне поисание на почту и я выложу на сервере для общего доступа.
01.2014 - месяц 1 и 2 символ 01.01.2014 - месяц 3 и 4 символ
201401 - 5 и 6 символ - месяц
20140101 - - 5 и 6 символ - месяц.
Так проще Да и переписывать нет желания.
Подумаем над этими предложениями. Но мне кажется так проще читать человеку. Программе все равно как считывать.
Нет. Есть разные коэффициенты. Стесненность, кратность, демонтаж и еще некоторые свои придумывают. Есть стесненность которая принимается к зарплате (труду), но не применяется к машинам.

У самураев было правило: "Если не знаешь что делать - делай шаг вперёд".
Перевожу с японского: "Если не знаешь что делать - делай хоть что нибудь!"
У тебя всё готово и вопрос только в описании фрмата? С одним интерфейсом месяц провозишься.

Нет. Зачем тогда в СМЕТЕ "mat_zak", "tr_zak", проценты зимнего по расценкам? Это же в СМЕТАХ не используется! Сам себе противоречишь. Разберитесь чего вы хотите в этой жизни!
А вообще-то, если мы определились что формат делаем совместно, то объявляю голосование: Передаём ТОЛЬКО сметы или акты тоже? Это касается и моего предложения по структуре Подчинюсь большинству

Переписать строчку FormatDateTime('yyyymm',X_data) в вид FormatDateTime('mm.yyyy',X_data) - это такая неподъёмная проблема? Помощь нужна?
Показывает твоё отношение к остальным. Без коментариев...

Стеснённость и коэф по постановлению 5 - это стандартные коэффициенты с вполне определёнными правилами применения. Речь только о них. Остальные (кратность, демонтаж и т.д.) - естественно расписывать постатейно.

И ещё:
1. Хотите оставить узлы "cena" и "stoimost" - ради бога. Но тогда "prc_ohr", "prc_pp", "prc_zu", "prc_zu_zrp" и т.д. из узла "cena" вынести в узел "rascenka" - там они не логично смотрятся (это НЕ цены).
2. Я так понял, что с "tip_ohr_pp" определились - номер пункта по приказу в виде: "1.2.", "3.", "5.10.1." и т.д. Не понял назначения "vid_ohr_pp", да ещё по каждой расценке?
3. Тип зимних писать в таком же формате. В виде: "1.1.10.", "1.4.1.а)" и т.д.
4. Проценты транспорта в "исходных данных" потеряли смысл.
5. Самый спорный момент - это вид расценки "tip". Жутко не люблю нумерацию через единицу - ничего невозможно вклинить в середину, если что-то забыл. Похоже на DOS-бейсике никто не писал. Кроме этого недостаточно определителей. Не навязываю свою структуру - сам бы сейчас немного по другом сделал, но покажу как у меня:
 10 - примечание
 100 - работа
 300 - Механизм
 311-314 - Перевозка (С310) по каждому классу груза
 321-324 - Перевозка (С311) по каждому классу груза
 500 - Материал
 510 - затраты на захоронение фиксированной суммой
 511..579 - Стоимость свалки по областям и полигонам (по 9 на каждый регион) Т.е. 511 - КУПП «Барановичская спецавтобаза» Полигон ТБО д. Деревная, 573 - Полигон «Северный» (д. Дубовляны) и т.д.
 600 - материал от разборки
 610 - мусор
 1000 - монтируемое оборудование
 1010 - не монтируемое оборудование

... заварил себе кофе ...
наверно по итогу у каждого будет Свой Единый Формат загрузки-выгрузки данных

В "СМР-Про" есть возможность в смете установить зимнее и материалы заказчика. Для этого и делалось. Если в другой программе нет этого, то не заполняются эти теги при экспорте и импорте. При импорте если нет тега - писать значение по умолчанию. Например, для mat_zak - это 0.
Апет только за СМЕТЫ без актов и ССР, так как считает, что передать акт нереально, так как у всех своя логика расчета стоимости. И смысл передачи акта немного сомнителен.

Мне то переписать не проблема. Это еще Апету и Синкевичу надо экспорт и импорт переписать. Сложность в том, что возможно еще кому-то, надо сообщить. Вот mike - это кто? Какую организацию представляет?

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

Это нелегко сделать как кажется. Самая засада - это теги tip, tip_ohr_pp, vid_ohr_pp и всякие особенные строки (перевозка, мусор и т.п. )Вот тут у всех все разное.
Надо найти что-то общее.

P.S. mike - это представитель какой организации.

Для того чтобы легче было найти что-то общее, наверно можно описание выкинуть на Google диск и дать доступ для корректировки участникам разработки. Правда надо что-то придумать с удобным слежением кто и что внес.
Мне на данный момент даже замечание по формату дать сложно, потому что я не ориентируюсь к чему пришли в итоге. Господин Татарников очень грамотные замечания дает и его понимание структуры наиболее близко к нашему пониманию, но чтобы свести все в едино надо постоянно форум перечитывать.

Надо не форум перечитывать, а свои предложения вносить. Указывать на ошибки, плюсы и минусы каждого варианта.
Вот как лучше писать месяц цен - 01.01.2014 или 01.2014, или 201401 или 20140101?

Сенкевич просил исходные данные в каждой смете - добавил. Сейчас для Татарникова пару тегов сделаю.

Повторюсь. Уже стало сложно ориентироваться у кого какой вариант.
Месяц цен мне все равно в каком виде писать/читать, выбирайте какой вам легче, я подстроюсь.
Объясните мне, для чего эти лишние вложения <materialy> и <mehanizmy>? Признак материал или механизм можно сделать атрибутом в теге <resurs>, или вместо тега <resurs> использовать два <material> и <mehanizm>, которые будут являться дочерними к тегу <rascenka>.

Варианта нет. Мы его разрабатываем.
Подстроюсь куда? Какая программа или что?

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

И чем его так акты напужали? Естественно , после экспорта/импорта сумма руб в руб не сойдётся - про это можете забыть. Но передать, например, генподрядчику выполнения по ПТМ-ам для С-2б (суммы), почему нет? И пускай в XML будет весь пакет данных - просто не обрабатывать их.

Уже столкнулся и обращаю внимание, что XML чувствителен к регистру в наименованиях атрибутов и узлов. Поэтом, давайте условимся, что все наименования атрибутов и узлов пишутся в нижнем регистре. Хотя, мне это непривычно...
Также следует условиться, что кроме описанных узлов и атрибутов каждый вправе включать свои. При чтении обрабатываются только описанные (известные).

Ааа... всего лишь для удобства ручного просмотра. Так давайте в excel выгружать, там еще удобнее просматривать!

Сразу немного не понял mike. Подумал что внуть расценки предлагает писать. Можно и так. Только те же яйца - тот же 6-й уровень в дереве, избавляемся от 1 подузла в расценке и ресурсы в куче. Никакой принципиальной разницы...

Когда начнёшь отладку делать тебе столько раз предстоит "в ручную" просматривать!..
Если, конечно, начнёшь...

Никаких проблем в просмотре без лишних вложений, из-за которых раздувается файл, не ощутил. Начал, иначе б не писал бы тут ничего. Говорите надо, значит наверно надо, сделаю. Формат же должен быть ЕДИНЫМ да?

Объемы передать можно. Передать расчет стоимости анрил. Давайте одно (сметы) сделаем. Потом за остальное возьмемся.
Посмотрим какие проблемы и трудности на первом этапе.
Первое с чем столкнулись - это регистр. Тут наверное от среды программирования зависит. Фоксу, вроде, все равно какой регистр. Поэтому решгено все в нижнем писать.
Второе - подход к структуре. было 2 варианта: 1)<node><param>Value</param></node> 2) <node param="Value"</node> Решили 2-й так как это проще считать, да и размер файла меньше.
Сейчас структуру вырабатываем. С верхними уровнями особых проблем нет, так как у всех одинаковые. А вот с нижними проблема.

Господа, присоединюсь к вашему обсуждению - дело-то нужное...
Есть пару моментов:
1. В материалах расценки есть транспорт, но это как я понимаю транспорт за единицу, неплохо бы было добавить процент транспортных и общую стоимость транспорта по данному материалу. Во-первых, это актуально с точки зрения последних веяний, а во-вторых неужели никто из ваших пользователей не просил сделать транспорт у какого-либо материала эдаким, рассчитанным через непонятный процент...
2. Насчет поиска общего в атрибутах расценки. Главное, определить верное количество уровней (сср/объектная смета/локальная/птм). А допиливание атрибутов расценки будет происходить позже путем обсуждения. Можно принять за основу некий общеположенный минимум (даже в том виде, что сейчас), после чего реализовать и обсудить чего не хватает. Как мне кажется, если за какой-либо атрибут будет не менее двух разработчиков - надо добавлять, один - не имеет смысла.
3. Имеет смысл на каждом уровне (сср/объектная смета/локальная/птм) добавить по паре пустых значений и каждый разработчик сможет их использовать для каких-то своих целей(например, пока будет идти процесс целесообразности обсуждения добавления новых, или же в случае переноса от себя к себе ). Благодаря тому, что в шапке есть указание на составившую данный хмл программу - это реально.   
4. Почему бы в формат не заложить данные ССР? Потому как если понадобиться его экспортнуть, то опять есть только один вариант - формат сис. А в рамках существующей разработки формата - ССР замечательно вписывается. +1 уровень. И потом все равно его придется реализовывать.
5. Формат дат и т.п. по большому счету не важен для нас - это пишется один раз и проблема перестает существовать, поэтому предлагаю согласится к Купером. 
6. А почему забыты расчеты по сборникам РСН 2007/2001, там есть прочие материалы/механизмы, например, которые тоже надо хранить на расценке. Или формат разрабатывается только для НРРов? По себе могу сказать, что еще есть у нас пользователи, работающие с 2001 годом, а про 2006 уже молчу.

а, да, забыл... Не буду шифроваться как mike (кстати, кто это? ).
Я представляю www.smetaby.by .

И предлагаю обсуждение перенести куда-либо с форума. Например,  в гугл-группу.  Это удобнее.

1. Особого смысла в этом не вижу. Например, у меня на каждый материал можно установить любой % транспорта или указать транспорт суммой (на ед.изм.). Но указывается это в своде материалов и при расчёте эти данные (стоимость, величина транспорта, как он посчитан - через процент или суммой и т.д.) автоматом переносятся внутрь расценок. А перелапачивать это в каждой расценке - это же взбеситься можно! Не принципиально. Если надо - впишу.
2. К атрибутам обращаешься по имени. При этом, по-барабану в какой последовательности они находятся. Даже если его нет - поставь значения по умолчанию. У себя обращение сделал через 4 собственные функции (для чисел, целых чисел, строк и дат). Передаю имя узла, имя атрибута, значение по умолчанию. Внутри функции проверяю есть ли атрибут с таким именем. если нет - возвращается значение по умолчанию.
3. У себя сделано так: Просматриваю ВСЕ подуровни узла без указания их имён и обрабатываю ТОЛЬКО ТЕ, чьи имена известны. Например в узле "ptm" предусмотрены ТОЛЬКО вложенные узлы "rascenka". А, собственно, почему "ТОЛЬКО". Ты можешь включать туда же любые свои узлы (и атрибуты). При чтении если имя узла <>"rascenka" - я его просто игнорирую (не обрабатываю). Поэтому нет никакого смысла в пустых значениях. Я, например, намерен в "loc_smeta" включать все итоговые суммы по расчёту. Не определился только - отдельным узлом вынести или в общую кучу атрибутов чтобы другим меньше мешали.
4. Включить в узел "stroyka" подузел "ssr" никогда не поздно.
5. Ладно. Не принципиально.
6. Да хоть бы про одну методику договориться.
7. Предложи свою структуру для "tip" расценки. Предложенная Cooper-ом мне реально не нравится.

🫵 А ВЫ прислали письма для Архива разъяснений стройотрасли?!
Ждем ваших писем-разъяснений от МАиС, Стройтехнорм, Экспертизы, МЧС, БСЦ, РНТЦ и т.д. для наполнения  разрабатываемого Архива писем-разъяснений стройотрасли.