Каталог решений - Задвоение элементов плана счетов в базе на SQL.

Итак, суть бесполезности обработок:

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

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

Короче, полная шляпа.

В голову пришла хорошая идея, которая отработала на ура:

База на SQL сервере, значит, можно исправить задвоение в самой базе SQL, удалив элементы непосредственно из SQL и избежав ловушки проверок конфигурации.

Делаем Select такого вида (у меня задвоение прошло по 96 счету):

SELECT [_IDRRef]
      ,[_Version]
      ,[_Marked]
      ,[_PredefinedID]
      ,[_ParentIDRRef]
      ,[_Code]
      ,[_Description]
      ,[_OrderField]
      ,[_Kind]
      ,[_OffBalance]
      ,[_Fld530]
      ,[_Fld531]
      ,[_Fld18988]
      ,[_Fld532]
      ,[_Fld533]
      ,[_Fld534]
      ,[_Fld535]
  FROM [ИмяВашейБазыНаСервере].[dbo].[_Acc15]
  Where [_Code] Like '96%'

(чтобы определить, в какой таблице лежит «ПланСчетов», нужно воспользоваться любой обработкой анализа структуры БД на SQL или попробовать разобраться тут — https://its.1c.ru/db/metod8dev#content:1591:hdoc)

Получаем табличку с данными:

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

Обратите внимание, задвоился не весь 96 счет, а лишь его часть. Таким образом можно установить, что [_IDRRef] «Правильного счета» — 0x815400155D03291711E51852F63B454F, так как он описан как родитель в незадвоенных элементах в колонке [_ParentIDRRef].

В общем, после анализа делаем проверочный запрос, чтобы убедиться, что будем удалять то, что надо:

SELECT [_IDRRef]
      ,[_Version]
      ,[_Marked]
      ,[_PredefinedID]
      ,[_ParentIDRRef]
      ,[_Code]
      ,[_Description]
      ,[_OrderField]
      ,[_Kind]
      ,[_OffBalance]
      ,[_Fld530]
      ,[_Fld531]
      ,[_Fld18988]
      ,[_Fld532]
      ,[_Fld533]
      ,[_Fld534]
      ,[_Fld535]
  FROM [ИмяВашейБазыНаСервере].[dbo].[_Acc15]
  --Where [_Code] Like '96%'
 Where [_IDRRef] IN 
	(0x815400155D03291711E51846D90DC41A
	,0x815400155D03291711E51846D90DC412
	,0x815400155D03291711E51846D90DC414
	,0x815400155D03291711E51846D90DC421)

Ну и, проверив, по точно такой же логике проверяем, что удаляемые элементы связаны по родителю аналогично.

Теперь можно выполнить Delete:

USE [ИмяВашейБазыНаСервере]
go

DELETE FROM [dbo].[_Acc15]
      WHERE [_IDRRef] IN 
	(0x815400155D03291711E51846D90DC41A
	,0x815400155D03291711E51846D90DC412
	,0x815400155D03291711E51846D90DC414
	,0x815400155D03291711E51846D90DC421)
go

В итоге — задвоение убрали, БД целая. Едиственное, о чем стоит упомянуть — если по удаляемому счету есть обороты, сначала их надо перекинуть на «правильный счет» обработкой «Подбор и замена значений».

Нужно также понимать последствия ошибочно выбранного счета, поэтому сделайте перед манипуляциями бэкап БД, и можно экспериментировать.

ВНИМЕНИЕ!!! Данное действие может нарушить лицензионное соглашение с компанией 1С. Будьте внимательны!