Использование регионализации и частота ее обновлений

Добрый день!

Прошу помочь в вопросе Регионализации. На данный момент процедура получения и интеграции в запрос на отгрузку занимает от 1,5 до 5 секунд! При наших объемах такая трата времени критична. Входные данные: GUID-ы нашего и клиентского Enterprise.

Можно ли хранить регионализацию в своей системе? Как часто ее надо обновлять? Или придется запрашивать информацию при каждой отгрузке (оформлении транспортных ВСД)?

Коллеги, интересны мысли пользователей и официальная позиция ведомства.

Павел.

Не только 2 предприятия, а еще точки маршрута.
Я полагаю, доверять результатам проверки на регионализацию можно до конца текущих суток. Если условие регионализации возникнет после того, как предыдущий (разрешающий) ответ был обработан и закеширован Вами, операция генерации транспортного сертификата не пройдет из-за ошибки "не подтверждены условия регионализации" или как-то похоже. Можно, с другой стороны, вообще не кешировать, а пробовать создавать транспортный сертификат, а вот в случае ошибки с известным номером - начинать канитель с выяснением условий регионализации, заставлять пользователя ставить галочки и т.д.

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

Благодарю Владимир, с Вашего позволения разберу ответ по цитатам.

Владимир Игнатов wrote:Не только 2 предприятия, а еще точки маршрута

Наша доставка не предполагает точек перегруза, не подумал о вариативности других вариантов логистики.

Владимир Игнатов wrote:а пробовать создавать транспортный сертификат

Этот вариант точно нет, так как существуют озвученные санкции за превышение определенного процента ошибок в день!

http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.API Пункт 12.1.
Такая мысль у меня была с целью определения достаточности количества товара на остатках, но увы, контролирую остатки без Меркурий.

Владимир Игнатов wrote:заставлять пользователя ставить галочки

При интеграции нет вообще возможности привлечения ручного труда. Если за ночь уходит 1000+ ТТН, то палец сотрешь галочки ставить.

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

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

Владимир, расскажите пожалуйста, почему нельзя кешировать галочки проставленные пользователем?
Просто мы их кешируем в разрезе точекмаршрута и видов продукции и криминала в этом пока не видим

UPD^
При подготовки транзакции смотрим есть ли у нас сохраненные галочки по этому маршруту этого 3 уровня продукции и если есть - просто их и используем.
Если нет - запрашиваем, просим поставить галки. (их как-раз и запомним)
Если так случилось что наши "запомненные" галочки устарели и там теперь новые - то Меркурий нам транзакцию свалит, что мы и выведем пользователю, обработчик заметит специфичный код ошибки и заново запросит условия и заново попросит пользователя проставить галки на уже обновленный набор условий

miskevich wrote:

Владимир Игнатов wrote:а пробовать создавать транспортный сертификат

Этот вариант точно нет, так как существуют озвученные санкции за превышение определенного процента ошибок в день!

Санкции же за ошибки, а ошибку вы не совершили если ВСД не сумел оформиться

Павел Большаков wrote:

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

Владимир, расскажите пожалуйста, почему нельзя кешировать галочки проставленные пользователем?
Просто мы их кешируем в разрезе точек маршрута и видов продукции и криминала в этом пока не видим

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

Павел Большаков wrote:Санкции же за ошибки, а ошибку вы не совершили если ВСД не сумел оформиться

Повторюсь, вот тут http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.API в пункте 7.3 указано:
"количество запросов с ошибками с кодом MERC не должно превышать 10% от общего количества запросов этого типа в сутки. Ошибки с кодом APL и APLM отсутствуют"

Мне страшно слышать такое от сотрудника интегратора, которые должен учить пользователей! Вы ОБЯЗАНЫ хотя бы понимать термин ОШИБКА!
Если регионализация требуется, но не будет указана в запросе, то вернется ошибка типа MERC. А точнее "MERC02469 Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение)."

Вот здесь http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0 есть неприметный раздел "Коды ошибок". Почитайте, удивитесь.

Созданный ВСД - Ваша награда за отсутствие ошибок любого рода.

Думая с кешированием разобрались, нельзя.

Как же нужна позиция официальных лиц по вопросу "Насколько часто нужно обновлять информацию о регионализации"

miskevich wrote:

Павел Большаков wrote:Санкции же за ошибки, а ошибку вы не совершили если ВСД не сумел оформиться

Повторюсь, вот тут http://help.vetrf.ru/wiki/%D0%92%D0%B5%D1%82%D0%B8%D1%81.API в пункте 7.3 указано:
"количество запросов с ошибками с кодом MERC не должно превышать 10% от общего количества запросов этого типа в сутки. Ошибки с кодом APL и APLM отсутствуют"

Мне страшно слышать такое от сотрудника интегратора, которые должен учить пользователей! Вы ОБЯЗАНЫ хотя бы понимать термин ОШИБКА!
Если регионализация требуется, но не будет указана в запросе, то вернется ошибка типа MERC. А точнее "MERC02469 Указаны не все обязательные условия перевозки в соответствии с регионализацией. Необходимо указать все обязательные условия (т.е. подтвердить их выполнение)."

Вот здесь http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0 есть неприметный раздел "Коды ошибок". Почитайте, удивитесь.

Созданный ВСД - Ваша награда за отсутствие ошибок любого рода.

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

Ответ API о невозможности оформить ВСД и ошибка в оформленном ВСД - это разные понятия. (не смотря на то что и то и другое называется ошибкой)
Пункт 7.3 который Вы привели описывает правила предоставления боевой учетки и к санкциям не относится.
Обратите внимание, что небольшое количество MERC ошибок сервиса (в пределах 10%) вообще считается нормой. Кстати список merc ошибок http://help.vetrf.ru/wiki/PrepareOutgoingConsignmentOperation_v2.0 о котором Вы говорите неполный

Санкции же предусмотрены если явно обманываете Меркурий: например в результате оформленного ВСД продукцию можно перепутать. Это 589ый - там санкции и все они за обман а не за rejected в ответе на запрос.
Согласны?

Теперь немного об официальной позиции "со слов разработчиков" (этот вопрос как-раз был рассмотрен месяц назад на ECR) Кто в теме поправьте меня, пожалуйста, если я что-то упустил.
1. Время от времени Вы должны опрашивать свои классификаторы на предмет изменений. Это касается не только регионализации, но и других классификаторов.
2. Нет ничего криминального получить ошибку "условия устарели" т.к. все равно существует вероятность изменения этих правил "за секунду до отправки" А если делать обязательную проверку перед оформлением каждого ВСД то скорость отправки ВСД существенно уменьшится. (У нас например есть клиенты у которых тысячи транзакций должны быть отправлены в течении получаса, а это не так то просто с учетом всем известной проблемы блокировки партий, но это уже мои примечания)
3. На текущем этапе (со слов НА) не будет санкций за регионализацию вообще т.к. иначе "мы поставим в неравные условия ХСы на 1.4[прим. нет регионализации] и 2.0 - а это несправедливо"

А про кэширование галочек - это пока неизбежно. Никто не будет их каждый раз на интеграции ставить - все интеграторы через это прошли. (за исключением, возможно, совсем мелких ХС с 10 отгрузками в день)
Все понимают что кэширование - это палка с двумя концами. Но если не кэширование - тогда что? как в вебе? Кажется что у нас особо выбора то и нет...

Теоретически есть способ как настроить эти галочки (они могут зависеть от продукции/площадки отправителя/получателя/прочих условий) - можно прикрутить инструментарий настроек в разрезе всего этого, дифференцировать галочки на постоянные или условные и приблизиться к автоматизации регионализации "как надо", но сейчас у всех есть задачи поважнее.

И в конце. Прошу воздержаться от резких слов здесь в чей либо адрес - мы же почти коллеги, а это очень неприятно и сразу отбивает любое желание помогать. (я про: Мне страшно слышать такое от сотрудника интегратора, которые должен учить пользователей! Вы ОБЯЗАНЫ хотя бы понимать термин ОШИБКА!.... Почитайте, удивитесь.)
Я, кстати, тоже не безгрешен и однажды тут сказал лишнего - до сих пор немного стыдно за свои слова.

Владимир Игнатов wrote:

Павел Большаков wrote:

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

Владимир, расскажите пожалуйста, почему нельзя кешировать галочки проставленные пользователем?
Просто мы их кешируем в разрезе точек маршрута и видов продукции и криминала в этом пока не видим

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

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

А Вы сейчас заставляете пользователей ставить галки? Сколько у Вас отгрузок?

Павел Большаков wrote:

Владимир Игнатов wrote:

Павел Большаков wrote:

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

Владимир, расскажите пожалуйста, почему нельзя кешировать галочки проставленные пользователем?
Просто мы их кешируем в разрезе точек маршрута и видов продукции и криминала в этом пока не видим

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

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

А Вы сейчас заставляете пользователей ставить галки? Сколько у Вас отгрузок?

Во! Заавтокомплитить-автопроставить из кеша, но не автоматически внести данные из кеша в "соблюдение условий регионализации" в генерируемый сертификат, не даже уведомив пользователя.
У меня отгрузок пока немного, в основном по городу.

Да, само-собой решение за пользователем, но

Когда отгрузок хотя бы 1000 в день (а это минимум для более-менее серьезного предприятия) то пользователи не станут их просматривать проверять, а скажут, "ааа, и тааак сойдет" (с)

Павел Большаков wrote:
Когда отгрузок хотя бы 1000 в день (а это минимум для более-менее серьезного предприятия) то пользователи не станут их просматривать проверять, а скажут, "ааа, и тааак сойдет" (с)

... "и будут как всегда в когне не правы!" (с)
Но здесь уже вопрос разделения зон ответственности. Если тов. пользователь так хочет, плотно зажмурив глазки, что-то там наотмечать - никто ему помешать не сможет, а вот если это интеграционное решение вместо пользователя из кеша взяло какие-то галочки - виноват только разработчик того ПО.

Дорогие мои борцы за правильность, вот вам простой пример из жизни:
Есть производитель, которые ответственно производит и ответственно доставляет клиентом свой товар. Внезапно появляется Меркурий и говорит "ты должен соблюдать правила регионализации или не доставлять товар!".

Внимание вопрос: Как поступить производитель, если он не соблюдает или соблюдает частично эти правила?
Варианты ответов:
1. Перестанет доставлять товар, который много лет доставлял
2. Продолжит доставлять товар
3. Прекратит производить товар
4. Сначала потратить N-е количество времени, чтобы начать соблюдать все указанные правила.

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

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