Ошибка в 1С: Значение поля Код не уникально
Такая ошибка возникает при добавлении нового элемента справочника, система автоматически присваивает элементу новый “Код”, но не дает сохранить объект.
Причиной является неправильная нумерация в справочнике. Происходит это когда пользователи вручную редактирует поле “Код” в элементах справочника.
Принцип нумерации справочника в 1С такой:
Код = Префикс+числовой код предыдущего элемента + 1.
Допустим код справочника состоит из 4-х символов, есть префикс “А” — он ставиться во всех элементах, остальные 3 знака используются под числовую составляющую кода. Если пользователь изменит код любого элемента справочника на “А999”, то при создании следующего элемента возникнет ошибка Значение поля “Код” не уникально, потому что система пытается прибавить к числовой составляющей кода единица, но разрядов для создания элемента с кодом А1000 не хватает. Такого рода ошибки могут всплыть не сразу, например если пользователь изменить код какого нибудь элемента на А990, то не уникальный код появится на десятом созданном впоследствии элементе.
Решить проблему можно, либо найдя неверно пронумерованный элемент и исправив его “Код” на корректный(а также перенумеровав все созданные после него элементы), либо если вручную эту работу проделать невозможно, то можно воспользоваться обработкой УниверсальныеПодборИОбработкаОбъектов (скачать можно по ссылке), при помощи нее перенумеровав все элементы справочника
Особенности кода счета в 1С:Предприятии 8
Код счета
Код счета хранится в информационной базе в том виде, в котором был введен. Исключение составляет хранение кода счета в условиях, когда маска кода счета содержит символы “@”. В этом случае группа знаков кода, для которой в маске стоят символы “@”, упаковывается – из нее вырезаются пробелы.
При создании нового счета или редактировании уже имеющегося счета в плане счетов код счета редактируется с использованием маски. При вводе ссылки на счета в записях регистров и в других местах код счета вводится без маски.
Перед началом редактирования счета в плане счетов, код счета распаковывается до вида, подходящего под маску. После окончания редактирования код счета упаковывается.
Рассмотрим пример упаковки – распаковки кода счета. Пусть есть некоторый план счетов, для которого указано:
Выполним следующие действия:
Порядок счета
В информационной базе порядок счета хранится в том виде, в котором был задан. Задавать порядок счета можно только в том случае, если длина поля Порядок больше нуля.
В форме счета поле Порядок доступно для редактирования, однако по умолчанию в форму не включается, и его содержимое автоматически не заполняется. Если длина поля Порядок больше нуля и значение, записываемое в поле, представляет собой пустую строку, записать объект Счет не удастся, и произойдет соответствующая ошибка времени выполнения.
Если маска кода счета состоит только из символов «@» и «.», можно автоматически сформировать поле Порядок. Это можно сделать в обработчике события ПередЗаписью() с помощью метода ПолучитьПорядокКода():
Процедура ПередЗаписью(Отказ)
Порядок = ПолучитьПорядокКода();
КонецПроцедуры
При формировании порядка счета функция ПолучитьПорядокКода() за основу берет код счета. В пределах групп номера счета символы кода счета сдвигаются вправо, дополняясь слева необходимым количеством пробелов.
Рассмотрим два примера:
1) Код счета: «10.12»
Маска кода счета: «@@@.@@@.@@»
Сформированный прядок счета: » 10. 12″
2) Код счета: «10.5»
Маска кода счета: «@@@.@@@.@@»
Сформированный прядок счета: » 10. 5″
Свойство АвтоПорядокПоКоду
Свойство АвтоПорядокПоКоду используется для подмены упорядочивания по полю Код упорядочиванием по полю Порядок. Упорядочивание по полю Порядок в этом случае используется как, например, в формах списков счетов, так и в процессе формирования запросов.
Пример использования свойства АвтоПорядокПоКоду в форме списка счетов
На рисунке видно, что в качестве колонки, по которой идет сортировка, отмечена колонка Код. Однако реально для сортировки используются данные из поля Порядок.
На рисунке видно, что сортировка данных не изменилась. Это действительно так, поскольку свойство АвтоПорядокПоКоду включено.
Если же свойство АвтоПорядокПоКоду выключить, то сортировка будет выполняться иначе:
На рисунке видно, что сортировка выполнена по полю Порядок.
На рисунке видно, что порядок следования счетов сменился и упорядочивание происходит по полю Код.
Пример использования свойства АвтоПорядокПоКоду в запросе
Пусть есть следующие счета:
Код Наименование Порядок
3.3.3 Счет 3.3.3 1
2.2.2 Счет 2.2.2 2
1.1.1 Счет 1.1.1 3
Выполним следующий запрос:
ВЫБРАТЬ
ПланСчетов1.Код КАК Код,
ПланСчетов1.Наименование,
ПланСчетов1.Порядок
ИЗ
ПланСчетов.ПланСчетов1 КАК ПланСчетов1
УПОРЯДОЧИТЬ ПО
Код
На этом примере видно, что в случае упорядочивания по полю Код вместо него используется поле Порядок.
Что делать в 2021, если в Плане счетов 1С создали свой счет 10.12
Вопрос задал sh***@sbskyline.ru
Ответственный за ответ: Ирина Шаврова (★9.82/10)
Добрый день. В моем плане счетов в 1С на данный момент есть с/счет 10.12 (этот субсчет мы создали сами в 1С для собственных нужд). Сейчас 1С готовит обновление где планирует использовать субсчет 10.12 для отражения малоценных объектов. Как пройдет данное обновление в моей базе, ведь если я правильно понимаю не может быть в 1С двух одинаковых счетов. Как поступить в данной ситуации. Спасибо.
Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно
Все комментарии (5)
Добрый вечер,
Да, вы совершенно правильно беспокоитесь.
У наших клиентов были такие случаи с Торговым сбором 68.13 раньше, когда счет они ввели для своих нужд самостоятельно и в какой-то момент 1С использовала этот счет в обновлении.
Кто не обратил на это внимание — потерял данные.
Как в этом случае ведет себя программа?
Обычно, в таких случаях при обновлении базы данных появляется ошибка, которая выглядит так, например: «Объект изменен: ПланСчетов.Хозрасчетный! Код счета не уникален:Хозрасчетный (10.12)!»
При этом сама конфигурация обновляется. И поскольку данные нового обновления затирают текущие, то данные своего счета можно потерять, если свой счет вводился в пользовательском режиме (счет обновления — всегда предопределен).
Если же вы вводили свой счет в конфигурацию и сделали его предопределенным, то скорее всего обновиться вы не сможете: предупреждение будет выдано в момент приема изменений обновления.
Поэтому для начала нужно себе ответить на вопрос: у вас добавлен свой счет 10.12 в пользовательском режиме или в конфигураторе?
Исправить ситуацию можно только переименовав счет.
Двух одинаковых счетов в Плане счетов быть не может. Изменить можно ваш счет или счет добавляемый разработчиком. Но второй вариант — это очень сложный путь, поскольку дорабатывать придется очень много: от закрытия регламентных операции и участия нового счета в отчетах и сдаче отчетности.
Не вариант.
В курсах Ольги Шерст мы не советуем добавлять свои счета и как раз ссылаемся на опыт со счетом 68.13, от которого некоторые пользователи пострадали.
Для анализа ситуации самые важные вопросы:
— ваш счет был добавлен в пользовательском режиме или в конфигураторе?
— ваш счет добавлен как предопределенный?
— как записываются данные в него: через настройку регистра счета учета номенклатуры?
— готовы ли вы его переименовать?
— пробовали ли вы в копии поменять субсчет 10.12 в Плане счетов на другой, например, 10.13 чтобы освободить место для типового 10.12 (внимание: данные после переименования останутся в счете)?
В зависимости от этого нужно рассматривать вопрос.
Иначе вы можете потерять при обновлении все данные, которые хранились на этом счете.
Предварительная работа:
1. Если создавали в пользовательском режиме новый счет, попробуйте в копии базы его переименовать в Плане счетов. Все данные должны сохраниться. Так вы освободите место под новый счет 10.12, который будут использовать разработчики.
2. При обновлении сначала выполните обновление на копии базы, потом уже если все хорошо, выполняйте в рабочей базе.
PS: Если необходимо сохранить свой счет 10.12 и не использовать новый счет — придется привлекать к обновлению программиста.
Вот счастливый случай, когда сисадмин при обновлении через конфигуратор увидел ситуацию не уникальности счета и тормознул обновление:
https://profbuh8.ru/smart_faq/net-cherez-konfigurator-obnovlyatsya-i/
При автоматическом обновлении данные просто затерлись бы.
Благодарю за подробный ответ. Выход вижу для себя один, переименовать счет в другой. Только вот интересует правовая сторона вопроса. Позволяет ли законодательство использовать счет 10.12 в 2020 году для одних нужд (соответственно его использование прописано в учетной политике), а с 01.01.2021 прописать, что теперь счет 10.12 это «Малоценные предметы», а используемый нами счет это теперь например 10.20?
Обратите внимание, что мы не аудиторы, поэтому по вопросам методологии учета я не вправе давать экспертных разъяснений. Могу выразить только свое профессиональное мнение, не претендуя на уровень экспертной оценки.
В законе «О бухгалтерском учете» от 06.12.2011 № 402-ФЗ перечислен закрытый перечень условий, при наличии которых в действующую учетную политику могут вноситься изменения (п. 6 ст. 8), например, появление новых требований в бухгалтерском законодательстве;
Я думаю, что это как раз наш случай: с 2021 года вступает в силу новый ФСБУ 5/2019 «Запасы». Он во многом меняет подход и принципы учета ТМЦ и добавляет использование нового счета 10.12.
После обновления БГУ на 1.0.49.4
Вот еще одно подтверждение того, что первые релизы с таким серъёзным реформированием всегда содержат ошибки и не конца потестированы.
Лучше подождать или на копии, проверять и принимать решение.
Коллеги, вчера обновился (ЗКБУ на платформе 8.3.9.2033) с 1.0.48.5 на 1.0.49.4.
Полагаю, тем у кого описанные проблемы, косяки следует искать в своих базах.
Добрый день.
Спасибо за предложенные решения проблемы. Пока справляемся очищением в правом углу даты.
Но эти неактуальные счета участвуют в контроле дублирования записей регистра.
Еще комментарий по делу:
В обновлении добавлены два новых реквизита в элемент плана счетов: ДатаНачала и ДатаОкончания (недоступных для редактирования на форме). В форме выбора счета добавлен отбор по некоей дате актуальности. Однако, у некоторых клиентов после обновления все без исключения счета имеют период начала и окончания равный пустой дате, из-за этого всякий раз выборе счета нужно очищать соответствующее поле ввода на форме. У других клиентов дата оконачания ставится 01.01.2999, что позволяет выбрать счет. Закономерности этой ошибки при этом мы не выявили, но это точно не связано с логической либо физической целостностью (либо утилиты платформы эти проблемы не выявляют). Регистр рабочих счетов здесь не при чем, со второй вкладки формы выбора счета выбираются без проблем.
Еще один комментарий:
И самое плохое в текущей ситуации то, что все ошибки скрытые. При обновление явного сообщения о ошибке нет. Все проявляется при тек. работе. А учитывая массовость данной ошибки, это явно очень негативный момент.
PS. Не поняла, зачем период действия счетов в плане счетов привязывать к рабочим счетам в обработке обновления? Разве этот период не регламентирован инструкциями? Почему его нельзя програмно проставить в зависимости от номера счета, или подчинения к какому-либо счету (в том случае, когда пользователем добавлен субсчет какого то конечного счета). Не лучше ли привязывать период к рабочим счетам только к добавленным пользователем счетам, т.е. к тем которые не регламентированы.
И это только малая часть. Нормально давать такое обновление в конце года?
Ошибка при обновлении
Если наблюдать за системой в момент ошибки то видно что процесс 1с занимает памяти около 4GB но свободной памяти еще около 9Gb.
Причем если запустить базу еще раз то опять поинтересуется легальностью обновления опять запустит обновление информационной базы но далее все произойдет штатно откроется окошко которое расскажет нам о прелестях новой версии.
Люди добрые, подскажите на сколько велика вероятность того, что в момент этой ошибки, что то потеряется или сломается в инф. базе.
Были ли у кого нибудь подобные прецеденты как решали или я один такой рукожопый.
И еще где-то читал что на одной машине нельзя запускать сразу третью и вторую платформу при обновлении будут ошибки, не знаете какие должны быть ошибки.
Спасибо, и спасибо всем кто откликнулся вот что сделал.
v1.Берем чистую 11_0_9_14 загружаем туда наш dt
v2.Отключаем регламентные задания
v3.Изменяем заголовок
v4.Загружаем стандартные правила
v6.Очищаем адресный классификатор
v5.Удаляем версии объектов
v6.Отключаем версионирование полностью
v7.Делаем резервную копию.
v8.Загружаем чистый CF 11_0_9_14 для постановки на поддержку
v9.Обработка РегистрацияИзмененийДляОбмена82 удалить всю регистрацию изменений для всех объектов
v10.Делаем резервную копию
v11.обновление конфигурации через цфу 11_0_9_15 и обновление инф базы
v12.обновление конфигурации через цфу 11_1_2_8
v13.Делаем резервную копию.
v14.обновление инф базы 11_1_2_8 старт 13:00 05.02.14 ОКОНЧАНИЕ без ошибки 13:40 06.02.14
скорее всего помогла очистка регистрации изменений, или отключение параноидального версионирования объектов (как то с психу включил и забыл)
Платформа: 1С:Предприятие 8.3 (8.3.4.408)
Конфигурация: Управление торговлей, редакция 11.1 (11.1.2.28)
Продолжаю обновляться через cfu до версии 11.1 (11.1.4.10)
При анализе конфигурации до реструктуризации помимо предстоящих изменений в базе выдает три предупреждения
1.Объект изменен: Справочник.ВидыКонтактнойИнформации
Справочник.ВидыКонтактнойИнформации. Старые предопределенные данные будут удалены, возможно образование зависших ссылок на предопределенные данные
Регистрация изменена: Справочник.ВидыКонтактнойИнформации
2.Объект изменен: Справочник.НастройкиХозяйственныхОпераций
Справочник.НастройкиХозяйственныхОпераций. Старые предопределенные данные будут удалены, возможно образование зависших ссылок на предопределенные данные
Регистрация изменена: Справочник.НастройкиХозяйственныхОпераций
3.Объект изменен: ПланВидовХарактеристик.РазделыДатЗапретаИзменения
ПланВидовХарактеристик.РазделыДатЗапретаИзменения. Старые предопределенные данные будут удалены, возможно образование зависших ссылок на предопределенные данные
С этим можно жить, или необходимо что-то предпринять?