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

Алексей Баранов wrote:

dk wrote:Через Ветис.API можно получать список продукции конкретного производителя. Через вёб видимо только через GTIN.

Спасибо за ответ.
В общем получается, что через WEB по производителю не выбрать.
Ну вот чего стоило разработчикам добавить производителя?

У нас не так много остатков, чтобы имело смысл реализовывать функционал инвентаризации через шлюз,
Но при этом хотелось бы, чтоб всё было корректно, а получается... как всегда получается.

Зачем реализовать функционал инвентаризации через шлюз, воспользуйтесь имеющимся.

От 3000 руб. в год. Не надо ничего устанавливать и обновлять. См. подпись.

Через Ветис.API можно получать список продукции конкретного производителя. Через вёб видимо только через GTIN.

Если я правильно нашёл мясокомбинат:
ЗАО "Йошкар-Олинский мясокомбинат"
GUID:
3712-5CE0-6BDD-40D4-A341-5B12-EA62-13B4
Российская Федерация, Республика Марий Эл, г. Йошкар-Ола, Кокшайский проезд, д. 44

Фирма-владелец (ХС):
ЗАКРЫТОЕ АКЦИОНЕРНОЕ ОБЩЕСТВО "ЙОШКАР-ОЛИНСКИЙ МЯСОКОМБИНАТ" (ИНН: 1215027621; КПП: 121501001; ОГРН: 1021200753970)
GUID:
FCED-F5C7-218A-11E2-A69B-B499-BABA-E7EA
424006, Российская Федерация, Республика Марий Эл, г. Йошкар-Ола, Кокшайский проезд, д. 44

У них много говядина тушёная.

Для примера:
25361: Говядина тушёная высший сорт №8 (GTIN: 4606639000013)

oleg-x wrote:

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий
2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

А если не по памяти, есть какая-нибудь ссылка какой-нибудь документ или письмо или новость на этот счёт.

oleg-x wrote:

dk wrote:О выполнении каких конкретно требованиях идёт речь?

На память, несколько:
1) Не запрашивать каждый раз остатки, а хранить в системе. Загрузка только один раз. Был пример одной интеграции, где при выборе партии, каждый раз шел запрос на остатки в Меркурий
2) Аналогично с входящими ЭВСД, не запрашивать каждый раз все входящие, а подгружать только новые. Хранить дату последнего запроса.
3) Хранить справочники в системе и обновлять их, а не запрашивать каждый раз.

Тогда мы даже в какой-то степени помогаем Меркурию, т.к. у нас одни справочники для всех клиентов и ни одного лишнего запроса))

О выполнении каких конкретно требованиях идёт речь?

APLM0012 имхо, это ограничитель общей очереди запросов, чтобы очередь не росла до бесконечности.

Вот чем больше таких интеграций, тем больше будет APLM0012 для всех.
http://vetrf.ru/vetrf-forum/posts/list/9130.page;jsessionid=acc5e6062e9ea11aa8c947dd9c7b

Мы заметили если задачи например по запросам новых ВСД стоят на 00 минут или 30 минут, они чаще получают APLM0012, чем в другое время.

В данном случае ошибок то никаких нет.

oleg-x wrote:Путь хоть 100500 запросов отправляют. Сейчас пока лояльно относятся. Но по результатам месяца, могут просто закрыть доступ к шлюзу. Из-за не корректной интеграции.
По идее должны будут сначала предупредить, но кто его знает.

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

miskevich wrote:только из профессиональной этики продолжу этот бесполезный разговор.

как быть предприятию, которое работает круглосуточно, когда в ответ на корректный запрос остатков получаешь APLM0012, или при оформлении транспортных ВСД, или при получении условий регионализации для транспортных ВСД? подождать часик?
это еще хорошо, что постоянную отгрузку убедили поставить в однопоточном режиме. многопоточный вариант в гарантией бы заклевал Меркурий.
по внутреннему регламенту максимальное время получения UUID транспортных ВСД - 3 минуты. Это время ожидания водителя уже погруженной машины пакета документов с ВСД. Ожидание более 30 минут - угроза срыва поставки из-за выпадания из времени разгрузочного окна.

Практический результат - своевременное ВСД у клиента, отсутствие штрафов у предприятия и водителя. Пока у нас получается.

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

Есть такая задачка по физике: если в закрытой комнате поставить холодильник, включить его и открыть дверцу этого холодильника, в комнате станет холоднее? Холодильник рабочий.

Вы реально думаете, чем больше вы будете долбить Меркурий ненужными запросами, тем быстрее получите ответ? Первые 5 секунд вообще бессмысленно ждать ответа.
Вот у вас регламент 3 минуты, 1 минута на регионализацию, 2 минуты на основной запрос, если регионализацию вы сделаете 5, 25, 45, 60, вы гарантировано получите результат, очень редко бывает дольше.
Ну если не в терпёж долбите со второй минуты каждые 5 секунд, меньше нет смысла. Аналогично для остального запроса.
Никакого выигрыша от постоянных запросов вы точно не получите, только увеличите APLM0012 для всех.

Ибо APLM0012 имхо, это ограничитель общей очереди запросов, чтобы очередь не росла до бесконечности.

nmzn1 wrote:

dk wrote:Не очень понятно, почему вы не можете завершить производство и жить не тужить дальше?
Если появятся ненужные записи складского журнала, удалите их через инвентаризацию.

вроде как нет кнопки "завершить пр-во", может зашли подо всеми площадками, поэтому

Ну так скорее всего.

uliaar wrote:Добрый день!
Столкнулись с проблемой: нужно удалить запись журнала, которая появилась в результате ошибочного создания незавершенного производства. Завершить производство мы не можем, потому что данной продукции нет и запись было создана два года назад, продукция в меркурии уже давно просрочена. Аннулировать производство мы не можем: такой кнопки нет. Инвентаризировать тоже: меркурий не находит эту запись журнала через поиск.
Появилась идея удалить эту запись с помощью кнопки "Очистить выбранные записи".
Хотели бы уточнить, что делает данная кнопка и насколько это корректно. Или может кто-нибудь знает другие способы удалить эту запись? Спасибо!

Не очень понятно, почему вы не можете завершить производство и жить не тужить дальше?
Если появятся ненужные записи складского журнала, удалите их через инвентаризацию.

miskevich wrote:Знаю, но за пределы ограничений по количеству запросов не выходим, значит соответствуем требованиям.

Чем больше вы будете бомбить меркурий ненужными запросами, тем больше APLM0012 будут получать все.
Я понимаю, если бы от этого был бы какой-то практический результат.
Они конечно тоже виноваты, что не дали конкретные рекомендации на этот счёт.

Нет смысла делать секунду между запросами, только увеличиваете общее время обработки для всех, на месте Меркурия, я бы отключал такие интеграции.
1000 таких интеграций и ниодин сервер не переживёт.

Ryasik wrote:При нажатии кнопки "Оформите" в 1С 8.3 - выдает сообщение "Недостаточно прав оформления партии на рыбу"
При оформлении исходящей ВСД через WEB - все ОК!
В чем может быть проблема?

В правах доступа. Для веба и Ветис.API они могут отличаться. Проверьте права в Ветис.Паспорт.

oleg-x wrote:

dk wrote:

bsd34 wrote:Здравствуйте. Есть ли какие то решения интеграции если мы не ведем партийный учет в 1с?

Тогда вам не смысла интегрироваться с 1С. Что конкретно вы делаете в Меркурии?

Здесь я бы поспорил. Если 20 записей да, нет смысла, можно шаблонами. А если 100 клиентов, руками замучаешься
А вот сопоставить один раз клиентов и прямо в документе выбирать партию очень удобно при небольших отгрузках. До 300 записей в день таким образом можно без проблем выписывать.

Шаблон, шаблону рознь. У нас нужно только номер авто и ТТН заполнять.
Он не только клиента запоминает, но даже список продукции может запомнить, он будет сам подбирать такую же из имеющихся на складе.
Правила регионализации можно запомнить, и запросить новые только если не сработает.
И маршрут тоже запоминается при мультимодальных перевозках.
Вообщем ничего кроме номера авто, ТТН и связанных документов не нужно заполнять.

bsd34 wrote:Здравствуйте. Есть ли какие то решения интеграции если мы не ведем партийный учет в 1с?

Тогда вам не смысла интегрироваться с 1С. Что конкретно вы делаете в Меркурии?