Если в конфигурации один и тот же объект (документ, элемент справочника) изменяется одновременно двумя переменными языка, созданными функцией "СоздатьОбъект", то потенциально такая ситуация является ошибочной.
Например, одна переменная позиционируется на некоторый документ. Фактически в этот момент происходит считывание из информационной базы данных документа. Далее другая переменная также позиционируется на этот документ, изменяет его и записывает, а потом первая переменная пытается записать или провести измененный уже ею документ (проведение тоже является записью).
В версии 7.5 эта ситуация не контролировалась, что иногда приводило к различным ошибкам.
В версии 7.7 введен контроль, запрещающий записывать изменения объекта, если он записывался кем либо (другой переменной или другим пользовавателем) после считывания его данной переменной. Чтобы избежать такой ситуации следует заново спозиционироваться на тот же документ перед внесением изменений и записью (проведением).
Встроенный язык 1С:Предприятия воспринимает константы языка типа "Дата", в которых год задан двумя цифрами, в соответствии с пользовательскими установками, заданными в параметре "Год начала рабочего столетия" ("Сервис - Параметры - Общие"). Аналогично воспринимаются строковые значения при преобразовании к типу "Дата". Таким образом, работа алгоритма будет зависеть от индивидуальных параметров пользователя, хотя как правило задаваемая непосредственно в алгоритме дата не должна зависеть от пользовательских установок.
В некоторых случаях пользователи меняют значение параметра "Год начала рабочего столетия". Например, устанавливают в нем значение 20 В этом случае, алгоритмы, использующие константы типа "Дата" в которых год задан двумя цифрами или выполняющие преобразование из аналогичных строковых значений будут работать неверно.
Для обеспечения устойчивости алгоритмов к изменениям пользовательских настроек рекомендуется в константах языка типа "Дата" и в строковых значениях преобразуемых к типу "Дата" задавать год четырьмя цифрами.
При записи движений и проводок система не выполняет проверки значений типа "Справочник" на то является значение группой справочника или нет, так как этот контроль занял бы достаточно продолжительное время. Однако, не следует использовать группы справочников в качестве значений измерений регистров и субконто.
Во-первых, это противоречит назначению групп справочников, предусмотренному в 1С:Предприятии. Во-вторых, это в большинстве случаев приведет к неверному формированию отчетов, так как механизмы "Запрос" и "Бухгалтерские итоги" рассчитаны на то, что в качестве значений в данных фигурируют элементы, а итоги по группам справочников формируются в процессе обработки данных запроса.
При работе с объектом "Операция" существует возможность перебора проводок с использованием различных условий отбора. Для этого используется метод "ВыбратьОперацииСПроводками". Достаточно часто эта возможность используется не только для формирования отчетов, но и для группового изменения проводок. Например, для замены значений субконто при изменении структуры учета. Одной из типичных ошибок при использовании данного метода является попытка выполнить корректировку и запись проводок непосредственно тем же объектом (переменной), которой выполняется отбор. Это действие не может быть выполнено системой, так как при записи операции проводки фактически записываются заново, и текущая позиция в списке проводок (текущая проводка) не может быть адекватно сохранена для последующего перебора.
Таким образом, для выполнения изменения проводок не следует выполнять запись тем же объектом, который выполняет перебор. Для наиболее надежного выполнения записи измененных операций можно рекомендовать не использовать перебор проводок, а выполнять перебор операций, и для каждой операции перебирать в цикле все проводки. В этом случае изменение проводок и запись операции не вызовет проблем.
В некоторых случаях, если требуется изменить проводки по определенному условию, можно рекомендовать для повышения производительности выполнить перебор проводок и накопить в таблице значений операции (документы) и номера проводок, которые нужно изменить. Затем можно поочередно открывать эти операции и изменять в них необходимые проводки.
При администрировании и конфигурировании 1С:Предприятия рекомендуется при выборе средств и методов решения конкретных задач жестко придерживаться документированных способов использования файлов информационной базы 1С:Предприятия. Использование файлов информационной базы не по назначению или недокументированным способом может привести к различным сбоям в работе программы и потере информации. Это утверждение является не просто "предупредительной надписью", а основывается на опыте анализа различных ситуаций, в которых некорректная работа с файлами 1С:Предприятия приводила к существенным проблемам с данными и конфигурацией, вплоть до необходимости повторного ввода информации. Сказанное выше относится практически ко всем файлам, расположенным в каталоге информационной базы, а не только к файлам DBF/CDX.
Так, например, основной файл информационной базы - файл конфигурации (1CV7.MD) логически жестко связан с данными информационной базы. Перезапись и модификация этого файла может выполняться только штатными средствами 1С:Предприятия (изменением конфигурации, загрузкой измененной конфигурации, объединением конфигураций, восстановлением и загрузкой данных). Перезапись в каталог информационной базы другого (даже незначительно отличающегося) файла конфигурации может привести к существенным нарушениям в работе программы. Последствия нештатной перезаписи или изменения файла конфигурации могут проявиться не сразу, а, например, при одной из последующих модификаций конфигурации.
Файл словаря данных (1CV7.DD или 1CV7.DDS) является служебным файлом, который должен записываться только самим 1С:Предприятием. Фактически этот файл непосредственно зависит от файла конфигурации (1CV7.MD) и содержит описание структуры таблиц базы данных. Система поддерживает четкое соответствие между файлами 1CV7.MD, 1CV7.DD (1CV7.DDS) и собственно базой данных (файлами DBF/CDX или таблицами в базе данных MS SQL Server). Ручное изменение или перезапись файла словаря может быть воспринято системой как нарушение структуры данных и система может выполнить очистку таблиц базы данных.
Не менее опасной является перезапись или модификация таблиц информационной базы. Фактически информационная база 1С:Предприятия представляет собой хранилище объектов, которые размещаются в нескольких таблицах (файлах DBF/CDX или таблицах MS SQL Server). В информационной базе существует достаточно большое количество внутренних взаимосвязей и связей с файлом конфигурации. Например, изменения таблиц информационной базы, выполненные нештатным образом, могут нарушить систему внутренней идентификации объектов или систему хранения производных данных. Нарушения в работе 1С:Предприятия при этом могут проявиться через весьма значительное время и их будет трудно непосредственно отнести к выполненным ранее нештатным действиям.
При возникновении различных сбоев в информационной базе или в конфигурации (из-за ошибок аппаратного или программного обеспечения или по другим причинам) рекомендуется воспользоваться штатными средствами 1С:Предприятия (режимом "Тестирование и восстановление ИБ" или режимами "Выгрузить данные" - "Загрузить данные"). Если это не привело к исправлению сбойных ситуаций, то следует восстановить архивную копию информационной базы. При этом восстановление должно выполняться целиком, а при использовании версий 1С:Предприятия для SQL, должно выполняться восстановление согласованно сохраненных файлов каталога информационной базы и содержимого базы данных MS SQL Server.
Одной из встречающихся ошибок при проектировании конфигураций 1С:Предприятия является использование не по назначению объекта XBase. Данный объект предназначен исключительно для интеграции 1С:Предприятия с другими системами и для использования внешних по отношению к информационной базе 1С:Предприятия данных, например, для загрузки стандартных классификаторов, распространяемых государственными организациями, или загрузки данных из других учетных систем.
Построение на основе использования объекта XBase алгоритмов связанных с задачами решаемыми объектами информационной базы является серьезной ошибкой проектирования, которая не будет проявляться в виде конкретных сбоев, но будет нарушать правильное функционирование различных механизмов 1С:Предприятия. Например, изменение файлов DBF с помощью объекта Xbase никак не рассматривается системой как факт изменения информационной базы. Соответственно расположение методов выполняющих запись между вызовами
процедур "НачатьТранзакцию" и "ЗафиксироватьТранзакцию" не приведет к тому, что при откате транзакции или сбое в процессе записи данных информационной базы будет отменена запись в файлы DBF. Таким образом, изменение файлов DBF нельзя выполнить согласованно с изменениями в данных информационной базы, что делает недопустимым построение на базе использования объекта XBase механизмов связанных с бизнес – логикой решаемой задачи.
Разумеется, на файлы изменяемые с помощью объекта XBase не распространяется действие таких механизмов, как контроль ссылочной целостности, управление распределенной информационной базой, тестирование информационной базы и т.д.
При построении алгоритмов модулей 1С:Предприятия, выполняющих согласованную запись данных с использованием транзакций, особую сложность представляет собой организация повторной записи после неудачного завершения транзакции. В большинстве случаев при неудачной записи транзакции система прекращает выполнение модуля. Однако в некоторых случаях допускается выполнение повторной записи. Откат транзакции без завершения модуля и повторная запись может выполняться после вызова в модуле процедуры "ОтменитьТранзакцию", после вызова метода документа "Провести", в котором было отменено выполнение проведения. Также повторная запись может выполняться при использовании конструкции языка "Попытка-Исключение-КонецПопытки".
При использовании вложенных транзакций следует учитывать, что любой откат транзакции отменяет все изменения, произведенные во вложенных транзакциях вплоть до транзакции верхнего уровня. При этом проведение документа также является транзакцией, автоматически выполняемой системой.
Важным моментом, который следует учитывать при выполнении повторной записи, является то, что данные объекта встроенного языка (его внутреннее состояние и реквизиты) после отката транзакции не возвращаются к начальным значениям, так как транзакция, в которой выполнялась запись, может быть прервана не в процессе записи данного объекта, а существенно позже. Таким образом, объект "считает" что он записан, и его данные в памяти соответствуют данным информационной базы, хотя на самом деле все изменения в информационной базе отменены. При попытке повторной записи может произойти нарушение логической целостности данных объекта. Например, в одной транзакции выполняется создание элемента справочника, его запись, присвоение значения данного элемента реквизиту документа и, соответственно, запись документа. Предположим, что в процессе записи документа произошел сбой, обработанный конструкцией "Исключение". Организованный в модуле цикл заново выполняет приведенный алгоритм. Реквизит документа уже заполнен значением типа "Справочник", поэтому новый элемент не создается, а документ записывается. В результате реквизит документа ссылается на несуществующий элемент справочника. Кроме того, в дальнейшем может оказаться, что эта ссылка совпадет с одним из реально созданных элементов, что будет явным нарушением логики работы системы.
Наиболее простым способом преодоления данных сложностей является прерывание работы модуля при откате транзакции. В этом случае пользователь заново активизирует выполнение модуля, и считывание всех объектов будет выполнено заново. Разумеется, такой способ не защищает от ошибок при использовании переменных глобального модуля. Более универсальным способом решения проблемы является обязательное считывание всех данных, которые будут записываться перед повторным выполнением транзакции. Так как для объектов встроенного языка не существует специальных методов пересчитывания данных, то следует выполнять повторное позиционирование объектов. Наиболее надежным способом будет являться повторное создание значений переменных, которые выполняют запись данных информационной базы.
При написании алгоритмов выполняемых в транзакции следует учитывать тот факт, что транзакция может не быть зафиксирована. Это может произойти в результате явного вызова функции "ОтменитьТранзакцию" или в результате системных сбоев. При отмене транзакции все действия по изменению данных в информационной базе будут отменены. Это необходимо учитывать в алгоритмах использующих транзакции. Например, если в процессе транзакции создать и записать элемент справочника или документ и присвоить полученное таким образом значение типа "Справочник" или "Документ" переменной или реквизиту другого объекта, то в случае неудачного завершения транзакции ссылка на такой объект будет недействительна. Кроме того, возможна ситуация, при которой эта ссылка фактически затем будет являться ссылкой на другой объект, созданный позднее.
Также следует учитывать, что процесс проведения документа и отмены проведения документа также выполняется в транзакции, автоматически инициируемой системой. Например, если создать и записать в процессе проведения элемент справочника, и присвоить его реквизиту документа, то в случае, если проведение не будет выполнено, а документ будет записан, то значение реквизита будет ссылаться на несуществующий или созданный позднее элемент.