Не смогли связать цепочку поставок со штрих-кодом

Разработка

Взаимодействие с АПИ РВ я реализовывал еще до того как библиотека МДЛП начала поддержку РВ в своем составе, поэтому на текущий момент используются в коде те самописные методы что были реализованы ранее.

За работу с РВ отвечает документ Уведомление о выдаче в отделения. Перед отправкой документа выполняется несколько проверок во избежание ошибок обработки документа РВ.

Первая проверка это запакованность SGTIN. Если отправите не разупакованный SGTIN все равно по итогу получите ошибку. Данную проверку например можно выполнять методом АПИ МДЛП по запросу информации о SGTIN (https://честныйзнак.рф/upload/iblock/200/IS-_Markirovka_.-MDLP.-Protokol-obmena-interfeysnogo-urovnya-v3.11.pdf  ) с помощью 8.3.3. Метод поиска по общедоступному реестру КИЗ по списку значений Endpoint: POST <endpoint>/<version>/reestr/sgtin/public/sgtins-by-list.

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

Вторая проверка это заполнение Base64 в ТЧ упаковки. Так как в РВ отправляется SGTIN упакованный вместе с криптохвостом, то отправка документа где есть незаполненные значения приведет к ошибке.

Третья проверка это наличие и длина криптохвоста. 92 часть SGTIN должна присутствовать и иметь длину строго 44 символа (на текущий момент имеется небольшой процент ЛП на которые производители нанесли неверный криптохвост).

Четвертая проверка наличие этого SGTIN на данном Месте деятельности (далее МД). Позволяет избежать ошибок если например у организации есть 2 и более МД или выдача была уже произведена другим документом. Аналогично пункту 1 либо запросом, либо хранить в базе состояния упаковок, либо через УпаковкиМДЛП.

Пятая проверка относится к первичным упаковкам. МДЛП позволяет выдавать SGTIN частично. В АПИ за это отвечает ключ sold_part который представляет собой дробь, например 1/2, где 2 количество блистеров в упаковке, как на рисунке. Выдали из них в документе 1 блистер.

Не смогли связать цепочку поставок со штрих-кодом

Осуществляется контроль не превышения этого количества по нескольким документам (остатки в регистре собираются по частям упаковок). Так как МДЛП не контролирует эти дробные части контроль остается на стороне 1С. Также нельзя передавать в РВ дроби типа 1/1, 5/5 и подобные, будет возвращена ошибка.

Любопытный факт – по одному SGTIN можно например выдать 5/10, 5/15, 14/15 последовательно разными документами и это не вернет ошибку. Упаковка по итогу спишется целиком если последняя отправка перекроет остаток в МДЛП на больше или равно.

Данные проверки уже позволят избежать множественных ошибок при отправке в РВ. Реализованы они на этапе Выполните проверку в документе. Пример кода проверок ниже. Вы можете адаптировать его под свои базы. Проверки количества и первичных упаковок не привожу, т.к. они работают только при наличии регистра накопления, отсутствующего в библиотеке МДЛП.

Для каждого стр из Объект.НомераУпаковок Цикл
	Если Объект.ПередачаСведенийЧерезСКЗКМ Тогда
		Если НЕ ЗначениеЗаполнено(стр.ШтрихкодBase64) Тогда
			Сообщение = Новый СообщениеПользователю;
			Сообщение.Текст = "У КИЗ: " + стр.НомерКИЗ + " - не заполнен штрихкод BASE64";
			Сообщение.Поле = "НомераУпаковок[" + (стр.НомерСтроки - 1) + "].НомерКИЗ";
			Сообщение.КлючДанных = Объект.Ссылка;
			Сообщение.ПутьКДанным = "Объект"; 														
			Сообщение.Сообщить();
			ОшибкиПроверки = ОшибкиПроверки + 1;
			Продолжить;
		КонецЕсли;
		// Удаление лишних символов.
		стр.ШтрихкодBase64 = СтрЗаменить(стр.ШтрихкодBase64, Символы.ВК, "");
		стр.ШтрихкодBase64 = СтрЗаменить(стр.ШтрихкодBase64, Символы.ПС, "");
		//проверка Base64 на наличие и корректность криптохвоста
		ДвоичныеДанныеСтроки = Base64Значение(стр.ШтрихкодBase64);
		Если ДвоичныеДанныеСтроки <> Неопределено Тогда
			Штрихкод = ПолучитьСтрокуИзДвоичныхДанных(ДвоичныеДанныеСтроки);
			СтруктураШтрихкода = ИнтеграцияМДЛПКлиентСервер.ДанныеШтрихкода(Штрихкод);						
			КриптохвостЗначение = "";
			Для каждого ЧастьШтрихкода Из СтруктураШтрихкода.ДанныеШтрихкода Цикл 							 							
				Если ЧастьШтрихкода.ИдентификаторПрименения = "92" Тогда 
					КриптохвостЗначение = ЧастьШтрихкода.Значение;
					Если НЕ СтрДлина(ЧастьШтрихкода.Значение) = 44 Тогда
						ЗаполненоBase64 = Ложь;
						Сообщение = Новый СообщениеПользователю;
						Сообщение.Текст = "КИЗ: " + стр.НомерКИЗ + " - имеет ошибочный криптохвост(92)";
						Сообщение.Поле = "НомераУпаковок[" + (стр.НомерСтроки - 1) + "].НомерКИЗ";
						Сообщение.КлючДанных = Объект.Ссылка;
						Сообщение.ПутьКДанным = "Объект"; 														
						Сообщение.Сообщить();
					КонецЕсли;
				КонецЕсли;  
			КонецЦикла;
			Если ЗначениеЗаполнено(КриптохвостЗначение) = Ложь Тогда
				Сообщение = Новый СообщениеПользователю;
				Сообщение.Текст = "У КИЗ: " + стр.НомерКИЗ + " - отсутствует криптохвост(92)";
				Сообщение.Поле = "НомераУпаковок[" + (стр.НомерСтроки - 1) + "].НомерКИЗ";
				Сообщение.КлючДанных = Объект.Ссылка;
				Сообщение.ПутьКДанным = "Объект"; 														
				Сообщение.Сообщить();
				ОшибкиПроверки = ОшибкиПроверки + 1;
			КонецЕсли;
		Иначе
			Сообщение = Новый СообщениеПользователю;
			Сообщение.Текст = "У КИЗ: " + стр.НомерКИЗ + " - некорректный BASE64";
			Сообщение.Поле = "НомераУпаковок[" + (стр.НомерСтроки - 1) + "].НомерКИЗ";
			Сообщение.КлючДанных = Объект.Ссылка;
			Сообщение.ПутьКДанным = "Объект"; 														
			Сообщение.Сообщить();
			ОшибкиПроверки = ОшибкиПроверки + 1;
		КонецЕсли;
	КонецЕсли;
КонецЦикла;

Также перед отправкой в РВ требуется проверить не заблокирован ли РВ (данная проверка реализована на текущий момент в библиотеке МДЛП). Осуществляется методами «Запросить состояние РВ» (RequestStatusRv) и «Получить информацию об устройстве» (GetInformationRv) (документация https://честныйзнак.рф/upload/iblock/92b/TC-RV-v25_07.06.2019_Publichnaya-versiya.pdf ). Здесь нас интересует ключ «timeBlock» в котором хранится время до блокировки. Если отправить документ в заблокированный РВ, а после этого его разблокировать, то с большой долей вероятности документ так и останется висеть в очереди.

После выполнения проверок документ упаковывается в json и отправляется методом «Записать задание в очередь» (QueueUp).

Рекомендация – хранить эти идентификаторы запроса, многократно возникала ситуация когда один из документов вешал очередь в РВ и все остальные документы повисали в ожидании. Исправляется либо перезагрузками РВ, либо что более надежно очисткой очереди методом «Отменить задание» (Delete). Для очистки очереди (а также очистки задания после успешного запроса статуса) и необходимо хранить все ранее переданные идентификаторы.

В случае положения успешного ответа следом отправляется запрос статуса задания методом «Запросить статус задания» (RequestStatus), где rvRequestId это идентификатор запроса, который присваивается в 1С (GUID). При успешном запросе статуса будет получено значение ключа «mdlpRequestId» по которому этот документ в дальнейшем можно найти в ЛК и получить квитанцию(и).

Важное замечание – на один документ выдачи в 1С через РВ может быть создано несколько документов в ЛК. Документы могут быть разбиты по типам ошибок, если таковые имеются в квитанциях, либо на текущий момент разбиение по 50 SGTIN, либо по различным GTIN.

После получения mdlpRequestId рекомендуется очистить очередь от этого документа в РВ методом «Отменить задание» (Delete).

Следующий метод является не обязательным и вариативным для каждого типа РВ. Речь о методе «Получить отчёты о выбытии» (GetReports) который поддерживается РВ Штрих и на момент написания статьи не поддерживается РВ АТОЛ. Данный метод позволяет получить ответ от РВ по каждому заданию и по каждому SGTIN прошла ли проверка этих SGTIN в РВ будут ли они отправлены в МДЛП (к сожалению это не всегда так, возможна ситуация – для ЛП выпущенных до 01.07.2020 будет написано, что выдача подтверждена, а по факту они так и не уйдут в МДЛП).

Для получения квитанции последовательно реализованы несколько методов АПИ МДЛП (документация https://честныйзнак.рф/upload/iblock/200/IS-_Markirovka_.-MDLP.-Protokol-obmena-interfeysnogo-urovnya-v3.11.pdf ) .

Для начала используется метод 5.18. Прослеживание документов по отчёту из СУЗ в фильтр которого передается mdlp_request_id. Данный метод вернет список document_id которые требуется загрузить методом 5.14. Получение документа по идентификатору. После получения списка требуется методом 5.16. Получение квитанции по номеру исходящего документа получить link по которому скачивается квитанция.

Важный момент – так как один документ в 1С может разделиться на несколько в МДЛП, причем каждый из этих документов будет иметь свою квитанцию, то по части документов может уже пройти обработка, а по части нет. Соответственно на какой-то момент времени документ будет находиться в статусе частичного получения квитанции. Но может возникнуть ситуация когда РВ некоторые SGTINы не отправил и не отправит уже в МДЛП. В таком случае необходим анализ документов в ЛК и правка документа в 1С. Для упаковок которые не выдались потребуется либо повторная отправка новым документом через РВ, либо в обход РВ (по 531 схеме). В таком случае документ отправится напрямую и будет видна квитанция по нему после обработки.

Как я писал ранее работа под веб типовой библиотекой МДЛП не поддерживается, но это не значит, что данная задача не решаема. Небольшая доработка напильником и методы работы с РВ становятся доступны в браузере.

Ошибочные ситуации

При работе с РВ возможны ошибочные ситуации, как по причине ошибок в 1С, так и по причине проверок в РВ или МДЛП.

Часть проверок реализована библиотекой МДЛП, разбор ошибочных ответов от РВ так же должен разбираться корректно.  При этом, как я обозначал выше, могут быть проблемные ситуации не самые очевидные.

Самой часто встречающейся ошибкой на текущий момент является ошибочность КМ при создании его поставщиком. Зачастую это относится к КМ выпущенным до 01.07.2020, но изредка встречаются КМ выпущенные позже, но имеющие те же самые проблемы.

Что происходит в данной ситуации? Документ с такими КМ отправляется в РВ, тот возвращает успешный ответ постановки в очередь, после запроса статуса он тоже будет возвращен успешный. Для РВ ШТРИХ можно запросить статусы выбытия и там они тоже будут как «Выбытие подтверждено». Но в ЛК эти КМ так и не придут.

Что предпринять в данном случае?

Первое подождать от 1 часа до 24 пока документ не появится в ЛК (возможны задержки обработки очереди).

Второе проверить КМ в ЛК на дату их выпуска на вкладке Товары и если имеются выпущенные ранее 01.07.2020, которые так и не появились в ЛК после отправки в РВ, необходимо рассмотреть возможность создания нового документа выдачи с отправкой по схеме 531, минуя РВ.

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

Также есть частая ошибка, одна из самых непонятных для пользователя на текущий момент возврат ошибки из МДЛП «Недопустимый переход в товаропроводящей цепочке». Под этой ошибкой может пониматься целое подмножество ошибок:

– КМ находился не в статусе «В обороте» на момент выдачи (выдан ранее, не принят);

– КМ выбывается не с того МД на котором находится (если МД у организации несколько);

– нарушена временная последовательность выдачи (ситуация когда приемка была позже чем выдача).

Тут надо остановиться подробнее с конкретным примером. Допустим, есть ситуация когда приемка зафиксирована в 12.00, но поставщик не учел рекомендации по указанию часового пояса и отправил без +03.00 в дате. РВ игнорирует передаваемое время в json и выставляет свое время фактическое. Таким образом любая выдача до 15.00 будет приводить к ошибке. Ситуация к счастью довольно редкая, но возможная.

В такой ситуации рекомендую обратить на время указанное в xml документа приемки, а именно передал ли поставщик часовой пояс в дате.

Возможно Вы наталкиваетесь на другие ошибки при использовании РВ, которые я забыл или не встречал. Напишите, пожалуйста, о них в комментариях и возможно решения по ним я смогу включить в статью для помощи другим пользователям.

Если Вас интересуют какие-то определенные темы напишите, пожалуйста, в комментариях. Возможно я включу их в последующие статьи. Также приветствуется здоровая критика статьи, которая поможет сделать ее лучше.

P.S. Довольно часто наталкиваюсь на обвинения что маркировка ухудшает работу, Честный Знак работает плохо и т.д. Тут выражу исключительно собственное мнение по данной ситуации. Идея маркировки ЛП исходит из уменьшения контрафактных ЛП и прослеживаемости каждого этапа жизненного цикла ЛП, что в целом приведет к улучшению медицины. За маркировку требуют денег – когда Вы начнете работать бесплатно можем вернуться к этому вопросу. РВ организациям выдают бесплатно. Нестабильная работа Честного Знака – я занимаюсь маркировкой ЛП уже 3й год и хорошо видел развитие с точки зрения разработчика. Служба поддержки всегда реагировала на мои заявки адекватно, некоторые пожелания были действительно учтены в новых релизах. Документация для разработчиков очень удобная и детальная. Я брал ее за образец при написании собственных АПИ например. Нестабильная работа и ошибки – да имеют место, но как разработчик я прекрасно понимаю какой объем работы необходимо проделывать чтобы система работала стабильно по всей нашей весьма немаленькой стране.

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

P.P.S. Хочу поблагодарить свою проектную команду, благодаря которой мы успешно развиваемся. Спасибо. Эта статья и ваша заслуга.

Приемка товара по обратному акцепту

Схема обработки документа при обратном акцепте¶

obratnyj akcept00

Информация от ИС МДЛП¶

Документ должен быть обработан согласно описания:

Найти и открыть документ во Вводе, редактировании.

Выбрать курсором строку с наименованием товара.

Выбрать курсором колонку штрихкода упаковки товара SGTIN в правой части Таблицы кодов.

Нажать сочетание «горячих клавиш» Ctrl + I или вызвать пункт Доп.иформация из МДЛП Ctrl+I контекстного меню, которое открывается по нажатию правой клавиши мыши в правой части Таблицы кодов на строке с отмеченным SGTIN.

obratnyj akcept01

Контрольные точки в обработке документа¶

Если для этих типов документов в колонке Комментарий указано значение получено подтверждение, то документ обработан успешно:

obratnyj akcept02

Если текст в колонке содержит слова Ошибка, Операция не может быть выполнена или иные утверждения о невозможности или запрете, то требуется ознакомиться с таблицей Ошибки на уровне документа из документа Описание кодов ошибок при обработке xml-документов Ошибки на уровне документа на сайте компании «Честный знак».

Проверка SGTIN¶

Узнать информацию о SGTIN в личном кабинете Честный знак.

Выбрать курсором строку штрихкода упаковки товара SGTIN в правой части Таблицы кодов

Нажать сочетание «горячих клавиш» Ctrl + Ins или вызвать пункт Копировать SGTIN в буфер Ctrl+Ins контекстного меню, которое открывается по нажатию правой клавиши мыши в правой части Таблицы кодов на строке с отмеченным SGTIN.

Открыть личный кабинет на сайте «Честный знак».

Читайте также:  Код ошибки 102 сертификат не действителен ошибка при получении контекста цепочки сертификатов

Выбрать вкладку «Товары».

Нажать кнопку «Фильтр».

Выбрать поле SGTIN для ввода значения.

obratnyj akcept04

Нажать кнопку «Применить».

obratnyj akcept05

Возможные результаты поиска и пояснения к ним:

obratnyj akcept06

Если SGTIN есть в личном кабинете, и товар числится в обороте, но 607 документа нет, то это значит, что Честный знак не отправил 607 документ в программе «М-АПТЕКА плюс», нужно ждать, какие-то задержки на стороне Честного знака.

obratnyj akcept07

В обоих случаях мы не можем повлиять на процесс ускорения процесса получения документа 607. Но в первом случае можно обратиться к поставщику и попросить акцептировать товар в Честном знаке.

Известные ошибки¶

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

Нет подтверждения поставщика¶

Есть квитанция по 416 документу с успешным завершением операции и нет документа 607 от поставщика.

obratnyj akcept03

Найти информацию по SGTIN: Проверка SGTIN.

Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке

В квитанции по документу ошибка №11. Текущий статус/состояние SSCC/SGTIN не позволяет совершить операцию.

Нарушение статусной модели (переходов);

Отсутствуют сведения о регистрации предшествующей требуемой операции 911/912/913/914

Проверить, что известно по документу 416:

Выполнить действия для получения Информации от ИС МДЛП.

Найти всё строки, где занчение 416 в колонке Тип док-та.

Если есть такие строки и хотя бы на одной из них в колонке Комментарий есть значение получено подтверждение, то товар перешел в состояние ожидания подтверждения (акцептирования) от поставщика, НО поставщик не подтвердил (не акцептировал, 607 документ). Необходимо сообщить это поставщику.

Если таких строк нет, то уточнить у поставщика и выслать ему документ 416 и квитанцию.

Попытка изменить состояние вложенного КИЗ¶

В квитанции по документу ошибка №15.

Ошибка появляется при попытке зарегистрировать операцию движения кодов SGTIN для товаров, которые вложены в SSCC (транспортную упаковку).

Фармацевту внимательно осмотреть коробку с товаром на наличие транспортной упаковки (SSCC):

Если транспортная упаковка присутствует – принять товар по SSCC. Подробнее см. Алгоритм сверки маркированного товара SSCC+SGTIN в одной товарной строке накладной.

Если транспортной упаковки нет, то обратиться к поставщику для разагрегации товара на SGTIN. После чего отправить данные в ИС МДЛП повторно.

Идентификатор текущего владельца и субъекта операции не совпадают

В квитанции по документу ошибка №22.

КИЗ (товар) принадлежит другому участнику.

Убедиться в том, что отправляют данные в МДЛП с верным адресом поставщика (Местом деятельности). Требуется отправить данные с верным адресом.

Если выслали данные с верным адресом, то проверить SGTIN на наличие в личном кабинете Честного знака. Подробне см. Проверка SGTIN.

В учете маркированного товара в таблице с колонкой SGTIN проверить значения в колонках:

obratnyj akcept08

Операция не может быть выполнена. Указанный контрагент отсутствует в списке доверенных контрагентов

В квитанции по документу ошибка №2014

Поставщик не добавил аптеку в доверенные контрагенты.

Сообщить поставщику информациюоб аптеке для добавления в доверенные контрагенты.

Источник

Ошибки при работе с маркированными ЛС

Устранение основных ошибок при работе с маркированным товаром.

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

Для работы с данной инструкцией необходимы:

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

Глоссарий.

ЧЗ – “Честный Знак”

Квитанция – Документ, содержащий информацию о статусе передачи данных в “Честный Знак”. Квитанцию можно посмотреть в программе “Склад” и отправить поставщику в случае необходимости.

SGTIN – Уникальный код для каждой упаковки.

SSCC – Код групповой упаковки. Как правило, указан на упаковке, в которой пришел товар. Актуально для позиций с большим кол-вом товара.

Идентификатор осуществления места деятельности или идентификатор участника – Код из системы ЧЗ. Присваивается для каждого адреса отдельно. Узнать свой код и код поставщика можно в личном кабинете ЧЗ.

Статус накладной – Статус в шапке маркированной накладной который показывает текущее состояние документа. Основные статусы:

Инструментарий.

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

Проверка версий базы и программы – для проверки версии базы данных и программ необходимо в главном меню выбрать пункт “Справка” и далее нажать “О программе”.

image8

В открывшимся окне вы увидите версию программы(1) и версию базы данных(2)

image2

Кнопка “Детали” – отображает поле с данными по упаковкам для выделенной позиции. Также в этом поле мы будем видеть статус обработки товара и ошибки, если ЧЗ вернет таковую. Ошибку можно увидеть в поле “Ошибка из чз”. Если в поле не вмещается ошибка целиком, то можно данное поле развернуть, потянув за правую границу поля. Также позиции, по которым были возвращены ошибки, будут подсвечены красным.

image6

Рис. 1 Кнопка “Детали”

Кнопка “Удаление информации” – необходима для удаления данных по уже отсканированным упаковкам в случае неправильных действий при оприходовании маркированного товара.

image4

Рис. 2 Кнопка “Удаление информации”

image7

Рис. 3 Кнопка “Дополнительно” =&gt; “XML документы ЧЗ”

unnamed 1

Рис. 3.1 Квитанция и документ

Документ в верхнем списке выбираем самый последний. Узнать, какой документ последний, можно отсортировав список по “Коду записи”(1) или по “Дате получения документа”(2). Если хотим отправить квитанцию поставщику, то копируем текст из раздела “Квитанция”(4) и отправляем текстом, например по электронной почте. Так же поставщик может запросить сам документ, в таком случае копируем текст из раздела “Документ”(3). Для выделения всего текста можно нажать сочетание клавиш Ctrl + A. Копирование производиться только сочетанием клавиш Ctrl + C, а вставка может осуществляться сочетанием клавиш Ctrl + V.

image3

Рис. 4 Кнопка “Отправить в ЧЗ”

Проверка наличия задачи для маркировки.

В правом нижнем углу, на панели задач необходимо нажать на значок как на рисунке ниже:

153b fdff 3863 703b

В открывшемся окне нажимаем “Модули”

3c8e b9ee 89f4 abbf 3

В следующем окне выбираем строку “Markirovka” и нажимаем кнопку “Задачи”

4193 2db5 d6f8 9bfa

В открывшимся окне вы увидите задачу на запуск обработки данных по маркировке

e1d0 2627 071b 42fe

5f1d a06c 1325 ae46

Ошибки и другие проблемы при работе с ЧЗ
1. Проблема: Не приходит подтверждение. Статус накладной “Ожидание подтверждения”. Статус упаковок “Ожидает ответа поставщика для обратного/прямого акцепта”.

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

Необходимо созвониться с поставщиком по данной накладной и указать на эту ситуацию. В случае если поставщику необходимо подтверждение того, что мы действительно отправили данные в ЧЗ, необходимо отправить квитанцию (как отправить квитанцию смотрите комментарий к рис. 3.1).

Поставщик может попросить отправить данные повторно. Для этого нужно нажать на выпадающий список рядом с кнопкой “Отправить в ЧЗ” и далее нажать “Отправить отказ” ( См. Рис. 4 ). Будет установлен статус упаковок “Отказ отправлен”, а чуть позднее статус изменится на “Отказ подтвержден”. После этого делаем повторную отправку кнопкой “Отправить в ЧЗ” и далее нажать “Повторная отправка в ЧЗ” ( См. Рис. 4 ).

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

2. Проблема: Не приходит подтверждение. Статус накладной “XML создан”.
3. Ошибка: “Попытка изменить состояние вложенного КИЗ”

В данной ситуации поставщик поставил товар в групповой упаковке. Как правило, это делается для удобства оприходования товара с большим кол-вом упаковок. Чтобы не сканировать, например, 50 упаковок товара, можно просканировать штрих-код с групповой упаковки и получить данные по всем 50-ти упаковкам автоматически через ЧЗ. Однако, игнорировать ее мы не можем, и если поставщик прислал товар в групповой упаковке, то нам необходимо сканировать именно код групповой упаковки и после подтверждения прихода ее расформировать.

Самый простой способ устранения ошибки – попросить поставщика расформировать групповую упаковку. После того, как поставщик подтвердит расформирование, необходимо отправить данные повторно. Для этого нужно нажать на выпадающий список рядом с кнопкой “Отправить в ЧЗ” и далее нажать “Повторная отправка в ЧЗ” ( См. Рис. 4 ). Статус позиций сменится на “Отправлен поставщику для подтверждения обратного акцепта”. После этого ожидаем подтверждения.

В дальнейшем необходимо будет обращать внимание на наличие групповой упаковки и сканировать именно ее, а не каждый товар отдельно. На данный момент поставщики никак не оповещают клиентов о наличии групповой упаковки, поэтому, если есть необходимость, то перед оприходованием уточняется эта информация у поставщика.

4. Ошибка: “КиЗ принадлежит другому участнику”

Ошибка говорит о том, что информация по упаковкам могла быть ошибочно отправлена поставщиком другой аптеке или поставщик неверно указал код осуществления места деятельности для получателя.

Необходимо обратиться к поставщику для уточнения информации, возможно потребуется отправить поставщику квитанцию (как отправить квитанцию смотрите комментарий к рис. 3.1). После устранения проблемы поставщиком необходимо отправить данные повторно. Для этого нужно нажать на выпадающий список рядом с кнопкой “Отправить в ЧЗ” и нажать “Повторная отправка в ЧЗ” ( См. Рис. 4 )

5. Ошибка: “Операция не может быть выполнена. Указанный контрагент отсутствует в списке доверенных контрагентов”

Необходимо найти в личном кабинете ЧЗ данного поставщика и добавить его в доверенные контрагенты, либо в нашем справочнике контрагентов указали идентификатор МД в ЧЗ для другой точки контрагента (уточнить правильный идентификатор МД в ЧЗ для точки можно у поставщика).

Также ошибка может возникать в случае если мы отправляем данные неправильным типом акцепта. Например, поставщик отправил прямым акцептом, а мы пытаемся отправить обратным. Необходимо уточнить у поставщика, каким акцептом он отправляет вам накладные.

6. Ошибка: “Указанный получатель не зарегистрирован в системе”
7. Проблема: Маркированный товар не провели через ЧЗ и продали в розницу.

Если товар нужно было оприходовать обратным акцептом, то для исправления проблемы нам необходимо будет получить SGTIN`ы проданного товара. Запросить SGTIN`ы можно у поставщика (если товара продано мало и вы знаете кому продали, то можно запросить фото QR-кода с упаковки у покупателя). После получения данных необходимо обратиться в техническую поддержку Алгоритм-с.

Если получить SGTIN`ы и QR-коды не получилось, то в данной ситуации можно только обратиться в ЧЗ, возможно они смогут помочь.

При такой же проблеме, но если прямой акцепт – обратиться в техническую поддержку Алгоритм-с.

8. Ошибка: “Операция не может быть выполнена. Указанный SGTIN/SSCC не найден в системе”

Товар который вы просканировали отсутствует в ЧЗ. Скорее всего он маркирован в рамках эксперимента, его не нужно проводить в ЧЗ. Проверьте дату изготовления препарата. Если препарат изготовлен раньше чем 01.07.20, то товар можно приходовать как немаркированный. Однако, лучше созвониться с поставщиком для уточнения информации по препарату.

9. Ошибка в рознице при продаже: “Позиция была снята с учета аптеки”. Пересорт.

image1

Упаковка, которую вы пытаетесь продать, была добавлена в чек ранее. Скорее всего, упаковка была отсканирована, но отдали клиенту другую упаковку. Поскольку каждая упаковка имеет уникальный код SGTIN допускать такие ошибки крайне нежелательно.

Продавать товар, по которому прошел пересорт, запрещено. Необходимо упаковку, по которой пересорт, списать с остатка. Списание будет осуществляться во время инвентаризации. На данный момент функционал по инвентаризации в разработке. Товары, по которым пересорт, нужно отложить до внедрения функционала.

10. Ошибка: “Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке”

Поставщик не сделал разагрегацию коробки. Поставщику необходимо сделать разагрегацию, после чего необходимо отправить данные повторно. Для этого нужно нажать на выпадающий список рядом с кнопкой “Отправить в ЧЗ” и нажать “Повторная отправка в ЧЗ” ( См. Рис. 4 ). Также можно просто отправить данные в ЧЗ по данной накладной по 702-й схеме.

11. Ошибка: “Операция отклонена. Некорректное состояние”

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

12. Проблема: Товар не выводится из оборота при розничной продаже.

Вывод товара из оборота осуществляется через кассовый аппарат. Данные передаются на ККМ, после ККМ отправляет их на ОФД, а они уже, в свою очередь, отправляют данные в ЧЗ. Чаще всего проблема возникает при передачи данных с ОФД в ЧЗ и товар в таком случае может длительное время быть не выведен из оборота. Сперва необходимо проверить есть ли документы розничной продажи в ЧЗ. Проверить можно в личном кабинете в разделе “Документы”. Если в ЧЗ документы присутствуют, то необходимо ожидать вывода из оборота (может затянуться до 2-х недель) либо обращаться в ОФД и выяснять почему данные не были переданы в ЧЗ. Если же документов розничной продажи в личном кабинете нет, то необходимо сразу обратится в ОФД и уточнить передаются ли к ним данные по маркированному товару. Если данные не передаются, то по данному вопросу необходимо обратиться в техническую поддержку Алгоритм-С.

13. Проблема: Маркированный товар не подсвечивается в реестре приходных накладных.

Подсветка маркированного товара в приходе возможна только при условии, что поставщик будет передавать признак маркированного товара в электронной накладной. На данный момент мы можем гарантировать подсветку маркированного товара только если вы принимаете накладные через систему заказов “СКЛИТ”. В остальных случаях подсветка будет реализована позднее. Рекомендуем на данный момент работать внимательнее с маркированным товаром.

Читайте также:  Код ошибки 0х0000005с
14. Проблема: Просканировали маркированный товар не на ту позицию.

Необходимо удалить данные на ошибочной позиции и проскарировать товар на правильной. Как удалить отсканированные упаковки вы можете посмотреть выше ( См. Рис. 2 ).

15. Проблема: Поставщик не довез одну или несколько упаковок или QR-код не читаемый(не сканируется, поврежден и т.п.)

По данным от ЧЗ если QR-код не читается на упаковке, необходимо данный товар вернуть поставщику. Поставщик в свою очередь вернет производителю для переупаковки.

Для возврата товара по которому отсутствуют QR-коды необходимо:

В накладную будут добавлены все упаковки по которым нет QR-кодов. После этого накладную можно просто отгрузить. Отправлять данные в ЧЗ не нужно.

2020 12 08 12 43 27

16. Проблема: Выбран не тот тип акцепта, накладная не должна маркироваться или необходимо удалить накладную из программы.

Для удаления привязки накладной к маркировке нужно, чтобы данные по упаковкам отсутствовали в накладной. Если данные в накладной есть, их можно удалить ( См. Рис. 2 ).

Для удаления привязки накладной к маркировке необходимо нажать правой клавишей мыши на накладной и выбрать пункт “Удалить подготовленный документ в ЧЗ”.

Для удаления признака(галочки в поле “Маркировка”) необходимо нажать правой клавишей мыши на накладной и выбрать пункт “Признак маркировки”. Повторное нажатие этой кнопки ставит признак обратно.

2020 12 08 12 52 34

17. Проблема: Товар не маркированный, но на позиции стоит признак маркировки.

2020 12 08 17 00 53

18. Проблема: Поставщик указал в электронной накладной не тот номер накладной, который нужен.

В данной ситуации необходима либо правильная накладная от поставщика, либо можно вручную менять номер накладной в программе перед отправкой в ЧЗ.

Источник

Что статус значит

«Найдены ошибки при форматной проверке» – это технический статус в системе ФСС, который, в большинстве случаев, означает наличие ошибок в поданной документации от заявителя (работодателя).

Важно! Заявления с допущенными ошибками дополнительно обрабатываются сотрудниками Фонда.

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

Если же допущена более серьезная ошибка, документы отправляются обратно, а в личном кабинете появляется статус извещение сформировано.

В более редких случаях такое оповещение указывает на технические проблемы со стороны серверов ФСС, связанные с «зависанием» системы. Именно поэтому рекомендуется подождать несколько рабочих дней, возможно все правильно и статус автоматически будет изменен на рабочий.

Важно сразу уточнить момент со сроками рассмотрения: 5 рабочих дней дается работодателю на отправку документов и 10 рабочих дней Фонду на рассмотрение и обработку данных. Сюда же можно прибавить время, которое займет денежный перевод через системе вашего банка, в среднем это 1-3 рабочих дня.

Если же ФСС обнаруживает ошибку и отправляет документы назад работодателю – сроки обнуляются и нужно отсчитывать новый цикл рассмотрения. Ускорить этот момент нельзя, поэтому вам остается только общаться со своим работодателем и решать данный вопрос лично.

Заключение

При появлении статуса «Найдены ошибки при форматной проверке» на портале ФСС, рекомендуем подождать несколько дней.

Если статус не будет меняться или появится предупреждение о формировании извещения – обратитесь к работодателю и попросите того внести изменения или исправления.

Если у вас имеются дополнительные вопросы, советы другим читателям или свои замечания – пишите их в х ниже.

Ошибки ИС МДЛП — Маркировка Фарма

При приемке операция может быть отклонена полностью, либо частично.

Если операция завершается частично, ошибку нужно исправить для кодов маркировки из текста ошибки. Список таких кодов указан внутри документа в описании ошибки.

В сервисе Контур.Маркировка Фарма отображаются ответы ИС МДЛП:

Попытка изменить состояние вложенного КиЗ

Возникает при обратном акцепте. Эта ошибка говорит о том, что вы пытаетесь принять штучный товар по коду маркировки SGTIN, который вложен в агрегат. Для решения:

Операция не может быть выполнена. Указанный контрагент отсутствует в списке доверенных контрагентов

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

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

Обработка запроса провалилась: ошибка на этапе первичной обработки документа. Неизвестная ошибка (или любая другая неизвестная ошибка)

При возникновении неизвестной ошибки пришлите на почту farma@kontur.ru письмо с информацией:

Операция не может быть выполнена. Недопустимый переход в товаропроводящей цепочке

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

КиЗ принадлежит другому участнику

Ошибка возникает, когда идентификатор текущего владельца и субъекта операции не совпадают. Для решения:

Операция не может быть выполнена. Указанный SGTIN/SSCC не найден в системе

Ошибка возникает в следующих случаях:

Сканер некорректно отсканировал код маркировки с упаковки из-за неисправности (чаще всего некорректно считывается регистр символов, то есть SGTIN содержит заглавные символы, а сканер считывает их как строчные).

Если ошибка вызвана неисправностью сканера, то она скорее всего будет повторяться неоднократно (например, в нескольких поставках или по нескольким кодам в рамках одной накладной).Для решения вопроса рекомендуем воспользоваться инструкциями на сайте Честного знака из раздела для проверки сканера.

Если ничего из вышеперечисленного не помогает, необходимо обратиться к поставщику и в ИС МДЛП для решения данной ошибки.

Указанный продавец неактивен

Ошибка возникает при попытке принять товар у субъекта с заблокированного места деятельности(МД).

Для исправления ошибки рекомендуем обратиться к поставщику и уточнить, с какого МД в ИС МДЛП производится отгрузка. После этого повторите приемку товара с указанием корректного МД.

Invalid request data: data. properties. contract_type should be equal to one of the allowed values

Ошибка означает, что при указании реквизитов накладной указан тип договора «Собственные средства» и не указан номер контракта.

Данный тип договора используется производителями и импортерами. При стандартной закупке должен быть выбран тип договора «Купля продажа».

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

Ошибка означает, что при заполнении шаблона XLSX перепутаны местами значения для столбцов «Сумма с НДС» и «Сумма НДС». Эта ошибка возникает из-за того, что сумма налога больше суммы товара с учетом этого налога.

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

Исправить значения внутри операции нельзя. Ошибочный документ рекомендуется удалить.

Хронология событий нарушена, неверно указана дата операции

Ошибка возникает, когда дата и время приемки оказывается меньше, чем дата и время операции, проводимой поставщиком перед отгрузкой (например, расформирование агрегата). Так происходит потому, что ИС МДЛП не проверяет корректность времени в отправляемом документе.

Для исправления ошибки:

Если ничего из перечисленного не помогает, то необходимо обратиться к поставщику и уточнить дату и время последней операции по этим кодам маркировки. Если это невозможно, то не принимать такой товар и просить заменить его на другой.

Возникла ошибка при отправке документа, попробуйте еще раз. Если ошибка сохраняется, обратитесь в техническую поддержку

Создание шаблона выписки по лицевым счетам

Перейдите на вкладку Шаблоны. Изначально в таблицу добавлены 8 базовых шаблонов. В них установлены наиболее распространенные параметры выписок.

Чтобы скачать пример базового шаблона типа Выписка по лицевым счетам, нажмите кнопку Скачать пример напротив шаблона с номером 2, 3, 4, или 5.

Введите Название шаблона в соответствующем поле.

В поле Выберите тип в выпадающем списке выберите пункт Выписка по лицевым счетам.

В поле Выберите формат файла в выпадающем списке выберите нужный формат файла выписки (*.txt, *.dbf, *.xls, *.xlsx, *.csv, *.y).

Загружать со строки №.Номер строки, с которой необходимо формировать фискальные документы;

Признак итоговой строки. Все строки после данного символа не будут загружены. Если система при обработке файла не найдет данный символ, на экране появится ошибка: «Загруженный файл не соответствует настройкам»;Символ-разделитель колонок. Выберите нужный символ из списка;№ поля «Дата» – номер столбца в файле, в котором указана дата совершения платежа в формате дд.мм.гггг.;№ поля «Лицевой счет« – номер столбца в файле, в котором указан номер лицевевого счета плательщика;№ поля «Сумма« – номер столбца в файле, в котором указана сумма платежа (дробная часть может быть выделена точкой или запятой).№ поля «Электронный чек» – номер столбца, в котором указаны данные для отправки электронного чека плательщику (электронный адрес или номер телефона);№ поля «Назначение платежа» – номер столбца, в котором указано назначение платежа.

Примечание: 1) Если название товара будет по умолчанию, то из всех настроек формата обязательны к заполнению только поля: Загружать со строки №, № поля «Лицевой счет« и № поля «Сумма«.

2) Если название товара будет устанавливаться самостоятельно, то из всех настроек формата обязательны к заполнению только поля: Загружать со строки № и № поля «Сумма«.

В сплывающем пункте Поставщик выберите нужного поставщика путем нажатия на него. После выбора поставщика нажмите кнопку Подтверждение.Если поставщиков нет, то Вы можете добавить поставщика, нажав на кнопку Добавить поставщика.

Более подробную информацию о создании поставщика смотерть в статье Добавление поставщика.

В сплывающем пункте Агент выберите нужного агента путем нажатия на него. После выбора агента нажмите кнопку Подтверждение.Если агентов нет, то то Вы можете добавить агента, нажав на кнопк Добавить агента.

Более подробную информацию о создании агента смотерть в статье Добавление агента.

Внимание! Добавлять можно только агентов того типа, который был указан при регистрации ККТ.

– При выборе Название товара пункт По умолчанию, для формирования наименования места расчетов в кассовом чеке будет использоваться неизменяемая часть «Оплата жилищно-коммунальных услуг по лицевому счету №» + номер лицевого счета из загруженного файла.

– Вы можете задать название для товара самостоятельно. Для этого выберите Установить самостоятельно в поле Название товара и введите название в поле ниже.

Примечание: Данное название будет автоматически подставлено для всех строк из загруженного файла. Вы сможете изменить название для каждой строки отдельно.Внимание! Если в пункте Подставлять к названию товара номер лицевого счета из выписки вы поставите галочку, по умолчанию после загрузки файла название товара будет иметь следующий вид: одинаковая часть для всех строк в файле «Оплата жилищно-коммунальных услуг по лицевому счету №« + индивидуальный номер лицевого счета из загруженного файла. – Вы можете в качестве названия товара использовать назначение платежа. В этом случае необходимо выбрать способ формирования названия: 1) Подставлять полностью значение из столбца «Назначение платежа» (Значение из столбца, номер которого был указан выше в подразделе «Настройки формата» в поле «Номер поля Назначение платежа», будет использовано в качестве названия товара. Вы сможете изменить название для каждой строки отдельно.),2) Использовать составное название: Общая часть + назначение (По умолчанию после загрузки файла название товара будет иметь следующий вид: одинаковая часть для всех строк в файле «Название товара» + индивидуальное назначение платежа из загруженного файла).

Перечень ошибок и пути их решения, которые возникают при формировании документов в ГИС

При переводе плана закупок в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: UE. Следующие идентификационные коды закупок не уникальны в пределах планов закупок, размещенных организацией xxxxxxxxxxxxxxxxxxxxxxxxxxxx»:172553500299055350100101040002120244172553500299055350100101690000000244″.

Ответ: Данная ошибка связана с тем, что в ЕИС план закупок был опубликован(изменен) напрямую в личном кабинете (далее — ЛК) ЕИС и статус контроля такого документа указан «На контроле». Необходимо чтобы финансовый орган (далее — ФО) подписал в ЛК ЕИС отрицательный результат контроля, т.е.

«Контроль не пройден», а в ГИС план закупок необходимо перевести в состояние «На доработку от ФО». Затем заказчики переводят план закупок в состояние «Редактируется», все позиции плана закупок переходят в состояние «Редактируется». Затем позиции плана закупок переводят в состояние «Ввод завершен».

План закупок необходимо перевести в состояние «На размещении» и он должен появится в ЛК ЕИС, где заказчик должен направить его на контроль в ФО.

При переводе плана закупок в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: UE. У плана закупок с реестровым номером 201703522000327001 уже присутствует более поздняя версия 1 или редакция 0».

Ответ: Данная ошибка связана с тем, что в ЕИС план закупок был изменен напрямую в ЛК ЕИС и статус контроля такого документа указан «На контроле». Необходимо чтобы финансовый орган (далее — ФО) подписал в ЛК ЕИС отрицательный результат контроля, т.е.

«Контроль не пройден», а в ГИС план закупок необходимо перевести в состояние «На доработку от ФО». Затем заказчики переводят план закупок в состояние «Редактируется», все позиции плана закупок переходят в состояние «Редактируется». Затем позиции плана закупок переводят в состояние «Ввод завершен».

Читайте также:  Коды ошибок форд мондео 4 расшифровать при самодиагностике 160782

План закупок необходимо перевести в состояние «На размещении» и он должен появится в ЛК ЕИС, где заказчик должен направить его на контроль в ФО.

При переводе плана закупок в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: UE. Объект с внешним идентификатором krista.52000000.0.703914 уже существует на ООС для организации с кодом СПЗ 03523000344».

Ответ: Данная ошибка связана с тем, что в ЕИС план закупок был заведен напрямую в ЛК ЕИС и статус контроля такого документа указан «На контроле». Необходимо чтобы финансовый орган (далее — ФО) подписал в ЛК ЕИС отрицательный результат контроля, т.е.

«Контроль не пройден», а в ГИС план закупок необходимо перевести в состояние «На доработку от ФО». Затем заказчики переводят план закупок в состояние «Редактируется», все позиции плана закупок переходят в состояние «Редактируется». Затем позиции плана закупок переводят в состояние «Ввод завершен».

План закупок необходимо перевести в состояние «На размещении» и он должен появится в ЛК ЕИС, где заказчик должен направить его на контроль в ФО.

При переводе плана-графика в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: UE. Следующий номер версии плана-графика с номером 2017036820000850020001 должен быть 4».

Ответ: Данная ошибка связана с тем, что в ЕИС изменения в план-график были внесены напрямую в ЛК ЕИС и статус контроля такого документа указан «На контроле». Необходимо чтобы финансовый орган (далее — ФО) подписал в ЛК ЕИС отрицательный результат контроля, т.е.

«Контроль не пройден», а в ГИС план-график необходимо перевести в состояние «Редактируется», все позиции плана-графика переходят в состояние «Редактируется». Затем позиции плана-графика переводят в состояние «Ввод завершен». В плане-графике в поле «Номер версии» необходимо указать номер версии.

Затем план-график необходимо перевести в состояние «На размещении» и он должен появится в ЛК ЕИС, где заказчик должен направить его на контроль в ФО.

Вопрос 5. При переводе плана-графика(изменения плана-графика) в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: UE.

Непредвиденная ошибка в интеграционном адаптере РПГ java.lang.NullPointerException at ru.lanit.fz44.validation.rpg.impl.PlanGraphValidatorImpl$2.validate(PlanGraphValidatorImpl.java:152) at ru.lanit.fz44.validation.rpg.impl.PlanGraphValidatorImpl$2.validate(PlanGraphValidatorImpl.java:105) at ru.lanit.fz44.validation.rpg.impl.ValidationFacadeImpl.

validateForPublish(ValidationFacadeImpl.java:58) at ru.lanit.fz44.ejb.validation.rpg.impl.PlanGraphValidationBean.validateForPublish(PlanGraphValidationBean.java:57) at ru.lanit.fz44.ejb.validation.rpg.api.EJSRemote0SLplanGraphValidationBean_35ef598a.validateForPublish(EJSRemote0SLplanGraphValidationBean_35ef598a.java) at sun.reflect.NativeMethodAccessorImpl.

invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:611) at com.ibm.CORBA.iiop.ClientDelegate$3.run(ClientDelegate.java:1190) at java.security.AccessController.doPrivileged(AccessController.

java:338) at com.ibm.CORBA.iiop.ClientDelegate.invoke0(ClientDelegate.java:1187) at com.ibm.CORBA.iiop.ClientDelegate$ClientDelegate0.invoke(ClientDelegate.java:1424) at com.sun.proxy.$Proxy195.validateForPublish(Unknown Source) at ru.lanit.fz44.ejb.validation.rpg.api._PlanGraphValidation_Stub.validateForPublish(_PlanGraphValidation_Stub.java) at ru.lanit.fz44.ejb.service.rpg.

business_transaction.UnitOfWorkIntegration.validate(UnitOfWorkIntegration.java:56) at ru.lanit.fz44.ejb.facade.rpg.integration.impl.IntegrationSaveServiceBean.saveAndPublishPlanGraph(IntegrationSaveServiceBean.java:64) at sun.reflect.GeneratedMethodAccessor1395.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.

reflect.Method.invoke(Method.java:611) at com.ibm.ejs.container.EJSContainer.invokeProceed(EJSContainer.java:5882) at co».

Ответ: Данная ошибка связана с ошибками приема файлов со стороны ЕИС. ЕИС должен устранить данную проблему. Пробуйте периодически отправлять план-график. Если данная ошибка не устранена, то необходимо написать в ТП ЕИС о данной проблеме.

Вопрос 6. После прохождения финансового контроля по п.5 ст.

99 44-ФЗ ФО переводит документа в состояние«Согласовано ФО», но через некоторое время документ переходит в состояние «В работе ФО» и возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: Непредвиденная ошибка в интеграционном адаптере Бюджетного контроля.

В ЛК органа контроля не найден контролируемый документ в статусе «На контроле» с идентификатором, равным значению поля «Внешний идентификатор документа, направленного на контроль» (refExternalId) 689243 или значению поля «Идентификатор документа, направленного на контроль» (refId) 313658».

Ответ: До ЛК ЕИС не доходит результат контроля. Если документ будет размещен в ЕИС, то такие документы будут переведены в состояние «Утвержден» автоматически на следующий день после публикации. Ошибка со стороны ЕИС.

3. Определение поставщика (подрядчика, исполнителя)

При формировании изменений по закупкам, кроме закупок по единственному поставщику(подрядчику, исполнителю) и переводе в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Некорректные данные; Описание: IDE.

Поскольку извещение в ЕИС находится в статусе Контроль не пройден изменения извещения на ЕИС ожидаются с тем же номером изменения 1, что и номер изменения в ранее принятом извещении. Уровень ошибки: error; Ошибка: Некорректные данные; Описание: IDE. Для требования Заказчика с кодом по СПЗ 03523000034 сведения о связи с планом-графиком не могут быть изменены».

Ответ: Данная ошибка связана с ошибками приема файлов со стороны ЕИС. ЕИС должен устранить данную проблему. Пробуйте периодически отправлять изменения в закупку. Если данная ошибка не устранена, то необходимо написать в ТП ЕИС о данной проблеме.

При формировании изменений по закупкам, кроме закупок по единственному поставщику(подрядчику, исполнителю) и переводе в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Некорректные данные; Описание: IDE.

Для требования Заказчика с кодом по СПЗ 03523001838 сведения о связи с планом-графиком не могут быть изменены».

Ответ: Данная ошибка связана с ошибками приема файлов со стороны ЕИС. ЕИС должен устранить данную проблему. Пробуйте периодически отправлять изменения в закупку. Если данная ошибка не устранена, то необходимо написать в ТП ЕИС о данной проблеме.

При формировании извещения по закупкам и переводе в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Некорректные данные; Описание: IDE.

Текущее значение статуса извещения (изменения извещения) — «Контроль не пройден». Размещение извещения (изменения извещения) может выполняться, только если статус извещения (изменения извещения) равен Формирование извещения, Формирование изменения извещения, Согласовано УО, На согласовании УО».

Ответ: Необходимо данный документ удалить и сформировать заново извещение о закупке и отправить в ЛК ЕИС.

4. Сведения о контракте (его изменении)

При переводе первичных сведений о контракте в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: Непредвиденная ошибка в интеграционном адаптере РГК. У организации-заказчика уже существует контракт с таким же номером с поставщиками Открытое акционерное общество «ОмскВодоканал», не находящийся в статусе «Исполнение прекращено»».

Ответ: Необходимо проверить существуют ли такие первичные сведения о контракте (его изменении) в ЛК ЕИС. Если данные сведения отсутствуют в ЛК ЕИС, то с данной ошибкой необходимо обращаться в ТП ЕИС.

При переводе первичных сведений о контракте в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: UE. Для юридических лиц не может быть указан код ОКОПФ соответствующий значению «Индивидуальный предприниматель». Информацию об индивидуальном предпринимателе необходимо указывать как для физических лиц».

Ответ: Необходимо проверить поле ОКОПФ в ГИС в справочнике «Контрагенты»/»Физические лица». Если данное поле заполнено(не заполнено) не корректно, то необходимо поправить значение в данном поле и повторить выгрузку в ЕИС.

При переводе первичных сведений о контракте в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: Непредвиденная ошибка в интеграционном адаптере РГК. В ЕИС уже существует проект контракта с внешним идентификатором документа externalID krista.52000000.0.717891 и кодом организации заказчика по СПЗ 03522000235.».

Ответ: Первичные сведения были отправлены успешно в ЛК ЕИС, но затем ФО провел контроль в ГИС и контроль в ГИС «Не пройден». Затем ФО перевел сведения о контракте в состояние «На доработку от ФО», но результат контроля, по техническим причинам со стороны ЕИС, не пришел в ЛК ФО.

Такие сведения о контракт находятся в ЛК заказчика в состоянии «На контроле». Чтобы повторить повторную выгрузку сведений о контракте из ГИС в ЕИС необходимо чтобы сведения о контракте, которые находятся в ЛК ЕИС ФО сменил статус контроля в «Контроль не пройден».

Затем повторить экспорт сведений из ГИС в ЕИС.

При переводе измененных сведений о контракте в состояние «На размещении» документ отправляется в личный кабинет ЕИС, но через некоторое время возвращается с ошибкой вида: «Документ не загружен на ООС из за ошибок: Уровень ошибки: error; Ошибка: Непредвиденная ошибка в ходе обработки; Описание: Непредвиденная ошибка в интеграционном адаптере РГК. Поскольку документ в ЕИС находится в статусе На контроле, изменения документа в ЕИС не принимаются.».

Ответ: Измененные сведения были отправлены успешно в ЛК ЕИС, но затем ФО провел контроль в ГИС и контроль в ГИС «Не пройден». Затем ФО перевел сведения о контракте в состояние «На доработку от ФО», но результат контроля, по техническим причинам со стороны, не пришел в ЛК ФО.

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

результат контроля не экспортируется из ГИС. Ошибка на данный момент не устранена.

Ответ: Ошибка означает, что в первичной версии контракта в поле «Состояние бюджетных обязательств» указано «На согласовании ФО» и сведения присутствуют в программе АС Бюджет.

Изменения в сведения о контракте возможно отправлять в ЕИС (АС Бюджет) только в 2-х случаях: 1. Если в поле «Состояние бюджетных обязательств» указано значение «Приняты» или 2.

Если в поле «Состояние бюджетных обязательств» указано значение «Отклонены».

Уведомительный режим работы с маркированным товаром

В связи с новыми рекомендациями Честного знака
по уведомительному режиму работы в системе маркировки,
в программу Фарм-ревизор добавлено подтверждение поступившего маркированного товара с помощью схемы 702 –
Оприходование и возможность реализации маркированных товаров, не дожидаясь ответа от Честного знака.

Использование операции Оприходование (схема 702) для уведомительного режима при поступлении маркированных товаров

Схему 702 – Оприходование можно использовать:

  • при оформлении поступления нового маркированного товара;
  • для подтверждения ранее поступившего, но все еще не подтвержденного поставщиком товара;
  • уже проданного, но все еще не подтвержденного маркированного товара;
  • в случае возникновения ошибок при приемке.

Статусы упаковок при использовании 702 схемы

Например, в аптеку поступил маркированный товар, подтвердить его в честном знаке не удалось из-за ошибки или
отсутствия ответа. Для маркированных товаров был вручную установлен статус Отправлен.
Затем часть товара была продана (статус таких товаров изменился на Выбыл – не подтвержден).
После успешной отправки в Частный знак схемы 702, будут подтверждены все эти товары.
Упаковкам со статусами Не подтвержден и Отправлен будет присвоен статус
Подтвержден. Упаковкам со статусом Выбыл – не подтвержден будет присвоен
статус Выбыл. Таким образом, операцию по оприходованию можно использовать даже для
подтверждения уже проданных, но ранее не подтвержденных упаковок.

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


         Использование Документа 702  для подтверждения вторичных упаковок

  1. В приходной накладной перейдите на закладку Упаковки. Если оформляется поступление нового товара, то с помощью сканера внесите сведения о поступившем маркированном товаре. Если вы хотите подтвердить ранее поступавший товар со статусами Не подтвержден, Отправлен, перейдите к следующему пункту.
  2. Нажмите на кнопку Не смогли связать цепочку поставок со штрих-кодом. В появившемся меню выберите: Выгрузить: Оприходование (702).
    В честный знак будут отправлены сведения обо всех ранее не обработанных маркированных упаковках из накладной. После успешного получения ответа от Честного знака статус упаковок изменится на Подтвержден для ранее неподтвержденных упаковок и на Выбыл для уже проданных упаковок. Больше никаких действий по подтверждению поступившего маркированного товара выполнять не нужно.

Уведомительный режим при поступлении третичных (транспортных) упаковок.

  1. В приходной накладной перейдите на закладку Третичные. Внесите сведения обо всех транспортных упаковках. Как это сделать подробно написано в
    инструкции по поступлению третичных упаковок с маркированным товаром в аптеку.
  2. Нажмите на кнопку Не смогли связать цепочку поставок со штрих-кодом. В появившемся меню выберите: Выгрузить: Оприходование (702).
    В честный знак будут отправлены сведения обо всех ранее не подтвержденных третичных упаковках из накладной. После успешного получения ответа от Честного знака статус упаковок изменится. Упаковкам со статусами Не подтвержден, Отправлен будет присвоен статус Подтвержден. Аналогичные статусы будут присвоены всем вторичным упаковкам, которые находились внутри транспортных упаковок.
  3. Разагрегируйте транспортную упаковку. Как это сделать подробно написано в той же инструкции по поступлению третичных упаковокБ.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *