Добрый день!
В одной базе ведется много организаций, причем некоторые из них работают друг с другом (Организации-клиенты и организации-поставщики).
При создании и проведении документов часто возникают блокировки, которые мешают работать.
Что можно сделать чтобы максимально снизить риск автоблокировок? Пробовал перевести файловую базу на SQL - не помогает.
Одно из решений - создать план обмена по организации для каждого бухгалтера, в каждую базу выгрузить нужные буху организации + общие организации (поставщики).
Вопрос:
1. Может еще есть решение?
И если все же РИБ, то вопрос:
2. Если в центральной базе не ставить префикс ИБ, а во всех переферийных - ставить. Чем это может быть чревато?
3. Как правильно добавить новую организацию в РИБ, чтобы по ней в переферийную базу все стало перегружаться? Пока что последовательность нарисовалась следующая:
- создаем организацию, вводим только ИНН, КПП и все.
- добавляем эту организацию в список организаций в настройках РИБ
- вручную регистрируем элемент справочника организации к обмену.
- заносим все остальные данные по организации (адреса, учетную политику и пр)
- запускаем обмен.
4. Если надо включить в РИБ организацию, по которой уже есть документы. В жизни - ведение организации передается другому бухгалтеру.
последовательность вижу такую:
- добавить организацию в настройки нужного плана обмена. (удалив ее из другого обмена)
- надо выгрузить все документы и связанную информацию по этой организации - но вот как??? Может есть какие-то обработки? В типовой Регистрация изменений для обмена - но там нет фильтра по организации.
В одной базе ведется много организаций, причем некоторые из них работают друг с другом (Организации-клиенты и организации-поставщики).
При создании и проведении документов часто возникают блокировки, которые мешают работать.
Что можно сделать чтобы максимально снизить риск автоблокировок? Пробовал перевести файловую базу на SQL - не помогает.
Одно из решений - создать план обмена по организации для каждого бухгалтера, в каждую базу выгрузить нужные буху организации + общие организации (поставщики).
Вопрос:
1. Может еще есть решение?
И если все же РИБ, то вопрос:
2. Если в центральной базе не ставить префикс ИБ, а во всех переферийных - ставить. Чем это может быть чревато?
3. Как правильно добавить новую организацию в РИБ, чтобы по ней в переферийную базу все стало перегружаться? Пока что последовательность нарисовалась следующая:
- создаем организацию, вводим только ИНН, КПП и все.
- добавляем эту организацию в список организаций в настройках РИБ
- вручную регистрируем элемент справочника организации к обмену.
- заносим все остальные данные по организации (адреса, учетную политику и пр)
- запускаем обмен.
4. Если надо включить в РИБ организацию, по которой уже есть документы. В жизни - ведение организации передается другому бухгалтеру.
последовательность вижу такую:
- добавить организацию в настройки нужного плана обмена. (удалив ее из другого обмена)
- надо выгрузить все документы и связанную информацию по этой организации - но вот как??? Может есть какие-то обработки? В типовой Регистрация изменений для обмена - но там нет фильтра по организации.
По теме из базы знаний
- Проведение документов, восстановление последовательностей, установка дат последовательностей, установка дат расчета итогов и пересчет итогов (1.7.3.1) (НЕ МОНОПОЛЬНО)
- Работа с управляемыми блокировками в примерах. Новая схема проведения документов 1с 8.2.
- Методика оптимизации программного кода 1С: проведение документов
- Ускоренное проведение документов в 1С (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)
- Гарантированное проведение документов (подключаемое расширение)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Спасибо за ваши ответы, буду отвечать по-порядку:
(2) Armando, в базе работает до 10 человек. по факту одновременно активно работает 3-5.
(3) vovan_victory, тоже думала про управляемые блокировки, но база то типовая БП2.0! Там по идее и так все на управляемых блокировках должно быть!
(4) ipoloskov, Проанализировать да, хорошо было бы. Думаю что регистр бухгалтерии и скорее всего при проведении реализации, т.к. там больше всего проверок.
Но вот отложенное проведение - думаю не вариант. Бухи захотят проверить результат своей работы, как счета закрылись и пр.
(5) avto1c, не согласна про РИБ, ведь всегда можно вернуться к работе в главной базе, отказавшись от переферийных. Все базы на одном серваке расположены, бухи заходят по RDP.
А по поводу блокировки строки в SQL - тоже думала что переход на SQL поможет. Но по факту когда запустили обработку документов в MS SQL - сразу же сработала остановка по блокировке.
(2) Armando, в базе работает до 10 человек. по факту одновременно активно работает 3-5.
(3) vovan_victory, тоже думала про управляемые блокировки, но база то типовая БП2.0! Там по идее и так все на управляемых блокировках должно быть!
(4) ipoloskov, Проанализировать да, хорошо было бы. Думаю что регистр бухгалтерии и скорее всего при проведении реализации, т.к. там больше всего проверок.
Но вот отложенное проведение - думаю не вариант. Бухи захотят проверить результат своей работы, как счета закрылись и пр.
(5) avto1c, не согласна про РИБ, ведь всегда можно вернуться к работе в главной базе, отказавшись от переферийных. Все базы на одном серваке расположены, бухи заходят по RDP.
А по поводу блокировки строки в SQL - тоже думала что переход на SQL поможет. Но по факту когда запустили обработку документов в MS SQL - сразу же сработала остановка по блокировке.
Проанализировать, что именно блокируется. Если регистры бухгалтерии - то можно включить отложенное проведение по регистрам бухгалтерии. Это наиболее простое и наиболее действенное средство. Правда, бухи могут возмутиться, из-за того, что не смогут видеть проводки сразу после проведения документа.
РИБ это гемор на всю жизнь. Разобраться с текущими блокировками и забыть /на какое то время/. Есть методики для анилиза причин блокировок на SQL /лучше если это MSSQL/. Гилевские сервисы и конфа - "1C Корпоративный инструментальный пакет" но нужно владеть этими методиками /они не очевидны и специфичны/. В любом случае на SQL будет блокироваться строка, часть строк или страница, а не вся таблица регистра.
(9) ditp, Может чего-то не понимаю до конца, но вроде пересчет итогов не влияет на блокировки. Да, скорость при чтении данных может возрасти, если итоги давно не пересчитывались.
Но при одновременной записи в регистр это не сильно влияет.
И сейчас итоги рассчитаны на 31.07.15.
Ну а ТИИ сделаю ночью, но не думаю что будут какие-то ошибки.
Но при одновременной записи в регистр это не сильно влияет.
И сейчас итоги рассчитаны на 31.07.15.
Ну а ТИИ сделаю ночью, но не думаю что будут какие-то ошибки.
+(13) m-serg74, попрробуй выключить итоги по периодам, оставь только использование текущих итогов, или наоборот:) не помню что делал, но сильно уменьшает количество блокировок, а на скорость работы не заметно влияет
(15) y-ha, Посмотрите обработки и что-то доработайте, отделите чтение данных и запись документов, используйте блокировку транзакций для групповой записи документов, вся проблема думаю в данных обработках, а не в системе и переход ничего не даст если вначале открывается транзакция, потом чтение файла, поиск по справочникам, проверка остатков, а потом только создание документов и т.д. и т.п., модальные окошки с вопросиками, а потом завершение транзакции. При таком подходе будут вечно блокировки, попробуйте оптимизировать обработки в этом направление.
(19) m-serg74, Пусть посмотрит, можно и поочерёдно записывать и без транзакции, главное отделить мух от котлет, его последнее сообщение (17) как раз подтверждает эту теорию, т.к. видимо они во время загрузки анализируют все данные, а для этого включают транзакцию, чтоб другие не повлияли на загрузку.
(19) m-serg74, Вот те и не может быть, это стандартная ошибка большинства начинающих разработчиков.
(22) y-ha, Главное связанные документы лучше выносить в одну транзакцию, чтоб не получилось что один есть документ, а другой не создался из-за блокировки.
Посмотри изменение кода в сторону оптимизации в части когда ты создаёшь документы. Создай ТЗ или Запрос на основе которого будут в конце обработки формироваться и записываться документы не производя сравнения и вычисления, ну думаю ты понял в каком направление идти, удачи. Если что пиши.
(22) y-ha, Главное связанные документы лучше выносить в одну транзакцию, чтоб не получилось что один есть документ, а другой не создался из-за блокировки.
Посмотри изменение кода в сторону оптимизации в части когда ты создаёшь документы. Создай ТЗ или Запрос на основе которого будут в конце обработки формироваться и записываться документы не производя сравнения и вычисления, ну думаю ты понял в каком направление идти, удачи. Если что пиши.
(18) Kedis, Спасибо, слона то я и не приметил! Посмотрел код - поскольку обработкой создается несколько связанных документов, то весь процесс помещен в транзакцию, внутри которой много когда, в том числе запись этих связанных документов. т.е. изначально не была предусмотрена многопользовательская обработка документов. Буду оптимизировать код.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот