Файл не соответствует спецификации в поле lanstate недокументированное значение
Я загрузил свой сайт на общий хост godaddy. Я!--3-->доступ эта база данных из моей студии управления. Я!--3-->не могу получить доступ к база данных с моего сайта. Я получаю следующую ошибку:
формат строки инициализации не соответствует спецификации, начинающейся с индекса 0.
моя строка подключения в web.config и выглядит это так:
что вызывает эту ошибку? У меня тоже пытался написать . Data Source=(local);.
Это может помочь, чтобы увидеть, что строка подключения. Добавить в мировой.асакс:
если фактическая строка соединения $(ReplacableToken_mcn-Web.config Connection String_0) , это объясняет проблему.
Я столкнулся с той же проблемой и обнаружил, что моя строка соединения имеет дополнительный символ двойной кавычки в середине строки соединения.
добавить ссылку на System.Конфигурация и обновление моего кода, как показано ниже, было моим решением. Строка подключения не была проблемой, так как другие элементы управления использовали ее без каких-либо проблем (SqlDataSource)
у меня было это в VS2015, и мое исправление состояло в том, чтобы изменить первую строку в моем WebConfig из
поэтому я создал его с помощью кнопки три точки, и после публикации он работал.
Что странно, так это то, что в течение длительного времени я уверен, что в этой конфигурации не было строки подключения, но это все еще работать.
еще одна ловушка-это connectionString иногда ссылается на имя строки подключения в app / web-config, а иногда на саму строку подключения и наоборот.
в моем случае виновником была точка с запятой и двойные кавычки в пароле для prod DB. Наша ИТ-команда использует какой-то инструмент для генерации паролей, поэтому он сгенерировал один с точкой с запятой и двойными кавычками Connectionstring выглядит как
получил пароль изменен и это сработало.
моей проблемой было то, что моя сеть.файл конфигурации содержит ссылку на удаленное соединение модели сущности, поэтому проверьте, нет ли устаревших строк подключения.
Я получил ниже ошибки при попытке запуска приложения :
формат строки инициализации не соответствует спецификации, начиная с индекса 57.
Я получал это исключение, исправил его, добавив throwIfV1Schema: false моему конструктору DbContext:
я столкнулся с этой же проблемой в Web API 2 после запуска этого в консоли PM:
я исправил его, изменив его, чтобы фактически использовать ApplicationDbContext создано в IdentityModels .
интересная вещь не только делает эту ссылку такой же точной строка подключения, но конструктор включает код, который 4castle сказал, что это потенциальное исправление (т. е. throwIfV1Schema: false предложение.
нежелательная одиночная цитата была моей проблемой. Проверка строки подключения из расположения индекса, упомянутого в строке ошибки, помогла мне определить проблему.
Если вы используете EF и публикуете профили, у вас может быть пустая запись строки подключения в вашем профиле публикации. Раздражает, но вполне возможно.
Зарплата и управление персоналом, редакция 3.1 (3.1.16.134)
при загрузке электронного больничного полученного через СБИС
Файл не соответствует спецификации: В поле "lnState" недокументированное значение: "".
так. чуть позже пояснили - "у нас поменялся формат файла xml (версия), а в 1С - нет, ждите обновления 1С"
обновился до версии 1.3.17.94 - такая же ошибка, эта версия от конца февраля, а СБИС сказал что изменение произошло в марте.
Была подобная ошибка. Сначала грешили на формат.
Потом оказалось, что номер ЛН был вписан неправильно (пропустили одну цифру).
Проверьте, может в этом причина.
А сплошь и рядом в мед.учреждениях забывают статус изменить, закрыть ЛН. И висит у них ЛН в статусе 010 или 020.
Потому для начала, первое, на что нужно сразу смотреть - вот тебе принесли бумажный квиточек с данными ЭЛН? Сразу смотрим - какой там указан статус?
НЕ 030? Сразу посылаем назад, даже не бери в руку эту бумаженцию. Фу, кака..
ps: ну и никакая религия не запрещает глянуть одним глазком в файлик, а какой там статус ЭЛН в xml-файле, выгруженном из СБИС.
Всем спасибо, это СБИС (Тензор) намудрили немного. в клиентской части для ПК "наулучшали" в результате чего больничные листы для загрузки 1С корректно выгружаются только из СБИС Онлайн. Через это получилось. Обещают вернуть в ближайшие дни в клиентскую часть -)
(10) ага. Они почему-то реквизит lnState относят к необязательным реквизитам. Т.е, по их мнению, lnState можно заполнять, но необязательно. Было такое уже в 2017 году и вот опять. :)))
Но, откровенно говоря, поддержу (11). +100500
Я вот четноговря непонимаю Если у тебя есть СБИС, значит, у тебя есть ЭЦП. А если у тебя есть ЭЦП, ты можешь взять ЭЛН непосредственно у первоисточника - в личном кабинете на сайте ФСС.
Зачем к этому приплетать всяких посредников в лице СБИС, Тензор, Астрал etc., каждый из которых считает своим долгом трактовать, какие реквизиты обязательны, а какие нет.
Нахрен (пардон за мой французский) тебе вообще в этом деле посредники, работай непосредственно напрямую с фсс? Не понимаю. Или что - операторы ЭВМ научились только на определенные кнопочки нажимать и ничего больше не умеют?
Так заверяю тебя - в личном кабинете ФСС ничего страшного, там все довольно просто, примитивно и дружелюбно. За полчаса с перекуром и чаепитием самой тупой расчетчице объяснить можно.
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа.
Фредерик Брукс-младший
При попытке загрузки электронного больничного пишет: Не заполнено поле LN_HASH или Не заполнено поле LN_STATE.
Готовое расширение, исправление для типовой конфигурации ЗУП 3.1.
1. Еще ни разу не встречал ЭЛН с пустым LN_HASH.
2. Согласно спецификации ФСС поле LN_STATE обязательно к заполнению.
Данная доработка вредна , т.к. дает возможность под видом ЭЛН загружать всякую фигню.
Например, можно будет загрузить реестр прямых выплат, что не соответствует методике учета в 1С.
Сначала надо загрузить ЭЛН (настоящий!), рассчитать больничный, ввести заявление, а только затем выгрузить реестр прямых выплат.
Настоящий ЭЛН всегда содержит LN_STATE и LN_HASH, это его родовой признак.
Более того, ФСС требует корректный LN_HASH, т.к. только так вы можете подтвердить что отправляете данные опираясь на последнюю версию ЭЛН.
Приложенный код в LN_HASH заполняет "мусором" и такой ЭЛН ФСС не примет и хорошо что 1С не принимает.
При чем тут "можно будет загрузить реестр прямых выплат" кто об этом говорит ?
Я прямо указал спецификацию на сайте ФСС и там реквизит LN_HASH НЕ ОБЯЗАТЕЛЬНЫЙ какие могут быть претензии.
Я оперировал с файлами которые выдавал SBIS и Контур и там не было этих полей и файлы не загружались в 1С.
Полагаю что ФСС генерирует этот хэш каждый раз по определенному алгоритму и потому не считает поле
обязательным. Если вам лично что то не нравиться вы можете переписать код под себя, он открыт.
Что касается выгрузки реестра то
В процедуре выгрузки ВыгрузитьЗапросДляОтправкиРеестраЭЛН есть строка
УстановитьЗначениеЕслиЗаполнено (ROW.LN_HASH, РегистрыСведений.СведенияОбЭЛН.ПрочитатьХеш(ДанныеЛН.НомерЛисткаНетрудоспособности));
как вы догадываетесь это значит что выгружать его если он заполнен.
Получается загружать ЭЛН без LN_HASH нельзя ,а выгружать можно, довольно противоречиво.
В любом случае статья показывает один из вариантов исправления, не нравится пишите свой.
Данная проблема возникает при попытке загрузить электронный больничный из файла, полученного, например, из СБИС или Контур.
Так вот, формат реализован согласно спецификации версии 1.1 Источник на сайте ФСС..
Согласно этой спецификации LN_HASH не обязательный реквизит, однако у 1С другая логика. По логике программы этот реквизит должен быть обязательно представлен, что не совсем корректно. Эта же логика относится и к LN_STATE.
Привожу код исправления:
Применив это исправление, файлы прекрасно грузятся.
Проверял на релизах : 3.1.15.96
При использовании расширения галочка "Безопасный режим" должна быть снята !.
Специальные предложения
1. Еще ни разу не встречал ЭЛН с пустым LN_HASH.
2. Согласно спецификации ФСС поле LN_STATE обязательно к заполнению.
Данная доработка вредна , т.к. дает возможность под видом ЭЛН загружать всякую фигню.
Например, можно будет загрузить реестр прямых выплат, что не соответствует методике учета в 1С.
Сначала надо загрузить ЭЛН (настоящий!), рассчитать больничный, ввести заявление, а только затем выгрузить реестр прямых выплат.
Настоящий ЭЛН всегда содержит LN_STATE и LN_HASH, это его родовой признак.
Более того, ФСС требует корректный LN_HASH, т.к. только так вы можете подтвердить что отправляете данные опираясь на последнюю версию ЭЛН.
Приложенный код в LN_HASH заполняет "мусором" и такой ЭЛН ФСС не примет и хорошо что 1С не принимает.
При чем тут "можно будет загрузить реестр прямых выплат" кто об этом говорит ?
Я прямо указал спецификацию на сайте ФСС и там реквизит LN_HASH НЕ ОБЯЗАТЕЛЬНЫЙ какие могут быть претензии.
Я оперировал с файлами которые выдавал SBIS и Контур и там не было этих полей и файлы не загружались в 1С.
Полагаю что ФСС генерирует этот хэш каждый раз по определенному алгоритму и потому не считает поле
обязательным. Если вам лично что то не нравиться вы можете переписать код под себя, он открыт.
Что касается выгрузки реестра то
В процедуре выгрузки ВыгрузитьЗапросДляОтправкиРеестраЭЛН есть строка
УстановитьЗначениеЕслиЗаполнено (ROW.LN_HASH, РегистрыСведений.СведенияОбЭЛН.ПрочитатьХеш(ДанныеЛН.НомерЛисткаНетрудоспособности));
как вы догадываетесь это значит что выгружать его если он заполнен.
Получается загружать ЭЛН без LN_HASH нельзя ,а выгружать можно, довольно противоречиво.
В любом случае статья показывает один из вариантов исправления, не нравится пишите свой.
Данная проблема возникает при попытке загрузить электронный больничный из файла, полученного, например, из СБИС или Контур.
Так вот, формат реализован согласно спецификации версии 1.1 Источник на сайте ФСС..
Согласно этой спецификации LN_HASH не обязательный реквизит, однако у 1С другая логика. По логике программы этот реквизит должен быть обязательно представлен, что не совсем корректно. Эта же логика относится и к LN_STATE.
Привожу код исправления:
Применив это исправление, файлы прекрасно грузятся.
Проверял на релизах : 3.1.15.96
При использовании расширения галочка "Безопасный режим" должна быть снята !.
Специальные предложения
1. Еще ни разу не встречал ЭЛН с пустым LN_HASH.
2. Согласно спецификации ФСС поле LN_STATE обязательно к заполнению.
Данная доработка вредна , т.к. дает возможность под видом ЭЛН загружать всякую фигню.
Например, можно будет загрузить реестр прямых выплат, что не соответствует методике учета в 1С.
Сначала надо загрузить ЭЛН (настоящий!), рассчитать больничный, ввести заявление, а только затем выгрузить реестр прямых выплат.
Настоящий ЭЛН всегда содержит LN_STATE и LN_HASH, это его родовой признак.
Более того, ФСС требует корректный LN_HASH, т.к. только так вы можете подтвердить что отправляете данные опираясь на последнюю версию ЭЛН.
Приложенный код в LN_HASH заполняет "мусором" и такой ЭЛН ФСС не примет и хорошо что 1С не принимает.
При чем тут "можно будет загрузить реестр прямых выплат" кто об этом говорит ?
Я прямо указал спецификацию на сайте ФСС и там реквизит LN_HASH НЕ ОБЯЗАТЕЛЬНЫЙ какие могут быть претензии.
Я оперировал с файлами которые выдавал SBIS и Контур и там не было этих полей и файлы не загружались в 1С.
Полагаю что ФСС генерирует этот хэш каждый раз по определенному алгоритму и потому не считает поле
обязательным. Если вам лично что то не нравиться вы можете переписать код под себя, он открыт.
Что касается выгрузки реестра то
В процедуре выгрузки ВыгрузитьЗапросДляОтправкиРеестраЭЛН есть строка
УстановитьЗначениеЕслиЗаполнено (ROW.LN_HASH, РегистрыСведений.СведенияОбЭЛН.ПрочитатьХеш(ДанныеЛН.НомерЛисткаНетрудоспособности));
как вы догадываетесь это значит что выгружать его если он заполнен.
Получается загружать ЭЛН без LN_HASH нельзя ,а выгружать можно, довольно противоречиво.
В любом случае статья показывает один из вариантов исправления, не нравится пишите свой.
Читайте также: