Не устраняется ошибка в базе 1 С Бухгалтерия 8.2

[Sandynist]

Добрый вечер!

 

После некоторых манипуляций с антивирусом произошло повреждение в базе 1 С 8.2 — не устраняется при тестировании и исправлении запись:

 

 

 

Проверка логистичекой целостности. РегистрСведений. ПлановыеУдержанияРаботниковОрганизаций 28.07.2014
Неверная ссылка на регистратор.

 

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

 

Как такое лечится?

 

Имеет ли смысл при проверке базы поставить галки в пункте  «Создавать объекты»?

 

Быть может эти объекты можно выдернуть из предыдущего бэкапа, когда такой ошибки ещё не было?

[MotherBoard]

Для этого есть специальные обработки по поиску битых ссылок.. Можно таковыми пробовать)))

[ACIK]

Как такое лечится?

Если автоматом - chdbfl.exe

 

Если ручками - в регистре нужно восстановить значение ссылки на регистратор... Или просто удалить эту запись, а потом ввести ее заново.

 

P.S. В любом случае, перед всеми манипуляциями делаем очередной бакап.

«Создавать объекты»?

Может помочь, а может и нет.

[Sandynist]

Если автоматом - chdbfl.exe

 

Утилита проверки базы никаких ошибок не находит. 

 

 

 

Для этого есть специальные обработки по поиску битых ссылок.

 

Посмотрел, нашёл несколько обработок, но они распространяются только по платной подписке.

 

Метод удаления битых ссылок вручную описан на инфостарте, нужно будет попробовать.

Изменено 23 ноября, 2014 пользователем Sandynist

[ACIK]

Метод удаления битых ссылок вручную

это практически то же самое:

галки в пункте «Создавать объекты»?

нужно будет попробовать.

 

И ничего у вас не получится... ибо в статье:

 

Общий вид кода будет таким:

НовЭл = Справочники.БюджетныеЦентры.СоздатьЭлемент();

 

- пример для справочника, а у вас регистратор - это документ, причем один из 3-х (ВводСведенийОПлановыхУдержанияхРаботниковОрганизаций, ИсполнительныйЛист, УвольнениеИзОрганизаций). Нужно смотреть в бекапе, куда вела старая ссылка и восстанавливать ее (ссылку), просто скопировав.

НО, есть вариант, что запись была создана (изменена) новым несохраненным документом. И есть вероятность, что удержания будут у сотрудника неверными.

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

[ACIK]

To be or not to be (Создавать или Удалять).

 

Итак, рассмотрим случай с ошибкой типа: Неверная ссылка на регистратор и файловым вариантом хранения базы данных. Конфигурация Бухгалтерский учет для государственных предприятий Казахстана, редакция 1.0.20.1.

 

Перед тем, как что-то исправлять, стои разобраться, а на сколько все серьезно?... Если нет действительно критических повреждений файла 1Cv8.1CD, то скорее всего у нас есть все шансы справиться с проблемой. Забегая вперед, добавлю, в рассмотренном примере повреждена запись (точнее поле) в регистре сведений "ВводСведенийОПлановыхУдержанияхРаботниковОрганизаций", отвечающая, как не сложно догадаться из названия, за удержания типа: профвзносы, исполнительные листки и т.д.

 

Из-за незнания или лени мы можем сразу же воспользоваться встроенным в конфигуратор инструментом

Тестирование и исправление (в меню Администрирование) и надеяться на автоматику.

 

Но тут сразу же возникает вопрос: создавать или удалять? Речь идет и об объектах, и о ссылках (переключатели "При наличии ссылок на несуществующие объекты" и "При частичной потере данных объектов"). Так как исправление только ссылок, скорее всего, не даст положительных результатов в нашем случае.

 

Сразу же хочется выбрать Создавать... Ну, раз чего-то нет, или оно неверное... бла-бла-бла. Плюс, если мы что-то удалим, нужно опять создавать...

Стоп. Вот тут мы рискуем попасть в еще одну "ловушку". Если ссылка была потерта или заменена на другую, после исправления будет создан новый документ-регистратор (причем "недоделанный", т.к. часть данных в нем будет отсутствовать). И есть большая вероятность, что старый документ тоже остался. Итог: ошибка при сохранении/проведении старых документов и прочие глюки в расчетах.

 

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

 

Чтобы действительно разобраться с данной ошибкой, потребуются дополнительные "инструменты".

Вариантов много, но рассмотрим только некоторые.

 

Пример анализа поврежденной базы.

 

Берем обработку типа "Просмотр метаданных 1С8" (их в интернете полно - бесплатных). Запускаем, смотрим структуру. Для данной типовой конфигурации таблица метаданных "ВводСведенийОПлановыхУдержанияхРаботниковОрганизаций" имеет название:

 

_InfoRg4583

 

и следующие поля:

 

Кто хочет узнать о них больше, можно прочитать тут:

http://main.1c-ei.ru/Home/help/objectdb/dbschema

http://its.1c.ru/db/metod8dev#content:1798:hdoc

http://its.1c.ru/db/metod8dev#content:1828:hdoc

 

А вот с просмотром и редактированием 1Cv8.1CD все намного сложнее, и варианты с Hex-редакторами рассматривать не будем (ибо очень геморный случай).

 

Самое простое - раздобыть программу Валерия Агеева Tool_1CD (текущая версия 0.2.5), а еще лучше альфа-версию с возможностью редактирования. Также Tool_1CD можно встретить в Total Commander 1C Edition.

 

Есть и другие аналоги. Доступный, но не самый удобный: restorateon

http://code.google.com/p/restoration-base-1c8/

 

Ладно, к делу.

Нам нужно в записях найти нужный период _Period, который выдается в ошибке.

Внимательно просматриваем поля регистраторов _RecorderTRef и _RecorderRRef на предмет некорректных данных.

 

В _RecorderTRef BINARY(4) должны быть только такие значения:

00000052(hex) - 82(dec) - Документ.ВводСведенийОПлановыхУдержанияхРаботниковОрганизаций

000000a4(hex) - 164(dec) - Документ.УвольнениеИзОрганизаций

0000006с(hex) - 108(dec) - Документ.ИсполнительныйЛист

Еще здесь может попасться документ КорректировкаЗаписейРегистров, но это маловероятно.

Названия возможных регистраторов у данного регистра можно подглядеть в конфигураторе (отмечены галочками), а их коды в обработке "Просмотр метаданных 1С8".

 

Замечу, что 1С при Тестировании и исправления без вопросов грохает всю запись, если увидит ошибку в этом поле. И вам придется вернуться к варианту с удалением и перепроведением документов.

 

В _RecorderRRef значение имеет вид BINARY(16). Это ссылка на конкретный документ. Пустая ссылка будет выглядит так: 0x00000000000000000000000000000000.

Значение можно подглядеть в прошлом бекапе базы и исправить.

Если такового нет, значит проще удалить всю запись и перепровести документ (как в рассмотренном выше варианте "Удалять").

 

Кстати, если использовать SQL-базу, то для знающих SQL это даже лучше, т.к. все можно решать языком запросов и средствами Microsoft SQL Server Management Studio. Но это отдельная тема.

 

Вывод: больше "работаем" головой перед принятием решений и чаще делаем бекап базы. Удачи.

[Sandynist]

Посмотрел внимательно лог проверки (после того как открыл его в блокноте), оказывается по этому работнику в плановых удержаниях профсоюзных взносов есть уже три проводки. Расчетчики любят заморочиться созданием дублей проводок, я уже об этом писал ранее. Получается, что сбойные ссылки и объекты вообще никак не влияют на отчётность и проводки удержаний, просто эти записи действуют мне самому на нервы.  

 

Попробовал при тестировании базы поставить галку в поле «При наличии ссылок на несуществующие объекты — очищать ссылки», в итоге осталась только одна сбойная запись. При следующем тестировании поставил галку в пункте «При частичной потере данных объектов — Создать объекты». В итоге эта проводка от 28.07.14 была создана с именем F0000000001. Открыл эту проводку, изменил в ней только поле «Отражение в бухучете» — «Профсоюзные взносы», записал — ОК.  Данная проводка записалась под тем же номером и датой, под которой её первоначально проводили расчётчики. Теперь при тестировании всё нормально, никаких ошибок больше не находит. Всем спасибо за содействие и советы!