Deeptown12

Совершенно верно по логике Аршина - да. Ссылаетесь на него при периодической поверке. Но тут встает другой вопрос: А если эталон негоден. А потом отремонтирован и снова в поверку после ремонта, она будет как первичная. И получается что вообще в этой ситуации надо новый номер присваивать. А эталон один. И зачем такая цепочка вообще нужна. Она ведь работает только в одном случае когда эталон всегда годен. И умирает на браковке или понижении разряда. А в жизни может негоден, а потом отремонтирован и снова годен. Вот и получается что номер этот фейковый и реальной прослеживаемости поверок конкретного эталона не несет. А может в будущем быть такая ситуация что конкретный эталон в будущем иметь несколько номеров в Фонде в зависимости от периода. Вот где каша у Росстандарта. Номер был бы логичным для прослеживаемости поверок если бы он шел даже при поверках после ремонта, смены разрядов (блоков) и пр. Ну типа эталон номер N 2019 - Первичная поверка - годен 2020 - Периодическая поверка - годен 2021 - Периодическая поверка - не годен 2021 - Первичная поверка после ремонта - годен 2022 - Периодическая поверка - годен 2023 - Периодическая поверка - годен с понижением разряда (в виду потери точности или по какой-то другой причине) 2024 - Периодическая поверка - годен Вот тогда бы был бы смысл, вся цепочка поверок была бы на ладони. С точки зрения информационных систем. Но с точки зрения поверки а зачем вообще это нужно, тем более так как это сделано в Аршине. А сделано это примерно так по их кривой логике: Ну типа эталон номер N1 2019 - Первичная поверка - годен 2020 - Периодическая поверка - годен 2021 - Периодическая поверка - не годен 2021 - Первичная поверка после ремонта - годен !!!!!!!! ПРИСВОЕН НОВЫЙ НОМЕР N2 !!!!!!!!! 2022 - Периодическая поверка - годен 2023 - Периодическая поверка - годен с понижением разряда (в виду потери точности или по какой-то другой причине) 2024 - Периодическая поверка - годен

Как как - обыкновенно, например калибратор - по току бьется по напряжению нет. По току подтверждаем, по напряжению - бракуем. НО! Может конечно я ошибаюсь. Мы можем понизить разряд, где написано что не можем, сделав первичную поверку по напряжению и спустив с 1 разряда ниже на второй. Калибратор ведь работает пусть не по 1 так по 2Р. Или мы вообще браковать должны. Вот и получается что идет смешение первичной и периодической поверки. И какой в этом смысл - проще сразу делать как первичную с присвоением новых номеров в Аршине. С точки зрения Аршина - неверно, а точки зрения поверки? А ваш пост это как раз третье мнение: ток-подтверждаем, напряжение по 1Р-бракуем + даем новый 2 разряд по напряжению раз первый не тянет. А если это блочный эталон, а если блоки меняются. А после ремонта части блока, Очень много вопросов...

Можно подносить патроны буду.... С эталонами вообще есть еще неявный момент когда пойдет далее периодическая поверка с указанием номеров в Аршине. Допустим у нас три разряда по ГПЭ. На все три были присвоены номера в Аршине. Прошел год, приносят эталон. А он по одному разряду не бьется, по двум бьется по одному нет, но можно дать понижение разряда. И тут возникает вилка как его публиковать такой эталон. Две записи (периодическая поверка) с подтверждением к номерам Аршина + новая запись с новым разрядом (но как первичная). Или делать первичную по трем, т.к. характеристики эталона все-таки поменялись. Ну нету периодической поверки СИ в качестве эталона с выставлением другого разряда как в первичной. По крайней мере в Аршине текущем. Кто-ж так строит системы информационные?. Если периодическая то только ссылка на номер Аршина, т.е. подтверждение или забраковка. А если понижение. И приплыли. А если нету периодической давайте тогда будем лепить первичную с присвоением новых номеров. Система позволяет.

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

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

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

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

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

Информация к размышлению! Коллеги, если вы случайно передали СИ поверенное как эталон, то знайте что удалить его из Аршина невозможно. Даже если вы ошиблись при вводе или загрузки из пакетов. Официальный ответ техподдержки: Как удалить запись о СИ, применяемом в качестве эталона ? Удаление записей из Перечня СИ, применяемых в качестве эталонов, не предусматривается. Рекомендуем Вам удалить записи о поверках, приведших к повторному заведению сведений о СИ, применяемых в качестве эталонов. В этом случае записи о СИ, применяемых в качестве эталонов, не будут подкреплены ни одной поверкой и будут, фактически недействительными. Правила удаления сведений о результатах поверки приведены в разделе 3.4.1.10 Руководства пользователя. Удалять обычные поверки можно. Но тоже не без чудес. Когда удаляешь записи получают статус "Помечен на удаление". Техподдержка дает такое объяснение, может кто логику поймет.... Записи, которые имеют статус "Помечен на удаление" были опубликованы. Если создать заявку с такими записями и ее опубликовать, все эти записи будут аннулированы из Фонда. После публикации данные записи будут перемещены в представление "Аннулированы" и удалены из публичной части ФИФ. Но по прямой ссылке на запись карточка записи будет доступна, и в ней будет информация об аннулировании записи.

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

Тут интересные вещи пишут Собственно вопрос, а как собирается это делать Пензенский ЦСМ. Если нормального протокола загрузки в аршине нет. А то что аршин выдает в виде XML-протокола публикации притянуть и четко идентифицировать с переданным пакетом, а вернее поверкой невозможно. А не возможно почему, а потому что нет четкого сопоставления идентификатора публикации GlobalID с записью в пакете. Я тоже сначала думал что 1 записи в пакете = 1 запись в протоколе публикации. А это не так. Данные бывают идут вперемешку и не в том порядке как в файле загрузки. Проверено железно. Четко идентифицировать что такой то поверке присвоен такой то глобальный идентификатор невозможно. Соответственно и ссылку невозможно сгенерировать. Причем вопрос задавался в поддержку ФГИСа но что был получен ответ, ждите API и не раздражайте нас. Вот такая поддержка, как клиентом давать данные на публикацию в Фонде их СИ не ясно.

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

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

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

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

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

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

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

Ну тут понятно, нужно в запросе 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 не все его поддерживают. Учитывайте это.

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

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

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

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

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

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