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

нам в тестовом контуре прислали от производителя транспортный ВСД на плавленный сыр с целью "реализация в пищу людям"
и мы нашим клиентам (в основном розничным) мыт оже так должны отправлять?

my.vetrf-forum wrote:
еще вопрос - делаю запрос getVetDocumentListRequest по ВСД с типом Incoming, а в ответе куча ВСД с типом TRANSPORT это нормально или что-то не так с запросом?

это нормально.
просто в фильтрацию по типу сделали и тип и направление. Но увидите вы все входящие (например возвратные тоже). ИМХО

и вообще наверное удобнее сначала "руками" тестировать в SOAP UI запросы.
сначала синхронные потренируете (пропроще) - со справочниками -
например в ProductServiceBinding сделаете GetProductChangesList с запросом вида

не забудьте авторизацию добавить.

А потом ассинхронный (например запросите список непогашенных входящих документов в ваш адрес)

через ApplicationManagementServiceBinding - submitApplicationRequest делаете запрос типа такого

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions" xmlns:app="http://api.vetrf.ru/schema/cdm/application">
   <soapenv:Header/>
   <soapenv:Body>
      <ws:submitApplicationRequest>
         <ws:apiKey>***</ws:apiKey>
         <app:application>
            <app:serviceId>mercury-g2b.service:2.0</app:serviceId>
            
            <app:issuerId>***</app:issuerId>
            
            <app:issueDate>2017-09-20T18:57:00</app:issueDate>
            <app:data encoding="?">
               
               <soapenv:Envelope xmlns:v2="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2" xmlns:base="http://api.vetrf.ru/schema/cdm/base" xmlns:v21="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2" xmlns:v22="http://api.vetrf.ru/schema/cdm/dictionary/v2">
                  <soapenv:Header/>
                  <soapenv:Body>
                     <v2:getVetDocumentListRequest>
                        <v2:localTransactionId>?</v2:localTransactionId>
                        <v2:initiator>
                           
                           
                           
                           <v21:login>vestaf-170813</v21:login>
                        </v2:initiator>
                        
                        
                        
                        <base:listOptions>
                           
                           <base:count>1000</base:count>
                           
                           <base:offset>0</base:offset>
                        </base:listOptions>
                        
                        <v21:vetDocumentType>INCOMING</v21:vetDocumentType>
                        
                        
                        <v22:enterpriseGuid>452ff3be-bdda-44f5-853e-35cc0f5e03c8</v22:enterpriseGuid>
                     </v2:getVetDocumentListRequest>
                  </soapenv:Body>
               </soapenv:Envelope>
            </app:data>

</app:application>
      </ws:submitApplicationRequest>
   </soapenv:Body>
</soapenv:Envelope>

тут видно куда APIkey и прочее

В ответе вам придет XML с тегом (если все успешно завершится) <applicationId>84c57445-8f5c-4b5f-88e2-26b82b4fc6f5</applicationId>
по этому ИД запросите результат через

receiveApplicationResult запросом вида

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

WSDL берите из пред. поста - нужно же по версии 2 протокола уже наверное все делать

Sky_nnov wrote:

Денис Сергеевич wrote:Проверьте в какой приказ попадает ваша колбаса в 646 и 647

Подскажите человеку далекому от ветеринарии как отличить колбасу 646 от колбасы 647
646:

видимо опираясь на коды ТН ВЭД из приложенных сертификатов (деклараций) соответствия

Nevzor wrote:Добрый день!
Хотя при запросе ВСД, эта информация отсутствует (в версии 1.4 это было)

мы в тесте видим эту инфу - по пути СертПартия - сведения о партии - сведения о происхождении
но в других тестовых ВСД (которые нам контур прислал) - этого раздела нет. получается даже если его нет, надо самим указать, что это Россия? Хотя в описании указано как необязательный.

может у вас теги есть, но значения пустые??

странно - казалось бы и в описании GetVetDocumentListOperation - сам раздел "origin" и подраздел "country" в нем необязательны и точно также написано в описании ProcessIncomingConsignment.
я думал игнорить эти поля - атак получается их надо сохранять при загрузке ВСД чтобы транслировать дальше?

Сам раздел похоже должен быть где-то тут prepareIncomingConsignmentRequest \ delivery \ consignment \ но этом в типе нет origin а в описании prepareIncomingConsignmentRequest указано origin.
а. понятно - он наследует все свойства batch - а 1С-ка это поймет интересно.. У меня в описании типа consignment не видно этих свойств.

подскажите как понять логику обязательных и необязательных реквизитов..
например в типе VetFocument внутри серт.партии реквизит transportStorageType - необязательный, но когда этот объект в ответе на getVetDocumentListResponse - то там он обязательный. при этом когда мы будем дальше выпускать свои тэВСД, то в PrepareOutgoingConsignmentOperation в типе Delivery такого поле необязательно.
Это я к тому, что полей много и мне надо уже четко понимать, какие мне реквизиты сохранять (и заводить в 1С соответсвующие типы) чтобы дальше транслировать в своих иходящих эВСД, а на какие можно не обращать внимание.

my.vetrf-forum wrote:Я считаю все правильно, нужно срок перенести. Мы уже частично работаем через Меркурий, сейчас будем делать полную интеграцию. Расслабляться не собираемся.

Срок 01/01/18 изначально странный, кто ж такие вещи на новогоднюю ночь планирует

как раз обычно таки планируют.. помнится я 31.12.15 еще в 23-30 допиливал интеграцию ЕГАИС, а потом 02.02.16 ставил пиво на баланс..

но 01.07.18 для нас тоже непростой срок, т.к. с этой же даты другие переходы есть в ) томе же ЕГАИС)..

ага. спасибо!
кfк раз втулил localid - (а что сн им дальше-то делать? к нему есть требования, он должен быть все время уникальным?)
но оказалось что не тот логин указал в инициаторе - указал логин к Ветис-АПИ а нужен логин пользователя (которы из ветис.паспорт).
сложно все )

что-то туплю.. подскажите - кидаю на https://api2.vetrf.ru:8002/platform/services/2.0/ApplicationManagementService

запрос вида:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ws="http://api.vetrf.ru/schema/cdm/application/ws-definitions"
xmlns:app="http://api.vetrf.ru/schema/cdm/application"
xmlns:v2="http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2"
xmlns:base="http://api.vetrf.ru/schema/cdm/base"
xmlns:v21="http://api.vetrf.ru/schema/cdm/mercury/vet-document/v2"
xmlns:v22="http://api.vetrf.ru/schema/cdm/dictionary/v2">

<soapenv:Header/>
   <soapenv:Body>
      <ws:submitApplicationRequest>
         <ws:apiKey>***</ws:apiKey>
         <app:application>
            <app:serviceId>mercury-g2b.service:2.0</app:serviceId>
            <app:issuerId>****</app:issuerId>
            <app:issueDate>2017-09-21T16:57:00</app:issueDate>
            <app:data>
               <v2:getVetDocumentListRequest>
                  <v2:initiator>
                     <v21:login>***</v21:login>
                  </v2:initiator>
                  <base:listOptions>
                     <base:count>500</base:count>
                     <base:offset>0</base:offset>
                  </base:listOptions>
                  <v22:enterpriseGuid>***</v22:enterpriseGuid>
               </v2:getVetDocumentListRequest>
            </app:data>
         </app:application>
      </ws:submitApplicationRequest>
   </soapenv:Body>
</soapenv:Envelope>

возвращает ошибку

<apl:error code="APLM0007" xmlns:apl="http://api.vetrf.ru/schema/cdm/application">Wrong application data format. Format validation failed due to XML Schema rules: Элемент 'initiator' не предусмотрен.</apl:error>

если убрать инициатора, то начинает ругаться налист опшионс и т.д. что-то я явно делаю не так.

что-то я подзапутался - тестовый запросы по v2 чтобы кинуть, это надо вот эту WSDL - api.vetrf.ru/schema/platform/services/ApplicationManagementService_v1.5_pilot.wsdl ?

Yoreg07 wrote:

wolfenstein66 wrote:Здравствуйте!
Когда стартует шлюз версии 2? Хотя бы тестовый.
Дело в том что в тестируемом 1.4 в справочнике наименований продукции отсутствуют Упаковки, GLN и штриходы продукта.
Версия 1.3-1.4 однозначно не подходит, интеграция приостановлена. Вокруг запуска 2.0 ходят темные слухи, пролейте пожалуйста свет на эту тайну

Присоединяюсь к вопросу.

неистово присоединяемся - можно ли разрабатывать под версию 2.0 сразу? По срокам вроде на тестовом контуре уже должно работать?

я правильно понимаю, что для "Подсистема работы со справочниками и реестрами" - разницы нет- есть только одна версия сервисов?
и версионирование касается только ассинхронных операций в "Подсистема обработки заявок в Ветис.API"

Денис Сергеевич wrote:А есть способ узнать GUID код без использования API?

думаю только спросить у контрагента.
нам некоторые производители-поставщики уже присылает листы-опросники, где спрашивают все GUID, которые мы используем.

чтобы 2 раза не вставать - подскажите, все эти UUID - версии всех объектов. В практической жизни их можно игнорировать? Т.е. если опираемся на GUID то UUID нам вроде не понадобиться?

UPD если посмотреть сюда (еще не все разобрал) http://vetrf.ru/vetrf-forum/posts/list/7130.page, то
UUID нужен для packingType в операции создания тВСД - prepareOutgoingConsignmentRequest
откуда его узнавать-то??

и потом - нам обычно приходит товар в ящиках (все эти плавленные сыры, бульонные кубики, сгущнка и т.п.).
А наши покупатели - розница, берут все поштучно. Чтобы не было проблем я вижу что нужно требовать от поставщиков (а не клали они на наши требования) выпускать свои ВСД в минимальных единицах измерения (у нас весового нет, только штуки-ящики). Иначе мы не сможем ничего отгружать. Или всякий раз делать инветнаризацию - списать 10 ящиков- оприходовать 100штук тогоже самого?? И все это руками (и потом прописывать реквы в партии в УС) или реализовывать в УС. это мы еще полгода будем разрабатывать (((

my.vetrf-forum wrote:
Поянтно, спасибо. А как посмотреть список activityLocation у ХС ?

зная GUID ХСа, getBusinessEntityByGuidRequest - смотрим activityLocation - там как я понял перечислены все привязанные площадки

так что видимо это и ответ на вопрос

Есть ли какой-нибудь дополнительный способ узнать GUID код площадки контрагента,помимо
скачивания файла со страницы выбора обслуживаемого предприятия?

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

итак по покупателям

перед тем как отгружать и видим что данная дляд анного ТТ не указаны в УС Предприятие/ХС осуществляем поиск в системе:

getBusinessEntityListRequest фильтр по ИНН получаем список (краткий) ХС
далее по каждому getBusinessEntityByGuidRequest - смотрим activityLocation это площадки.
загружаем их в свой классификатор в УС с помощью getEnterpriseByGuidRequest - автоматом сопоставить с торговыми точками (или пунктами разгрузки как ни называй) не получится, т.к. в «карточке» площадки (площадка = подназорный объект = enterprise ?) нет ничего кроме адреса (в ИКАР формате).
Таким образом заставляем операторов вручную ставить соответствие ТТ – площадки. И вот если нет площадки, то тогда (опять же по кнопке) создавать площадку? А если и ХСа нет, то сначала создать ХС:
1. Создаем при необходимости ХС – modifyBusinessEntityRequest (или находим если есть по ИНН/КПП)
2. Создаем площадку - ModifyEnterpriseOperation - а владельцем ее кого указывать, ХС из п1 ?

Это имеет смысле вообще?