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

oleg-x wrote:

В интеграционном шлюзе при попытке выполнения операций, которые приводят к редактированию устаревшей записи журнала (хотя это практически не выполнимо) будет возвращаться ошибка с текстом «Запись журнала помечена для переноса в архив и не может быть использована в текущей операции» и соответствующим кодом.

Этот момент работает частично, аннулирование возможно, а отправка транзакции нет.

На странице Обновления системы Меркурий за 2019 год размещена информация:

**********************************
29.01.2019: Версия 6.13.1
Основные изменения:

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

**********************************

Из этой информации непонятно какие записи будут признаны устаревшими и как с этим вообще работать.

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

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

Ольга Панькова wrote:Здравствуйте! Поясните пожалуйста, как быть в ситуации, когда груз уже прибыл к нам на склад, но в системе входящего эВСД все еще нет?? (У водителя имеется идентификатор, при проверке по нему данные отображаются). Как тогда производить гашение??

Если на странице проверки ВСД в статусе "погашен", то его не сможете погасить, если он "оформлен", тогда посмотрите в разделе "Сведения о получателе" на кого он оформлен, если не на вас, тогда вы его и не увидите.

Инга С wrote:Всем доброе утро!

Помогите, пожалуйста, снять вопрос.

ООО №1 приехало и самовывозом забрало корма у ООО №2.
При этом ООО №2 не оформляет на №1 ВСД по принципиальным соображениям (типа они не нужны в данной ситуации).

Кому попадет и когда?

При этом №1 уже благополучно корма доставило физлицам (там небольшие партии).

Если документы оформлены на физ лиц от ООО 2, тогда ВСД не нужны. Попадет когда поймают, если ООО 1 продает физ лицам по бумагам от себя.

Mai_Vi wrote:Коллеги, расскажите, пожалуйста, про понятие "Холдинг" в Мерке.
Какими связями/прослеживаемостями/зонами ответственности на деле отличается ХС - член Холдинга от обычного ХС?

В Меркурии понятия холдинга нет, там есть ХС и площадки, больше ничего нет. Соответственно для каждого ХС должны быть свои пользователи, они могут быть одни и те же, что у других ХС (регистрируются один раз, дальше привязываются к другим ХС администратором ХС). Можно регистрировать несколько ХС на один АПИ ключ (указываются в заявлении на подключение). Зоны ответственности у каждого ХС свои (это если про разграничение прав для пользователей). Прослеживаемость - не понятно, что это, в Меркурии видно откуда и куда товар отправляется и где производится. Связи между ХС не устанавливаются, но можно привязать площадку одного ХС к другому, если есть перепродажа товара.

Private wrote:

serg882 wrote:

Private wrote:Необходимо регистрировать отдельные ХС, привязывая к ним те самые площадки, которые сейчас привязаны к ИП1.

Привязывать не обязательно, транзакцию можно оформить и без привязки.

Смотря какую транзакцию. Как вы оформите производство без привязки? Поставщик, в принципе, сможет оформить ВСД для гашения, но ему нужно будет знать GUID площадки, и при первом гашении площадка все равно привяжется автоматом, так что лучше сразу.

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

Private wrote:Необходимо регистрировать отдельные ХС, привязывая к ним те самые площадки, которые сейчас привязаны к ИП1.

Привязывать не обязательно, транзакцию можно оформить и без привязки.

BelikJan wrote:Здравствуйте. Помогите советом, пожалуйста.
В общем, есть ИП1. В Меркурии заведен как хозяйствующий субъект, имеющий несколько площадок.
Есть второй ИП2. В Меркурии НЕ числится как отдельный хозяйствующий субъект, а заведен как предприятие (или площадка) под ХС ИП1.
И есть ООО, который также в Меркурии НЕ числится как отдельный хозяйствующий субъект, а заведен как предприятие (или площадка) под ХС ИП1.

Вопрос: можно ли вести дальнейшую деятельность в этом виде или необходимо регистрировать каждое отдельное ИП и ООО как хозяйствующий субъект со своими площадками (кстати, совпадающими с ИП1)?
Не будет ли никаких проблем с интеграцией Ветис.API с 1С Управление торговлей? Т.к. если я правильно понимаю, во входящих документах организация = хозяйствующий субъект.

Не спрашивайте, почему так получилось. Ответ популярный: я недавно в этой компании, всё сделали до меня.

ХС = ИНН или ФИО для физических лиц, Площадка = Адрес доставки/хранения/реализации товара. Площадка не обязательно может принадлежать только одному ХС, если перемещение товара без перевозки, то оформляется транзакция с одного ХС на другое, но площадка одна и та же. Соответственно у вас 100% есть ХС по всем перечисленным юр. лицам (найти можно в Меркурии по ИНН, если у вас нет данных).

АПИ ключ выдается только на указанные в заявлении ХС, другие ХС не могут использовать этот ключ, если они не были указаны.

По вопросу: все должны быть зарегистрированы в Меркурии, площадки регистрируются по факту хранения/реализации товара. Как правило есть договор аренды, по нему и регистрируют на нужный ХС площадку, далее идет перепродажа на другие ХС. По 1С не знаю, смотря какая версия.

Andrewww wrote:

serg882 wrote:

Andrewww wrote:

serg882 wrote:
Эта номенклатура есть только в продуктиве, в тестовом контуре нет, у вас все таки запрос неверный отправляется, нужно смотреть полный текст (без личных данных). В базе перемешаны тестовые данные с рабочими и в Меркурии просто так нельзя понять где рабочая, а где нет (одна номенклатура может быть и в тестовом и в продуктивном контуре).

Можно получить список актуальной номенклатуры с помощью метода GetProductItemList с фильтром по производителю и уже по нему удалить всю неактуальную номенклатуру из базы.

Всё-таки до конца не понял. Если отправлять запрос по номенклатуре "b80d8a78-19ea-4c65-be43-ded108f11ed8" на адрес https://api.vetrf.ru/platform/services/2.1/ProductService, то должен вернуться корректный ответ? Номенклатура же из продуктивного контура.

Я же написал, что у вас неверный запрос отправляется, Меркурий его не может прочитать и выдает ответ "BEA-382513: OSB Replace action failed updating variable "body": Error parsing XML: {err}FORG0005: expected exactly one item, got 0 items"

Так в этом и вопрос был, что в запросе не так. А вы пишете что причина в том, что номенклатура не найдена.

Я написал, в первом посте про номенклатуру, потом написал, что запрос неверный (выделил текст).

Andrewww wrote:

serg882 wrote:
Эта номенклатура есть только в продуктиве, в тестовом контуре нет, у вас все таки запрос неверный отправляется, нужно смотреть полный текст (без личных данных). В базе перемешаны тестовые данные с рабочими и в Меркурии просто так нельзя понять где рабочая, а где нет (одна номенклатура может быть и в тестовом и в продуктивном контуре).

Можно получить список актуальной номенклатуры с помощью метода GetProductItemList с фильтром по производителю и уже по нему удалить всю неактуальную номенклатуру из базы.

Всё-таки до конца не понял. Если отправлять запрос по номенклатуре "b80d8a78-19ea-4c65-be43-ded108f11ed8" на адрес https://api.vetrf.ru/platform/services/2.1/ProductService, то должен вернуться корректный ответ? Номенклатура же из продуктивного контура.

Я же написал, что у вас неверный запрос отправляется, Меркурий его не может прочитать и выдает ответ "BEA-382513: OSB Replace action failed updating variable "body": Error parsing XML: {err}FORG0005: expected exactly one item, got 0 items"

Andrewww wrote:

serg882 wrote:

Эта номенклатура есть только в тестовом контуре, в продуктиве ее нет, поэтому и ответ возвращается, что ничего не найдено.

Спасибо за ответ, но запрос для guid "b80d8a78-19ea-4c65-be43-ded108f11ed8" возвращает точно такой же ответ. А это идентификатор номенклатуры из нашей рабочей базы, которая работает с продуктивным контуром.
И нет ли возможности где-то посмотреть актуальные данные классификатора продукции чтобы не мучиться с запросами?

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

Можно получить список актуальной номенклатуры с помощью метода GetProductItemList с фильтром по производителю и уже по нему удалить всю неактуальную номенклатуру из базы.

Andrewww wrote:Подскажите, пожалуйста почему запрос возвращает ошибку.
Запрос отправляю из Хрома с помощью расширения "Restlet Client".
На адрес https://api.vetrf.ru/platform/services/2.1/ProductService.
В заголовках указаны данные авторизации и Content-Type - "application/xml".

<ws:getProductItemByGuidRequest>
<bs:guid>31be83d0-4867-43fb-a3b6-460a03bd260b</bs:guid>
</ws:getProductItemByGuidRequest>

<faultcode>soapenv:Server</faultcode>
<faultstring>BEA-382513: OSB Replace action failed updating variable "body": Error parsing XML: {err}FORG0005: expected exactly one item, got 0 items</faultstring>
Ну а началось всё из-за проблем в 1С ERP. Данные классификатора продукции в нашей базе по некоторым наименованиям не совпадают с данными Меркурия, хотя классификатор обновляется. Решил вот вручную проверить данные по одной позиции, не получается.

Эта номенклатура есть только в тестовом контуре, в продуктиве ее нет, поэтому и ответ возвращается, что ничего не найдено.

Yoreg07 wrote:Добрый день, подскажите пожалуйста, может ссылку дадите, какие документы и куда их надо подавать чтобы зарегистрировать новые площадки в Ветис?

У вас же вроде бы АПИ есть, через него можно целую гору площадок завести, если площадки создаются по своим ХС, то их можно и привязать.

Вальтос wrote:

Доброго времени суток.

Полетели ошибки такие же:"Ожидайте завершения обработки данных ВетИС". Перед этим выдается пользователю ошибка "Нарушение прав доступа!", в журнале регистрации появляется сообщение:

При загрузке документа с типом prepareOutgoingConsignmentResponse возникла ошибка:
Текст ошибки: {Документ.ИсходящаяТранспортнаяОперацияВЕТИС.МодульМенеджера(2315)}: Ошибка при вызове метода контекста (Записать)
НаборЗаписей.Записать();
по причине:
Нарушение прав доступа!

Сталкивался кто-нибудь?

У пользователя нет прав доступа на какой-то регистр 1С, текст ответа Меркурий зря запостили, он здесь не причем.

Посмотрите здесь "Документ.ИсходящаяТранспортнаяОперацияВЕТИС.МодульМенеджера(2315)" в какой регистр записывается информация и проверьте доступ на запись у пользователя 1С в этот регистр.

Маринин wrote:Добрый день! Вопрос такой:

Имеется GUID записи складского журнала. Как получить список всех оформленных транспортных ЭВСД по данной записи складского журнала? Работаем через ШЛЮЗ.

Что бы получилось как если работаем через WEB. Когда открываешь запись складского журнала, есть кнопка "показать список всех выписанных ЭВСД".

Спасибо.

Метод GetStockEntryVersionListOperation, работает или нет не знаю, но назначение у него подойдет для решения задачи.