1С. Досадная ошибка при изменении плана счетов.
С чего все началось:
А началось все 28 января 2009 года. http://tapacbl4.livejournal.com/677.html
(1С 7.7.026 SQL)
Это второй случай в моей практике, когда при загрузке измененной конфигурации с измененным планом счетов, произошло следующее - проводки не переехали на тот счет где они были, а зависли на группе счетов.
Объясню: был счет, например, 11.2 "Малоценные необоротные материальные активы". По этому счету есть куча движений, и куча карточек необоротных активов, где этот счет выбран как счет учета (плюс ко всему реквизит периодический). Понадобился новый счет, например, для учета спецодежды... Решено сделать два субсчета 11.2.01 и 11.2.02. По идее, если в конфигураторе у счета 11.2 изменить код на 11.2.01, то все должно стать красиво. Проводки и ссылки в справочниках должны остатся на объекте метаданных у которого просто изменился код, т.е. на 11.2.01, а появится новый объект - группа счетов 11.2 по которой никакого движения быть не может в принципе. Остается завести новый счет 11.2.02 и все.
К сожаленью не всегда получается все так красиво... Возможно это связано с тем что таким образом разбивали не один счет, а сразу несколько. А может нужно было все это проделать прямо в рабочей конфигурации, а не грузить изменения из другой конфигурации (сразу оговорюсь - как правильно готовить файл MD для загрузки я знаю и сообщения типа "Выбранный файл не является потомком данного файла" у меня не было и быть не могло :) ). И вот опять случилось... План счетов изменился, но проводки каким то чудодейственным образом повисли на новых объектах метаданных - группах счетов (в примере 11.2). Ну и в справочниках соответственно тоже стала фигурировать группа... :(
Насколько я помню, первый случай бороли написанием внешних обработок, которые лопатили справочники, меняя значения реквизитов и операции, меняя счет группу на соответствующий нормальный счет. Но в связи с большим оборотом по этим счетам, большим количеством элементов справочника, малыми сроками на решение возникшей проблемы (поджимало закрытие периода) нужно было найти новое решение… И оно было найдено! :)
Решили изменить коды счетов в базе данных напрямую.
Подготовка:
1. Делаем резервную копию.
2. Откроем в энтерпрайз манагере сиквел сервера базу данных и видим вот такую таблицу "_1SACCS". Это и есть наш план счетов.
Теперь нужно найти идентификатор группы счетов (11.2) где зависли остатки/обороты и счета (11.2.01) куда нужно их перевести. Поля:
ID - это и есть тот самый идентификатор.
PLANID - идентификатор плана счетов (если их у вас не один :) )
SCHKOD - код счета, как он виден в 1С (по нему и ищем)
3. Ищем что на что менять. Я искал то что мне надо в Query Analyzer с помощью SQL запроса:
select * from dbo._1SACCS where
SCHKOD = ' 11.2.01. '
and planid = '33933'
select * from dbo._1SACCS where
SCHKOD = ' 11.2. '
and planid = '33933'
Итак, нашли...
ROW_ID ID PLANID SCHKOD
1557 182 33933 11.2.01.
1556 2IT 33933 11.2.
Значения в полях у вас будут совсем не такие, так что не ищите у себя те же значения что получились у меня :)
4. Теперь о том что нужно сделать. Нужно поменять местами коды в поле ID. Т.е. сделать так:
ROW_ID ID PLANID SCHKOD
1557 2IT 33933 11.2.01.
1556 182 33933 11.2.
Как это сделать. Во первых нужно выгнать всех из 1С и перевести базу в режим Single user дабы избежать недоразумений :)
Далее нужно убрать индекс у таблицы по полю ID, чтобы можно было записать не уникальные значения в это поле. Ну или отключаете галочку уникальности значений (Unique values).
В Query Analyzer пишем вот такой запрос на обновление данных:
UPDATE dbo._1SACCS
SET ID = ' 2IT '
WHERE ROW_ID = 1557
UPDATE dbo._1SACCS
SET ID = ' 182 '
WHERE ROW_ID = 1556
После выполнения запроса нужно вернуть назад индекс по полу ID.
5. Снимаем режим Single user, запускаем 1С, проверяем где у нас проводки... Вуаля! Все на месте! :)
Едем домой вовремя, по пути балуем себя чем нить алкогльсодержащим :)))
А началось все 28 января 2009 года. http://tapacbl4.livejournal.com/677.html
(1С 7.7.026 SQL)
Это второй случай в моей практике, когда при загрузке измененной конфигурации с измененным планом счетов, произошло следующее - проводки не переехали на тот счет где они были, а зависли на группе счетов.
Объясню: был счет, например, 11.2 "Малоценные необоротные материальные активы". По этому счету есть куча движений, и куча карточек необоротных активов, где этот счет выбран как счет учета (плюс ко всему реквизит периодический). Понадобился новый счет, например, для учета спецодежды... Решено сделать два субсчета 11.2.01 и 11.2.02. По идее, если в конфигураторе у счета 11.2 изменить код на 11.2.01, то все должно стать красиво. Проводки и ссылки в справочниках должны остатся на объекте метаданных у которого просто изменился код, т.е. на 11.2.01, а появится новый объект - группа счетов 11.2 по которой никакого движения быть не может в принципе. Остается завести новый счет 11.2.02 и все.
К сожаленью не всегда получается все так красиво... Возможно это связано с тем что таким образом разбивали не один счет, а сразу несколько. А может нужно было все это проделать прямо в рабочей конфигурации, а не грузить изменения из другой конфигурации (сразу оговорюсь - как правильно готовить файл MD для загрузки я знаю и сообщения типа "Выбранный файл не является потомком данного файла" у меня не было и быть не могло :) ). И вот опять случилось... План счетов изменился, но проводки каким то чудодейственным образом повисли на новых объектах метаданных - группах счетов (в примере 11.2). Ну и в справочниках соответственно тоже стала фигурировать группа... :(
Насколько я помню, первый случай бороли написанием внешних обработок, которые лопатили справочники, меняя значения реквизитов и операции, меняя счет группу на соответствующий нормальный счет. Но в связи с большим оборотом по этим счетам, большим количеством элементов справочника, малыми сроками на решение возникшей проблемы (поджимало закрытие периода) нужно было найти новое решение… И оно было найдено! :)
Решили изменить коды счетов в базе данных напрямую.
Подготовка:
1. Делаем резервную копию.
2. Откроем в энтерпрайз манагере сиквел сервера базу данных и видим вот такую таблицу "_1SACCS". Это и есть наш план счетов.
Теперь нужно найти идентификатор группы счетов (11.2) где зависли остатки/обороты и счета (11.2.01) куда нужно их перевести. Поля:
ID - это и есть тот самый идентификатор.
PLANID - идентификатор плана счетов (если их у вас не один :) )
SCHKOD - код счета, как он виден в 1С (по нему и ищем)
3. Ищем что на что менять. Я искал то что мне надо в Query Analyzer с помощью SQL запроса:
select * from dbo._1SACCS where
SCHKOD = ' 11.2.01. '
and planid = '33933'
select * from dbo._1SACCS where
SCHKOD = ' 11.2. '
and planid = '33933'
Итак, нашли...
ROW_ID ID PLANID SCHKOD
1557 182 33933 11.2.01.
1556 2IT 33933 11.2.
Значения в полях у вас будут совсем не такие, так что не ищите у себя те же значения что получились у меня :)
4. Теперь о том что нужно сделать. Нужно поменять местами коды в поле ID. Т.е. сделать так:
ROW_ID ID PLANID SCHKOD
1557 2IT 33933 11.2.01.
1556 182 33933 11.2.
Как это сделать. Во первых нужно выгнать всех из 1С и перевести базу в режим Single user дабы избежать недоразумений :)
Далее нужно убрать индекс у таблицы по полю ID, чтобы можно было записать не уникальные значения в это поле. Ну или отключаете галочку уникальности значений (Unique values).
В Query Analyzer пишем вот такой запрос на обновление данных:
UPDATE dbo._1SACCS
SET ID = ' 2IT '
WHERE ROW_ID = 1557
UPDATE dbo._1SACCS
SET ID = ' 182 '
WHERE ROW_ID = 1556
После выполнения запроса нужно вернуть назад индекс по полу ID.
5. Снимаем режим Single user, запускаем 1С, проверяем где у нас проводки... Вуаля! Все на месте! :)
Едем домой вовремя, по пути балуем себя чем нить алкогльсодержащим :)))