Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / ERP и учетные системы Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
 Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

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

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

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

Так как описание алгоритма резервирования может пригодиться и само по себе - подробно расписал мой вариант алгоритма и выкладываю в отдельной теме (в следующих сообщениях).
27 дек 16, 14:16    [20052874]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Вот описание в гугл доках:
https://drive.google.com/open?id=1WDSbfBZmql-Blz_wCgy5QUHx5xbJ2cthoEcVN6E5gAw
27 дек 16, 14:20    [20052888]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

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

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

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

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

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

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

При реализации резервирования необходимо не допустить следующих типичных проблем:
Потери резервов. Во многих системах могут возникать ситуации, когда товар, который должен быть зарезервирован за одним клиентом, отгружается другому клиенту, и система не блокирует такую отгрузку. Часто такие ситуации возникают при перемещениях товара (приход товара от поставщика, приход товара при межскладских перемещениях) или при выявлении отклонений факта от документов (по факту пришло не то количество или не тот товар, который указан в документах перемещения или покупки).
Сложности с выполнением складских операций. Если кладовщик обнаружил недостачу или бракованную деталь, модуль резервирования не должен мешать перемещению этой детали на склад “недостачи” или на склад “брак”. Но надо отслеживать, чтобы при таких операциях не терялись резервы.
Длительное время расчета резервов (несколько минут) и блокировки. Если резервы считаются дольше, чем несколько секунд, это вызывает массу негативных эмоций как у пользователей системы, так и у клиентов. Часто расчет резервов блокирует других пользователей. И самое неприятное в блокировках и длительном времени расчета - расчет резервов в некоторых случаях вообще не выполняется (надо запускать заново) или выполняется с ошибками, что приводит к потерям резервов по некоторым заказам покупателей.
27 дек 16, 14:21    [20052889]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Описание алгоритма

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

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

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

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

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

В результате у нас есть корректный список резервов.
Если отфильтровать резервы, у которых тип места резервирования = склад и место назначения <> место резервирования и статус равен “резервировать и перемещать” или “резервировать, перемещать и закупать”, то получим список товаров для формирования межскладских перемещений под заказы клиентов.
Если отфильтровать резервы с типом “необходимо закупить” и статус равен “резервировать, перемещать и закупать”, то получим список товаров для закупки у поставщиков.
27 дек 16, 14:22    [20052898]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Вариант реализации алгоритма
Несколько пояснений к алгоритму:
Модуль резервирования создавался для 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.
Все расчеты резервов выполнены, все нужные таблицы обновлены.
27 дек 16, 14:24    [20052905]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
Сисой
Member

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

Я делал подобную реализацию на 1С. Без ежесекундного пересчета. И с изменением только тех резервов (товарные позиции+склад) , по которым возникли события (заказы, закупки, перемещения). Естественно, строки заказов хранились не в документах (а в РС). И реальная строка заказа "расщеплялась" на несколько в зависимости от способа пополнения, партий закупки, складов резервирования.
Не уверен, что моя реализация "потянула" бы большую контору, нас устраивало.
27 дек 16, 15:36    [20053206]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3153
s_ustinov
... обсуждался вопрос, насколько 1С готова к БОЛЬШИМ внедрениям (насколько хорошо масштабируется).

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

Штатно - нельзя. Можно связать БД через триггер, но это уже шаманство.
s_ustinov
Эту задачу нормально можно решить только при одной централизованной базе. Но возник вопрос - а насколько эта задача решается штатными средствами 1С?

Мы делали подобное на клюшках примерно в 2008 году. Все работало. Но опять же - число пользователей было около 100. Если в снеговике решили проблему с большим количеством пользователей и блокировками, то вероятно взлетит и на снеговике (утверждать небуду т.к. снеговиком не занимался и не планирую).
Учитывая кривизну 1С я б не рискнул внедрять такое в большой конторе. Здоровье дороже.
27 дек 16, 23:21    [20054777]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Сисой
s_ustinov, подобного подхода (ежесекундный пересчет резервов с созданием заново) я не встречал ни в одной ERP. И даже в WMS не попадалось. Совершенно непонятно, зачем каждую секунду их пересчитывать, если необходимость пересчета можно отслеживать триггерами. У Вас каждую секунду 24*7 что-то происходит с запасами и заказами? Не верю. И уж точно не верю, что процент обновления статусов настолько высок, что пересоздавать резервы всякий раз заново выгоднее, чем работать "по отклонениям".

Запасы не пересчитываются каждую секунду.
Каждую секунду идет проверка - есть ли товары, по которым надо пересчитать резервы.
Если таких товаров нет - ничего не пересчитывается. И вы правы, именно этот вариант срабатывает в 99% запусков.

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

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


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

А как именно выполнялось "изменением только тех резервов (товарные позиции+склад) , по которым возникли события (заказы, закупки, перемещения)"?
Я в свое время не смог придумать нормальный алгоритм для таких ситуаций.
Я уже описал ситуацию - есть несколько заказов. И например количество на складе уменьшилось (списали в брак). Если в результате на этом складе не хватает количества для резервирования, надо зарезервировать на другом складе - а там могут быть резервы по другим заказам с другим приоритетом. Как именно работает ваша реализация резервирования в такой ситуации?
28 дек 16, 11:25    [20055646]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Злой Бобр
s_ustinov
... выявили как минимум одну задачу, которую нельзя решить при использовании распределенных баз - это резервирование на нескольких складах.

Штатно - нельзя. Можно связать БД через триггер, но это уже шаманство.


Я на секунду представил несколько десятков территориально разнесенных баз, бизнес логика в которых связана через триггеры...
Это не шаманство, это совсем другим словом называется.
28 дек 16, 11:52    [20055800]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Злой Бобр
s_ustinov
... обсуждался вопрос, насколько 1С готова к БОЛЬШИМ внедрениям (насколько хорошо масштабируется).

Нету там такого. Там только попытка сравнить 1С с САПом. Типа как сравнивать мерс и запорожец.

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

Точно были фразы, что 1С ERP из коробки поддерживает до 1000 пользователей, а если надо больше - можно сделать распределенные базы.
А это уже большие внедрения.
28 дек 16, 11:58    [20055829]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
Злой Бобр
Member

Откуда: Украина, Кривой Рог
Сообщений: 3153
s_ustinov
Это не шаманство, это совсем другим словом называется.

Согласен. Просто вариант такой может быть. Естественно вазелином придется запастись впрок.
s_ustinov
Есть там такое.

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

Вы конечно можете продолжать верить в рекламу 1С, но практика показывает что далеко не все так просто. Я вовсе не хочу сказать что у 1С все хреново. Например формоклепание даже офис мелкомягких подвинули. Плюс еще пару моментов. Но в остальном - это такая стремная поделка, что ...
28 дек 16, 14:16    [20056663]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Злой Бобр
s_ustinov
Есть там такое.

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

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

Я как раз не верю в рекламу.
В той ветке форума были отдельные утверждения, что 1С готов к крупным внедрениям. Лично я такого не говорил и в это не верю. Хотя могу ошибаться, последние лет 5 новинки 1С активно не смотрел - но всё равно не верю, слишком много 1С наклепала у себя велосипедов, от которых не желает отказываться. И в качестве возможного решения проблем с масштабируемостью 1С упоминались распределенные базы.
28 дек 16, 14:47    [20056863]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
Кстати, если кто делал аналогичные вещи (в любой из систем) - поделитесь деталями.
28 дек 16, 15:01    [20056962]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

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

1. Всего есть 100 единиц Т1
2. На заказ Петрова зарезервировали с 100 Т1 (резерв пересчитался - заказ не закрыт)
3. Иванов хочет зарезервировать 50 Т1, но его нет (все у Петрова в резерве)
4. Иванов закрыл заказ
5. Петров отказался от Т1 вообще (резерв пересчитался заказ закрыт!)
6. 100 единиц Т1 - все еще доступны для заказа :-)

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

В результате косяки, когда одному клиенту оформили резерв, по этой причине отказали другому клиенту, а потом первый клиент отказался - встречаются относительно редко. Хотя полностью исключить такие косяки нельзя.
4 янв 17, 16:43    [20073107]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
_bob
Member

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

1. Всего есть 100 единиц Т1
2. На заказ Петрова зарезервировали с 100 Т1 (резерв пересчитался - заказ не закрыт)
3. Иванов хочет зарезервировать 50 Т1, но его нет (все у Петрова в резерве)
4. Иванов закрыл заказ
5. Петров отказался от Т1 вообще (резерв пересчитался заказ закрыт!)
6. 100 единиц Т1 - все еще доступны для заказа :-)

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

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



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

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

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

4Б. Та же история, что и в самом начале: Иванову отказали в предрезервировании.
5Б. Петров отказался от покупки
6Б. 100 единиц Т1 - все еще доступны для заказа :-)
5 янв 17, 09:58    [20074421]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
starteg
Member

Откуда:
Сообщений: 29
Что точно будет работать!

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

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

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

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

Ну как-то так :-)
5 янв 17, 11:56    [20074593]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

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


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

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

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

Нет "предрезервирования". В свое время долго обсуждали такие вещи. Нельзя быть немного беременной, и товар не может быть "предрезервирован". Именно по описанной вами причине.

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

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


Именно так и должно быть.
Неприятно, но если "Петрову нужно именно 100 штук. А он уже тендер на поставку выиграл", а уже "отгрузили 50 Т1 Иванову" - будет еще хуже.
5 янв 17, 14:15    [20074928]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
ViPRos
Member

Откуда:
Сообщений: 7667
s_ustinov,

какой то у вас черно-белый мир
все зависит от ситуации, штрафных санкций, значимости клиента, характеристик заделов и т.д.
для этого существуют политики резервирования, некоторые политики запросто могут разрешать нарушение обязательств по резервированию по другим политикам и т.д.
5 янв 17, 14:21    [20074946]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
ViPRos
Member

Откуда:
Сообщений: 7667
ViPRos,

правила нужны для того что бы можно было бы управлять алгоритмом оптимизации по заданным критериям с учетом деловых обычаев - и только, главное критерии
5 янв 17, 14:23    [20074951]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
starteg
Что точно будет работать!

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

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

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

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

Ну как-то так :-)

Я со скоропортом не сталкивался...
Алгоритм, который я описал, для скоропорта точно не сработает. Тут, как я понимаю, именно резервирования вообще нет, а есть планирование продаж (заказов) + производство под заказы (с возможностью для поставщика изменить заказ покупателя)...
5 янв 17, 14:57    [20075041]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
svcoder
Member

Откуда: Кырск->СПб
Сообщений: 396
s_ustinov
Но возник вопрос - а насколько эта задача решается штатными средствами 1С? То есть решить эту задачу в 1С можно - путем написания кода на SQL. Но это не совсем феншуйный вариант. А при использовании только штатных инструментов 1С лично мне не очень понятно, как вызывать модуль пересчета резервов, чтобы была приемлемая скорость работы и не было блокировок.

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

От обычного резервирования в типовых решениях 1С ваше отличается тем, что в регистрах резервов нужно добавить измерения дата и способ резерва. Но ваше решение - очищать резервы при каждом пересчете очень спорное. Почему нельзя делать сторнирующие или корректирующие движения при изменениях. Например при уменьшении количества в одном из заказов клиента, сделать движение в минус по резервам и одновременно поискать размещение этой позиции в заказах поставщика у других заказов, движение в минус там и в плюс по складскому резерву
5 янв 17, 15:37    [20075105]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
ViPRos
s_ustinov,

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

Такое вполне может быть, но я на практике не сталкивался с настолько сложными бизнес-процессами.

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

А чтобы резервировать с учетом приоритета клиентов или штрафных санкций... Я могу себе представить такой алгоритм, но у тех фирм, где работал, не было необходимости в таком усложнении. Все исключения из логики FIFO встречались относительно редко и решались в ручном режиме.
5 янв 17, 15:58    [20075134]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
_bob
Member

Откуда: Москва
Сообщений: 1629
s_ustinov

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


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


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

ну и следующий вопрос: чем навик удобнее для написания логики на SQL по сравнению с 1С?
5 янв 17, 16:55    [20075244]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

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

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

А по поводу очищения резервов...
У очищения есть небольшой плюс - размер таблицы с резервами не растет со временем, а только при росте оборотов (количества обрабатываемых заказов). Но это не было основной причиной выбора варианта с очисткой. Алгоритм с очисткой банально оказалось проще реализовать. И он оказался быстрее (по крайней мере первые пробные варианты).
Попробуйте прописать алгоритм действий при событии "уменьшение количества в одном из заказов клиента", а потом при событии "уменьшение остатка на складе" (например при недостаче). Тогда будет видно, что если не сторнировать все старые резервы и считать новые резервы с нуля логика получается довольно сложная. А просто удалить старые резервы проще, чем найти резервы, которые надо сторнировать, создать сторнирующие записи и потом создать новые резервы.
5 янв 17, 17:41    [20075381]     Ответить | Цитировать Сообщить модератору
 Re: Алгоритм резервирования для нескольких складов  [new]
s_ustinov
Member

Откуда: Lugano, CH
Сообщений: 1384
_bob
s_ustinov

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


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



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

_bob
ну и следующий вопрос: чем навик удобнее для написания логики на SQL по сравнению с 1С?

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

Сделать быстрый асинхронный пересчет резервов в навике проще - можно ЛЕГКО писать с помощью SQL прямо в таблицы навика. А вот как сделать что то с аналогичным результатом в 1С (не с помощью SQL - писать сиквелом в таблички БД, в которых "хранятся" регистры 1С мне как-то совсем не хотелось) я в свое время придумать так и не успел (перешел на другую работу).
5 янв 17, 17:54    [20075400]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6   вперед  Ctrl      все
Все форумы / ERP и учетные системы Ответить