Сообщения, отправленные пользователем: ANIT

Владимир Игнатов wrote:
Да. Пригодицца! На самом деле, во-первых, моя база сильно быстрее отрабатывает, чем шлюз, а во-вторых, "архив" нужен для генерации документов прошлых периодов. Иногда иметь его - полезно.

А вы вообще учли, что помимо всех российских предприятий, там еще целый список всех мировых производителей чья подконтрольная продукция проходит через нашу границу? А еще всякие ИПшники, физ.лица, розничные магазины всей страны и т.д. Вы потом актуализировать весь этот зоопарк как собрались? Что у вас там за СУБД чтоб это все хранить.

после обеда гляну что там в продуктиве, через пару часиков отпишусь. Я на тесте смотрела, тоже всё гуд.

впринципе все нормально отрабатывает, мне результат вернул. Может опечатка какая или проблема была временная? wsdl точно свежий берете?
И где проблема? в продуктиве или в тесте?

Vladimir2017 wrote:На пример с сайта:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2" xmlns:bs="http://api.vetrf.ru/schema/cdm/base" xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2"> <soapenv:Header/> <soapenv:Body> <ws:getProductItemChangesListRequest> <bs:listOptions> <bs:count>3</bs:count> <bs:offset>0</bs:offset> </bs:listOptions> <bs:updateDateInterval> <bs:beginDate>2017-09-19T00:00:00</bs:beginDate> <bs:endDate>2017-10-19T00:00:00</bs:endDate> </bs:updateDateInterval> </ws:getProductItemChangesListRequest> </soapenv:Body> </soapenv:Envelope>
Приходит такой ответ
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <v2:getProductItemChangesListResponse xmlns:bs="http://api.vetrf.ru/schema/cdm/base" xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2" xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2"/> </soap:Body> </soapenv:Envelope>

Поскольку пример с сайта, полагаю что все-таки что-то сломалось в Ветисе, но есть сомнения. У кого-нибуть используется эта функция?

Тут один ключевой вопрос
<bs:updateDateInterval>
<bs:beginDate>2017-09-19T00:00:00</bs:beginDate>
<bs:endDate>2017-10-19T00:00:00</bs:endDate>
</bs:updateDateInterval>
Вы с сентября по октябрь обновляли (добавляли) какие-нибудь значения в справочник Наименований продукции?
И где в вашем запросе собственно указан производитель, чью номенклатуру вы собрались получать? где поля businessEntity и enterprise?

если вопрос для Вас еще актуален, перенаправьте его в ветку Меркурий. Эта ветка форума была создана для техподдержки в вопросах интеграции, но по факту она мертвая как с пол года год.

mevgenym wrote:это ведь очень удобно - по гуид можно искать любой операцией

Вопрос не в том что по ГУИД искать любой операцией, а вопрос, что поиск по UUID сломался после первой же ошибки. Искал себе нормальненько, переслали ему GUID вместо UUID и всё, не работает больше поиск по UUID при передаче UUID.

"Если в Google написать Google то можно сломать интернет"©
В ходе отладки кода в 1С, наткнулась на любопытную штуку, которая сломала мне мозг на день. Оказалось дело не в 1С, а в сервере Меркурия.
Тестился блок записи ошибок в журнал регистрации. На тестовом сервере намеренно был отправлен некорректный запрос, а именно при вызове функции ПолучитьСтрануПоГУИДУ (getCountryByGuid) был передан UUID одного из элемента, а именно КНДР. Сервис благополучно возвратил ошибку в части того, что такая страна не найдена. ОК. После был запущен корректный запрос, тот же UUID но операция GetCountryByUUID. Каково же было удивление, когда и тут упорно система возвращала ошибку.

ОК. Проводим другой эксперимент подсовываем UUID другой страны, вызываем GetCountryByUUID, УСПЕШНО возвращает нужный элемент. НЕ МЕНЯЕМ UUID и вызываем getCountryByGuid передав его в качестве параметра.

ВОЗВРАЩАЕТ ЭЛЕМЕНТ, хотя должен был вывалиться по ошибке.

Перелопатила 1С вдоль и поперек. Добралась до SOAP_UI. И вот он результат:

------------------------------------------------------------------------
Запрос:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2" xmlns:base="http://api.vetrf.ru/schema/cdm/base">
<soapenv:Header/>
<soapenv:Body>
<v2:getCountryByUuidRequest>
<base:uuid>1f52fd35-5ee5-ecb3-b23c-2bf3897de0c0</base:uuid>
</v2:getCountryByUuidRequest>
</soapenv:Body>
</soapenv:Envelope>

Ответ:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<SOAP-ENV:Body xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Fault>
<faultcode xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">soap-env:Server:BEA-380001</faultcode>
<faultstring>Requested entity not found</faultstring>
<faultactor>http://api.vetrf.ru:80/ikar/api/ikar/services/IkarService</faultactor>
<detail>
<ws:entityNotFoundFault xmlns:ws="http://api.vetrf.ru/schema/cdm/base/ws-definitions">
<base:message xmlns:base="http://api.vetrf.ru/schema/cdm/base">Country with uuid [1f52fd35-5ee5-ecb3-b23c-2bf3897de0c0] not found.</base:message>
</ws:entityNotFoundFault>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</soapenv:Envelope>

------------------------------------------------------------------------
Запрос:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2" xmlns:base="http://api.vetrf.ru/schema/cdm/base">
<soapenv:Header/>
<soapenv:Body>
<v2:getCountryByGuidRequest>
<base:guid>2ca4d153-0e81-15d1-f7b3-78eba7e814ef</base:guid>
</v2:getCountryByGuidRequest>
</soapenv:Body>
</soapenv:Envelope>

Ответ:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<SOAP-ENV:Body xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<v2:getCountryByGuidResponse xmlns:bs="http://api.vetrf.ru/schema/cdm/base" xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2" xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2">
<dt:country>
<bs:uuid>1f52fd35-5ee5-ecb3-b23c-2bf3897de0c0</bs:uuid>
<bs:guid>2ca4d153-0e81-15d1-f7b3-78eba7e814ef</bs:guid>
<bs:active>true</bs:active>
<bs:last>true</bs:last>
<bs:status>200</bs:status>
<bs:createDate>2012-09-03T09:48:36+04:00</bs:createDate>
<bs:updateDate>2012-09-03T09:48:36+04:00</bs:updateDate>
<bs:previous>0bff845e-c9b3-f4bd-4332-9d2c865ce93b</bs:previous>
<dt:name>Корея, Народно-Демократическая Республика</dt:name>
<dt:fullName>Корейская Народно-Демократическая Республика</dt:fullName>
<dt:englishName>North Korea</dt:englishName>
<dt:code>KP</dt:code>
<dt:code3>PRK</dt:code3>
</dt:country>
</v2:getCountryByGuidResponse>
</SOAP-ENV:Body>
</soapenv:Envelope>

------------------------------------------------------------------------
И еще интереснее

Запрос:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2" xmlns:base="http://api.vetrf.ru/schema/cdm/base">
<soapenv:Header/>
<soapenv:Body>
<v2:getCountryByUuidRequest>
<base:uuid>2ca4d153-0e81-15d1-f7b3-78eba7e814ef</base:uuid>
</v2:getCountryByUuidRequest>
</soapenv:Body>
</soapenv:Envelope>

Ответ:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/>
<SOAP-ENV:Body xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<v2:getCountryByUuidResponse xmlns:bs="http://api.vetrf.ru/schema/cdm/base" xmlns:dt="http://api.vetrf.ru/schema/cdm/dictionary/v2" xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2">
<dt:country>
<bs:uuid>1f52fd35-5ee5-ecb3-b23c-2bf3897de0c0</bs:uuid>
<bs:guid>2ca4d153-0e81-15d1-f7b3-78eba7e814ef</bs:guid>
<bs:active>true</bs:active>
<bs:last>true</bs:last>
<bs:status>200</bs:status>
<bs:createDate>2012-09-03T09:48:36+04:00</bs:createDate>
<bs:updateDate>2012-09-03T09:48:36+04:00</bs:updateDate>
<bs:previous>0bff845e-c9b3-f4bd-4332-9d2c865ce93b</bs:previous>
<dt:name>Корея, Народно-Демократическая Республика</dt:name>
<dt:fullName>Корейская Народно-Демократическая Республика</dt:fullName>
<dt:englishName>North Korea</dt:englishName>
<dt:code>KP</dt:code>
<dt:code3>PRK</dt:code3>
</dt:country>
</v2:getCountryByUuidResponse>
</SOAP-ENV:Body>
</soapenv:Envelope>

------------------------------------------------------------------------

Шедеврально товарищи.
Теперь 2 вопроса:
1. Как вычистить кэш на Меркурианском сервере и вернуть нормальный результат после ошибочного? Стоит послать UUID в операцию получения по GUID и всё, операция получения по UUID не отрабатывает больше.
2. ЭТО ТАК ВО ВСЕХ СПРАВОЧНИКАХ И ЗАЯВКАХ РАБОТАТЬ БУДЕТ???

если это просто смена типа упаковок, то как бы через инвентаризацию вариант пропускать как смена типа упаковки и ее количества. А вот если это смена СКУ что не редкость, то никак.

ilart1991 wrote:

Есть извращенный вариант. Зарегать тот склад в кач-ве ПО под вашим ХС, далее перемещать без смены собственника, и далее уже переупаковывать. Тогда, по идее, вы останетесь производителем.

Но насколько это законно - яхз.

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

PS: вот кстати тема которой почти год http://vetrf.ru/vetrf-forum/posts/list/7012.page#40695 Вет управления писали письма в РСХН по этому поводу, бестолку.

GusVal wrote:

polet wrote:
xmlns:v2="http://api.vetrf.ru/schema/cdm/registry/ws-definitions/v2"

<ws:getAllCountryListRequest>
</ws:getAllCountryListRequest>

При отправке через HTTPЗапрос ругается благим матом.
Кто то уже получал?

Я бы на месте XML-парсера такое не съел бы... Все равно даже если бы и Икар...

Ааа.. вот в каком вы смысле.

GusVal wrote:
Обычно такое, когда нет завершающего тега для какого-нибудь элемента... ws везде заменили на v2?

Это Икар, там библиотеки не менялись, нет там V2

count до 100 уменьшить?

nselezneva wrote:
Спасибо за ответ!
Но я так и не поняла, ХС может создать сам ВСД, чтобы отправить его на утверждение врачу?

Могу предположить, что проблема в том, что большая часть интеграторов еще не успела перейти на работу под шлюз 2.0, и работает под версией 1.4. Архитектура меркурия поменялась существенно и эти Лабы что вы видите, возможно находятся в других полях и вэб гашение не отрабатывает корректно. Т.е. данные хранились в поле ЛабИсследования, а перекачевали в структуру ПереченьЛабораторныхИсследований, на распечатке вы все нормально видите, данные по первому полю, а данные по второму скрыты (они пустые). Как только вы погасили, вы видите информацию по второму полю, а первые скрыты. А то и вообще затираются. Это та же история что была с количеством упаковок.
(PS: Наименования полей выдуманы для описания примера)

Милашка wrote:
Не могу ответить ибо врачи поставщика сами не знают что у них.

Сейчас только обратила внимание, что вы гасите через ВЭБ. У нас данные затирались как раз то когда оформляли через ВЭБ, а гасили через API (через интеграцию).

DmitrO wrote:

Private wrote:Пришел эВСД на продукцию "п/ф куриные замороженные:филе грудки-10010 кг,крыло-455 кг." (это все в поле наименование, общий вес совпадает с суммой весов, указанных в этом поле). Гасим через шлюз. Подскажите, какими методами в данном случае выполнять гашение, чтобы создать строки складского журнала по отдельным номенклатурам?

Цитата из http://help.vetrf.ru/wiki/%D0%93%D0%B0%D1%88%D0%B5%D0%BD%D0%B8%D0%B5_%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%86%D0%B8%D0%B8,_%D0%BF%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B8%D0%B2%D1%88%D0%B5%D0%B9_%D0%BF%D0%BE_%D1%8D%D0%BB%D0%B5%D0%BA%D1%82%D1%80%D0%BE%D0%BD%D0%BD%D1%8B%D0%BC_%D0%92%D0%A1%D0%94,_%D0%B2_%D0%9C%D0%B5%D1%80%D0%BA%D1%83%D1%80%D0%B8%D0%B9.%D0%A5%D0%A1

Если пришел один ВСД на продукцию в ассортименте?
Не гасить входящий ВСД. Требовать от отправителя корректное оформление эВСД – на каждое товарное наименование продукции свой ВСД.

НУ да. А как быть с вариантами когда в таком виде всд принимал поставщик от своего поставщика? Т.е. запись в его журнал попала не путем ввода вручную, а путем гашения входящего ЭВСД. А поставщик поставщика зарубежная компания и запись заводили сотрудники РСХН на таможне? Да еще лабы проведенные через весту и прикрепленные к этому "зоопарку"? Тут лишь один вариант, списывать это всё и заводить новые записи в соответствии с маркировкой. Только уже никакой привязки к Аргусу этой партии, никаких ранее отобранных проб через Весту, никакой прослеживаемости.