Работа с классом CreateXMLobj

Добрый день!

Это не класс, а функция, возвращающая экземпляр класса DOMDocument...

см.   ..\SCRIPT\msxml.S

Точнее Msxml2.DOMDocument.6.0

Если интересуют какие функции есть у этого объекта, то это в официальной документации Microsoft:
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/ms757878%28v%3dvs.85%29

Может быть скажете, что хотите сделать и мы подскажем как это можно сделать?

Да просто хочу принять в таблицу данные по ЭЛН из реестра,  чтобы подтянуть туда инфо по ТН,  №подр и прочими данными с целью последующей засветки бухгалтерами своих ЛС для расчета БЛ.  

?! У меня вопросов стало еще больше.

Из какого реестра ЭЛН собираетесь данные подтянуть? Из Контур-Зарплаты? Как собираетесь это делать? Будете перебирать все xml-файлы в каталоге eln? будете читать xml-файл реестра ЭЛН и определять по каждому ЭЛН какой из файлов ЭЛН является последним?

Какое-то дикое количество работы на ровном месте с туманными перспективами на работоспособность в настоящем и уж тем более в будущем (поменяем структуру реестра например).

Может попросить разработчиков ускорить добавление расчета больничных из реестра или хотя бы засветку ЛС по списку в реестре?

?! У меня вопросов стало еще больше.

Из какого реестра ЭЛН собираетесь данные подтянуть? Из Контур-Зарплаты?

-  Из Контур-Зарплаты

Как собираетесь это делать? Будете перебирать все xml-файлы в каталоге eln?

-  пока не готов ответить на этот вопрос поскольку принят, расчитан и отправлен был только один БЛ.

  В корне папки с ЭЛН наряду с папками BACKUP и ELN нашел файлик resp_xxxxxxxxxxxx.xml  с информацией

  по принятому БЛ, вот и предположил, что возможно, информация по другим БЛ тоже должна

   присутствовать в этом файле - впрочем в этом могу быть неправ, но пока и посмотреть негде,

  поскольку рассчитан пока всего один БЛ.

будете читать xml-файл реестра ЭЛН и определять по каждому ЭЛН какой из файлов ЭЛН является последним?

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

  предполагаемой технологией расчета ЭЛН на предприятии:

  а)  ОК  с сайта ФСС принимает данные по №_ЭЛН и СНИЛС в пустую папку для ЭЛН (в демо КЗ) и добавляет

        в принятый ЭЛН свою информацию, после чего, один раз в неделю, отправляет эту папку с реестром ЭЛН 

        в бухгалтерию для расчета БЛ, и полностью  чистит свой реестр - удаляет из папки для ЭЛН все

        внутренности.

   б)  бухгалтерия копирует эту папку на диск для ЭЛН, рассчитывает БЛ и отправляет в ФСС, после чего саму

        папку с  рассчитанными и отправленными ЭЛН нумерует и складирует в архив.

Какое-то дикое количество работы на ровном месте с туманными перспективами на работоспособность в настоящем и уж тем более в будущем (поменяем структуру реестра например).

Может попросить разработчиков ускорить добавление расчета больничных из реестра или хотя бы засветку ЛС по списку в реестре?

-  добавление расчета из реестра в данном случае не актуально, поскольку расчет БЛ планируется по старому

  (Alt_F4),  а вот засветка из реестра пожалуй поможет бухгалтеру уже в списке ЛС среди засвеченных ЛС

   опознать свои  ЛС по №_подр. 

   Собственно и проблема-то возникла из-за отсутствия в реестре  №_подр,  если допустить что в реестре

   несколько сотен ЭЛН, то для опознания своих ЭЛН только по Таб№ у бухгалтера уйдет столько же времени

   что и для расчета БЛ.

В качестве примера можно посмотреть CreateLsSbrXml.S Он заполняет таблицу данными из xml файла...

Если бы была возможность запустить расчет ЭЛН из реестра - думаю это сняло бы все вопросы...

Зачем засвечивать ЛС в списке, а потом среди засвеченных искать свои - непонятно. У вас же наверняка настроено распределение ЛС (каждый расчетчик видит только "свои" ЛС)?

В реестре должны отображаться только ЭЛН, доступные данному конкретному расчетчику.

Итого нужно уметь: 

• массово обновлять ТН в реестре ( чтобы отработал фильтр на доступные ЭЛН)
• рассчитывать ЭЛН прямо из реестра

Настроено не распределение подразделений по расчетчикам а настроен фильтр по Shift_F3,  чтобы при случае (отсутствие расчетчика )  любой другой расчетчик смог бы поработать с чужими ЛС,  а в штатном режиме только

со своим набором подразделений.