Статья "1С:Предприятие 7.7": хождение по граблям

"1С:Предприятие 7.7": хождение по граблям

Нарушение целостности данных в компоненте РАСЧЕТ
Глюки с вытеснением расчетов
Неожиданное закрытие программы
Побеждаем ограничение длины неопределенного типа
Препарируем план счетов
Общие справочники

        Нарушение целостности данных в компоненте РАСЧЕТ.

        С этой особенностью компоненты РАСЧЕТ я столкнулся совершенно случайно.
Жила-была база ЗиК первой редакции. И вот наступил новый 2003 год. Подготовили и сдали все отчеты, настала пора переходить на вторую редакцию. Процесс перехода описывать не стану, все прошло относительно неплохо. Проработали полгода - все нормально. Так дернули-ж черти перенести базу с DBF на SQL. После простой выгрузки/загрузки данных пропали некоторые записи журнала расчетов и отменилось проведение нескольких документов. Из чего следовало, что резервное копирование методом выгрузки данных, проводимое регулярно, не имеет смысла, т.к. не обеспечивает 100% отката!
Причину мне подсказали на форуме: "Территория 1С". Это - результат перехода с первой редакции, где документ Кадровое перемещение принадлежал к компоненте расчет.
    Я решил проверить. Оказалось, что при выключении флажка Бухгалтерский учет или Оперативный учет

система проверяет наличие проведенных документов и не позволяет записать изменения,

а Расчет - выключай на здоровье! При загрузке записи журнала расчетов оказывались привязанными к "непроводному" документу и просто удялялись, а сам документ делался непроведенным.

наверх

Глюки с вытеснением расчетов.

Интересненькое дельце. Отпускаем работника в отпуск в межрасчетный период. Месяц закрываем, переходим на следуюжий. Отзываем работника из отпуска. В журнале все нормально, записи об отпуске отсторнировались и ввелись заново (по другую дату включительно). Теперь оформляем оплату по среднему и... Сторнирующая запись об отпуске вытесняет оплату по среднему! Если перепровести начисление зарплаты, то за этот период (со дня фактического выхода по дату окончания отпуска согласно первого варианта приказа) встанет оплата по окладу (по табелю)! Еще чудесатее!

Избежать этой ситуации можно, переписав модуль проведения документа Приказ на оплату по среднему заработку.
Вместо: ЖрнЗарплата.ВвестиРасчет(Сотрудник, ВвводимыйВР, Начало, Окончание, 0);
необходимо использовать:
     ЖрнЗарплата.Новая();
     ЖрнЗарплата.ВидРасч=ВвводимыйВР;
     ЖрнЗарплата.Объект=Сотрудник;
     ЖрнЗарплата.ДатаНачала=Начало;
     ...
     ЖрнЗарплата.Записать();
Осталось предусмотреть, что Начало и Окончание могут быть из разных периодов, тогда придется ввести более одной записи, учитывающих начало и окончание каждого периода.

наверх

        Неожиданное закрытие программы.

        Подобная штука получилась совершенно случайно: поместил на форму таблицу значений и при открытии решил закрепить первую колонку. И программу я в этом плане тоже понимаю: требую сделать того, чего еще не описано (ни одна колонка еще не была добавлена). Но эффект мне понравился. Как оказалось, это работает и в случае программного создания объекта Таблица значений.
     ТЗ=СоздатьОбъект("ТаблицаЗначений");
     ТЗ.Фиксировать(0 ,1 )

наверх

        Побеждаем ограничение длины неопределенного типа.

        В таблице под неопределенный тип отводится 23 знака. Если нужна строка большей длины, тогда вносим еще один атрибут типа строка нужной длины.

Процедура ПриЗаписи()
     ВыбратьСтроки();
     Пока ПолучитьСтроку()=1 цикл
         ДопРеквизит=Строка(НеопределенныйРеквизит);
...
Процедура ПриОткрытии()
     ВыбратьСтроки();
     Пока ПолучитьСтроку()=1 цикл
         Если ТипЗначенияСтр(НеопределенныйРеквизит)="Строка" тогда
             НеопределенныйРеквизит=ДопРеквизит;
...

наверх

Препарируем план счетов.

План счетов хранится в таблице 1SACCS. Счета можно вводить как в ркжиме Конфигуратор, так и в режиме Предприятие. Редактировать счета можно только в том режиме, в котором они были введены. Во втором случае, счета доступны для редактирования в режиме Предприятие, что не всегда хорошо.

А возможно ли счета, введенные в режиме Предприятие видеть в Конфигураторе?
Попробуем разобраться. Введем пару счетов. Вот так они выглядят в талице 1SACCS

А вот так выглядит план счетов в файле конфигурации 1Cv7.MD

MDID = F - это как раз 15 (MDID - это уникальный идентификатор, как и у всех объектов метаданных, поэтому у Вас он может иметь другое значение, отличное от пустого). Т.е. записи, введенные в режиме Конфигуратор прописываются и в конфигурацию. Таким образом, если счета введены в режиме Предприятие, мы не имеем возможности их видеть в конфигураторе (т.к. будет отображаться информация не из 1SACCS, а из 1Cv7.MD). Зато наоборот - можно. Поле MDID = 0 - значит счет введен в режиме Предприятие. Если мы ручками поменяем это значение, то пользователи больше не смогут их править.

Примечания
Если произвести тестирование и исправление ИБ, то программа вернет значение MDID = 0 для всех счетов, введенных в режиме Предприятие.
Если таки приспичилоувидеть в "конфигураторе" счета, введенные в "предприятии", то можно пуступить следующим образом:

скопируйте в пустой каталог файлы 1cv7.md и 1cv7.dd;

создайте новую ИБ, указав путь к этому каталогу, запустите конфигуратор;

сейчас в плане счетов нет ниодного введенного из "предприятия" счета, создаем их в "конфигураторе (не все, а только нужные), сохраняемся и закрываем конфигуратор;

теперь описанным выше способом узнаем и правим MDID счетов в исходной базе (в таблице 1SACCS), десятичные значения необходимо перевести в 36-ричные (калькулятор есть в обработке: Просмотрщик внутренних кодов объектов агрегатного типа);

нагло Копируем файлы 1cv7.md и 1cv7.dd из исправленной копии поверх исходных.
Дополнительную информацию о значении полей таблицы 1SACCS можно узнать из статьи: Бухгалтерская подсистема (01.09.2001) автор: Шемякин Павел aka toypaul.

наверх

Общие справочники.

Эта проблема периодически возникает почти у всех. Допустим, Вы ведете несколько информационных баз (допустим: товарный учет в - Торговле, бухгалтерский - в Бухгалтерии). Часть справочников (например: Контрагенты и Расчетные счета контрагентов) должны быть одинаковыми. При всем при этом, не очень-то хочется дублировать информацию и заморачиваться с синхронизацией.
Однако есть таки способ сделать общими справочники, при условии полного совпадения их внутренней структуры. Т.е. не только структура полей, но и их идентификаторы.

Для этого достаточно прописать в файле словаря 1Cv7.DD полный путь к таблицам справочников SCxxx.dbf, уникальности 1SUIDCTL.dbf, длинные строки (если используются такие реквизиты) 1SBLOB.dbf и 1SCONST.DBF (т.к. в нем содержатся периодические реквизиты), но могут возникнуть сложности с константами (т.к. константы тоже содержаться в этом-же файле).

Примечание
Операция создания общих справочников повлечет за собой ряд сложностей.

Как уже говорилось, сложности возникнут с константами и периодическими реквизитами, так как она хранятся в одном и том-же файле 1SCONST.DBF.
При каждом изменении структуры метаданных (даже если структура не менялась, но производился анализ изменений) словарь 1Cv7.DD генерируется заново, поэтому все пути к общим справочникам снова придется прописать ручками.
При архивировании. Для того, чтобы общие справочники архивировались, необходимо или добавить маску для сохранения

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

Пара слов о том, как привести в соответствие объекты различных конфигураций.

Сначала средствами Конфигуратора приводим в полное соответствие структуру общих справочников.
Идентификаторы объектов и их реквизитов необходимо поправить вручную, прямо в файле конфигурации 1Cv7.MD.
Потом удаляем словарь 1Cv7.DD и в Конфигураторе делаем: Загрузить измененную конфигурацию, выбираем файл 1Cv7.MD из каталога ИБ (свой-же собственный). В результате анализа конфигурации программа создаст словарь уже с новыми идентификаторами.
Если Вы используете dbf версию, то переименуйте файлы таблиц в соответствии с их новыми идентификаторами, а затем и идентификаторы полей в этих таблицах (для этой операции вполне подойдет старый добрый DBU).
Для SQL версии необходимо создать новую базу, затем перенести данные из таблиц исходной базы средствами SQL.

Подробности о структуре 1Cv7.MD можно узнать в статье: Плагин к FAR менеджеру для просмотра контейнерных файлов или на сайте: База Знаний 1cv7.MD Гендин.RU редактор: Дмитрий Гендин (Dag).
Там же Вы найдете ссылки на инструментарий для работы.
И последнее. Во время творческих исканий не забывайте почаще делать копии.

наверх