Deeptown12

9 минут назад, Филатова Виктория сказал:

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

Пока что мертвым грузом... увы...

Не знаю, вот смотрю сейчас в личном кабинете, есть у нас один СИ поверенный в качестве эталона, который мы загрузили в БД для оттестирования загрузки из XML. Думали удалим потом после публикации. А вот не дает. И на обращение в техподдержку с просьбой что надо удалить неверно внесенную запись, был получен прямой ответ: Удаление записей из Перечня СИ, применяемых в качестве эталонов, не предусматривается. 

Пишу как есть. Еще раз - после публикации, до публикации можно. После не дает.

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

2 минуты назад, AQZWSX сказал:

речь именно про сведения о поверках СИ, применяемых в качестве эталонов.

Очень очень интересно, до публикации или после. До - можно. После публикациии - не дает.

И даже логика понятна почему нельзя. Допустим гипотетически в понедельник поверили СИ в качестве эталона, во вторник поверили рабочее СИ со ссылкой на эталон (тот который в понедельник поверили) а в среду решили эталон аннулировать. А у нас уже есть поверки которые ссылаются на этот эталон. Коллизия. Да. Решаема? Теоретически да, проверить прослеживаемость, и если нет ссылок на этот эталон дать его удалить. Если есть ссылки, можно тоже много механизмов придумать, смена статуса например "неполный/проблемный" и пр пр. Но ребята в Аршине перестраховались и вообще удалять не дают. И получается что БД Аршина превращается в мусорный полигон.

3 минуты назад, AQZWSX сказал:

а редактировать уже опубликованные там разве нельзя?

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

Информация к размышлению!

Коллеги, если вы случайно передали СИ поверенное как эталон, то знайте что удалить его из Аршина невозможно. Даже если вы ошиблись при вводе или загрузки из пакетов.

Официальный ответ техподдержки:

Как удалить запись о СИ, применяемом в качестве эталона ?

Удаление записей из Перечня СИ, применяемых в качестве эталонов, не предусматривается. 
Рекомендуем Вам удалить записи о поверках, приведших к повторному заведению сведений о СИ, применяемых в качестве эталонов. В этом случае записи о СИ, применяемых в качестве эталонов, не будут подкреплены ни одной поверкой и будут, фактически недействительными. 
Правила удаления сведений о результатах поверки приведены в разделе 3.4.1.10 Руководства пользователя. 

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

Записи, которые имеют статус "Помечен на удаление" были опубликованы. Если создать заявку с такими записями и ее опубликовать, все эти записи будут аннулированы из Фонда. После публикации данные записи будут перемещены в представление "Аннулированы" и удалены из публичной части ФИФ. Но по прямой ссылке на запись карточка записи будет доступна, и в ней будет информация об аннулировании записи. 

1 час назад, VSVS сказал:

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

О!!! Айфонд, сами не пользуемся, но очень хорошо знаем тех ребят которые этот Aйфонд продвигают вместе с Айсбергом.

Я бы на вашем месте сто раз подумал связываться с ними или нет. Очень ушлые ребята сильно хотящие денег.... Наглые, самоуверенные и не пуганные. С клиентами ведут себя по хамски.

Тут интересные вещи пишут

Собственно вопрос, а как собирается это делать Пензенский ЦСМ.

Если нормального протокола загрузки в аршине нет. А то что аршин выдает в виде XML-протокола публикации притянуть и четко идентифицировать с переданным пакетом, а вернее поверкой невозможно. А не возможно почему, а потому что нет четкого сопоставления идентификатора публикации GlobalID с записью в пакете. Я тоже сначала думал что 1 записи в пакете = 1 запись в протоколе публикации. А это не так. Данные бывают идут вперемешку и не в том порядке как в файле загрузки. Проверено железно. Четко идентифицировать что такой то поверке присвоен такой то глобальный идентификатор невозможно.

Соответственно и ссылку невозможно сгенерировать.  Причем вопрос задавался в поддержку ФГИСа но что был получен ответ, ждите API и не раздражайте нас. Вот такая поддержка, как клиентом давать данные на публикацию в Фонде их СИ не ясно.

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

Странные люди аршин делают. Логичнее было ИНН передавать вместо наименования. Ведь есть организации с дочерними филиалами. А если уж так наименование владельца надо то запрашивать его из ЕГРЮЛ и налоговой средствами межведомственного обмена. Да и эта мода на ЭЦП которое суют куда надо и не надо. Далее ... Где обратная связь черт возьми. Мы в неделю пару тысяч поверок делаем. Сотня другая не примется как с гэтами было недавно. Год поменяли. Никто не сном не духом.  Как потом эти поверки снова передавать подправленные. Где обратная связь где сопоставление ошибочных записей с хмллом. Это же черте что поверки потеряются просто.   Потом на них забьют. Нет блин нужно факторы поверки сначала сделать. Очень важная задача. А то что не работает двухсторонний обмен нормально это так на будущее. Ладно мы маленький центр а большие как будут отслеживать. Игра в одни ворота. Где api хотя бы по справочникам. Ранее были в первой очереди. А будут ли дальше хрен знает. Такое ощущение что те кто даёт задания на разработку страшно далеки от народа.

22 часа назад, Stepawa сказал:

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

Длинное наименование, должно быть максимум 32 символа, у вас их больше.

Дословно длина значения 36, но требуемый максимум 32

лежит красавчик

Внимание, информация по передаче через API.

Косвенным путем выяснено, что API ФГИС Аршина не любит большие файлы XML. Нелюбовь проявляется вот в чем, в руководстве ФГИСа написано посылать не более 5000 записей о поверочных работах через API. Так вот вранье, он уже не может проглотить и 4000. Как проявляется эта проблема, пакет передачи принимается успешно, но только частично публикуется. Т.е. из 4000 поверочных работ в одном пакете только малая часть опубликована становится, хотя ошибок не дает. Фактически часть работ теряется. Могу предположить что парсеру xml просто не хватает памяти что бы загрузить большой файл xml и обработать его. Странные люди, есть же SAX парсеры которые могут обрабатывать огроменнейшие файлы, но видать разработчики API про них не знают. Решение которое помогло нам - делить пакеты по частям (мы делим по 500 работ), тогда все нормально. 

1 минуту назад, CSM сказал:

Завалили его, видать...

Ага, только хотел посмотреть а уж лежит...

1 час назад, CSM сказал:

Сейчас удалось таки протолкнуть пакет по API. Вы долго ждете результатов? Я думал этим методом напрямую в их БД пишется. Оказывается создается такая же заявка со своим номером и нужно ожидать её обработки. Просто все это через API механизм, а не через интерфейс.

В последнее время около суток, недели две назад было - 2-3 дня. Для cURL можно использовать ключ -v для выдачи более полной информации о приеме-передачи. Ну это так к слову.

Да создается заявка, в ответном сообщении в JSON формате указывается номер дата принятия и статус. Статус обычно после отправки Recived, после обработки Аршином он меняется, т.е. нужно перезапрашивать информацию пока не сменится статус на другой и обрабатывать ошибки если они возникли.

16 часов назад, CSM сказал:

Возникает вопрос о компетентности людей из техподдержки. Сегодня вот первый раз на пробу отправил API-запрос, вернулся результат "Please, set X-API-Key header to access this API". 

Ну тут понятно, нужно в запросе c передаваемым файлом xml (закодированным в base64) отправить пользовательский Header X-API-Key с секретным ключом 

как то так

NetHTTPClient.Accept      := '*/*';
NetHTTPClient.UserAgent   := 'curl/7.65.3';// макрировка под curl
NetHTTPClient.ContentType := 'application/xml';
NetHTTPClient.CustomHeaders['X-API-Key']:= SecretKey;
NetHTTPClient.CustomHeaders['Expect']   := ' 100-continue';
 

можно с помощью php скрипта на собственном web сервере

<?php
    print "HEADERS:<br>";
    $headers = GetAllHeaders();  
    foreach($headers as $header=>$value)  
    echo "$header: $value<br>";
    print "ENDHEADERS:<br>";
    
    print "CONTENT:<br>";
    $postData = file_get_contents('php://input');
    print $postData;
    print "ENDCONTENT:<br>";
?>

через curl отправить файл не не ФГИС а на скрипт и посмотреть какой пакет передаются и с какими заголовками.

Да и еще некоторые сервисы API, в частности проверка статуса передачи и получение результатов работают с HTTP 2.0 не все его поддерживают. Учитывайте это.

В 10.09.2019 в 08:15, CSM сказал:

Очень интересно... А мне техподдержка ответила, что на данный момент API  работает некорректно и очень советуют передавать данные пакетами через ЛК. Получается, что всё работает как надо?

Работает, а поддержка все что касается 2 способа передачи - отвечает стандартным "API  работает некорректно, работа не гарантируется"

4 минуты назад, evGeniy сказал:

А разве в ЦСМ не предоплата?

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

Самый основной вопрос к разработчикам ФГИС Аршин, по крайней мере у меня:

Раз есть возможность ручной корректировки поверочной работы через личный кабинет (при ситуации когда неверно передали данные, ошиблись, очепятались и пр), то почему нет механизма обновления ошибочных записей через API. Т.е. если вручную исправлять можно, почему нельзя в автомате. Исправления на стороне API минимальны - запретить проверку на ранее внесенную в Фонд запись, а эту запись обновлять при другой передаче. Свистоперделки - вроде даты актуализации данных, информации что запись была скорректирована накрутить просто. 

Вариант отзыва поверочной работы с Фонда (удаление информации о поверке). Да - иногда клиенты от поверки отказываются, а если запись уже в Фонде, как быть. Бумажное свидетельство можно не выдавать, а тут... Соответственно доработка API нужна. Все в ручном режиме делать невозможно.

31 минуту назад, БорисБ сказал:

Пункт 7.3 Руководства

Тогда я не понимаю, нам предоставили тестовый режим, который по факту оказался полным. Либо нам неверно отписались, либо руководство ФГИСа лукавит. Т.к. при отправке пробной партии из трех поверок в тестовом режиме, они появились в ФГИСе, что в тестовой среде не должно было бы быть.

16 минут назад, БорисБ сказал:

Возможно я неточно выразился. Я говорю от имени одного из региональных ЦСМов. Ключик и право на передачу сведений конечно есть, я подозреваю, что и доступ в реальную базу «аршина» тоже есть (но это не точно). Нет доступа именно к тестовой среде, которую должна выдавать техподдержка по запросу, но не выдает.

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

Тестовой среды в природе нет, дается сразу полный доступ, почему все его упорно называют тестовым не ясно.

По второму пункту.

Значит первое что, когда сведения передаются через API (2 способ) в личном кабинете нет информации в внесении сведений (о загруженной информации через API). Это и логично, т.к. по секретному ключу Аршин сопоставляет передачу с конкретным юр.лицом (хочется сказать что еще используется информация о шифре знака поверки, но если ЦСМ имеет один шифр - то эта часть может быть опущена). Поэтому при такой передаче все равно сколько людей имеют доступ личный кабинет. Так как привязка переданных данных не завязана на учетной записи личного кабинета (конкретного сотрудника) не один сотрудник не видит переданные данные роботом. Информацию по регистрации переданных данных, статусу обработки и возможных ошибках тоже все получаем с API.

А раз это так значит информацию о передаче должна хранить передающая сторона, запрашивая у Аршина изменение статуса обработки принятых данных, выявления ошибок при передаче и пр. У нас это решается связкой переданных данных с нашей БД поверочных работ. Т.е. мы всегда можем посмотреть что ушло когда и как. Какие были ошибки при приеме в Аршине, сколько принято, сколько не принято вплоть до конкретной поверки. Ошибочные записи можно потом отправить следующей партией исправив их. При такой организации передачи доступ в ЛК в принципе вообще не требуется. 

1 час назад, БорисБ сказал:

Для начала расскажите как получить доступ к API. Очень хотим, хотя бы попробовать, но техподдержка на запрос подключения «тестового доступа» молчит, а в «нетестовый» доступ так сразу писать не хочется.

Что бы получить доступ ваша организация должна обладать правом на передачу сведений. Можно обратиться в ФГУП «ВНИИМС» заполнив заявку и отправив запрос на получение такого доступа и секретного ключа.  Мы общались со Сковородниковым Борисом Валерьевичем, ведущем инженером dept103-vm[собака]vniims.ru

Насчет тестового доступа - на самом деле дают сразу полный. Тестового доступа у них нет.

1 час назад, БорисБ сказал:

И второе. Когда грузит сведения о поверке человек - то он в своём кабинете видит эти поверки и может, теоретически, внести исправления. Это страшный бред, конечно, но с этим пока поделать ничего нельзя. А кто видит, что грузит робот?

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

Информация для тех кто хочет выгружать через API пригодится

При  передачи  данных  через  ФГИС  API Аршина, далее "API"
мы столкнулись со следующими проблемами, решение который предложено ниже.

Техническая часть формирования XML пакетов и  отправки их на сервер.

1.   Название  нод  в xml файле регистрозависимы. Это значит, название ноды  (узла)  OBJ  не  идентично Obj. Хотя стандарт XML допускает, что ноды  OBJ=Obj=OBj,  но  API  к этому относится очень нехорошо, поэтому названия   нод   должны   быть  полностью  идентичны,  как  описаны  в
руководстве.
2.   При  формировании  файла  закодированного  по стандарту Base64 из сформированного  файла важно что бы этот файл не содержал символы CLRF
(#$a#$D).  Многие  библиотеки  кодирования  в  формат  Base64  да и сам стандарт  допускают  использовать CLRF для переноса строк, но API нет. Если  CLRF  там  присутствует  API  выдает ошибку связанную с неверным форматом Base64. Хотя по стандарту кодирования он верен и декодируется успешно многими сторонними утилитами. На этом факте мы потеряли очень много времени на разбирательстве.
3. Секретный ключ полученный для передачи данных тоже регистрозависим.

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

Сразу  оговоримся,  что  мы  посылаем  завершенные  работы, (калибровку в отправку не включаем).

1.  Проверка  №  госреестра на соответствие в справочнике Утвержденных типов СИ.
Проблему  с неверно введеными номерами мы решили созданием справочника утвержденных  типов  и  загрузкой  через  сервис api туда информации и
сверкой № при отправке

2. Не соответсвие вида деятельности в справочниках (в том числе и исторических) с требованиями api.
Решение частично приведены справочнике видов деятельности к   тестовке   api.   Для   проблемных   записей  (исторических  и  не
сопоставленных)  мы  решили принудительно выставлять "Выполнение работпо   обеспечению  безопасных  условий  и  охраны  труда"  иначе  нужно
переделывать множество старых поверочных работ.
3. Так как api проверяет записи на дублипрование целиком, мы столкнулись  с  проблемой отправки однотипных приборов с одним серийным
номером (обычно б/н).
Хороший  пример  10  манометров  без с/номеров, так вот при передаче 1 примется, другие 9 нет - api скажет что запись уже принята.
Наше  решение,  т.к.  api  проверяет  всю  запись  целиком,  мы решили использовать  необязательное  поле  PrimPOV,  для передачи туда нашего
уникального номера в БД, после этого api считает такие поверки разными и  успешно принимает их. Маленький бонус - мы можем сопоставить запись
в Аршине с нашей БД.
4. Не  указана методика поверки, в этом случае мы передаем строку "МП согласно ОТ"
5.  Ошибка,  но  которая  не  перехватывается  api  бывает  в  БД  дата след.поверки  <  даты  поверки.  Хоть api и принимает такие записи, мы
их  решили  в  формируемый  пакет  не  передовать.  Вернее мы пытаемся расчитать   дату   следующей   поверки  по  указанному  межповерочному
интервалу, и если не может то и не передаем.

Контроль отправки и статистика обмена.

Т.к.   штатными   средствами   Аршина не  возможно  сопоставить поверочную  запись с запись для передачи нам пришлось вносить изменения
в  БД  для  контроля и сопоставления. Дополнительно мы видим что и когда отправлено и как обработано. 

Добрый день!

Мы решили проблему с однотипными записями проще. Так как мы формируем пакеты для загрузки автоматически с БД и передаем их в Аршин автоматически через API то проблемы записей в одном пакете мы решили так:

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