дублируется значение реквизита код строки
Обнаружено дублирование ключевых значений в 1C 8.3
Абсолютно любая конфигурация 1С может выдать ошибку.
Она может быть вызвана при работе в режиме управляемого приложения, при открытии списка, формы выбора или установлении отбора. Другими словами, программа применяет запрос в динамическом списке.
При переносе из-за сбоя могут возникнуть дублирующие строки. В списке будут содержаться идентичные ссылки на регистр или справочник. К примеру, при установлении отбора в справочнике «Сотрудники». В результате появляется подобная ошибка.
Были и такие случаи, когда ошибка возникала при установлении отбора по группе в справочнике «Номенклатура» в «1С:Управление торговлей», при открытии «Входящие ТТН для ЕГАИС» в «1С:Розница».
Для устранения подобной ошибки требуется удалить из списка запроса ссылки, которые повторяются. Для этого нужно осуществить проверку регистров.
В ситуации со справочником «Сотрудников» необходимо проверить регистры текущих данных (кадровая информация и тарифная ставка), чтобы в них отсутствовали дубли по одному и тому же сотруднику, и регистр «Основные сотрудники», чтобы не было физических лиц с незаполненной информацией.
Здесь может быть сохранена информация о том, когда сотрудник устроился на работу и когда был уволен с нее, но почему-то первая запись не была удалена и произошло образование дублей.
Тогда требуется просмотреть записи регистров. В том случае, если подобная запись попадается, ее нужно удалить (предыдущую, оставив одну последнюю). В результате этого ошибка исчезает. Просмотр регистров осуществляется при помощи команды «Все функции».
Если этот раздел недоступен, то включить его можно в меню «Сервис-Параметры», для этого требуется установить соответствующую галочку.
Открыв регистр и проведя анализ информации, при обнаружении дублирующих записей их требуется удалить.
Появление ошибки происходит, так как динамические списки не поддерживают дублирование записей по ключевым полям. Когда вы работаете с динамическим списком, записи формируются в основную таблицу. Из нее происходит динамическое считывание сведений.
«Код строки» или Сопоставление табличной части Товары у документов «Заказ поставщика» и «Поступление товаров и услуг»
Конечно, данная разработка не является чем-то ВЕЛИКИМ, но тоже достойна внимания.
Возможно, эксперты скажут, что что-то есть на infostart. Или регламентные задания и обработки правят всё сами. Не знаю. Может, и так.
Я лично не нашел ничего и написал свой метод исправления поступлений товаров и услуг.
Введение:
Недавно столкнулся с данной проблемой и не нашел ничего путного в интернете. Ни статей, ни форумов.
Впрочем нет, была статья, но автор выложил конфигурацию целую, и я так и не понял, зачем это всё.))
Все ссылки на похожие статьи я выложу ниже.
Итак. Есть Заказ. На его основании создается Поступление. Номенклатура между документами синхронизируется по реквизиту «КодСтроки».
Что делает обработка:
1) показывает все Заказы и Поступления, по которым случился рассинхрон.
2) правит собственно.
Как пользоваться:
Тут всё крайне просто. Запускаем открываем, жмем кнопку и видим все баги.
Кстати, если рассинхрон, то можно его видеть по специальной картинке в Поступлении ТУ.
После исправления, картинка должна исчезнуть.
Точечно выбираем то, что нужно поправить, и правим.
Ну и добавлю, что не стал бы тратить время на статью, если б сам не потратил уйму времени на выяснение причин проблем со статусами.
С КодСтроки тоже не все так тривиально оказалось, поэтому и решил сэкономить время тем, кто столкнется с подобными проблемами.
Желаю успехов в разработке 🙂
Ссылки на похожие статьи:
Скачать файлы
Специальные предложения
Такой конфигурации ERP не бывает 🙂
КодСтроки это головная боль, которая тянется в ERP еще с ранних версий. Мы столкнулись с этой проблемой на связке Заказов на перемещение и Перемещениями товаров. Контроль отрицательных остатков в этом случае работал только по регистру Товары организаций, а регистр Себестоимость товаров уходила в минус, что доставляло немало головной боли при закрытии месяца.
Не помню в каком документе, но тип реквизита КодСтроки, разработчиками ERP, с числового был изменен на Уникальный Идентификатор, что гораздо лучше. К сожалению не во всех документах.
В итоге у нас есть тысячи перемещений созданных на основании сотен заказов на перемещение, где 1 строка с общим количеством из заказа на перемещение была раскидана по разным документам перемещений с одинаковыми кодами. Как такое исправлять непонятно, нет зависимости Один к Одному. Т.е. даже если исправить код строки в заказах на перемещение, то такой же код можно проставить ровно одной строке в документе перемещения, но она там разбита на несколько, а схлопнуть не представляется возможным, т.к. там разные аналитики и т.д. и т.п. Стало быть надо строки бить уже в самих заказах на перемещение. В общем еще один кошмар после Ключей Аналитики Номенклатуры.
Проверка на наличие дублирующихся строк в табличных частях
Здесь все достаточно просто. Обращаемся к данным табличной части документа, группируем по ключевым полям с использование агрегатной функции для подсчета количества номеров строк. Накладываем условие по вычисленному значению агрегатной функции. Все.
2) Классика жанра. Выведем в сообщении пользователю номера всех тех строк табличной части, которые являются дублями.
Запрос = Новый Запрос ;
А теперь попробуем оценить перспективу доработки. Допустим, у нас изменился состав ключевых полей в сторону увеличения их количества: добавились ЕдиницаИзмерения и ЗаказПокупателя. Чтобы контроль дублей строк не перестал работать, нам нужно доработать запрос и обход результата запроса следующим образом:
3) Альтернативный вариант.
Несколько комментариев по поводу запроса.
Теперь о производительности. Производились тестовые замеры каждого из вариантов на документе с большим количеством строк в табличной части. Количество строк в тестируемом документе: 47 817, 4 комбинации ключевых полей с дублями по 2, 2, 3 и 4 строки. Результаты замеров:
Вариант 1) 0:00:00.078 сек.
Вариант 2) 0:00:00.265 сек.
Вариант 3) 0:00:01.513 сек.
Как видим, третий вариант, как и ожидалось, самый медленный, но он же является самым удобным в перспективе модификации.
Прилагаемая обработка является демонстратором третьего варианта. Работает она и в обычном, и в управляемом режимах. Внешний вид и функционал полностью одинаков.
1) Выбираем вид объекта: Документ или Справочник.
2) Выбираем тип объекта: Какой именно документ или справочник.
3) Выбираем табличную часть объекта.
4) Определяем состав ключевых полей в специальном диалоге
5) Если мы хотим, то можем указать ссылку на объект, чтобы проверить его на наличие дублей.
6) Если активен флажок «Сгенерировать и показать код для проверки на дубли», то будет сгенерирован программный код для выполнения проверки на дубли строк с имеющимися настройками.
Эксперт по технологическим вопросам ООО ЦБР ИнфоСофт
«Код строки» или Сопоставление табличной части Товары у документов «Заказ поставщика» и «Поступление товаров и услуг»
Конечно, данная разработка не является чем-то ВЕЛИКИМ, но тоже достойна внимания.
Возможно, эксперты скажут, что что-то есть на infostart. Или регламентные задания и обработки правят всё сами. Не знаю. Может, и так.
Я лично не нашел ничего и написал свой метод исправления поступлений товаров и услуг.
Введение:
Недавно столкнулся с данной проблемой и не нашел ничего путного в интернете. Ни статей, ни форумов.
Впрочем нет, была статья, но автор выложил конфигурацию целую, и я так и не понял, зачем это всё.))
Все ссылки на похожие статьи я выложу ниже.
Итак. Есть Заказ. На его основании создается Поступление. Номенклатура между документами синхронизируется по реквизиту «КодСтроки».
Вроде все просто, но как всегда есть подводные камни. В моем случае, часто сбивалась синхронизация. Возможно это особенность нашей конфы, а может, и на стандартной erp 8.3 тоже глючит. В любом случае проблема имеет место быть, а данная обработка корректирует систему и исправляет доки. Рассинхрон по строкам влияет в моем случае на корректное закрытие документа «Заказ поставщика», а именно — статус в документа не меняется.
Что делает обработка:
1) показывает все Заказы и Поступления, по которым случился рассинхрон.
2) правит собственно.
Как пользоваться:
Тут всё крайне просто. Запускаем открываем, жмем кнопку и видим все баги.
Кстати, если рассинхрон, то можно его видеть по специальной картинке в Поступлении ТУ.
После исправления, картинка должна исчезнуть.
Точечно выбираем то, что нужно поправить, и правим.
Ну и добавлю, что не стал бы тратить время на статью, если б сам не потратил уйму времени на выяснение причин проблем со статусами.
С КодСтроки тоже не все так тривиально оказалось, поэтому и решил сэкономить время тем, кто столкнется с подобными проблемами.
Желаю успехов в разработке 🙂
Ссылки на похожие статьи:
Related Posts
3 Comments
Ещё бы для реализаций и заказов клиентов такую.
Такой конфигурации ERP не бывает 🙂
КодСтроки это головная боль, которая тянется в ERP еще с ранних версий. Мы столкнулись с этой проблемой на связке Заказов на перемещение и Перемещениями товаров. Контроль отрицательных остатков в этом случае работал только по регистру Товары организаций, а регистр Себестоимость товаров уходила в минус, что доставляло немало головной боли при закрытии месяца.
Не помню в каком документе, но тип реквизита КодСтроки, разработчиками ERP, с числового был изменен на Уникальный Идентификатор, что гораздо лучше. К сожалению не во всех документах.
В итоге у нас есть тысячи перемещений созданных на основании сотен заказов на перемещение, где 1 строка с общим количеством из заказа на перемещение была раскидана по разным документам перемещений с одинаковыми кодами. Как такое исправлять непонятно, нет зависимости Один к Одному. Т.е. даже если исправить код строки в заказах на перемещение, то такой же код можно проставить ровно одной строке в документе перемещения, но она там разбита на несколько, а схлопнуть не представляется возможным, т.к. там разные аналитики и т.д. и т.п. Стало быть надо строки бить уже в самих заказах на перемещение. В общем еще один кошмар после Ключей Аналитики Номенклатуры.
Ввод по строке (переопределение)
При работе с клиентом столкнулся с пожеланием к вводу по строке при заполнении документа «Реализация товаров и услуг».
А именно было необходимо, чтобы система искала нужную номенклатуру, при наборе с клавиатуры не только по первым символам (это стандартное поведение), но и по вхождению введенных символов в название.
Если мы начинаем набор со слова «газета», система нам находит нужную позицию. Совсем другое дело, если мы не помним точно, как у нас записана нужная номенклатура и, допустим, начинаем ввод со слова «Ярмарка». В этом случае система не сможет найти нужную нам позицию:
В принципе, мы могли бы изменить обработчик изменения реквизита нужной нам формы, но этот метод является менее предпочтительным, если алгоритм работы нам необходимо поменять во всех формах, где используется нужный нам тип данных, т.е. справочник «Номенклатура».
Итак, обращаемся к модулю менеджера справочника «Номенклатура»:
В результате одной небольшой процедурой мы полностью решили поставленную задачу:
Данный способ решиния задачи я использовал еще на Платформе 2.0. Как подсказали в комментариях коллеги в Платформе 3.0 задача решается ещё проще. В справочнике на закладке «Поле ввода» можно выбрать режим ввода по строке. Там два варианта: «начало» и «любая часть«.