ВладимирWW

Посмотрите вот здесь http://orenpov.ru. Проблем с передачей данных вообще нет

Не совсем так. В соответствии с описанием формата данных обязательно должно быть заполнено поле NumCertfPOV (Номер свидетельства о поверке) или поле NumSvidPOV (Номер извещения о непригодности). При отсутствии номера (свидетельство не выписывалось) необходимо указать «Нет данных»

Когда ведутся работы, тогда они вывешивают сообщение на сайте. А сейчас и них тупо недоступна сеть - 504 Gateway Time-out

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

Если по хорошему, то, если есть разрывы, можно попробовать, например, так: Начальный номер = 23-35, 45-47, 65, 68-75 Конечный номер = 76 Тогда будет соответствовать количеству

А Вы при внесении номеров делали разрывы, типа этого: 12-16, 35, 44-65? Или просто не учитывали разрывы в нумерации (просто указали начальный и конечный номера)?

Думаю, что для реализации такой проверки у них чего-то не хватает... Именно поэтому думаю., что при внесении в одной строке более 1 можно указывать Начальный и Конечный номера = б\н

В этом есть логика! Дело в том, что б\н тоже буквы. И с учетов того факта, что есть номера с буквами, АРШИНовцы, судя по тому, что они творят, просто не могут проверять непрерывность номеров Начальный и Конечный номера в партии, где в номерх присутствуют буквы. А это означает, что для партии, скорее всего, можно указывать Начальный номер=б\н и Конечный номер = б\н

А что делать если заводской номер = б\н?

И какой вариант? Не этот ли: В описании формата данных для SerialNumPOV написано, что это "Заводской номер СИ.При отсутствии заводского номера необходимо указать «б/н»". Для SerialNumEndPOV написано: "Конечный заводской номер СИ". И сноска: "Необходимо вводить конечный номер только той партии, в которой все номера идут по порядку. В противном случае, требуется создать отдельную запись для каждого диапазона номеров, в котором все номера идут по порядку"

А если номера содержат букву?

А если у них у всех "б\н"? Проходит?

В описании формата данных для SerialNumPOV написано, что это "Заводской номер СИ.При отсутствии заводского номера необходимо указать «б/н»". Для SerialNumEndPOV написано: "Конечный заводской номер СИ". И сноска: "Необходимо вводить конечный номер только той партии, в которой все номера идут по порядку. В противном случае, требуется создать отдельную запись для каждого диапазона номеров, в котором все номера идут по порядку" НО возникает вопрос - можно ли проверить, что номера идут по порядку с учетом того факта, что завномера могут содержать буквы? И никак эту беду не идентифицируешь. Тем более, что многие ведут учет без завномеров - указывают б\н Если у Вас основная цель - передать данные в АРШИН, то передавайте. Тем более, что на бардак, который творится в АРШИНе Вы никак повлиять не можете

Это поле не обязательно для заполнения. Так что во избежание проблем лучше его не заполнять

Интересно, а Вы попробовали передавать как написали ("Хотели передать по количеству шт. Одного реестра поверенных в один день"). Только указывайте Конечный номер также как "б\н". По идее, должно проходить - они же (АРШИН) не знают первичная это поверка или периодическая.

Сначала проверьте наличие ГПЭ в базе АРШИН, а потом указывайте. Причем при проверке пробуйте разные варианты поиска, например так - гтэ, затем так ГТЭ. Если далее, то так гэт34 (ГЭТ34), потом так гэт 34 (ГЭТ 34) Если найдете в базе АРШИН, то постарайтесь в данных о поверке указывать регномер именно так, как это внесено в АРШИН

Судя по описанию формата данных для количества более одного (DeviceCountPOV>1): - указывается начальный номер партии (поле SerialNumPOV) - указывается конечный номер партии (поле SerialNumEndPOV) А далее сноска: Необходимо вводить конечный номер только той партии, в которой все номера идут по порядку. В противном случае, требуется создать отдельную запись для каждого диапазона номеров, в котором все номера идут по порядку Это на основе описания АРШИН Если же начать теоретизировать, то в завномерах могут использоваться буквы и АРШИН тогда не сможет отслеживать непрерывность номеров, так как поле должно быть текстовым (если оно действительно текстовое). Тогда там можно писать что хочешь. Другой вопрос, какой длины поле, то есть что туда удастся написать. Это может показать или эксперимент или вопрос в службу сопровождения АРШИН Если сомневаетесь, оформляйте поверки отдельными записями

ЦСМ и ГНМИ

А Вам удалось при анкетировании выразить неудовольствие работой именно АРШИНа?

Пишите на адрес fgis2@gost.ru А вообще-то у нас только 07.06.2019 обработались данные, отправленные в апреле 2019 года

А Вы заявку на подключение к АРШИНУ с пакетом документов во ВНИИМС отправляли?

С 5 апреля загружено более 3-х десятков файлов. До сих пор ни один не обработан

Это от лукавого (Данная ошибка не относится к работе ФГИС "Аршин",): - во-первых, служба сопровождения находится на адресе fgis2@gost.ru, а это почтовик Росстандарта, где находится АРШИН -во-вторых ФГИС АРШИН - это ПО, которое не может висеть в воздухе - оно как раз и должно быть размещено на "центральном сервере fgis.gost.ru" Чушь полнейшая: АРШИН что, без веб-сервера работает и без сервера СУБД? Эдакое висящее в воздухе ПО без железа и прочего пирога в соответствии с моделью OSI Что же тогда поддерживают те, кто отвечает как СП?

Выложите, сравним

Во вложении версии 1.04 и 1.05 ФГИС2. Руководство пользователя. Публичный портал (1.04).pdf ФГИС2. Руководство пользователя. Публичный портал (1.05).pdf