Типовая конфигурация УНФ, файловый вариант, операционная система Windows Server 2008 R2, платформа 1с 8. 1489, обмен с Ветис работает!
Делаю выгрузку этой базы и загружаю в SQL Server 2008 на этом же компьютере – обмен с Ветис не работает. При проверке подключения Ветис выходи ошибка –
Загружаю эту базу в SQL Server 2008 на другом компьютере (операционная система Windows 10, платформа 1С 8. 1489) – обмен Ветис работает!
Буду признателен за помощь.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку “Обновить” в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно. Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Если вы только что вошли в систему и получили 401 Несанкционированную ошибку, это означает, что введенные учетные данные по какой-либо причине были недействительными.
401 Неавторизованные сообщения об ошибках часто настраиваются на каждом веб-сайте, особенно очень больших,
поэтому имейте в виду, что эта ошибка может проявляться больше, чем остальные общие:
Ошибка 401 Unauthorized отображается в окне интернет-браузера, как это делают веб-страницы.
Проверьте наличие ошибок в URL. Возможно, что ошибка 401 Unauthorized возникла из-за неправильного ввода URL-адреса или ссылки, на которую было нажата точка с неправильным URL-адресом – только для авторизованных пользователей.
Если вы уверены, что страница, которую вы пытаетесь открыть, не нуждается в авторизации, сообщение об ошибке 401 Unauthorized может быть ошибкой. В этот момент, вероятно, лучше всего связаться с веб-мастером или другим контактом на веб-сайте и сообщить им о проблеме.
Ошибка 401 Unauthorized также может появиться сразу после входа в систему, что свидетельствует о том, что веб-сайт получил ваше имя пользователя и пароль, но обнаружил, что что-то в них недействительно (например, ваш пароль неверен). Следите за тем, какой процесс на веб-сайте существует, чтобы восстановить доступ к их системе.
Ошибки, похожие на 401 Несанкционированную
Следующие сообщения также являются ошибками на стороне клиента и поэтому связаны с 401 несанкционированной ошибкой: 400 Bad Request, 403 Forbidden, 404 Not Found и 408 Timeout.
Причина №1. Не указан идентификатор сессии (X-SBISSessionID) в HTTP-заголовке запроса
Пример неверного запроса (идентификатор сессии отсутствует)
Причина №2. Идентификатор сессии (X-SBISSessionID) в HTTP-заголовке запроса устарел
Идентификатор может устареть из-за большого периода неактивности (отсутствия вызовов) или после окончания регламентных работ на сайте СБИС.
Ошибка — в указании кодировки UTF-8. При этом, в JSON части запроса используется кодировка Win-1251. По тексту запроса это невозможно определить.
Причина №3. В запросе указан неверный адрес
Укажите правильный адрес в запросе.
Пример ответа на неправильный запрос
Нашли неточность? Выделите текст с ошибкой и нажмите ctrl + enter.
Ветис уже скоро. А что-то вокруг тишина. В программах даже что-то появилось, а на ИТС ни одной инструкции. Все ждут? или может кто-то что-нибудь делает для подготовки?
Походу у них действительно сломался метод. Теперь если UUID в базе есть, то отдает всё по формату, с кодом ответа 200, если UUID нет, то получаем код ответа 500, и внутреннюю ошибку сервера.
Они что-ли все старые тикеты порезали в базе?
хмм. я, честно говоря, никогда и не рассчитывал на то что тикеты будут храниться сколько-то долгое время. Это же невероятный объем мусора. Кому надо – перезапросят.
(909) Как можно перезапросить?
У тебя при создании транспортной ВСД дается тикет. Потом по тикету ты получешь GUID ВСД. Если тикет удален, как ты теперь ссылку на ВСД получишь? Еще одну ВСД выписать?
(910) я постоянно мониторю ответы по тикетам и записываю данные сразу как ответ положительный, после чего тикет мне не нужен.
(911) А у меня получает номер ВСД в момент печати по тикету, и нигде он не сохраняется. Конечно допишу чтоб сохраняла, но честно говоря я не понимаю как продукт в таком состоянии можно было запускать в продуктив в масштабах страны.
(912) так они просто xml валидируют, поэтому (905) и не проходит
(915) тут согласен
(912) ошибка 500 это ошибка веб-сервера, которая не определена явно другими 5ХХ ошибками. Похоже что они пихнули туда результаты валидации XML, который им приходит в SOAP-пакетах. Собственно, я не вижу причин почему так делать нельзя.
(917) Потому что так делать не принято. Это соответствует их описанию, но так не делают.
(913) я сохраняю UUIDы ВСД. Привязываю их к накладной. Это статическая штука, я думаю что они будут храниться по крайней мере до тех пор, пока существует партия. Что касаемо тикетов – то это та фигня, которая отдается после submitApplicationRequest? Я правильно понял? Тогда я бы не рассчитывал на то что это будет доступно долго.
(919) Теперь и я сохраняю. А все старые похерены.
как думается мне, их нужно передавать в некое фоновое задание, которое будет немедленно добиваться по ним ответа. Как только ответ есть – данные записываются в базу, тикет уничтожается. есть очередь тикетов, в хвост пристраиваются новые, а голова постоянно очищается путем получения ответов. Как-то так. При завершении программы юзер должен дожидаться чтобы все тикеты были отработаны, иначе ругаться громко и матом – ибо по факту это будет означать что результаты выполнения всех необработанных заявок будут утеряны.
это я про тикеты. А UUIDы я сохранял изначально. Помимо UUIDов, я подбираю из веток еще кое-какое барахлишко для локальной печати веток (без участия Меркурия).
(921) Зачем? У меня и так всё отлично работает. Я их в любом случае получаю в момент печати. Без него же не распечатать. Теперь как получил буду сохранять. (922) И тикеты в любом случае нужно сохранять, если ассинхрон как у меня. Конечно сохраняются.
Короче в итоге вернул обратно – код 500 у меня опять равносилен либо пустому запросу, либо REJECTED. Даже не разбираю его. Что конечно-же неправильно.
Вопрос. “Зелененькую машинку” кто-нибудь на API реализовывал? Т. возможно ли API двойкой как-нибудь получить все непогашенные входящие? Пока приходит в голову только getVetDocumentListChangesRequest за ближайшие несколько дней и ручками отобрать из массива непогашенные. Но это какое-то извращение.
Похоже, что ответ на мой вопрос кроется в версии API 2. Чует мое сердце, что надо переползать.
По (925) вопрос снят, разобрался
(927) Интересная встреча. Но это только десяток крупнейших производителей и сетей. Каждый из которых вбухал по 100 млн. руб и имеет процент гашения на уровне 30% – 70%. А каково остальным сотням тысяч предприятий. И что будет с системой Меркурий, когда эти предприятия начнут активно работать.
Лично у нас распределительный центр на 50 магазинов. На сегодняшний день мы получаем только на 10% продукции входящие ВСД, и изготовляем 0% исходящих ВСД
(927) Магнит в касте избранных? Похоже из 80 серверов – половина у них. Имхо, нечестная конкуренция и попытка задавить частные сети. Власов всех затыкал, когда разговор заходил не в то русло, а им минут 10 дал поболтать совсем не по-делу. И да, все кругом идиоты, а у них все шикарно без ошибок.
(931) Вот что животворящий выкуп акций ВТБ делает! 🙂
(931) вы думаете они х5 задавят.
Я не понял. оборудование меркурия на площадках магнита или на их серверах крутится? или все это магнит задумал
(933) там странная история. Вы статистику смотрели? Магнит обрабатывает четверть всего трафика ВСД. А Х5 – несколько процентов.
(934) обрабатывает или использует ВСД?
(936) Элементарно. Это их распредцентры генерят.
Поставщики отдают товар не по магазинам а на РЦ, у х5 РЦ меньший траффик видимо.
а ВСД формировать то надо от РЦ в магазин. перевозка хоть и без смены владельца.
(937) Видимо, у x5 прямых поставок в магазины больше, чем у Магнита.
(937) да, точняк. Но тогда тем более интересно, почему такое различие между Х5 и Тандером. Тандер раньше начал, да. Они требовали ЭВСД еще в середине прошлого года. (938) Не исключено. Х5 загонять своих поставщиков на РЦ в обязательном порядке стали не так давно как Тандер.
(938) видимо
(939) судя по моим знакомым. тандер стал еще с июня требовать ВСД. с чего. не все возможно в РЦ загнать. У Магнита кстати логистика построена видимо через РЦ. более. чтобы не отвлекать народ в магазинах на поставки. да и поставка на РЦ всегда цена ниже. чем поставщик развозит по магазинам. и у Тандера остается больше бабла.
У Магнита может быть куча распределительных центров, куча магазинов, все от разных юр. лиц. При этом гасить ВСД магазины не могут чисто физически. Получается ситуация как у нас. Распределительный склад + 50 магазинов должны генерить 10 млн. ВСД в год. При количестве номенклатуры 1000 позиций. А у сетей и магазинов и позиций поболее. Поэтому для крупных сетей количество ВСД может достигать мрлд. в год. Не завидую я им
(941) если прибавить еще алкоголь. то Ит трафик у магазина огого
(933) Я думаю, либо они часть серверов сами купили и поставили Россельхозу под Меркурий под свои нужды, либо пришла директива выделить им сервера чисто под них. Иначе ситуация когда никто не может получить ВСД, а у них все хорошо – выглядит странной.
(943) ну да. Причем если Галицкий еще мог заупрямиться, то теперь-то там зеленая улица. Скажут – сделают.
Либо они сами не понимают в какой ж-пе находятся.
(943) ну это да. что-то тут явно не так
для компаний у кого РЦ тут ве проще. Им не надо в одночасье выплевывать всд в магазины. главное чтобы в РЦ пришло все с ВДС. А далее они оформят когда будет свободно.
Это если поставщик в магазин приводит должно быть уже ВСД. а для своих то поставок такой спешки явно нет. и авто едет из РЦ порой сутки. всегда есть время.
А вот компании которые не на РЦ везут из за того. чо свой сбыт и до РЦ дальше чем до магазина. вот тут уже засада
(947) Больше всех производители страдают, как собственно обычно.
(948) производителю до РЦ тоже не проблема сделать. хоть в ручную.
а вот если у производителя свой распределенный сбыт. тут вот уже проблема
(949) Между площадками при производстве ничего не перевезешь толком. Через дорогу перевезти – тоже нужно ВСД выписать.
(950) знаю. у нас 3 завода 2-4 км друг от друга. и все 3 находятся в разных раонных ветслужбах.
У меня сейчас Ветис умер. При этом умер он на функции getProductByGuid. Это основополагающая функция. Если она умирает, тогда останавливается весь Ветис. При этом умирал он медленно. Сначала умерла функция getProductByGuid, а через несколько минут – Ветис
(952) У меня если продукт не может получить по guid-у (а проверяет active обязательно, ибо выводят из базы продукцию), тогда инвентаризация, и отгрузка по ТНВЭД (третьему уровню). Ничего не останавливается.
И, кстати, только что делал большую ВСД на 41 позицию – всё нормально, ушло с гуидами. Значит getProductByGuid работает.
Как на неё реагировать? Это в ответ на запрос по тикету.
(954) Похоже, что у них в разных регионах разные сервера, и балансировка нагрузки не очень работает.
(955) Вроде позавчера 12 было. Чет новое?
По поводу getProductByGuid ошибочка у меня вышла. Оказывается что
Родитель второго уровня это GetProductByGuid
Родитель третьего уровня это это GetSubProductByGuid
И если по GUID элемент не найден, тогда возвращается код ошибки 500 – сервис не доступен.
(957) Да. Причем ночью опять всё штатно отработало. Буду писать список кодов при которых нужно пытаться перевыписать ВСД (ошибка со стороны меркурия), и список с которыми нужно разбираться.
Часть накладных не уехало, потому что по непонятной причине не дало выписать от имени уполномоченного сотрудника, с ошибкой
“MERC02386” Данная транзакция не может быть оформлена, так как роль пользователя не позволяет оформлять ВСД
ПО ТНВЭД
d99981f8-b4a3-4d13-867c-01ed252edb1b
желированные продукты из мяса и субпродуктов (1602)
Это продукция прошедшая термообработку, из 646 приказа.
(960) Назначение какое указали?
(961) Как и все остальные. Реализация в пищу людям
(960) Это была ошибка в меркурии, вроде по нашему обращению поправили. Действительно под этим ТНВЭД уполномоченным не давала выписывать. Завтра проверим.
Что-то ветка затихла. Насчет APLM20001 – битые площадки. Вывели полный список – у нас их сотни. И оказалось что проблема решаемая, сотрудником РСХН с достаточными правами. Чтоб решить проблему нужно изменить что-либо в площадке и пересохранить. GUID площадки при этом не меняется. Единственная проблема в правах.
(964) очевидно, все как-то приноровились и работают.
(966) та ладно, с чего такой пессимизм. Оно уже не раз обновлялось и не десять, а ложилось в редких случаях
вот про лабораторные исследования надо уточнить. По-моему, я при запросе партий это дело проверяю, но я работаю через getStockEntryList, не через Changes. Так что меня коснуться не должно
Кстати, рекомендую почитать список обновлений уважаемому NSSerg. Там первое обновление как раз по его душу – появилась возможность указывать иностранное предприятие-поставщика без указания его GUID для входящей партии.
(965) У нас на такие площадки в день сотни ВСД, выписать на них невозможно в принципе. Эти площадки не выбираются в меркурии, через API на них не сделать ни регионализацию, ни транспортную ВСД. (969) Мы закачали справочник иностранных площадок, и во всех товарах проставили площадку производителя. Хотя ИМХО почему бы этот справочник просто не выложить? Почему РСХН его не выкладывает? Там по каждой стране всего лишь несколько сотен площадок. Все наши площадки там есть.
(971) нет. У меня тот же вопрос, но походу нет, у тебя вместе с ошибкой возвращается её текстовое описание.
(971) так вроде в BusinessError возвращаются текстовые описания. Или у вас провайдер, а не API?
У меня в IncomingOperation – оформление входящей партии возвращает только КодОшибки.
Кто нибудь сталкивался с такой ошибкой. MERC14023 В сведениях о принимаемой партии указана устаревшая версии записи вида продукции наименовании продукции. Что то я не вижу способа обойти эту ошибку по API
В справке написано “В запросе для номенклатуры продукции указан идентификатор устаревшей версии записи реестра РСХН” и как это перевести на русский язык?
(975) это значит продукция выведена из реестра РСХН?
Через WEB Я погасил эту ВСД. Где-то проскакивало, что в Меркурии утверждают, что такую ВСД можно погасить только через WEB интерфейс
Через API не смог, хотя продукция полностью обновлена.
(975)(976)(977) скорее всего это означает, что в запросе для продукции указали UUID продукции, а не GUID, и этот UUID является идентификатором непоследней версии продукции. Я не Ванга, но думаю, что произошло следующее: ваши контрики выписали ВСД, используя последний на тот момент UUID продукции. А потом, пока ВСД летел к вам, что-то подправили в справочнике для этой номенклатуры – название там поменяли или еще чего, может, просто ОК нажали. В результате для соответствующего GUID номенклатуры образовалась новая последняя версия с новым UUID, а тот UUID, который был в ВСД – стал неактуальным. Чтобы это полечить, наверно, нужно при приемке либо сменить UUID на последний, либо очистить его и заполнить GUID.
Кстати! Ща скажу важную вещь, на которую напоролся. Если для какой-то версионной сущности в запросе заполнен и GUID, и UUID, приоритет у UUID! Так что если не хотите ловить ошибки с устаревшей версией, не пользуйтесь UUID без крайней необходимости.
В конфигурацию Розница (2. 19) добавили работу с Меркурием, кто уже тестил?
Конечно функционал только для подписчиков ИТС.
И в УТ11 не в курсе когда?
+ (979) чтобы было более понятно, как это работает, надо понимать, как работает механизм Versioning Entity в Ветис. АПИ. Грубо говоря, каждая номенклатура это связный список элементов, каждый из которых содержит GUID и UUID. GUID уникален для каждого элемента справочника номенклатуры, это типа как код в справочнике 1С. А UUID уникален для каждого элемента списка. Когда создается новый элемент номенклатуры, в списке создается первый элемент. Первая версия. Она активна и не содержит ссылок на предыдущие и следующие элементы. Потом решили ее подправить. Создается второй элемент списка, ссылающийся на первый. GUID у него тот же, а UUID уже другой. И теперь уже второй элемент активен, а первый нет. Второй ссылается на первый, первый на второй. Если запустили процедуру удаления – признак активности у последнего элемента снимается, т. все элементы в списке тупо неактивные, а физически ничего не удалилось. Старые документы могут ссылаться на неактивные версии номенклатуры, а новые нет – будет вот эта самая ваша ошибка с устаревшей версией. Как-то так это все работает.
У вас ВЕТИС у НАС ВС внедряют. Виртуальный склад. Скоро будут следить за всеми движениями товаров (((
(983) у нас каждый день несколько Guid ( а не uuid) становятся неактуальными.
(985) Т. вы уверены что используете GUID в запросе, но получаете ошибку неактуальной версии? Тогда, возможно, в цепочке вообще нет актуальных, т. номенклатура “удалена” хозсубъектом который ее завел.
И надо проверить (981) – если вдруг вышло так что указали и GUID и UUID, то используется UUID
(982) В УТ 11 уже давно. Вот только у меркурия пока проблемы с APLM0012
(988) У нас уже нет APLM0012. Эта ошибка на 80% проблема разработчиков интеграционных решений и на 20% Меркурия.
(988) Понятно, скоро знакомые колбасники с УТ11 начнут доставать по интеграции.
(989) по-моему, все в точности наоборот. Проблемы с перегрузками связана с тем, что изначально разработчики меркурия сделали сверхтяжелые запросы вроде получения всех ветеринарок или всех партий практически без фильтрации или с минимальной. И когда все разработчики начали это себе выкачивать ввиду того, что у них просто не было других вариантов – все вполне ожидаемо прилегло отдохнуть. Лично мне это было очевидно еще в 2016 году, что так оно и будет.
то же самое, кстати, подтвердил Власов на встрече с представителями бизнеса. И сейчас (конкретно в сегодняшнем обновлении) они уже пытаются повыкинуть из ответов часть данных, чтобы хотя бы снизить нагрузку на сеть.
(989) Как вы решили вопрос с получением входящих документов без запросов списков?
(993) Корректно сделали таймауты. Запрос на получение списка вет сертификатов. Цикл с таймоутом 120 сек и задержкой между запросами 10 сек. Прерываемся только если COMPLETED. На все остальные ошибки не смотрим. Получение ответа на запрос. Цикл с таймоутом 120 сек и задержкой между запросами 3 сек. Прерываемся только если COMPLETED ИЛИ REJECTED. На все остальные ошибки не смотрим. Где то так примерно. Не могу посмотреть точно. Проблем с получением списка сертитификатов имеем если на протяжении 120 сек не смогли отправить запрос на получение. Но это происходит когда Меркурий совсем висит.
(994) Ну хорошо, обошли. А вы сами как считаете, ожидания не в миллисекундах, а в десятках секунд для продуктивной системы уровня не много не мало федеральной – это вообще как? Я тут даже слово “нормально” не употребляю, потому что по-моему, это вообще за гранью добра и зла. И кто в этом виноват, интеграторы?
Не так страшен черт. У нас гашение входящих ВСД 1 машины занимает 30 секунд. Не очень много. Если взять распределительный склад уровня Метро, то у них не более 1000 машин в сутки. Вполне могут работать. Интеграционное решение должно быть нормальным.
Не случайно же на совещании по итогам первой недели работы был сделан вывод, что если Меркурий не висит мертво, то работать можно.
Мы не производители, поэтому продукцию не заводим, а получаем из входящих ВСД. Ставим только соответствие между продукцией меркурия и нашей номенклатурой. Входящие ВСД можно получать в регламентном задании.
(998) у нас после отмены молочки осталось 10000 ВСД транспортных в сутки, по бизнес-процессу они должны выписываться за полтора часа. То есть это нормально, что внедрение электронной сертификации взамен бумажной ухудшило процессы у дистрибьютеров? Я так не думаю. ИМХО это неудовлетворительно.
(999) есно исходящих