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

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

да мы пару дней назад получили такой ВСД.
с этим назначением груза..

my.vetrf-forum wrote:Бывает иногда. Приходит в ответ APLM12, а ВСД исходящие создаются.

н тогда бы мы их увидели в вебе? раз там их нет, значит не создалось?

Shadasp wrote:
Скорее всего проблема в корректности заполнения заявки, тоесть в ней может быть не корректно заполнена цель реализации, не кооректная упаковка и т.д.

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

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

результат ВСЭ = ВСЭ подвергнуто сырьё, из которого произведена продукция
назначение - в корм непродуктивным животным
способ хранения при перевозке - Вентилируемый
благополучие - Местность благополучна по заразным болезням животных

мы в свою очередь в заявке указываем только номер СЖ (чтобы не ошибиться в полях, стараемся своих данных по минимуму указывать). И как теперь диагностировать? ждать когда вернут причину (повторно запрашивая результат по прежнему AppID)??

подскажите, это APLM0012 выдается (по идее) только при запросах на получение?

Мы вот отправляем заявку на оформление тВСД (и кровь из носу надо из нашей УС, т.е. через API-2). Получили AppID, но по нему в ответ получаем реджектед с этим же APLM0012.
Это нормально??
я думал при отправке заявок в обработку (раз уж заявка принята и AppID присвоено) такого быть не должно??

Подскажите плиз.

подскажите, это APLM0012 выдается (по идее) только при запросах на получение?

Мы вот отправляем заявку на оформление тВСД (и кровь из носу надо из нашей УС, т.е. через API-2). Получили AppID, но по нему в ответ получаем реджектед с этим же APLM0012.
Это нормально??
я думал при отправке заявок в обработку (раз уж заявка принята и AppID присвоено) такого быть не должно??

Подскажите плиз.

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

[муа-ха-ха]

извините, нервное )

OFFTOP OFF

Маринин wrote:

Vesta_IT wrote:коллеги, помогите ))

я уже не знаю что думать.. Как так может ,ыть - один и тот же текст запроса из SOAP GUI норм, из 1С не норм..

Скажите пожалуйста. Такая же проблема, в чем ошибка? Все перепробовал. Спасибо.

даже не знаю - само прошло. при этом вроде ничего не менял. Я решил, что на сервере что-то подправили

ilart1991 wrote:
Вы сможете провести сверку ваших контрагентов с фактом их наличия в Меркурии.

я честно говоря пока не видел рабочего сценария как это сделать. Или уже с новыми способами фильтрации можно в (полу)автоматическом режиме сопоставить своих клиентов с меркурием? (в ЕГАИС это делалось просто - классификатор единственный (ЮЛ), запрашивали все по ИНН, и сопоставлялось по паре ИНН+КПП). А как тут? по ИНН положим запросить можно, а как сопоставить все их площадки(=поднадзорные объекты=предприятия)?

nsnt wrote:
Я так понимаю, что сюда: http://help.vetrf.ru/wiki/CheckShipmentRegionalizationOperation_v2.0
Если для перевозки требуется выполнение дополнительных условий, они вернутся в результате этой операции.

угу. т.е. получается это надо заполнять элемент appliedR13nRule ?
исходно их надо брать видимо из входящих ВСД..? или запрашивать перед каждой отправкой по энтерпрпрайзам??
а по 646 приказу тож могут быть такие? (просто тестовый пример от контура на котором я в SOAP GUI отрабатываю видимо самого общего вида, тут 2 условия мне пришло)
Или может быть такое что на момент оформления первого тВСД (который мне пришел) условия были одни, а в момент отгрузки покупателю - стали другие?

Jupiter wrote:

Vesta_IT wrote:

Jupiter wrote:Пытаюсь исполнить processIncomingConsignmentRequest в версии 2.0.
В сведениях о происхождении продукции указываю
<vd:origin>
...

в таком виде origin у меня сработал:

А в каком месте кода Вы это указывали?

путь вот такой:
processIncomingConsignmentRequest.delivery.consignment.origin
отправил в личку полный текст

подскажите по оформлению транспортной партии (PrepareOutgoingConsignmentOperation )

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

рискну процитировать всю delivery:

<v2:delivery>
                     <v21:deliveryDate>2017-10-20T15:10:00</v21:deliveryDate>
                     <v21:consignor>
                        <v22:businessEntity>
                           <base:guid>1ef8e97f-23f5-4496-a7c0-76a775a4147d</base:guid>
                        </v22:businessEntity>
                        <v22:enterprise>
                           <base:guid>452ff3be-bdda-44f5-853e-35cc0f5e03c8</base:guid>
                        </v22:enterprise>
                        <v22:globalID>4607810709992</v22:globalID>
                     </v21:consignor>
                     <v21:consignee>
                        <v22:businessEntity>
                           <base:guid>108a8401-25f0-4828-98b1-4ef1e8f10718</base:guid>
                        </v22:businessEntity>
                        <v22:enterprise>
                           <base:guid>f197f446-6247-469b-827d-3d6fa34fe053</base:guid>
                        </v22:enterprise>
                     </v21:consignee>
                     
                     <v21:consignment>
                        <v21:volume>1.12</v21:volume>
                        
                        <v21:unit>
                           <base:guid>21ed96c9-337b-4a27-8761-c6e6ad3c9f5b</base:guid>
                        </v21:unit>
                        <v21:sourceStockEntry>
                           <base:guid>b0e39e4a-ab96-40d5-9557-bd8f83ffa54c</base:guid>
                        </v21:sourceStockEntry>
                     </v21:consignment>
                     <v21:transportInfo>
                        <v21:transportType>1</v21:transportType>
                        <v21:transportNumber>
                           <v21:vehicleNumber>o001oo161</v21:vehicleNumber>
                        </v21:transportNumber>
                     </v21:transportInfo>
                     <v21:transportStorageType>CHILLED</v21:transportStorageType>
                     <v21:accompanyingForms>
                        
                        
                        <v21:vetCertificate>
                           <v21:authentication>
                              
                              <v21:purpose>
                                 <base:guid>96de622d-2cb2-424a-888b-7ced5225ce17</base:guid>
                              </v21:purpose>
                              
                              <v21:cargoExpertized>UNFULFILLED</v21:cargoExpertized>
                              <v21:locationProsperity>Местность благополучна.</v21:locationProsperity>

</v21:authentication>
                        </v21:vetCertificate>
                     </v21:accompanyingForms>
                  </v2:delivery>

... пожалуй в другую ветку положу...

Jupiter wrote:Пытаюсь исполнить processIncomingConsignmentRequest в версии 2.0.
В сведениях о происхождении продукции указываю
<vd:origin>
...

в таком виде origin у меня сработал:

в моем тестовом ВСД (от контура) производитель тоже не указан - я взял предприятие из отправителя

подскажите.. есть тег producer в certifiedBatch (там он обязательный и ровно 1 раз) а есть в сеции Origin - там producer может быть [1..*] - несколько раз.
Так откуда брать производителя? и сколько их может быть?