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

АнтонКос wrote:У кого-то еще наблюдаются проблемы с продукцией?

MERC02023: В запросе для номенклатуры продукции указан идентификатор устаревшей версии записи реестра РСХН.

Запись складского журнала была изменена, у записи новый UUID, а вы подставляете старый.
Вообще это нормальная ситуация, если пользователи работают в нескольких программах одновременно, без единой БД.

[quote=Сергеевна-Я]Чем вас аннулирование ВСД не устраивает?

Отвечу:
ВСД создан и уже принят системой приёмки у клиента, и вдруг обнаруживается ошибка. Я аннулирую ВСД, и создаю новый, НО у клиента в базе остаётся старый всд, так как идёт ещё и привязка к связанным докам (например заказ).
Т.е когда я создаю новый ВСД- нужно тогда и электронное уведомление обновить, водителю позвонить и сказать-Это ВСД не отдавай, оно не правильное, Вот фото Нового.
и много ещё чего....[/quote]

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

Slava85 wrote:

TWAIN wrote:

Slava85 wrote:

NikoV wrote:

Mai_Vi wrote:Коллеги, в вебе весь день флажки красные, машинки вчерашние - нас одних так накрыло?

У нас тоже проблема с предприятиями (в терминалогии Меркурия). Машинок нет, но заходишь вручную - есть возвратные ЭВСД. Через API еще интереснее, вместо 3-х предприятий показывает одно, и на него "слил" все входящие ЭВСД. Чудит Меркурий?

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

Может есть кто сталкивался с такой проблемой?

Обратитесь скорее в техподдержку 1с увс, пусть исправят! А то сейчас слияния активно ведут, все в опасности!

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

Площадки с одинаковыми адресами объединяют без предупреждения, ещё до НГ с этим впервые столкнулись.

Prometeusll wrote:Интеграционные решения стоят денег и не малых. Их также приходится дорабатывать и чаще за доп оплату, что в данный момент и делается.
По факту мы имеем плохо проработанную систему, которая падает, платим деньги на интеграционные решения, нанимаем и обучаем новых сотрудников чтобы просто продолжать работать.

Если вас проблема с просрочкой. У нас есть услуга ежедневное автоудаление просрочки: стоит это всего 3000 руб в год на одну площадку + 3000 руб. загрузка остатков за предыдущие периоды (единоразово).

Prometeusll wrote:Меркурий и так регулярно падает. - поставить доп. сервер

Сервера не помогут, нужно ограничивать кол-во запросов.
Большинство недорогих решений не имеют собственной БД и по любому поводу делают запрос в БД Меркурия. Если такие решения не запретить, то система будет регулярно падать.
Потом нужен чёткий алгоритм запроса результата транзакций, если он не соблюдается, блокировать доступ. Многие бездумно "долбят" шлюз каждую секунду забивая очередь запросов.

Prometeusll wrote:чтобы сравнивать даты, нужно их преобразовывать и хранить в формате пригодном для сравнения, создавать соответствующие индексы в БД и т.п. - так создайте! разве нет отдела разработки?

Думаю, это необоснованно дорого будет стоить, нет смысла это делать для всей БД. Это можно сделать в интеграционном решении.

Prometeusll wrote:Проще добавить новую запись в БД(База данных), чем обновить существующую, на таких объёмах данных это практически невозможно сделать. - дайте пользователю, который создал ВСД - удалить это ВСД! Даллее по расписанию регламентным заданием очищать БД от удаленных ВСД. БД меньше будет разраста́ться и не загибаться.

Чем вас аннулирование ВСД не устраивает?

Очевидно никто не будет делать эти улучшения.

№ 1 и № 2
В общем случае для некоторых видов товаров сроки сроки годности могут быть представлены в виде неполной даты(8 форматов дат http://help.vetrf.ru/wiki/%D0%A4%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D1%8B_%D0%B4%D0%B0%D1%82 ).
Для живых животных он может быть не указан.

<vd:expiryDate>
<vd:firstDate>
<dt:year>2021</dt:year>
<dt:month>12</dt:month>
<dt:day>6</dt:day>
<dt:hour>1</dt:hour>
</vd:firstDate>
</vd:expiryDate>

Т.е. даты в Меркурии хранятся не в виде даты, которая может участвовать в сравнении.

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

Этот функционал вы можете реализовать в своём интеграционном решении или использовать имеющиеся.

№ 3
Очевидно, что меркурий всячески пытается избежать обновляемых полей, и это правильно.
Проще добавить новую запись в БД(База данных), чем обновить существующую, на таких объёмах данных это практически невозможно сделать. Любая БД загнётся, либо нужно каждый деть отключать систему от работы для сервисного обслуживания, проводить VACUUM и т.п.

nmzn1 wrote:

dk wrote:Вот самому интересно какая чёткая процедура назначения Администратора ХС для пользователя.
Нужно писать и вести заявление с подписями, печатями, доверенностями и т.п. или достаточно только позвонить в ТУ РСХН?

заявление подавать с подписями-печатями в ТУ/ВУ, а лучше всего было при первой подаче заявления на подключение указать одного поль-ля - директора с правом админХС

Есть где-нибудь бланк для этого заявления?

Вот самому интересно какая чёткая процедура назначения Администратора ХС для пользователя.
Нужно писать и вести заявление с подписями, печатями, доверенностями и т.п. или достаточно только позвонить в ТУ РСХН?

1. Пользовать с правами Администратор ХС, может назначить необходимые права через Ветис.Паспорт или Ветис.API(интеграционное решение).
2. Поставщик может аннулировать ВСД, которое он выписал.

С помощью запроса GetVetDocumentByUuidOperation можно определить текущее состояние ВСД.
Но не факт, что за время запроса он не будет погашен, например через вёб или другую программу.

Единственный способ - это работа в одной программе с единой централизованной БД.

У нас, если все пользователи ХС работают только в нашей программе, то такой ошибки не будет, но если они одновременно работают в какой-нибудь другой программе, то ошибка возможна.

oleg-x wrote:

dk wrote:

oleg-x wrote:

dk wrote:Это как раз хорошая практика. Работать могут много пользователей одновременно, а остатки и новые ВСД одни на всех.

Имеется ввиду не получения остатков каждым пользователем, а выполнение запросов под администратором.

Остатки и новые ВСД от администратора, а действия от пользователя. Не обязательно у пользователя будут права на запрос новых ВСД, а у администратора должны быть.

В ВетисAPI нет разграничений прав на получение остатков и получение ВСД. Там есть только на чтение и выполнение операции. А так же дополнительные права на выписку ВСД и оформление возврата.
То есть такие ограничения могут быть только на уровне интеграционного решения.

О разграничении прав на получение остатков и получение ВСД никто не говорил.

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

oleg-x wrote:

dk wrote:Это как раз хорошая практика. Работать могут много пользователей одновременно, а остатки и новые ВСД одни на всех.

Имеется ввиду не получения остатков каждым пользователем, а выполнение запросов под администратором.

Остатки и новые ВСД от администратора, а действия от пользователя. Не обязательно у пользователя будут права на запрос новых ВСД, а у администратора должны быть.

oleg-x wrote:

undefined wrote:Вопрос решён. Звёзды совпали таким образом, что при отправке запроса в качестве инициатора подставлялся единственный заблокированный пользователь этого предприятия. Сейчас посмотрю алгоритм выбора пользователя, исправлю. Доложен был подставиться администратор предприятия и я был уверен что так и происходит.

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

Это как раз хорошая практика. Работать могут много пользователей одновременно, а остатки и новые ВСД одни на всех.

oleg-x wrote:

B1-66ER wrote:

oleg-x wrote:

griny28rusgmailcom wrote:Если они сделают групповое гашение, то тогда народу не нужны будут услуги сторонних компаний, в свою очередь эти компании, те что у них в списке им платят!

Где вы взяли информацию о том, что компании на сайте РСХНД платят РСХНД.
Это похоже как в социальных сетях, выдумать всякую хрень и написать, пусть все лайкают.
Этого хватает на других развлекательных сайтах, а здесь хотелось бы видеть объективную информацию.

Наивный

Скажу для непонятливых. Любой желающий может создать продукт, работающий через шлюз и продавать или распространять бесплатно.
Если хочет, может написать Власову и попросить разместить ссылку на сайт о своем продукте на сайте РСХН абсолютно бесплатно.
Это будет бесплатная реклама вашему продукту, а РСХНД полностью отстранен от разработки интеграционных решений и занимается только развитием шлюза.
Все кто хотел на данный момент воспользоваться данной возможностью, воспользовались.

Ничего подобного:
По вопросу о заключении соглашения о партнерстве и сотрудничестве обратитесь в Информационно-аналитический отдел Центрального аппарата федеральной службы по ветеринарному и фитосанитарному надзору (http://www.fsvps.ru/fsvps/structure/top#dep18).

А вот и начались задержки

В этом году даже задержек больших пока не было.