Мерурий и логика, где?! - Нет её!

Одна сегодняшняя новость меня малость взбесила.
В начале июля, была новость, что удаляются из справочника видов продукции часть 3-го уровня.
"О внесении изменений в справочник продукции компонента Меркурий" http://www.fsvps.ru/fsvps/news/30963.html
После анонса, мы быстро пробежались по своим позициям и изменили 3-й уровень продукции.

А сегодня - выкатили новость "О запрете изменения ветеринарной группы при редактировании справочника номенклатуры в компоненте Меркурий" http://www.fsvps.ru/fsvps/news/31360.html
Т.е. в очередной раз, когда в Меркурии решат "прибить" 3-й уровень в справочнике продукции, у пользователей не будет возможности изменить его на активный.

Команда "Меркурий" - молодцы!
Так держать!

правильная логика,
Вы полностью поменяли данные продукции, а UID все старые
как с программно с этим работать
API не дает работать с такими записями

MadeMa wrote:правильная логика,
Вы полностью поменяли данные продукции, а UID все старые
как с программно с этим работать
API не дает работать с такими записями

И в чём она правильная? Аргументируйте пожалуйста.
И что значит полностью поменяли данные продукции?
Вот "убили" Меркурианцы виды продукции в июле:
• чистопородная племенная свинья / хряк (0103),
• племенная и пользовательная свинья,
• племенной хряк (0103),
• племенная свинья (0103),
• свинья домашняя (0103).
Вместо неё предлагается использовать один вид = "свинья, хряк племенные (0103)"
Сейчас мы у позиций внесли требуемый вид продукции и при этом сохранили GUID и SKU.
API кстати даёт распродать сток со старым UUID.
Новые партии уже будут с новым UUID.
UUID вообще меняется при любом изменении позиции в Меркурии, скорректировали наименование согласно требований Власова Н.А. - всё новый UUID.
По Вашей логике при каждом изменении UUID - надо вносить новую позицию.
Сейчас GUID позиции можно сохранить, а он разослан и прописан у тысяч клиентов.
Замена SKU - это Вам не просто новую строчку в справочник внести.

В общем после 20-го августа очень многие взвоют.
В т.ч. сети.

Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.
Пользователи ничерта не понимают и начинаю терарезировать техподдержку, а они начинают разбираться и пытаются понять, что же произошло. А потом смотрят и о боже, просто производитель поправил карточку по видам продукции...
Это хорошо, если в рабочее время, а если нет...
Если бы меняли только, когда вносятся изменения в справочники 2 и 3 уровня. Но нет, многие просто меняют, от нежелания создавать новую.

oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.
Пользователи ничерта не понимают и начинаю терарезировать техподдержку, а они начинают разбираться и пытаются понять, что же произошло. А потом смотрят и о боже, просто производитель поправил карточку по видам продукции...
Это хорошо, если в рабочее время, а если нет...
Если бы меняли только, когда вносятся изменения в справочники 2 и 3 уровня. Но нет, многие просто меняют, от нежелания создавать новую.

Вы таки не поверите, но ни у кого из клиентов проблем не было.
Ввод новой SKU, это куда более проблематично для клиентов, нежели смена вида продукции в Мерке.

И в чём она правильная?

в том что продукция у Вас другая с точки зрения Меркурия (другая классификация) - иначе за чем эти 3 верхних уровня?

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

слов не хватает

MadeMa wrote:

И в чём она правильная?

в том что продукция у Вас другая с точки зрения Меркурия (другая классификация)

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

oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.

Это ошибка в интеграции, если имеется актуальный справочник ProductItem, то всё можно погасить и инвентаризировать.
Вместо того, чтобы выдать рекомендации для интеграций, решили, что проще запретить.

dk wrote:

oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.

Это ошибка в интеграции, если имеется актуальный справочник ProductItem, то всё можно погасить и инвентаризировать.
Вместо того, чтобы выдать рекомендации для интеграций, решили, что проще запретить.

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

dk wrote:

oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.

Это ошибка в интеграции, если имеется актуальный справочник ProductItem, то всё можно погасить и инвентаризировать.
Вместо того, чтобы выдать рекомендации для интеграций, решили, что проще запретить.

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

Yoreg07 wrote:

dk wrote:

oleg-x wrote:Вот Вы поменяли 3 уровень, а у ваших 1000 клиентов интеграция выругнулась, невозможно погасить, невозможно проинвентаризировать. Не соответствие данных.

Это ошибка в интеграции, если имеется актуальный справочник ProductItem, то всё можно погасить и инвентаризировать.
Вместо того, чтобы выдать рекомендации для интеграций, решили, что проще запретить.

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

subProduct guid берите из актуального справочника ProductItem, а не из ВСД.
Мы уже давно победили все проблемы с гашением через шлюз.

т.е. хотите сказать, что через WEB нельзя менять subProduct при гашении, а через API можно?

Yoreg07 wrote:т.е. хотите сказать, что через WEB нельзя менять subProduct при гашении, а через API можно?

Не могу понять вопроса! Менять ничего нельзя. В ВСД неактуальная информация subProduct.guid(она была актуальной на момент выписки ВСД), а при гашении мерк видимо сверяется с актуальным справочником ProductItem.

Разрешали бы указывать только productItem.guid, без subProduct, product, productType, тогда бы и проблемы такой не было.

dk wrote:

Yoreg07 wrote:т.е. хотите сказать, что через WEB нельзя менять subProduct при гашении, а через API можно?

Не могу понять вопроса! Менять ничего нельзя. В ВСД неактуальная информация subProduct.guid(она была актуальной на момент выписки ВСД), а при гашении мерк видимо сверяется с актуальным справочником ProductItem.

а как же MERC14231 Вид продукции в сведениях о принимаемой партии должен совпадать с указанным в ветеринарно-сопроводительном документе?

subProduct.guid у ProductItem на момент оформления был один, а перед гашением стал другим, но оба subProduct.guid на момент гашения актуальны в справочнике subProduct ... вот про какой момент я рассказываю.

что можете посоветовать? как гасить такие ВСД?