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

Yoreg07 wrote:Только что в webe погасил ВСД, запомнил время гашения и время добавления записи складского журнала. Сделал запрос на получение истории изменений записей складского журнала с указанием в beginDate времени добавления этой записи и в ответе эта запись пришла. НО ... сделав аналогично запрос на получение истории изменений ВСД ПОГАШЕННОГО ВСД НЕТ в ОТВЕТЕ. Как так? Кто может что-нибудь пояснить?

У них время на серверах отстает

Yoreg07 wrote:Поделитесь опытом, кто как организовал у себя загрузку входящих ВСД в УС с помощью этого запроса

С часовыми поясами это косяк, у них, кстати, еще и время неправильное на некоторых серверах. Я вычитаю сутки, с момента последнего обновления, и загружая документы проверяю на наличие дубликатов.

Милашка wrote:Поддержу вопрос Ириалы. И от себя дополню: если и предоставят возможность через api создавать заявки (на продукцию не попавшую в пр.646), так ветврачи не сразу бросятся их подтверждать. Это нужно договаривать, а не обещать ХС моментального оформления не учитывая работу врача. Ветсаносмотр продукции и проверку заявки еще никто не отменял, и, смотря какая загруженность у врача в работе. После нажатия кнопочки "оформить" вся ответственность за сведения внесенные в всд возлагается на врачей. ХС как всегда открестится, в случае ошибки и пальцем покажет на врача, дескоть он подтверждал, а создатель заявки не виноват. Поэтому и не дают врачи свои логины для интеграционных решений и правильно делают.

Вы прям как на другой планете живете. Мы, по факту, имеем навязанную, неработающую систему, которую надо заставить работать. Для этого даже не надо отдавать свой логин ХС, он нам просто не нужен. Нужно сделать то, чего российские чиновники никогда не умели - просто пойти навстречу.

Ириала wrote:Я работаю в веб. Объясните мне, пожалуйста, допустим апи доработают, заявки в ГВЭ пойдут автоматически - врачу ведь все-равно придется проверять каждую заявку, каждую позицию (а то МЕРКУРИЙ напишет "В госхран на длит.хранение", или для производства комбикорма ", или еще что-нибудь; или ВСЭ не пройдена??? Сколько надо ветврачей, чтобы просто обработать эти заявки, я не говорю, что надо еще продукцию посмотреть? Получается, что делать заявки в веб. долго, а обрабатывать - раз плюнуть? Про две кнопки не говорите...

Я не совсем понял что Вы имеете ввиду. Разработчики специально не сделали отправку через API на одобрение ГВЭ, чтобы замедлить скорость добавления заявок хозсубъектом? Чтобы ветврачи успевали их оформлять? Довольно коварно, с их стороны.

anig99 wrote:Первое решение кажется проще для данного случая. Но только пока не учтешь, что таких случаев по стране будет ОЧЕНЬ много.

Я, как разработчик, одного не могу понять: проект документа отличает от документа, скорей всего, только пара бит в статусе. Доработать такое решение займет пару минут, даже в описании API ничего менять не придется. Неужели разработчикам так сложно облегчить жизнь хозсубъектам?

Корнетт wrote:Странное поведение СББЖ, во- первых, на их логин никто не собирается покушаться, чушь какая то; во-вторых, им не нужна лишняя денежка что-ли ( договор ведь предусматривает оплату услуг ветспеца). Видимо дело тут совсем в другом. А как тогда СББЖ предлагает вам работать по оформлению эвсд?

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

Через API номер прицепа возвращается пустым. Это баг, разрабы в курсе.

Николай Власов wrote:Почему нет специалистов? Они есть - уже десятками исчисляются. Вот и вы - заведите своего и проблем у вас не будет. Или договоритесь с СББЖ, чтобы они обслуживали.

Николай Анатольевич, все это очень гладко на бумаге, в реальности, особенно отечественной, все гораздо сложнее. Завести своего АС, насколько я понимаю, процесс который может затянутся на несколько месяцев. Попытка договориться с СББЖ закончилась именно тем что писано в первоначальном посте - они отказались, обосновывая это тем что их волнует безопасность их логина.

P.S. Скажите пожалуйста, может это не недостаток сервиса, а административное решение?

Николай Анатольевич, добрый день. Вот что теперь делать? По 646 мы не походим, по 647 нет специалистов, а API не дает загружать документы на рассмотрение ГВЭ. Транспортных документов, по самым скоромным подсчетам, у нас будет около 500 в день, по нескромным в десятки раз больше. Николай Анатольевич, без загрузки транспортных документов на рассмотрение в ГВЭ, через API, теряется весь смысл API в частности и Меркурия в целом.

Я считаю что самый достойный выход это сделать так: если номер заранее не известен оформить груз на любую свою машину, создав мультимодальную перевозку. Когда машина придет - добавить номер в первую точку маршрута. Если у кого-то есть более честные варианты - прошу озвучить.

vv-adm wrote:В моем случае перевозка осуществляется только одним транспортным средством без промежуточных перегрузок, номер которого не известен.

Тогда остались только полу-законные методы

Мультимодальные перевозки + updateTransportMovementDetailsRequest.

Надо не UUID, а GUID.

Есть две версии API:

В версии 1.4 у getStockEntryListRequest неймспейс http://api.vetrf.ru/schema/cdm/application
В версии 2.0 у getStockEntryListRequest неймспейс http://api.vetrf.ru/schema/cdm/mercury/g2b/applications/v2

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

P.S. Кстати у Вас и для Application подставляется не тот неймспейс, который Вы указываете. Возможно его надо указывать другим способом.

Вдогонку: у Вас там подставляется подставляется неймспейс из версии 1.3-1.4, а запрос Вы отправляете на сервис второй версии. Проверьте импорт WSDL, похоже проблема там.