В http://www.sql.ru/forum/1198634-17/o-sap обсуждался вопрос, насколько 1С готова к БОЛЬШИМ внедрениям (насколько хорошо масштабируется).

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

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

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

Вот описание в гугл доках:
https://drive.google.com/open?id=1WDSbfBZmql-Blz_wCgy5QUHx5xbJ2cthoEcVN6E5gAw

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

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

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

Как выглядит типичный “идеальный” бизнес процесс продажи в таких фирмах:
1. Клиент делает заказ - согласовывается номенклатура, количество, цена и срок поставки.
2. Заказ утверждается к исполнению (проверяется задолженность, кредитный лимит, поступление предоплаты и т.п.).
3. В случае, если не весь товар есть в наличии - отдел закупок создает заказ закупки у поставщика.
4. Отдел логистики перемещает все товары по заказу клиента на склад, откуда будет выполняться отгрузка (обычно склад филиала). Товар может перемещаться или с центрального склада, или со складов других филиалов.
5. При поступлении всего товара по заказу клиента на склад филиала - клиенту отсылается сообщение, что можно забрать товар или планируется доставка до клиента.
6. Товар отгружается клиенту, и на этом заказ считается выполненным.

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

Отдельно необходимо обрабатывать ситуации поставок под заказ крупных партий товара. Например, есть 30 штук товара на складах при среднем объеме продаж 5-7 штук в месяц. Клиент заказывает 100 штук товара. Это количество можно заказать у поставщика, и товар прибудет через 2 месяца. Если мы зарезервируем весь имеющийся товар на складе, то в течении этих двух месяцев не будет доступного товара для других покупателей. В таких ситуациях необходимо, чтобы резерв в 100 штук сформировался на складах фирмы после прихода от поставщика товаров, заказанных именно под этого клиента.

При реализации резервирования необходимо не допустить следующих типичных проблем:
Потери резервов. Во многих системах могут возникать ситуации, когда товар, который должен быть зарезервирован за одним клиентом, отгружается другому клиенту, и система не блокирует такую отгрузку. Часто такие ситуации возникают при перемещениях товара (приход товара от поставщика, приход товара при межскладских перемещениях) или при выявлении отклонений факта от документов (по факту пришло не то количество или не тот товар, который указан в документах перемещения или покупки).
Сложности с выполнением складских операций. Если кладовщик обнаружил недостачу или бракованную деталь, модуль резервирования не должен мешать перемещению этой детали на склад “недостачи” или на склад “брак”. Но надо отслеживать, чтобы при таких операциях не терялись резервы.
Длительное время расчета резервов (несколько минут) и блокировки. Если резервы считаются дольше, чем несколько секунд, это вызывает массу негативных эмоций как у пользователей системы, так и у клиентов. Часто расчет резервов блокирует других пользователей. И самое неприятное в блокировках и длительном времени расчета - расчет резервов в некоторых случаях вообще не выполняется (надо запускать заново) или выполняется с ошибками, что приводит к потерям резервов по некоторым заказам покупателей.

Описание алгоритма

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

Каждая строка заказа, которую необходимо резервировать, имеет “приоритет резервирования”. Например, если резерв под заказ клиенту Петрову был создан раньше, чем резерв под заказ клиенту Иванову, то приоритет строки заказа Петрова будет выше, чем приоритет заказа Иванова.

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

Отслеживаем любое из двух событий:
Количество, которое должно быть зарезервировано для строки заказа продажи, не соответствует фактическому резерву. Например, по строке были созданы резервы, потом строку перевели в статус “не резервировать”, количество к резервированию равно нулю, но резервы есть. Или создали новую строку заказа покупателя со статусом “только резервировать” и количеством 10 - количество к резервированию равно 10, а фактически зарезервировано 0.
Изменение количества товара в одном из мест, где можно резервировать товар (переместили товар на склад “Брак”, создали межскладское перемещение, перевели заказ поставщику в статус подтвержденного и т.п.).

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

В результате у нас есть корректный список резервов.
Если отфильтровать резервы, у которых тип места резервирования = склад и место назначения <> место резервирования и статус равен “резервировать и перемещать” или “резервировать, перемещать и закупать”, то получим список товаров для формирования межскладских перемещений под заказы клиентов.
Если отфильтровать резервы с типом “необходимо закупить” и статус равен “резервировать, перемещать и закупать”, то получим список товаров для закупки у поставщиков.

Вариант реализации алгоритма
Несколько пояснений к алгоритму:
Модуль резервирования создавался для MS Dynamics NAV. Реализовать алгоритм на языке бизнес логики NAV (C/AL) c приемлемой скоростью работы не получалось - слишком медленно происходили пересчеты. Поэтому был использован T-SQL.
Сам код выкладывать не очень корректно (там много специфических для конкретной фирмы вещей), поэтому привожу обобщенное “описание” кода без несущественных подробностей. Можно сделать вариант реализации для “ванильной” версии NAV, но это требует времени.
При реализации одним из основных требований была минимизация блокировок.
Расчет резервов всегда выполняется с нуля. Строки резервирования, которые были сформированы раньше, просто удаляются. Такой вариант выбран по той причине, что проверить существующие резервы, найти, что надо изменить в строках резервирования, удалить ненужные строки и создать и записать новые строки требует больше ресурсов (времени), чем каждый раз рассчитывать строки резервов с нуля.
Вызов модуля расчета резервов должен вызываться асинхронно, иначе будут проблемы с блокировками. Рассматривал вариант с сообщениями, но при этом усложнялась логика работы. Остановился на другом варианте. Джоб каждую секунду запускает хранимую процедуру, которая пересчитывает резервы. Это оказалось самым простым и надежным вариантом. SQL Server 2008 R2 не может запускать джоб на выполнение каждую секунду, он может запускать с периодичностью 10 секунд. Поэтому настроены 10 джобов, запускающих одну и ту же хранимую процедуру каждые 10 секунд, но время запуска каждого джоба сдвинуто по отношению к другим на 1 секунду. В результате хранимая процедура запускается на выполнение каждую секунду. Решение спорное, но работает без нареканий.

Таблицы, созданные под модуль резервирования
“Товары к пересчету” - список товаров, резервы по которым необходимо пересчитать. Поля:
код товара,
приоритет пересчета (1 или 2),
ДатаВремя создания записи.
“Товары в пересчете” - список товаров, резервы по которым сейчас пересчитывает один из запущенных экземпляров хранимой процедуры. Поля:
код товара,
ДатаВремя начала пересчета.
“Надо зарезервировать” - список строк заказов продажи и перемещений (созданных, но не отгруженных со склада - отправителя), под которые надо сформировать резервы. Поля:
ID потребности в резервировании
приоритет резервирования (бигинт, чем меньше число - тем выше приоритет),
тип документа резервирования,
номер документа резервирования,
номер строки документа резервирования,
код склада назначения (откуда товар будет отгружен покупателю),
код товара,
надо пересчитать резерв (булево),
статус резервирования,
тип закупки,
количество.
“Резервы” - список резервов. Поля:
код товара,
тип места резервирования (склад, межскладское перемещение, заказ поставщику),
код склада,
номер межскладского перемещения,
номер заказа поставщику,
ID потребности в резервировании - в данной таблице является ссылкой на строку в таблице “Надо зарезервировать”,
тип документа резервирования,
номер документа резервирования,
номер строки документа резервирования,
код склада назначения (откуда товар будет отгружен покупателю),
статус резервирования,
тип закупки,
количество.
“Приоритет мест резервирования” - в каком порядке резервировать товары. Поля:
код склада назначения (откуда товар будет отгружен покупателю),
приоритет места резервирования (int, чем меньше - тем выше приоритет, для каждого склада назначения свой список приоритетов),
тип места резервирования (склад, межскладское перемещение, заказ поставщику),
код склада,
код склада назначения межскладского перемещения,
код склада поступления товаров по заказу поставщику.
Эта таблица позволяет задать любой порядок приоритетов резервирования. Например, для регионального склада “Склад10” резервы должны формироваться в следующем порядке: Склад10 (сам региональный склад); перемещения на Склад10; ЦентральныйСклад; перемещения на ЦентральныйСклад; региональный Склад8; региональный Склад5; региональный Склад6; региональный Склад2; закупки у поставщиков с приходом на Склад10; закупки у поставщиков с приходом на ЦентральныйСклад. При этом, если в списке нет строк для каких либо мест резервирования, резервы там не создаются - на складах “Брак”, “Потери и излишки”, “Склад1”, “Склад4” и т.д. резервы под заказы покупателей с отгрузкой со “Склад10” не создаются, так как эти склады не указаны в таблице приоритетов для “Склад10”. Фактически, этот список приоритетов задает “стандартные” направления межскладских перемещений товаров.

Вспомогательные модули функционала резервирования
Отдельная хранимая процедура запускается раз в 5 секунд, и находит все товары, по которым с момента последней проверки выполнилось хотя бы одно из условий:
были движения,
были созданы новые межскладские перемещения,
были созданы новые подтвержденные заказы поставщикам.
При нахождении таких товаров они помещаются в таблицу “Товары к пересчету” с текущим временем и приоритетом 2.
Если данные в строках межскладских перемещений не совпадают со строками в таблице “Надо зарезервировать”, то в таблице “Надо зарезервировать” создаются правильные строки к резервированию с приоритетом 0, а товары помещаются в таблицу “Товары к пересчету” с текущим временем и приоритетом 2.

При создании новой строки заказа покупателя с одним из статусов, предусматривающим резервирование, создается строка в таблице “Надо зарезервировать”. Если строка заказа получает статус “не резервировать” и были строки в таблице “Надо зарезервировать” - они удаляются.
Если изменилось количество для резервирование в строке заказа покупателя (отгрузили товар клиенту или изменили количество) - меняется и количество в таблице
“Товары к пересчету”. Причем, если количество к резервированию уменьшилось - в существующей строке уменьшается количество, а если количество к резервированию увеличилось - создается новая строка в таблице “Товары к пересчету”. “Приоритет резервирования” присваивается из последовательности с шагом 1000.
Также пользователи могут “обмениваться” резервами. Тот пользователь, у заказа покупателя которого приоритет выше (значение поля “приоритет резервирования” меньше) может передать весь свой резерв или часть другому заказу покупателя. При этом создаются новые строки в таблице “Товары к пересчету” с “промежуточными” значениями приоритетов резервирования (не кратными 1000) и “надо пересчитать резерв” = истина.

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

Каждую минуту проверяем таблицу “Товары в пересчете”. Если есть записи, созданные раньше, чем 5 минут назад, эти записи удаляются, а товары из этих записей помещаются в “Товары к пересчету” с приоритетом 1.
Основной модуль резервирования
Begin transaction
Поиск товаров к пересчету резервов - проверяем таблицы “Надо зарезервировать” и “Резервы”.
Если у строк в таблице “Надо зарезервировать” поле “надо пересчитать резерв” = истина, то добавляем товары из этих строк, которые еще не присутствуют в “Товары к пересчету” с приоритетом 1, в таблицу “Товары к пересчету” с приоритетом 1. Если уже была запись с приоритетом 2, то она удаляется, и создается запись с приоритетом 1.
Строкам в таблице “Надо зарезервировать” с полем “надо пересчитать резерв” = истина изменяем значение этого поля на ложь.
Если количество в таблицах “Надо зарезервировать” и “Резервы” не совпадают друг с другом (соединение по полю “ID потребности в резервировании”), то включаем эти товары в таблицу “Товары к пересчету”, если их еще там нет. Резервы по заказам продажи включаем с приоритетом 1, резервы под перемещения - с приоритетом 2. Если уже была запись с приоритетом 2 и есть несоответствие по резервам заказа продажи, то запись с приоритетом 2 удаляется, и создается запись с приоритетом 1.
Commit
Begin transaction
Отбираем товары для пересчета резервов
Отбираем первые 100 записей (100 записей - ориентировочное значение, зависит от железа и настроек сервера СУБД и данных в системе - значение надо подбирать так, чтобы процедура завершалась в среднем не более чем за 1-2 секунды) из таблицы “Товары к пересчету”, отсортированные по возрастанию по полям “приоритет пересчета”, “ДатаВремя создания записи”, и отвечающих условию, что этих товаров нет в таблице “Товары в пересчете”, и помещаем во временную таблицу “Temp Товары к пересчету”.
Все товары, которые есть в таблице “Temp Товары к пересчету” помещаем в таблицу “Товары в пересчете”.
Все товары, которые есть в таблице “Temp Товары к пересчету” удаляем из таблицы “Товары к пересчету”.
Commit
Begin transaction
Находим все остатки товаров из таблицы “Temp Товары к пересчету” на всех складах, в межскладских перемещениях и заказах поставщикам, и записываем во временную таблицу “Temp остатки”. Поля:
код товара,
тип места резервирования (склад, межскладское перемещение, заказ поставщику),
код склада,
номер межскладского перемещения перемещения,
номер заказа поставщику,
ДатаВремя ожидаемого выполнения (для заказа поставщику и межскладского перемещения - поступление на склад получатель)
количество.
Копируем во временную таблицу все строки, для которых необходимо создать резервы. Из таблицы “Надо зарезервировать” отбираем все строки, у которых “код товара” присутствует в таблице “Temp Товары к пересчету”, и копируем эти строки во временную таблицу “Temp Надо зарезервировать”. Поля те же, что и в таблице “Надо зарезервировать”:
ID потребности в резервировании
приоритет резервирования (бигинт, чем меньше число - тем выше приоритет),
тип документа резервирования,
номер документа резервирования,
номер строки документа резервирования,
код склада назначения (откуда товар будет отгружен покупателю),
код товара,
надо пересчитать резерв (булево),
статус резервирования,
тип закупки,
количество.
Commit.
Все дальнейшие расчеты выполняются во временных таблицах, и процедура не блокирует работу остальных экземпляров процедуры расчета резервов или других модулей ERP системы.
Begin transaction
Создаем резервы под документы межскладского перемещения. Находим в таблице “Temp Надо зарезервировать” все строки с приоритетом 0 (такой приоритет устанавливаем для межскладских перемещений) и создаем под них резервы в таблице “Temp Резервы”. При этом надо проверять, что в документах перемещения количество меньше или равно остатку на складе.
Создаем резервы для поставки под заказ.
Находим все строки “Temp Надо зарезервировать” с типом “поставка под заказ” и помещаем в таблицу “Temp Надо зарезервировать под заказ”.
Ищем в учтенных поступлениях от поставщика строки с такими заказами покупателей (под какой заказ покупателя была закупка - храним в привязке к строке заказа поставщику и к строке прихода от поставщика). Если нашли - уменьшаем количество к резервированию в строке “Temp Надо зарезервировать под заказ” на количество в приходах от поставщика; если в результате количество к резервированию ноль или меньше нуля - удаляем такие строки из “Temp Надо зарезервировать под заказ”.
Ищем в “Temp остатки” строки с типом заказ поставщику, созданные под заказы покупателей из “Temp Надо зарезервировать под заказ” (дополнительно читаем данные - под какие заказы покупателей создана строка заказа поставщику). Если нашли - создаем строки “Temp Резервы” (резервируем в найденных строках “Temp остатки”) и уменьшаем количество к резервированию в строке “Temp Надо зарезервировать под заказ” на количество в приходах от поставщика; если в результате количество к резервированию ноль (все количество зарезервировали) - удаляем такие строки из “Temp Надо зарезервировать под заказ”.
Для всех оставшихся количеств в строках таблицы “Temp Надо зарезервировать под заказ” создаем строки в “Temp Резервы” с типом “необходимо закупить”
Основной цикл расчета резервов под заказы - начало.
Для каждого товара находим строку “Temp Надо зарезервировать”, для которой еще не созданы все резервы, и приоритет резервирования которой максимальный из еще не зарезервированных строк.
Для найденных строк “Temp Надо зарезервировать” находим все строки из “Temp остатки”, которые есть в списке приоритетов “Приоритет мест резервирования” для данного склада. Количество остатка уменьшаем на уже сформированные резервы из “Temp Резервы”. Если свободный остаток ноль - не включаем в список к резервированию. Сортируем по “приоритет места резервирования” и “ДатаВремя ожидаемого выполнения”.
Создаем строки резервов в “Temp Резервы” - для каждой найденной строки из “Temp остатки” резервируем большее из значений - свободный остаток в данном месте резервирования или еще не зарезервированное количество из “Temp Надо зарезервировать”. Если осталось не зарезервированное количество - резервируем в следующем по приоритету свободном остатке и т.д.
Если свободных (не зарезервированных) остатков не хватило - создаем на не зарезервированное количество резерв в “Temp Резервы” с типом “необходимо закупить”.
Проверяем, есть ли строки в таблице “Temp Надо зарезервировать под заказ”, количество в которых больше количества в созданных под эту строку строках в “Temp Резервы”. Если есть - переходим к пункту 14 (цикл).
Основной цикл расчета резервов под заказы - завершение.
Commit
Расчет резервов завершен. Записываем результат в общие таблицы.
Begin transaction
Удаляем все записи в таблице “Товары в пересчете” с товарами, которые есть в таблице “Temp Товары к пересчету”.
Удаляем все записи в таблице “Резервы” с товарами, которые есть в таблице “Temp Товары к пересчету”.
Копируем все записи из таблицы “Temp Резервы” в таблицу “Резервы”.
Commit.
Все расчеты резервов выполнены, все нужные таблицы обновлены.

Сисойs_ustinov, подобного подхода (ежесекундный пересчет резервов с созданием заново) я не встречал ни в одной ERP. И даже в WMS не попадалось. Совершенно непонятно, зачем каждую секунду их пересчитывать, если необходимость пересчета можно отслеживать триггерами. У Вас каждую секунду 24*7 что-то происходит с запасами и заказами? Не верю. И уж точно не верю, что процент обновления статусов настолько высок, что пересоздавать резервы всякий раз заново выгоднее, чем работать "по отклонениям".
Запасы не пересчитываются каждую секунду.
Каждую секунду идет проверка - есть ли товары, по которым надо пересчитать резервы.
Если таких товаров нет - ничего не пересчитывается. И вы правы, именно этот вариант срабатывает в 99% запусков.

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

А пересоздавать проще не потому, что очень высокий процент обновлений статусов.
Я ведь сознательно ВЕСЬ функционал расчета резервов переместил в один модуль, чтобы не было тормозов и блокировок, и при тех же отгрузках клиенту идет простая проверка, что резервов хватает (чтение из таблицы резервов), но сами резервы не пересчитываются (ничего в таблицу резервов не пишется). В результате учет документов выполняется существенно быстрее (нет пересчетов резервов) и нет блокировок, связанных с резервами. Но в результате полностью пересчитать резервы по товару проще, чем пытаться рассчитать изменения резервов.
Например, есть 10 разных заказов с одним и тем же товаром. Под них создано 20 разных строк резервов. И вот на одном из складов, где был один из резервов, количество уменьшилось на 4 штуки (списали в брак / учли межскладское перемещение / отгрузили клиенту). Какой должен быть алгоритм, чтобы рассчитать изменения в резервах?


СисойЯ делал подобную реализацию на 1С. Без ежесекундного пересчета. И с изменением только тех резервов (товарные позиции+склад) , по которым возникли события (заказы, закупки, перемещения). Естественно, строки заказов хранились не в документах (а в РС). И реальная строка заказа "расщеплялась" на несколько в зависимости от способа пополнения, партий закупки, складов резервирования.
Не уверен, что моя реализация "потянула" бы большую контору, нас устраивало.
А как именно выполнялось "изменением только тех резервов (товарные позиции+склад) , по которым возникли события (заказы, закупки, перемещения)"?
Я в свое время не смог придумать нормальный алгоритм для таких ситуаций.
Я уже описал ситуацию - есть несколько заказов. И например количество на складе уменьшилось (списали в брак). Если в результате на этом складе не хватает количества для резервирования, надо зарезервировать на другом складе - а там могут быть резервы по другим заказам с другим приоритетом. Как именно работает ваша реализация резервирования в такой ситуации?

Злой Бобрs_ustinov... выявили как минимум одну задачу, которую нельзя решить при использовании распределенных баз - это резервирование на нескольких складах.
Штатно - нельзя. Можно связать БД через триггер, но это уже шаманство.

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

Злой Бобрs_ustinov... обсуждался вопрос, насколько 1С готова к БОЛЬШИМ внедрениям (насколько хорошо масштабируется).
Нету там такого. Там только попытка сравнить 1С с САПом. Типа как сравнивать мерс и запорожец.

Есть там такое.

Точно были фразы, что 1С ERP из коробки поддерживает до 1000 пользователей, а если надо больше - можно сделать распределенные базы.
А это уже большие внедрения.

Злой Бобрs_ustinovЕсть там такое.

Точно были фразы, что 1С ERP из коробки поддерживает до 1000 пользователей, а если надо больше - можно сделать распределенные базы.
А это уже большие внедрения.
Вы конечно можете продолжать верить в рекламу 1С, но практика показывает что далеко не все так просто. Я вовсе не хочу сказать что у 1С все хреново. Например формоклепание даже офис мелкомягких подвинули. Плюс еще пару моментов. Но в остальном - это такая стремная поделка, что ...
Я как раз не верю в рекламу.
В той ветке форума были отдельные утверждения, что 1С готов к крупным внедрениям. Лично я такого не говорил и в это не верю. Хотя могу ошибаться, последние лет 5 новинки 1С активно не смотрел - но всё равно не верю, слишком много 1С наклепала у себя велосипедов, от которых не желает отказываться. И в качестве возможного решения проблем с масштабируемостью 1С упоминались распределенные базы.

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

startegПардон , не удержался.
Если вы сразу пересчитываете резервы, в момент приема заказа, то есть риск наступить на следующий косяк:

1. Всего есть 100 единиц Т1
2. На заказ Петрова зарезервировали с 100 Т1 (резерв пересчитался - заказ не закрыт)
3. Иванов хочет зарезервировать 50 Т1, но его нет (все у Петрова в резерве)
4. Иванов закрыл заказ
5. Петров отказался от Т1 вообще (резерв пересчитался заказ закрыт!)
6. 100 единиц Т1 - все еще доступны для заказа :-)
Есть две возможности уменьшить риск такого косяка:
1. Обычно первым оформляется запрос (заявка / предварительный заказ / Quote - называют по разному). В навике это отдельный тип документа Quote, в мы 1С делали дополнительный статус для документа "Заказ". С помощью этого документа можно посчитать общую цену с учетом скидок и посмотреть наличие товара (сколько есть незарезервированного товара и на каких складах), но товар не резервируется. И только если клиента всё устраивает - из квоты создается заказ. И только иногда (например, для постоянных клиентов) сразу создается заказ с резервированием строк. То есть резервы создаются тогда, когда риск отказа от заказа небольшой.
2. По каждому товару можно установить максимальное количество, которое может быть зарезервировано одним заказом. Например, известны "желаемые" (которые должны быть по плану) остатки товара на всех складах. И устанавливаем максимальное количество резервирования по одному заказу покупателя 20% от общего желаемого количества остатков. Если надо больше - оформляется поставка под заказ. В особых случаях директор филиала (согласовав с менеджером этой группы товаров) может оформить резерв на большее количество, но это исключение.

В результате косяки, когда одному клиенту оформили резерв, по этой причине отказали другому клиенту, а потом первый клиент отказался - встречаются относительно редко. Хотя полностью исключить такие косяки нельзя.

_bobну отлично
1. Всего есть 100 единиц Т1
2. На заказ Петрова ПРЕДзарезервировали 100 Т1 (резерв пересчитался? - заказ не закрыт)
3. Иванов хочет ПРЕДзарезервировать 50 Т1, но его нет? или есть?

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

_bobдальше события могут развиваться двумя путями:

4А. Предзарезервировали Т1 на оба заказа.
5А. Окончательно зарезервировали и продали и отгрузили 50 Т1 Иванову.
6А. С Петровым была согласована цена 100 Т1, при покупке 50 Т1 цена будет другая, но Петрову нужно именно 100 штук. А он уже тендер на поставку выиграл ))))
Нет "предрезервирования". В свое время долго обсуждали такие вещи. Нельзя быть немного беременной, и товар не может быть "предрезервирован". Именно по описанной вами причине.

Товар или зарезервирован, или нет.
Для Иванова сформируется резерв с типом "надо закупить", и до тех пор, пока товар не приедет от поставщика или пока не отменят заказ Петрову - система не даст ничего отгрузить Иванову.

_bob4Б. Та же история, что и в самом начале: Иванову отказали в предрезервировании.
5Б. Петров отказался от покупки
6Б. 100 единиц Т1 - все еще доступны для заказа :-)

Именно так и должно быть.
Неприятно, но если "Петрову нужно именно 100 штук. А он уже тендер на поставку выиграл", а уже "отгрузили 50 Т1 Иванову" - будет еще хуже.

startegЧто точно будет работать!

Опыт из производства скоропорта работающего с розницей
Число операторов приема заявок от 10 и выше

Предпосылки:
а) скоропорт не производится в момент и доложен быть реализован быстро и желательно без остатка
б) на первый план выходит планирование производства исходя из планируемого(!) объема заявок

1. У каждой торговой точки Заказчика есть волатильность, которая достаточно хорошо прогнозируется (по дням недели, датам выдачи зарплаты-аванса, праздникам)
2. Каждая точка заказывает(с учетом п.1 (!)) обычно одно и тоже количество
3. Есть крупные заказчики (точки) для которых отклонение от среднего количества заказа не является столь критичным, как для малых точек

Подходы:
Заказы на поставку принимаются заранее ( с учетом затрат времени на производство)
Время приема заявок от крупных точек согласовывается заранее и устанавливается на максимально поздний срок
есть договоренность с крупными торговыми точками о возможном изменении количества из заказов как в большую так и в меньшую сторону но не более 10% от среднего объема (как вариант!)
Система должна мониторить заказы и предлагать для каждой торговой точки расчетное (обычное для этого дня, количество)
После получения заказов от мелочи, остатки закрываются на крупные торговые точки

Ну как-то так :-)
Я со скоропортом не сталкивался...
Алгоритм, который я описал, для скоропорта точно не сработает. Тут, как я понимаю, именно резервирования вообще нет, а есть планирование продаж (заказов) + производство под заказы (с возможностью для поставщика изменить заказ покупателя)...

ViPRoss_ustinov,

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

Тот алгоритм, который я описал, реализует довольно примитивную логику:
- Автоматическое резервирование - товар получает тот, под кого раньше создали резерв (FIFO)
- "Ручное" управление резервами - резервы вручную перебрасываются с одного клиента на другого клиента.

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

svcoderОт обычного резервирования в типовых решениях 1С ваше отличается тем, что в регистрах резервов нужно добавить измерения дата и способ резерва. Но ваше решение - очищать резервы при каждом пересчете очень спорное. Почему нельзя делать сторнирующие или корректирующие движения при изменениях. Например при уменьшении количества в одном из заказов клиента, сделать движение в минус по резервам и одновременно поискать размещение этой позиции в заказах поставщика у других заказов, движение в минус там и в плюс по складскому резерву
Отличия с типовыми 1С не только в "измерения дата и способ резерва". Я переделывал типовое резервирование в УПП, и ограничился относительно небольшими изменениями. В результате получил те же проблемы, которые видел и у других - блокировки и как результат медленный расчет резервов (иногда) и потери резервов. Например при перемещении с центрального склада на склад филиала одновременно должен "переместиться" и резерв, и вот тут то и возникали проблемы (тормоза и потери резервов). Но там было немного пользователей и относительно немного заказов - проблемы возникали редко и это не было критичным. А в другой фирме (где навик) количество операций было на порядок больше. Изначально там было реализованно похожее решение - документы при учете переписывали резервы. И в один не очень прекрасный момент склад не смог отгрузить все перемещения, так как медленно учитывались отгрузки - кладовщики блокировали друг друга (пересчет резервов при учете перемещений). И пришлось придумывать другую реализацию - без блокировок . Заодно и проблему с "потерянными" резервами решили (она в старой реализации тоже была).

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

_bobs_ustinov
Именно так и должно быть.
Неприятно, но если "Петрову нужно именно 100 штук. А он уже тендер на поставку выиграл", а уже "отгрузили 50 Т1 Иванову" - будет еще хуже.

тогда поздравляю! ваш гениальный алгоритм практически полностью повторяет сильно усеченный документ "заказ" из 1С_УТ: там у заказа куча статусов, для вашего алгоритма хватит и части: заказан, зарезервирован, отгружен, доставлен


И в какой же именно версии УТ реализовано автоматическое создание резервов на нескольких складах по определенным приоритетам? Не так, чтобы пользователь выбирал, где ему резервировать, а система сама всё резервировала? И чтобы при перемещениях резервы сохранялись?

_bobну и следующий вопрос: чем навик удобнее для написания логики на SQL по сравнению с 1С?
В решении проблемы с блокировками (тормоза и потери резервов).

Сделать быстрый асинхронный пересчет резервов в навике проще - можно ЛЕГКО писать с помощью SQL прямо в таблицы навика. А вот как сделать что то с аналогичным результатом в 1С (не с помощью SQL - писать сиквелом в таблички БД, в которых "хранятся" регистры 1С мне как-то совсем не хотелось) я в свое время придумать так и не успел (перешел на другую работу).

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

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

Взаимоблокировки это всегда ошибка в логике

В целом согласен - это ошибки логики.
svcoders_ustinovИ пришлось придумывать другую реализацию - без блокировок . Заодно и проблему с "потерянными" резервами решили (она в старой реализации тоже была).

Как и в исходной ветке весь спор скатывается к сравнению блокировочников и версионников. Ответить на вопрос справится ли 1с с той нагрузкой, с которой у вас справляется навик сможет только реализация и испытание подобной системы резеруирования на платформе 1с. Но я не думаю, что будут какие то проблемы.
авторПопробуйте прописать алгоритм действий при событии "уменьшение количества в одном из заказов клиента", а потом при событии "уменьшение остатка на складе" (например при недостаче)..
Не вижу особой сложности, просто не нужно пытаться каскадно поменять все резервы, достаточно обработать существующие резервы, начиная с последнего. Если вы пообещали клиенту, что его заказ прибудет 10 числа, ничего плохого не произойдет, если резерв отмененного заказа на 5 число, достанется заказу, который был запланирован на 15 число

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

Ок. Давайте обсудим конкретный пример.
Три события происходят "почти одновременно", то есть с разницей в несколько миллисекунд.
Событие 1. На "Склад А" учитывается поступление от поставщика, которое включает поступление 100 штук товара "Т".
Событие 2. Со "Склад В" списывается 5 штук товара "Т" (обнаружили недостачу).
Событие 3. В филиале "Склад С" учитывается заказ продажи (формируются резервы) на 15 штук товара "Т". Филиалу "Склад С" разрешено резервировать товары на "Склад С", "Склад В", "Склад А".
При этом существует несколько других заказов продажи с товаром "Т", под которые сформированы резервы. В том числе резервы были и в заказе покупки, по которому идет поступление на склад (событие 1), и на "Склад В", на котором обнаружили недостачу (событие 2), и на "Склад С", где учитываем новый заказ.

Каким, по вашему мнению, должен быть корректный (без ошибок логики) алгоритм резервирования и как он должен отработать в данном случае?
svcoder Взаимоблокировки это всегда ошибка в логике

_bobs_ustinovпропущено...

В решении проблемы с блокировками (тормоза и потери резервов).

Сделать быстрый асинхронный пересчет резервов в навике проще - можно ЛЕГКО писать с помощью SQL прямо в таблицы навика. А вот как сделать что то с аналогичным результатом в 1С (не с помощью SQL - писать сиквелом в таблички БД, в которых "хранятся" регистры 1С мне как-то совсем не хотелось) я в свое время придумать так и не успел (перешел на другую работу).

1. чем таблицы навика эскуэльнее таблиц 1С ? То, что вы не разобрались в архитектуре хранения данных и не умеете отследить профайлером что куда пишется, это понятно...вопрос именно об эскуэльности таблиц )))

Во первых, в 1С надо дополнительно ковыряться, чтобы определить, какие таблицы за что отвечают. Согласитесь, это уже сложнее, чем в навике - там ковыряться не надо.
Во вторых, есть такая вещь, как изменение версии платформы 1С. Иногда версию менять надо (по разным причинам), а что может произойти при смене версии платформы вы, вероятно, и сами знаете.
Ну и в третьих - а где вы вообще видели "таблицы 1С"? В конфигураторе их точно нет. И в документации 1С их тоже нет. Ну и смотрим "во вторых".
Да и просто написать селект с "интуитивно понятными" названиями полей - удовольствие сильно ниже среднего. Можно, разумеется, сделать вьюшку и работать с ней. Но это всё лишний геморрой.

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

svcoders_ustinovОк. Давайте обсудим конкретный пример.
Три события происходят "почти одновременно", то есть с разницей в несколько миллисекунд.
Событие 1. На "Склад А" учитывается поступление от поставщика, которое включает поступление 100 штук товара "Т".
Событие 2. Со "Склад В" списывается 5 штук товара "Т" (обнаружили недостачу).
Событие 3. В филиале "Склад С" учитывается заказ продажи (формируются резервы) на 15 штук товара "Т". Филиалу "Склад С" разрешено резервировать товары на "Склад С", "Склад В", "Склад А".

Зачем вы вносите неопределенность в условия задачи? Если в начале алгоритма резервирования установить необходимые блокировки , все эти события очень даже упорядочены и их логика очевидна. При поступлении резервы в заказе заменяются на резервы склада, списание со склада меняет последние резервы со склада на следующие по доступности. Ну про заказ и так все понятно
А где оно, начало алгоритма резервирования, для события 1? И какие блокировки необходимо установить?
При старте проведения поступления на склад? Или после проведения (записи в регистры) модуль резервирования вызывается отдельно? Если при старте проведения - то учет поступления может выполняться довольно долго (несколько сотен позиций + пересчеты резервов) - и всё это время остальные документы заблокированы... А если после проведения - то получится, что остатки уже обновлены, а резервы еще нет, и может вклиниться заказ покупателя (событие 3) и забрать резервы себе...

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

Когда рассуждаешь "в принципе" - всё легко. А при попытке это реализовать проявляются нюансы...

svcoders_ustinovВо вторых, есть такая вещь, как изменение версии платформы 1С. Иногда версию менять надо (по разным причинам), а что может произойти при смене версии платформы вы, вероятно, и сами знаете.
Последние изменения в языке запросов происходили при переходе с 8.1 на 8.2 т.е. 8 лет назад. Из-за необходимости поддержки oracle, пришлось отказаться от некоторых конструкций, а для некоторых добавили ограничения

При чем тут язык запросов?

Сама 1С ясно написала:

http://v8.1c.ru/metod/faq2/answer.jsp?id=493]Как просмотреть структуру таблиц информационной базы?
...

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

...

ВНИМАНИЕ

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

Не рекомендуется использовать её для реализации какой-либо части прикладной функциональности .


Я даже догадываюсь, почему не рекомендуется:

http://downloads.v8.1c.ru/content//Platform/8_3_7_1845/1cv8upd.htm]Переход с предыдущей версии на версию 8.3.6

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

svcoder,
вас действительно не напрягает вариант с записью в таблицы 1С (которые создала платформа) с помощью SQL?
Лично мне такой вариант совсем не нравится...

_bob, svcoder
Не надо меня убеждать, что в 1С с помощью кода на SQL можно создать модуль резервирования - я знаю, что можно.
Вопрос в другом - как можно реализовать резервирование штатными средствами 1С (в конфигураторе)? Естественно, реализовать без ошибок в логике и тормозов.

_bobs_ustinov, а вы знаете, обычно после написания и внедрения нетипового функционала ни конфигурацию ни технологическую платформу НЕ ОБНОВЛЯЮТ
Знаю.
Довольно много фирм до сих пор на 1С 7.7
Вы считаете, что это хорошо? Технический долг
Да и в некоторых случаях платформу приходится обновлять...

_bobа зачем?
вы на навике штатными средствами без ошибок в логике и тормозов сделать этого не смогли
воплотить практически любой замудреный алгоритм резервирования товара штатными средствами 1С (в конфигураторе) МОЖНО, но есть шанс налететь на тормоза
все же надо отдавать себе отчет, что существуют ограничения, и некоторые процессы даже для очень небольшой компании невозможно воплотить на 1С
Когда разбирались с этой задачей в навике - почти сразу стало понятно, что средствами нава (на C/AL) эту задачу не решить - не хватит скорости.
А когда начали разбирать такую же задачу в 1С (в другой фирме) - то всё было не столь очевидно. Платформа 1С намного больше фич содержит. Язык запросов, менеджер временных таблиц - вроде бы почти всё получалось...
Да и навик подружить с сиквелом существенно проще и удобнее, чем 1С с сиквелом... Вот и думали, как это в 1С сделать...

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

svcoders_ustinovА где оно, начало алгоритма резервирования, для события 1? И какие блокировки необходимо установить?
При старте проведения поступления на склад? Или после проведения (записи в регистры) модуль резервирования вызывается отдельно? Если при старте проведения - то учет поступления может выполняться довольно долго (несколько сотен позиций + пересчеты резервов) - и всё это время остальные документы заблокированы... А если после проведения - то получится, что остатки уже обновлены, а резервы еще нет, и может вклиниться заказ покупателя (событие 3) и забрать резервы себе...
При поступлении никаких алгоритмрв резервирования вызывать не нужно. Нужно перенести резервы из размещения заказа на склад . При списании нужно блокировать, но в чем проблема? Это не такая частая операция по сравнению с обычным порядком резерв-поступление-отгрузка.

Вы пробовали использовать управляемые блокировки 1с? Они работают быстрее блокировок БД и гораздо позже эскалируются.
Перенос резервов - это тоже алгоритм резервирования. Просто перенести резервы не получится - поступление далеко не всегда равно заказу. Мы не в идеальном мире живем, и всегда можно наткнуться на разницы (пересортица, например). Поэтому резервы надо пересчитать.
Вопрос - в какой момент использовать блокировки, чтобы не нарушить логику работы? Если вызвать слишком рано - автоматом появятся тормоза, так как резервы будут узким местом. Если чуть позже - риск взаимных блокировок и потери резервов.
И управляемые блокировки в данном случае ничем не помогают.
При детальном анализе у меня получилось, что единственный вариант с правильной логикой работы и без тормозов - асинхронный вызов пересчета резервов. Но как сделать это в 1С - не понятно.

_bob, ну я никогда не утверждал, что крут именно как программист 1С
В 1С у меня средний уровень.

_bob4. РЗ "пересчитыватель" которое по таймеру берет из регистров задания , пересчитывает резервы и записывает в регистр "выполненные_пересчитывателем_задания" ИД выполненных заданий, чтоб их второй раз не выполнять


А можно уточнить, как именно вы это сделали?

Я думал использовать:


Но мне сказали, что это не будет работать так, как нужно.
Нужно, чтобы каждую секунду запускался новый экземпляр процедуры пересчета резервов независимо ни от чего. Например в 11:40:10 запустился один экземпляр процедуры "ПересчитатьРезервы", в 11:40:11, не дожидаясь завершения предыдущего запуска, запустился еще один экземпляр процедуры "ПересчитатьРезервы", в 11:40:12 запустился третий экземпляр (при этом всё еще работает запущенный в 11:40:10, а например запущенный в 11:40:11 уже завершил работу) и т.д.
Мне сказали, что так в 1С не будет параллельно выполняться несколько экземпляров процедуры "ПересчитатьРезервы".

Или мне сказали неточные сведения, и ПодключитьОбработчикОжидания будет работать так, как надо для этой задачи?

_bobя считаю что это замечательно, когда люди не тратят деньги на ненужные обновления софта
как замечательный пример: система бронирования билетов в РЖД, система бронирования авиабилетов в США, обе написаны на коболе под AS/400 столетие назад, ну и знаменитая АБС Equation (PRG/400 под AS/400), в Альфа-банке радостно юзают и не жужжат

Одно дело, когда обновление не нужно.
А другое дело, когда обновление очень нужно (новые фичи всем бы пригодились), но из-за "технического долга" перейти на новую версию очень дорого.

OremaxУважаемые коллеги.
Поскольку я не являюсь специалистом 1С и MS Dynamics мне не совсем понятно почему в этой теме говорят о проблемах с блокировками и как следствие с "тормозами"?
Как работает механизм блокировок?
Есть ли возможность при обработке данных управлять транзакциями и уровнями изоляции транзакций?
Именно для резервирования на нескольких складах тема блокировок является ключевой.
Если реализовывать алгоритм без логических ошибок "в лоб" - надо очень рано вызывать блокировки, и тогда пользователи будут постоянно блокировать друг друга - всё будет тормозить. А если попытаться блокировать данные попозже, чтобы уменьшить блокировки - начинаются логические ошибки (потери резервов).
И в 1С, и в навике управлять блокировками можно... Но...
В 1С сделали свой механизм управляемых блокировок, который работает "выше" транзакций СУБД, и программисту надо самому продумывать, что и в какой момент блокировать для обеспечения целостности данных. Автоматические блокировки в 1С тоже есть, но с ними масштабируемость совсем плохая.
В навике блокировки автоматические на уровне MS SQL, сам нав только стартует транзакции. Из кода нава можно вызвать коммит, если принудительно надо разбить код на несколько транзакций. Но в наве проблема с масштабируемостью не связана напрямую с транзакциями. У многих таблиц есть поле "Entry No" - номер операции, которые идут последовательно по возрастанию - 1,2,3,4 и т.д. И этот номер генерируется кодом нав, а не автоинкремнтом СУБД... Так что всё печально...

А уровнем изоляции транзакций, насколько знаю, ни там ни там управлять нельзя.

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