Добрый день! Время от времени поставщики меняют в меркурии продукцию (удаляют старую, пересоздают новую), в связи с чем в КА 2.4 возникают большие сложности с удаленной продукцией, которую невозможно ни принять, ни отписать (т.к. статус у продукции "удален"). При работе через сайт автоматом подтягивается новая продукция.  В 1С я могу вручную подтянуть нужную продукцию из мерка, но тогда в справочнике продукции уже 2 позиции- одна удаленная, вторая актуальная, а все остатки числятся на удаленной (запрос журнала продукции ничего не меняет). Вопрос к тем, кто работает с меркурием через 1С: как вы обрабатываете подобные ошибки?

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

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

(2) нет, это не косяк. Это норма. Дело в том, что в Меркурии продукция является версионной сущностью. Это означает, что при любой правке, например, наименования, образуется новая актуальная версия номенклатуры, а то что уже находится в обороте - живёт с предыдущими версиями, с теми, которые были на момент создания этих партий. Удаление номенклатуры в терминах Меркурия означает всего лишь то, что нет больше актуальной версии, т.е. нельзя создать новую партию с этой номенклатурой. А старые в зависимости от своих сроков годности могут быть в обороте ещё месяцами и годами. Поэтому мне, если честно, не очень понятно, почему (0) пишет что нельзя даже погасить такую партию.

(3) вы говорите про UUID (номер версии записи), а в 1С скорее всего используется GUID (идентификатор).

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

Тогда это не удаление,а запрет использования.
Собственно говоря,в 1с тоже такое есть.
Дело в том,что пометка на удалкние номенклатуры,по которой были движения,никак эти движения,собственно как и документы,где эта номенклатура встречается,не удаляет.

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

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

(0) тру-программисты, разрабатывающие тру-системы на тру-языках, не слышали о целостности реляционных бд. До 1сников им как до Луны...

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

(10) ну да, поэтому можно одним движением снести весь свой же 4уровень и радостно смотреть на остатки в складском журнале ))) Конечно, очень умная архитектура.

(11) в любой системе есть свой формат це.