Ошибка блокировки средств

Безналичные платежи – это такой же признак прогресса, как горячая вода или интернет. Ведь пользоваться банковскими картами удобно и безопасно. Но иногда случается, что деньги частично или полностью блокируются на счету. Заблокированные средства на карте никуда не списываются, но пользоваться ими владелец уже не может.

Мы расскажем, как узнать заблокированную сумму на карте, что делать в случае «заморозки» денег и как решить этот вопрос с кредитным учреждением.

Блокировка денег на банковском счету: краткая характеристика

Не всегда обычные пользователи пластиковых карт понимают, что означает – «Сумма заблокирована на карте». Для многих такая фраза становится громом среди ясного неба и причиной настоящего нервного расстройства. На практике блокировка – это рядовая банковская операция, которая, хоть и причиняет неудобства, но имеет обратное свойство.

Давайте разбираться, заблокированная сумма на карте – что это и как с этим бороться. При выдаче карты между банком и клиентом заключается договор на обслуживание счета. Согласно этому документу, кредитное учреждение имеет право в любой момент приостановить обслуживание карты и «заморозить» имеющиеся деньги до выяснения обстоятельств, повлекших такую меру.

Если заблокированы деньги на карте, то значит они пока еще на счету, но недоступны для снятия или других операций.

При «заморозке» вероятны 3 сценария развития ситуации:

• Средства удастся разблокировать после предоставления банку нужных документов;
• Деньги разблокируются через время без вмешательства со стороны владельца (обычно на это уходит до 30 суток);
• Средства спишутся со счета в уплату долгов или услуг (это чаще всего происходит, если заблокировали счет по решению суда).Пример пункта.

При «заморозке» вероятны 3 сценария развития ситуации:

• Средства удастся разблокировать после предоставления банку нужных документов;
• Деньги разблокируются через время без вмешательства со стороны владельца (обычно на это уходит до 30 суток);
• Средства спишутся со счета в уплату долгов или услуг (это чаще всего происходит, если заблокировали счет по решению суда).

Заблокированная сумма на карте видна при запросах баланса, но при других манипуляциях со счетом система не даст ею воспользоваться.

Виды блокировки денег

Банками предусмотрены несколько вариантов временной «заморозки» денег на счету клиента. У каждого свои особенности и последствия.

Преднамеренная блокировка средств

К этому виду относятся ситуации, когда заблокированная сумма на карте «замораживается» с ведома и разрешения владельца. Обычно причиной блока становятся покупки в крупных интернет-магазинах. При оформлении заказа менеджер торговой площадки посылает покупателю сообщение о том, что для подтверждения платежеспособности требуется зафиксировать на счету небольшую сумму. Чаще всего она не превышает 1 доллара. Но распространены случаи, когда блокируется сумма, эквивалентная полной оплате заказа.

После отправки заказанных товаров покупателю заблокированная сумма на кредитной карте «Сбербанка» или других кредитных учреждений станет вновь доступна владельцу.

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

К преднамеренной блокировке средств относится и «заморозка» с уведомлением. Ее отличительной чертой является мессендж, отправленный банком своему клиенту. В сообщении указываются номер счета и размер «замороженных» средств. Причину такого решения можно узнать только, обратившись в свое кредитное учреждение.

Непреднамеренная блокировка средств

Здесь ситуация гораздо запутаннее предыдущей. Что значит заблокированная сумма на кредитной карте непреднамеренно, понимают не все пользователи банковских продуктов. Такое происходит, когда кредитное учреждение начинает подозревать своего клиента в отмывании денег или других незаконных операциях. Если сомнения по транзакциям появляются, то весь счет или только крупный финансовый приход «замораживается». Владельца карты о возникших проблемах не предупреждают ни звонком, ни сообщением.

Узнать про блок можно только при совершении операций, когда денег не хватит для оплаты товаров, или через мобильный банк. После входа в личный кабинет владелец счета увидит надпись, подобную следующей – «Заблокировано средств по основной карте» и сумму. В ряде систем «замороженные» средства отражаются в виде разницы между «общими» и «доступными» деньгами.

Непреднамеренно заблокированная сумма на карте «Сбербанка», «ВТБ» или иного учреждения может находиться в таком статусе неопределенное время.

Как узнать заблокированную сумму на карте Сбербанка

Если сообщение о блокировке пришло или ситуация прояснилась другим образом, а размер «заморозки» неизвестен, то нужно следовать простому алгоритму действий. То, как узнать заблокированную сумму на карте, напрямую зависит от банковского учреждения, в котором открыт счет. Давайте разберем в качестве примера, как узнать заблокированную сумму на карте «Сбербанка»

«Сбер» предлагает своим клиентам 3 способа для выяснения размера блокировки:

1. Горячая линия 8 800 555 55 50 – операторы удаленно сообщают всю нужную информацию, если звонящий назовет кодовое слово, номер карты и паспортные данные;
2. Банкомат – среди кнопок интерфейса существует ярлык «Заказать выписку по карточному счету», позволяющий получить полную информацию по доступным и заблокированным средствам;
3. «Сбербанк-онлайн».

Последний вариант требует некоторых пояснений:

• В личном кабинете нужно нажать на интересующий счет;
• Проверить два вида данных – «Собственные средства» и «Для снятия наличных»;
• При выявлении разницы требуется зайти в «Детальная информация по карте».

В этом разделе указывается точный размер средств, подвергшихся блокировке.

«ВТБ» и другие банки, имеющие лицензию для работы в России, предлагают владельцам карт аналогичные способы получения информации по счетам и произведенной блокировке.

Причины блокировки средств

Банковские учреждения оперируют широким перечнем причин, которые могут стать веским поводом для «замораживания» денег. Самые распространенные перечислены ниже.

Введен неверный пин-код

Нередко клиенты банка сами провоцируют блокировку своего счета. Дело в том, что для совершения операций по карте требуется идентификационный код. Ошибка в одной или нескольких цифрах приведет к предупреждению о возможной блокировке счета. После неудачной третьей попытки карта автоматически заблокируется и любые манипуляции с деньгами по ней станут недоступны.

Истек срок действия карты

Любой банк выдает свой продукт на определенный срок. Чаще всего к окончанию срока действия кредитное учреждение делает автоматический перевыпуск карты, одновременно блокируя старую.

Если пропустить этот момент, то можно внезапно остаться без денег в самый неподходящий момент.

Блокирование отелями и при покупках при помощи карты

Такие ситуации хорошо известны шопоголикам и тем, кто часто путешествует, бронируя отели через интернет. После совершения сделки и сообщения номера карты платежная система блокирует на счету сумму в размере полной оплаты услуги или 1/3 от нее.

Блокировка по решению суда

Если у клиента банка существуют любые долги перед сторонними организациями, то значит рано или поздно суд вынесет решение об изъятии задолженности с карточного счета.

Происходит это по распоряжению пристава, сделавшего предварительный запрос о состоянии счетов должника. Деньги блокируются только в границах той суммы, которая указана в судебном решении.

Блокировка из-за незаконных операций

Все крупные денежные переводы на счет физического лица банк рассматривает как незаконные и сразу же блокирует не только проведенную транзакцию, но и весь счет целиком. Решить такую проблему будет крайне сложно.

Блокировка из-за образования превышенного кредитного остатка

С такой ситуацией часто сталкиваются лица, которые превышают кредитный лимит по счету и вовремя не вносят минимальный платеж.

Блокировка по причине нарушения договора

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

Собственные и заёмные средства

Клиенты банка не всегда понимают разницу между озвученными понятиями, а ведь это может привести к серьезным проблемам при блокировке карты по решению суда. Рассматривать вопрос удобнее в виде табличных данных.

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

Как разблокировать деньги на карте

Каждая причина, приведшая к «заморозке» счета, предусматривает свой алгоритм разблокировки. Мы собрали их в таблице.

Теперь вы знаете, что значит заблокированная сумма на карте. Несмотря на то, что в большинстве случаев эта проблема решаема, таких ситуаций лучше не допускать. А если блокировка все же произошла, то нужно немедленно идти в банк и действовать по обстоятельствам.

Заблокированные деньги – это ситуация, когда сумма денежных средств на счету или на какой-либо карте не может быть использована или доступна для обналичивания. Такая блокировка может вызвать серьезные неудобства и привести к некоторым финансовым проблемам для человека или компании. Основные причины блокировки могут быть разнообразными, включая мошенничество, ошибки в платежных операциях или соблюдение международных правил и норм.

Одной из наиболее распространенных причин блокировки средств является подозрение в мошенничестве. Банки и финансовые организации активно борются с мошенническими операциями и, если возникают подозрения, могут заблокировать счета и карты на месте. В таких случаях необходимо связаться с банком и предоставить дополнительную информацию для подтверждения легитимности операций. После проверки и разрешении ситуации деньги могут быть возвращены.

Другой причиной блокировки может быть ошибка в платежной операции. В некоторых случаях, при проведении платежей могут возникнуть ошибки, и деньги могут быть блокированы в процессе. Это может произойти из-за ошибок в номере счета, неправильной суммы или неверных данных. Если вам кажется, что ваши деньги были неправильно заблокированы, вам следует обратиться в банк или к финансовому менеджеру для выяснения причин и дальнейших действий по разблокировке средств.

Наконец, блокировка средств может быть обусловлена соблюдением международных правил и норм. В связи с тем, что некоторые операции или транзакции могут являться подозрительными с точки зрения финансовых мошенничеств или нарушения законодательства, они блокируются для дополнительной проверки. В таких случаях следует обратиться к команде безопасности финансовой организации или провайдеру платежей и предоставить необходимую информацию для разблокировки средств.

Важно помнить, что блокировка денежных средств может создать большие неудобства и проблемы, но, как правило, в большинстве случаев средства могут быть возвращены после выяснения обстоятельств и подтверждения правдивости информации. Однако для решения таких проблем необходимо оперативно обратиться в банк или к финансовым специалистам, чтобы ситуация была разрешена с минимальными потерями времени и эмоциональных издержек.

Что такое заблокированные деньги?

Основные причины блокировки денежных средств:

• Авторизационные блокировки – временная блокировка денежных средств на карте при совершении определенных операций. Например, при оплате отеля или аренде автомобиля может быть заблокирована определенная сумма на карте в ожидании окончательного расчета.
• Блокировка по требованию суда – судебные ордеры могут привести к блокировке денежных средств на счете физического лица или организации.
• Мошеннические операции – в некоторых случаях банк может заблокировать деньги на счете клиента из-за подозрительной операции, чтобы предотвратить возможные финансовые потери.
• Нарушение заявленных правил банка – если клиент нарушает условия договора с банком, это может привести к временной блокировке его счета и денежных средств.

Блокировка денег может вызывать неудобства в повседневной жизни, особенно если средства были заморожены для длительного периода времени. Чтобы вернуть заблокированные деньги, необходимо обратиться в банк или финансовую организацию, которая произвела блокировку, и уточнить условия и сроки разблокировки счета или карты.

Определение и суть механизма

Механизм блокировки денежных средств может быть применен в различных ситуациях и по разным причинам. Например, банк может заблокировать сумму на счету для предотвращения мошенничества или подозрительных операций. Торговый центр или интернет-магазин может заблокировать оплату до подтверждения доставки товара или выполнения услуги.

Основная цель блокировки денежных средств — обеспечение защиты и безопасности как клиента, так и поставщика услуги. Блокировка денег позволяет избежать возможных финансовых потерь и ущерба обеим сторонам сделки.

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

Примеры заблокированных средств

Заблокированные средства могут возникать по разным причинам. Ниже приведены несколько примеров наиболее распространенных случаев, когда деньги могут быть заблокированы:

1. Овердрафт: Если вы превысили сумму доступного овердрафта на своем банковском счете, банк может заблокировать вашу карту или удерживать деньги для оплаты задолженности.

2. Платежные споры: Некоторые компании могут приостанавливать доступ к средствам на вашем счете в случае возникновения платежных споров. Это может произойти, например, если вы вернули товар, но продавец отказывается вернуть вам деньги.

3. Подозрительные операции: Банк может заблокировать деньги на вашем счете или на карте, если обнаружит подозрительную операцию, связанную с мошенничеством или с кражей личных данных.

4. Несоответствие данных: В случае, если данные, указанные в вашем банковском аккаунте или карте, не соответствуют данным, указанным в системе банка, средства могут быть заблокированы до уточнения информации.

5. Блокировка по решению суда: В случае получения судебного решения в отношении вашего банковского счета, банк может заблокировать доступ к средствам на время рассмотрения судебного процесса.

Если ваши деньги были заблокированы, вам следует обратиться в банк для получения информации о причине блокировки и дальнейших действиях.

Основные причины блокировки денежных средств

Блокировка денежных средств может происходить по различным причинам. Наиболее распространенные из них:

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

Содержание
1. Ошибка 1С: “Конфликт блокировок при выполнении транзакции”. В чем причина?
2. Ошибки в 1С из-за блокировок
2.1 Пример необходимой блокировки в 1С
2.2 Пример избыточной блокировки в 1С 
2.3 Как избавиться от избыточных блокировок в 1С

Ошибка 1С: “Конфликт блокировок при выполнении транзакции”. В чем причина?

Этот вопрос возник у нас на проекте по внедрению ЗУП2.5 с численностью 20000 и средним количеством одновременных пользовательских сессий 200.

На этапе опытной эксплуатации при расчете зарплаты пользователи начали интенсивно работать с документами «Начисление зарплаты сотрудникам организаций». Объем документов был порядка 2500 строк.  У пользователей начали появляться сообщения «Конфликт блокировок при выполнении транзакции», и расчет приходилось запускать заново.

Стали разбираться. Оказалось, мы столкнулись  с эффектом «Избыточной блокировки». Обычно этот эффект появляется при параллельном проведении документов, во время него самым первым документом блокируется большой объем записей регистров на все время проведения документа. Эта блокировка задерживает проведение остальных документов, мешает параллельной работе пользователей и замедляет рабочий процесс. Вообще блокировка данных при проведении документов вещь полезная, она сохраняет целостность данных и гарантирует правильность выполнения расчетных алгоритмов. Но бывает так, что либо объем заблокированных данных чрезмерен, либо время блокировки слишком велико. В результате мы имеем многопользовательскую систему, которая по сути является однопользовательской: вместо параллельного проведения документов — последовательное.

Ошибки в 1С из-за блокировок

Пример необходимой блокировки в 1С

Представим такую ситуацию – есть два документа «Начисление зарплаты сотрудникам организаций», в которых указан одинаковый налоговый период, а на закладке НДФЛ указаны одинаковые сотрудники. Рассмотрим случай, когда блокировка вообще отсутствует. Если последовательно запускать расчет этих документов, то в первом сумма НДФЛ посчитается правильно, а во втором будет равна нулю, т.к. рассчитанный и фактически начисленный НДФЛ на момент проведения второго документа будут совпадать.

 Но если запустить эти документы параллельно, то они одновременно начислят НДФЛ, не подозревая о существовании друг друга, и в результате налог удвоится. Если блокировка настроена верно, то первый документ, запущенный на долю секунды раньше второго, успеет первым прочитать и заблокировать данные о фактически исчисленном налоге в регистре «НДФЛ расчеты с бюджетом» по сотруднику Пушкину А.С. Из этого запроса будет видно, что фактический налог за январь пока не начислялся и значит надо выполнить движение по регистру. Блокировка будет отпущена только после завершения записи в регистр. Второй документ, дойдя до запроса чтения фактически начисленного налога будет поставлен системой на ожидание до тех пор, пока первый документ не закончит транзакцию проведения, после чего он прочитает в запросе, что налог уже начислен и движение по регистру выполнять не надо. Это необходимая блокировка.

Конечно, этот пример притянут за уши для простоты объяснения. На самом деле логика ЗУП 2.5 такова, что для задвоения НДФЛ пользователям не нужно прикладывать особых усилий. НДФЛ рассчитывается до проведения документа, а при проведении содержимое табличной части просто заносится в регистры без всякой проверки. Пользователям между расчетом и проведением предоставляется возможность посмотреть будущий результат и при необходимости поправить руками. Конечно это большой плюс в пользу гибкости ЗУПа, но предъявляет высокие требования к профессиональному уровню расчетчиков. Поэтому вопрос предотвращения задвоения НДФЛ решается организационным путем или с помощью дополнительных проверочных отчетов. Конечно, в ЗУП2.5 есть регистры, которые рассчитываются и записываются одновременно при проведении документа, например «НДФЛ к зачету», но этот пример пришлось бы дольше объяснять ;).

Пример избыточной блокировки в 1С

А теперь представим другую ситуацию. При проведении документа выполняется запрос, который должен отобрать документы, в которых присутствует сотрудник из этого документа. Но запрос написан так, что сервер SQL вынужден находить нужные документы методом перебора. Для технических специалистов это означает, что вместо CLUSTERED INDEX SCAN выполняется TABLE SCAN, т.е. вместо сканирования таблицы индексов происходит сканирование самой таблицы. Причем в процессе перебора блокируются все записи, к которым прикоснулся запрос, даже те, в которых не присутствуют искомые сотрудники. И эта блокировка будет действовать до конца завершения проведения документа, что будет препятствовать параллельному проведению документов с другими сотрудниками. Это избыточная блокировка.

Как избавиться от избыточных блокировок в 1С

Лечение избыточных блокировок может идти двумя путями. Первый — это оптимизация запросов, выполняемых внутри транзакций и добавление необходимых табличных индексов в конфигураторе. Второй — это перевод выполнения SQL-запросов на более низкий уровень изоляции, когда при выполнении запросов записи в таблицах блокируются только на момент выполнения самого запроса, либо не блокируются вовсе. А необходимые блокировки устанавливаются средствами объекта «БлокировкаДанных» и выполняются на стороне сервера 1С.

Теперь немного теории про уровни изоляции на SQL сервере:

1.      В автоматическом режиме в транзакциях используется уровень изоляции SERIALIZABLE. Этот уровень накладывает блокировки типа X (запрещает чтение и запись) до конца транзакции на все данные, которых коснулись запросы или произошла запись данных.

2.      В управляемом режиме в транзакциях используется уровень изоляции ReadCommitted. Этот уровень на записанные данные также устанавливает блокировки типа X до конца транзакции. Но при выполнении запросов на данные накладывает блокировки типа S (запрещает запись и проверяет нет ли в этот момент параллельных записей), при завершении запроса блокировки снимаются не дожидаясь завершения транзакции.

3.      Если база данных переведена в режим  ReadCommitted SNAPSHOT, то в управляемом режиме при чтении данных не накладывается блокировка типа S, есть только блокировка типа X при записи.

Тоже самое чуть более подробно в таблице:

Обычно лечение начинают с понижения уровня изоляции, т.к. это не особо трудозатратно и дает быстрый результат. Достаточно перевести конфигурацию из «Автоматического» режима управления блокировкой данных в «Управляемый», и транзакции начнут выполняться на уровне изоляции типа ReadCommitted, вместо SERIALIZABLE или Repeatable Read.

Чтобы переключить базу данных в режим READ COMMITTED SNAPSHOT (RCSI) необходимо в «SQL Server Management Studio» в свойствах базы данных установить параметр «Is Read Committed Snapshot On» в значение «True»:

В некоторых источниках предлагают установить параметр «Allow Snapshot Isolation» в значение «True», но в этом нет необходимости, т.к. это приведет к включению другого режима изоляции SNAPSHOT, который не поддерживается платформой 1С (На момент написания статьи релиз платформы 8.3.9).

Режим управления блокировкой данных задается для неявных транзакций, которые выполняются при записи или при проведении документов, т.е. внутри  предопределенных процедур типа ПриЗаписи() или ОбработкаПроведения(). Но большинство «тяжелых» вычислений в типовой конфигурации ЗУП2.5 происходит при выполнении команды «Рассчитать». При этом в модуле объекта запускается процедура РассчитатьВсе(), внутри которой неоднократно повторяется конструкция НачатьТранзакцию() …ЗафиксироватьТранзакцию(). Это явно указанные транзакции, внутри которых происходит запись и очистка регистров и выполняются запросы. Нам необходимо убедиться, что при переключении конфигурации в управляемый режим в процедуре «РассчитатьВсе()» транзакции также начинают выполняться на уровне ReadCommitted.

Для этого проведем небольшой эксперимент: 

• Запустим SQL Server Profiler.

• Запустим «NEW TRACE».

• Выполним подключение к серверу SQL.

• В окне «Trace Properties» на закладке «General» выберем «Use the template» = «Blank», а на закладке «Events Selections» раскроем группу «Stored Procedures» и выберем «RPC:Complited». По кнопке «Column Filters» укажем имя базы и длительность выполнения запросов более 1.

  
• Кнопку RUN пока нажимать не будем, т.к. нам надо сначала запустить базу данных в режиме отладки и остановить выполнение расчета документа «Начисление зарплаты сотрудникам организаций» перед выполнением самого массивного запроса. Например, это будет команда
«Результат = Запрос.ВыполнитьПакет();» в функции «ПолучитьДанныеНДФЛПоРегистратору» в общем модуле «ПроведениеРасчетов». Здесь происходит выполнение основного запроса для расчета НДФЛ. Поставим на ней точку останова отладчика и запустим расчет в документе.

·         После того как отладчик остановится, нажмем кнопку RUN в Профайлере.

·         Теперь сделаем один шаг в отладчике кнопкой F11. Когда запрос будет выполнен и отладчик перейдет на следующий шаг, остановим чтение Профайлера кнопкой «Pause Selected Trace».

·         Теперь найдем самый длительный запрос по колонке Duration и внимательно изучим текст запроса. Если при обращении к реальной (а не временной) таблице после слова WITH стоит SERIALIZABLE, то мы имеем дело с автоматическим режимом блокировки. Если ничего не стоит – то с управляемым.

Если в хинте запроса (Hint – это параметр после слова WITH, позволяющий влиять на план выполнения запроса) не указан уровень изоляции, то выполняется уровень изоляции, установленный по умолчанию для текущей SQL-сессии. Определить уровень изоляции, действующий по умолчанию для текущих сессий можно в «SQL Server Management Studio» с помощью команды

SEL ECT CASE transaction_isolation_level 

WHEN 0 THEN ‘Unspecified’ 

WHEN 1 THEN ‘ReadUncommitted’ 

WHEN 2 THEN ‘ReadCommitted’ 

WHEN 3 THEN ‘Repeatable’ 

WHEN 4 THEN ‘SERIALIZABLE’ 

WHEN 5 THEN ‘SNAPSHOT’ END AS TRANSACTION_ISOLATION_LEVEL 

FR OM sys.dm_exec_sessions

В управляемом режиме для всех сессий будет указан режим ReadCommitted.

Таким образом мы получили экспериментальное подтверждение того, что после перевода в управляемый режим всей конфигурации, в этом режиме начинают работать не только процедуры записи и проведения, но и процедуры расчета документов ЗУП. А это значит, что количество сообщений о конфликте блокировок будет существенно снижено, а параллельность работы с базой данных увеличится.

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

Настройка  управляемых блокировок – это тема для отдельной статьи. Вкратце скажу, что программно управляемые блокировки устанавливаются с помощью объекта «БлокировкаДанных». Сами управляемые блокировки работают уже не на уровне SQL сервера, как в случае с автоматическими блокировками, а на уровне сервера 1С. Для определения необходимых и достаточных управляемых блокировок надо понимать логику программы одновременно на уровне бизнес-процессов и на уровне архитектуры таблиц СУБД.

Но на мой взгляд, для таких конфигураций, как ЗУП2.5 вообще нет смысла использовать какие-либо блокировки, лучше использовать проверочные отчеты для выявления нарушения целостности данных — на практике это самый быстрый способ расчета зарплаты. Особенно на крупных предприятиях, где точно есть сотрудники с внутренним совмещением в обособленных подразделениях, а за каждым ОП закреплен отдельный расчетчик, что и является причиной задвоения НДФЛ. Какой бы не был вышколенный персонал, сама идеология конфигурации допускает возможность задвоения НДФЛ. Поэтому лучше не мешать пользователям работать параллельно во время массированных месячных расчетов, а по завершении точечно и быстро исправить небольшой процент ошибок, чем заставлять их сидеть и нервничать в очереди из-за страха допустить хотя бы одну ошибку. В этом проекте мы использовали самописный отчет «Проверка НДФЛ», который отображал сотрудников с некорректным НДФЛ.

Так же на этом проекте мы столкнулись с эффектом «Эскалация блокировок», когда SQL сервер сам принимает решение, что надо укрупнить область наложения блокировок вплоть до блокировки целиком всей таблицы. В результате работа пользователей останавливается, и все ждут завершения проведения одного документа – виновника эскалации, либо когда по таймауту снимутся взаимные блокировки, либо произойдет перезагрузка сервера. В каких случаях возникает эскалация и как с этим бороться тоже тема для отдельной статьи.

Валерий Федоров

Руководитель проектов ООО “Кодерлайн”

Всем привет!

На днях на работе столкнулся с проблемой блокировок, а именно стало появляться сообщение «Конфликт блокировок при выполнении транзакции. Превышено максимальное время ожидания предоставления блокировки».

Очевидно, что здесь нет проблемы взаимоблокировок, здесь просто какой-то сеанс поставил блокировку и «забыл» убрать. При этом проблема грозила серьезными последствиями — не проводился документ Реализации товаров и услуг. В базе единовременно работает около 100 человек, и невозможно выполнить типовую и частую операцию!

Решения было два — перезагрузка сервера или поиск сбойного сеанса. Первое решение простое и быстрое, но, как здесь уже кто-то писал — ребутать сервер можно до тех пор, пока тебя не уволят. Решил пойти по второму пути.

Первый день — проблема появилась днем, поначалу казалось, что проблема в удаленном пользователе, который засел в Конфигураторе. Было похоже, что просто выполнение остановилось на точке, и блокировка, естественно, не снялась. Через пару часов удалось освободить конфигуратор, но проблема не ушла. Убивать принудительно конфигуратор было крайне нежелательно, возможно, в нем работали. После этого в ход пошел гугл. Нашел статью на этом сайте, в которой пишется, как найти блокировки в СУБД MS SQL, проверил, блокировок на уровне СУБД не было. Странно. Далее были попытки настроить тех. журнал. Настроил, а дальше что? За 15 минут пара гигов логов! Как их читать, что искать? Неизвестно.

Нашел статью, как посмотреть, что заблокировано через SQL Trace. Да даже если найду, дальше что? Мне нужен сеанс!

Ближе к 16:00, когда я понял, что дальше тянуть нельзя, я сделал ребут. В надежде, что такого больше не повторится (а это был первый случай за полгода работы), вздохнул с облегчением, все заработало. А зря… Второй день — та же ситуация. Копался часа полтора, опять непонятные попытки гуглить и прочее. Без результатов. Ребут. Под конец дня произошло еще раз. Ну, думаю, замечательно, спокойно приеду домой и посижу, поковыряюсь. Приезжаю домой, все уже нормально. Печально.

На третий день глянул вебинар, рассказали про интересный и эффективный способ поиска проблемы. Запомнил, но проблема больше не возникала. Прошла неделя и вот оно — опять блокировки! Потираю руки и начинаю действовать.

Первое — настраиваем журнал. Да, без него никак, но теперь я умею его читать. Ставим два события: первое TLOCK, второе TTIMEOUT. Первое отображает все события блокировки, второе показывает блокировки, которые не смогли установиться в отведенное им время. На самом деле, скорее всего, достаточно только TTIMEOUT.

Копируем файл техжурнала в отведенное место, летим в программу, вызываем блокировку, получаем сообщение и убираем или переименовываем файл техжурнала. Нам же не нужны тонны инфы о других блокировках!

Переходим в папку rphost_PID, находим текстовые файли и делаем поиск по слову TTIMEOUT. Видим строку:

53:16.789126-0,TTIMEOUT,5,process=rphost,p:processName=*****,t:clientID=16536,t:applicationName=1CV8,t:computerName=ASUSM,t:connectID=17272,SessionID=2242,Usr=*******,WaitConnections=8239

К слову, папок rphost_PID может быть несколько, все зависит от того, сколько рабочих процессов запущено на сервере.

А дальше все просто: смотрим в конец строки — WaitConnections = 8239, это наш номер СОЕДИНЕНИЯ. Заходим в консоль сервера, переходим в Соединения, находим этот номер и смотрим номер сеанса. В моем случае на одного пользователя было два сеанса — сбойный и какой-то другой. Грохнул сеанс, на который указывал техжурнал. И о чудо! Все заработало, радости нет предела! Но, как выяснилось позже, сеанс был не зависший:), в нем работали. Поэтому на будущее — желательно связываться с пользователем и предупреждать.

На мой взгляд, достаточно типовое решение достаточно типовой проблемы. Неизвестно, почему оно мне не попалось, возможно из-за того, что приходилось его искать по тревоге, а когда пользователи не поджимали, то и тесты проводить не получалось — ошибки же нет.

«Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки» — достаточно часто встречающая ошибка в 1С 8.3 и 8.2, связанная с конкуренцией за использование ресурсов в системе.

Система 1С позволяет работать параллельно большому количеству пользователей: как показывают нагрузочные тестирования, сегодня это количество не ограничивается и пятью тысячами пользователей, одновременно работающих в системе. Однако чтобы база данных 1С 8 могла одновременно поддерживать большое количество пользователей, конфигурация должна быть правильно разработана.

Получите 267 видеоуроков по 1С бесплатно:

Выполнение большого количества операций

Вполне вероятно, что какой-либо пользователь запустил, например, за большой период в одной транзакции. Архитектура 1С 8.3 предполагает, что система не дает изменять данные, которые используются в одной транзакции другим пользователем, и блокирует их.

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

Ошибка в конфигурации

Кроме ошибок в коде часто встречаются методически неверные решения. Например, — он сам по себе подразумевает последовательное проведение документов. Партионный учет можно заменить на РАУЗ — этим Вы серьезно повысите производительность системы.

Как исправить эту ошибку в 1С 8.3?

В любом случае, появление ошибки «Конфликт блокировок при выполнении транзакции» говорит о необходимости инспекции системы, особенно для средних и крупных информационных систем в клиент-серверном режиме работы (MS SQL, PostgreSQL и т.д.). Если это проигнорировать на раннем этапе, возможны необратимые последствия позже, когда работа системы будет особенно важна (в период сдачи отчетности).

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

Когда с программами и данными одновременно работают сотни пользователей, появляются проблемы, свойственные только масштабным решениям. Речь о проблемах, вызванных блокировками данных.

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

Проблемы, вызванные блокировками, не имеют общего решения. Поэтому мы попробуем проанализировать причины возникновения таких проблем и систематизировать варианты их решения.

ПРИЧИНЫ ВОЗНИКНОВЕНИЯ БЛОКИРОВОК ТРАНЗАКЦИЙ

Давайте сначала вспомним, что такое блокировки, а заодно разберемся, нужны ли они. Рассмотрим пару классических примеров блокировок, с которыми мы сталкиваемся в жизни.

Пример 1: покупка билета на самолет или поезд. Предположим, мы озвучили свои пожелания кассиру. Кассир сообщает нам наличие свободных мест, из которых мы можем выбрать наиболее понравившееся (если их несколько, конечно). Пока мы выбираем и подтверждаем своё согласие с предлагаемым вариантом, эти места не могут быть проданы кому-либо еще, т.е. временно «блокируются». Если бы они не блокировались, то к моменту подтверждения могла бы быть ситуация, когда выбранные нами билеты уже проданы. А в этом случае цикл выбора может быть непрогнозируемого количества повторений. Пока выбираем места, а их уже продали!.. Пока выбираем другие, и их уже нет…

Пример 2: покупка чего-либо в магазине или на базаре. Подошли мы к прилавку, выбрали самое красивое яблоко из сотни доступных. Выбрали и полезли в карман за деньгами. Как будет выглядеть, если в тот момент, пока мы считаем деньги, именно выбранное нами яблоко будет продано подошедшему позже нас покупателю?

Таким образом, сама по себе блокировка — это нужное и полезное явление. Именно благодаря блокировке мы гарантируем выполнение действий за один этап. А к негативу чаще всего приводит не самая удачная реализация программного обеспечения, когда, например:

• блокируется избыточное количество объектов (билетов, яблок);
• время блокировки необоснованно растягивается.

ИЗБЫТОЧНЫЕ БЛОКИРОВКИ В ТИПОВЫХ КОНФИГУРАЦИЯХ 1С

На крупных проектах, как правило мы используем «1С:Предприятие». Поэтому практические рекомендации решения проблем блокировок мы попробуем описать на примере связки «1С:Предприятие»+MS-SQL.

8-е поколение 1С:Предприятия обеспечивает очень и очень неплохую параллельность использования. Одновременно с одной конфигурацией (то есть на одной базе) при нормальных серверах и каналах связи может работать огромное количество пользователей. Например, сотни кладовщиков оформляют выдачи или поступления товаров, экономисты одновременно считают затраты на оплаты труда по различным подразделениям, расчетчики проводят расчет и начисление зарплаты и т.д.

Но есть причина, из-за которых бытует мнение об обратном — миф о том, что при интенсивном одновременном использовании работать с решениями на базе 1С:Предприятия некомфортно или невозможно. Ведь как только типовые решения под 1С:Предприятие начинают использовать сотни пользователей на промышленных масштабах, всё чаще на экране появляется окошко с гордой надписью: «Ошибка при вызове метода контекста (Записать): Конфликт блокировки при выполнении транзакции: …» и дальше в зависимости вида применяемого SQL-сервера что-то типа «Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded. …».

Почти все типовые решения в предлагаемой «из коробки» реализации настроены на автоматический режим управления блокировками. «Автоматический» тут можно воспринимать как «параноидальный». На всякий случай при проведении любого документа блокируем всё, что хоть как-то с ним может быть связано. Вот и получается, что когда один пользователь что-то проводит (а иногда и просто записывает), остальные могут только ожидать.

Выскажу свое мнение, почему 1С решила не настраивать свои типовые решения под высокую параллельность использования. Трудозатраты на такую доработку не высоки — несколько «человекомесяцев», что по масштабам 1С не значимо. Мне кажется причина в другом.

Во-первых, такая доработка значимо усложняет обработчики проведения всех документов. А значит для тех потребителей, кто использует 1С на небольших задачах, без какого-либо выигрыша будет только недостаток — сложность доработки типовой конфигурации усложнится. Статистика в то же время подсказывает, какая категория клиентов является основной кормушкой для 1С…

Вторая причина зарыта в типовых базовых настройках SQL-серверов, например, MS-SQL, который всё еще используется чаще других. Так уж повелось, что приоритеты в настройках отданы экономии оперативной памяти серверов, а не сокращению блокировок. Это приводит к тому, что при необходимости заблокировать несколько строк SQL-сервер принимает «экономное» для памяти и процессора решение — заблокировать сразу всю таблицу!..

Вот эти недоработки типовых решений или специфику используемой настройки сервера баз данных часто и отождествляют с проблемами, вызванными блокировками. В результате технические недоработки приводят к очень значимым организационным проблемам. Ведь если сотруднику дать повод отвлечься от работы или обосновать, почему работу нельзя было сделать — эффективно работать будет меньшинство. Ну а сообщение о блокировке транзакций или «тормозящая» программа — идеальное обоснование, почему нельзя было что-либо сделать.

РЕКОМЕНДАЦИИ ПО УСТРАНЕНИЮ ИЗБЫТОЧНЫХ БЛОКИРОВОК ДЛЯ 1С:ПРЕДПРИЯТИЯ

Что же делать, если решение проблем избыточных блокировок настолько важно?

На завершающей стадии внедрения всех крупных комплексов необходимо провести тонкую доработку на предмет устранения излишних блокировок транзакций. Крайне важно решить проблемы, которые могут возникать из-за недостаточно проработанных условий блокировки или методики реализации.

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

1. Если используемая СУБД или система разработки (например, 1С:Предприятие) по умолчанию использует автоматический режим блокировки данных, откажитесь от автоматического управления блокировками. Настройте правила блокировок самостоятельно, опишите критерии блокировки целых таблиц или отдельных строк.
2. При разработке программы всегда, когда это возможно, обращайтесь к таблицам в одном порядке.
3. Постарайтесь не писать в одну и ту же таблицу несколько раз в пределах одной транзакции. Если это сложно, то хотя-бы минимизируйте промежуток времени между первой и последней операцией записи.
4. Проведите анализ возможности отключения эскалации блокировок на уровне SQL-сервера.
5. Внятно информируйте пользователей о причинах невозможности выполнения каких-либо действий, если они обусловлены блокировками. Давайте доступные и понятные рекомендации, что делать дальше.

Если внимательно посмотреть на рекомендации, то становится понятным, что подобная отработка уместна не только для 1С:Предприятия, но для любых систем
. Абсолютно не важно на каком языке они написаны и с каким работают сервером БД. Большинство рекомендаций имеют универсальный характер, а потому одинаково справедливы и при использовании 1С:Предприятия, и для «самописных» программ или других «коробочных» ERP-систем.

P.S. А Вы знали о том, что мы предлагаем профессиональную помощь с обновлением 1С по лучшей цене?

Тэги для поиска:

• Блокировки транзакций
• Устранение блокировок
• Блокировки 1С
• Блокировка
• Конфликт блокировок
• Конфликт блокировок при выполнении транзакции

Не мог записать изменения для передачи в распределенную базу, обратился в поддержку 1с предложили следующее. У меня решилось просто перезагрузкой сервера приложений и cсервера с SQL. Вообще можно поставить галочку «Блокировка регламентных
заданий включена»
Тоже помогло без перезагрузки.

Регламентные операции на уровне СУБД для MS SQL Server

Инструкция по выполнению регламентных операций на уровне СУБД.

Информация применима к клиент-серверному варианту 1С:Предприятия 8 при использовании СУБД MS SQL Server.

Общие сведения

Одной из часто встречающихся причин неоптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД. Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы.

Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.

Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.

Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.

Обновление статистик

MS SQL Server строит план запроса на основании статистической информации о распределении значений в индексах и таблицах. Статистическая информация собирается на основании части (образца) данных и автоматически обновляется при изменении этих данных. Иногда этого оказывается недостаточно для того, что MS SQL Server стабильно строил наиболее оптимальный план выполнения всех запросов.

В этом случае возможно проявление проблем с производительностью запросов. При этом в планах запросов наблюдаются характерные признаки неоптимальной работы (неоптимальные операции).

Для того, чтобы гарантировать максимально правильную работу оптимизатора MS SQL Server рекомендуется регулярно обновлять статистики базы данных MS SQL.

Для обновления статистик по всем таблицам базы данных необходимо выполнить следующий SQL запрос:

exec sp_msforeachtable N»UPDATE STATISTICS ? WITH FULLSCAN»

Обновление статистик не приводит к блокировке таблиц, и не будет мешать работе других пользователей. Статистика может обновляться настолько часто, насколько это необходимо. Следует учитывать, что нагрузка на сервер СУБД во время обновления статистик возрастет, что может негативно сказаться на общей производительности системы.

Оптимальная частота обновления статистик зависит от величины и характера нагрузки на систему и определяется экспериментальным путем. Рекомендуется обновлять статистики не реже одного раза в день
.

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

Настройка автоматического обновления статистик (MS SQL 2005)

Запустите MS SQL Server Management Studio и подключитесь к серверу СУБД. Откройте папку Management и создайте новый план обслуживания:

Создайте субплан (Add Subplan) и назовите его «Обновление статистик». Добавьте в него задачу Update Statistics Task из панели задач:

Настройте расписание обновления статистик. Рекомендуется обновлять статистики не реже одного раза в день. При необходимости частота обновления статистик может быть увеличена.

Настройте параметры задачи. Для этого следует два раза кликнуть на задачу в правом нижнем углу окна. В появившейся форме укажите имя базу данных (или несколько баз данных) для которых будет выполняться обновление статистик. Кроме этого вы можете указать для каких таблиц обновлять статистики (если точно неизвестно, какие таблицы требуется указать, то устанавливайте значение All).

Обновление статистик необходимо проводить с включенной опцией Full Scan.

Сохраните созданный план. При наступлении указанного в расписании срока обновление статистик будет запущено автоматически.

Очистка процедурного КЭШа

Оптимизатор MS SQL Server кэширует планы запросов для их повторного выполнения. Это делается для того, чтобы экономить время, затрачиваемое на компиляцию запроса в том случае, если такой же запрос уже выполнялся и его план известен.

Возможна ситуация, при которой MS SQL Server, ориентируясь на устаревшую статистическую информацию, построит неоптимальный план запроса. Этот план будет сохранен в процедурном КЭШе и использован при повторном вызове такого же запроса. Если Вы обновили статистику, но не очистили процедурный кэш, то SQL Server может выбрать старый (неоптимальный) план запроса из КЭШа вместо того, чтобы построить новый (более оптимальный) план.

Для очистки процедурного КЭШа MS SQL Server необходимо выполнить следующий SQL запрос:

Этот запрос следует выполнять непосредственно после обновления статистики. Соответственно, частота его выполнения должна совпадать с частотой обновления статистики.

Настройка очистки процедурного КЭШа (MS SQL 2005)

Поскольку процедурный КЭШ необходимо очищать при каждом обновлении статистики, данную операцию рекомендуется добавить в уже созданный субплан «Обновление статистик». Для этого следует открыть субплан и добавить в его схему задачу Execute T-SQL Statement Task. Затем следует соединить задачу Update Statistics Task стрелочкой с новой задачей.

В тексте созданной задачи Execute T-SQL Statement Task следует указать запрос «DBCC FREEPROCCACHE»:

Дефрагментация индексов

При интенсивной работе с таблицами базы данных возникает эффект фрагментации индексов, который может привести к снижению эффективности работы запросов.

sp_msforeachtable N»DBCC INDEXDEFRAG (<имя базы данных>, «»?»»)»

Дефрагментация индексов не блокирует таблицы, и не будет мешать работе других пользователей, однако создает дополнительную нагрузку на SQL Server. Оптимальная частота выполнения данной регламентной процедуры должна подбираться в соответствии с нагрузкой на систему и эффектом, получаемым от дефрагментации. Рекомендуется выполнять дефрагментацию индексов не реже одного раза в неделю.

Возможно выполнение дефрагментации для одной или нескольких таблиц, а не для всех таблиц базы данных.

Настройка дефрагментации индексов (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Реиндексация».Добавьте в него задачу Rebuild Index Task:

Задайте расписание выполнения для задачи дефрагментации индексов. Рекомендуется выполнять задачу не реже одного раза в неделю, а при высокой изменчивости данных в базе еще чаще – до одного раза в день.

Реиндексация таблиц базы данных

Реиндексация таблиц включает полное перестроение индексов таблиц базы данных, что приводит к существенной оптимизации их работы. Рекомендуется выполнять регулярную переиндексацию таблиц базы данных. Для реиндексации всех таблиц базы данных необходимо выполнить следующий SQL запрос:

sp_msforeachtable N»DBCC DBREINDEX («»?»»)»

Реиндексация таблиц блокирует их на все время своей работы, что может существенно сказаться на работе пользователей. В связи с этим реиндексацию рекомендуется выполнять во время минимальной загрузки системы.

После выполнения реиндексации нет необходимости делать дефрагментацию индексов.

Настройка реиндексации таблиц (MS SQL 2005)

В ранее созданном плане обслуживания создайте новый субплан с именем «Дефрагментация индексов». Добавьте в него задачу Rebuild Index Task:

Задайте расписание выполнения для задачи реиндексирования таблиц. Рекомендуется выполнять задачу во время минимальной нагрузки на систему, не реже одного раза в неделю.

Настройте задачу, указав базу данных (или несколько баз данных) и выбрав необходимые таблицы. Если точно неизвестно, какие таблицы следует указать, то устанавливайте значение All.

Не редко при работе в 1С возникает ошибка «Конфликт блокировок при выполнении транзакций: Превышено максимальное время ожидания предоставления блокировки». Суть ее кроется в том, что несколько сеансов пытаются одновременно выполнить похожие действия, затрагивая один и тот же ресурс. Сегодня мы разберемся как исправить данную ошибку

Большое количество выполняемых операций

Первым делом при поиске причин следует уточнить, сколько же одновременно работающих пользователей находится в той информационной базе, в которой выдается подобная ошибка. Как мы знаем, максимальное их количество может быть довольно большим. Это и тысяча, и пять тысяч.

Механизм блокировок и транзакций описан в руководстве разработчика. Их используют при обращении нескольких сеансов к одним и тем же данным одновременно. Логично, что одни и те же данные не могут изменяться разными пользователями в один и тот же момент.

Так же следует проверить, не запущено ли у кого-то из пользователей обработки по массовому изменению данных. Это может быть как , закрытие месяца и тому подобное. В таком случае после окончания работы обработки ошибка пропадет сама по себе.

Регламентные задания

Не редки случаи, когда причина ошибки кроется в , которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.

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

«Зависшие сеансы»

Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.

По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).

Ошибки при написании конфигурации

Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.

В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.

Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.

В многопользовательских системах важную роль играет правильная организация структуры и настройка блокировок. Если ее нет, пользователям придется часто сталкиваться с ошибками, вызванными конкуренцией за определенные ресурсы системы. Но существует проблема конфликта блокировок, знакомая многим пользователям. Почему возникает конфликт блокировок 1С и как его устранить?

Конфликт блокировок в 1С 8.3 и его значение

Для большинства пользователей сообщение о конфликте блокировок 1С означает лишь ошибку, мешающую им выполнять свою работу. Они хотят поскорее избавиться от этой проблемы и осаждают IT-отдел жалобами на то, что «1С не работает».

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

Причины возникновения ошибок блокировки в 1С

Показательные нагрузочные тестирования демонстрируют, что сервер 1С выдерживает параллельную работу более чем пяти тысяч пользователей. Но идеальные условия подобных экспериментов недостижимы в повседневных условиях крупных и средних компаний. Чтобы добиться аналогичного быстродействия и безошибочности, конфигурация должна быть идеально разработана и заточена под конкретные бизнес-процессы предприятия.

Если не брать идеальные варианты, то конфликты блокировок 1С встречаются по следующим причинам:

Одновременная работа пользователей с большим объемом данных. Эта первопричина продиктована внутренними механизмами 1С. Они предполагают запрет изменения данных, вовлеченных в транзакцию, запущенную от имени другого пользователя;

Ошибки и недочеты в конфигурации. В структуре типовых решений от компании «1С» учтены рекомендации по максимизации производительности. Но сторонние разработчики не всегда придерживаются высоких стандартов, и в их коде часто можно встретить следующие недочеты:

• Неоптимальные запросы;
• Запрос остатков в начале действий;
• Непонимание предназначения объектов конфигурации и их неправильное применение;
• Избыточность заложенных в системе или дополнительно разработанных блокировок.

Как исправить конфликт блокировок в 1С 8.3

Системное сообщение «конфликт блокировки при выполнении транзакции 1С 8.3» не характеризует конфигурацию в качестве неверно спроектированной. Но если подобные сигналы игнорировать, то существует вероятность в самый ответственный момент, например, при сдаче квартальной или годовой отчетности получить большие проблемы. В лучшем случае – тормозящую систему и недовольных пользователей. В худшем – неправильные данные на выходе, что может повлечь за собой штрафные санкции от контролирующих органов.

Решением проблемы конфликта блокировок в 1С 8.3 может стать перевод конфигурации на управляемый (ручной) режим управления блокировками. Реализованный в версии 8.1, механизм в руках грамотных специалистов решает проблему конфликта блокировок при транзакции в 1С.

Но стоит иметь в виду, что это действие снизит уровень защиты данных от изменения в процессе чтения их другими пользователями. Поэтому, если вы не готовы самостоятельно контролировать все блокировки в системе, не торопитесь изменять настройки конфигурации.

Быстрое решение конфликта блокировок 1С

В работе администратора или разработчика может произойти ситуация, когда нет времени на проверку ошибки и поиск первопричин проблемы. Например, необходимо сдать отчет или подать данные к определенному времени, а ошибки блокировок 1С препятствуют этому.

Для быстрого решения проблемы существуют два пути:

• Найти и завершить сеанс, заблокировавший необходимые данные. В небольших компаниях, где количество пользователей 1С не превышает пары десятков человек, это оптимальный вариант решения;
• Если вы контролируете систему, в которой работают сотни сотрудников, поиск нужного сеанса без специализированного программного обеспечения может затянуться надолго. В этом случае намного эффективнее будет перезагрузить сервер.

Эти решения радикальные и направлены только на быстрое решение проблемы и освобождение данных для срочной сдачи отчетов. Искоренить ее можно только разобравшись в причине, из-за которой возник конфликт блокировок при выполнении транзакции 1С. После таких действий необходимо найти уязвимые места в системе, оптимизировать конфигурацию или работу сотрудников. Использовать подобные меры на постоянной основе при регулярных конфликтах блокировок на транзакциях не рекомендуется.