Итак, суть бесполезности обработок:
Элементы в плане счетов предопределенные и имеют предопределенное вложение, то бишь субконто. При попытке переназначить привязку выходит ошибка, так как есть предопределенные субконто. Можно пойти в конфигуратор и вынести эти субконто, а затем добавить, но конфа-то типовая, и ломать план счетов нецелесообразно. К тому же абсолютно не ясно, какой элемент "правильный".
Да, можно и тут постараться определить, какой из задвоенных является искомым "правильным", но только на глаз. Добавить к счету синтетический код нельзя, так как тогда появится ошибка о неуникальности записываемого элемента.
Короче, полная шляпа.
В голову пришла хорошая идея, которая отработала на ура:
База на 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)
Получаем табличку с данными:
| [_IDRRef] | [_Version] | [_Marked] | [_PredefinedID] | [_ParentIDRRef] | [_Code] |
|
0x815400155D03291711E51846D90DC41A |
0x00000000017933DD |
0x00 |
0xBEA8FB94C602B84545099B8D8AE52424 |
0x00000000000000000000000000000000 |
96 |
В этой таблице мы видим данные, которые уже взяты не с потолка и поддаются анализу.
Обратите внимание, задвоился не весь 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С. Будьте внимательны!
