Архив форума

Процитировано сообщение: Рубанов Сергей от 08.04.2009 :: 19:25:03:

Кто такой "хрепень"? Почему у него нет смыслу?

Просто Аксапту надо уметь готовить! В последних версиях WMS намного лучше проработан, нежли в 3.0 и 2.5. А если повезёт с консультантами, которые имеют реальный опыт - то можно сделать конфэтко!

Запись на экскурсию:
1. Дмитрий Перов.
....

Ой, что-то забыл сообщить Склад находится в г. Дзержинском (несколько км. от МКАД). Переговорю с клиентом и назначу дату экскурсии

А что это за высокие требования, которые нельзя реализовать в ERP??

Процитировано сообщение: Ильина Евгения от 10.04.2009 :: 23:09:40:

 
Ну вот как раз бы и форум просветил на эту тему ( если б вспомнил конечно)))))
А если серьезно  - сроки годности, акцизы, справка А, Б; ТТН, уд. о качестве, серийный учет марок (специальные, региональные)...............вообщем много чего.

занимаю за Соломатиным, четвертым буду

1) Кто мешает транзакции исполнять в релальном времени? Сразу оговрюсь, что наше решение вообще не работает в режиме офф-лайн. Однако, некоторые WMS системы позволяют нащелкать на терминале заданий, а потом их "залить в стакан". Где тут реальное время???
Цитата:

Вы, возможно, действуете с точки зрения системы, с которой работаете. Возможно, если вы понимаете SQL, найдете отличия в производительности:
Это принцип блокировки, который вы описываете:
declare m cursor local for select ПОЛЕ from ТАБЛИЦА
open m
fetch next from m  
while @@FETCH_STATUS=0
begin
     -- КАКОЙ-ТО РАСЧЕТ
     fetch next from m  
end
Когда кто-то будет исполнять этот код, то действительно, все остальные курят бамбук.
Этот код исправляет данную проблему:
select ПОЛЕ into #temp from ТАБЛИЦА
declare m cursor local for select ПОЛЕ from #temp
fetch next from m  
while @@FETCH_STATUS=0
begin
     -- КАКОЙ-ТО РАСЧЕТ
     fetch next from m  
end
Никто никого не блокирует, все живут весело и дружно со своей копией массива данных.  
Если еще добавить возможность (в случае удаленных складов) репликацию по критерию, т.е. можно определить какие таблицы реплицировать (офису не нужны таблицы баланса по ячейкам, а складу не нужны таблицы аналитик продаж), то все будет работать, как часы.
Для терминалов мы используем Citrix, интерфейс системы можем править в он-лайне и достаточно компактно его отображать в окне терминала, поэтому с ТСД проблем не имеем, рисуем интерфейс для обычного компьютера и потом гоняем его на цитриксе, все копии программы выполняются на сервере.
Кстати, сервер, на котором работает склад не является наимощнейшим вычислительным центром, это 2-х процессорный ксеон с 4 ГБ (просто SQL Server любит кушать 2 Гб) памяти.

Цитата:

И почему каждый по отдельности считает всех остальных за идиотов?
Я лишь привел пример того, как можно в какой-то ситуации избавиться от блокировок. Вы налетели со словами, которые буквально означают следующее: "в моей системе такое не пройдет". Вы бы еще сказали "у-у-у-у-у, так вы select используете  ". В каждой системе методы достижения цели могут быть разными, и это нужно учитывать, прежде чем готовить шапки к полету.
P.S. Сервер не взлетит.

[Процитировано сообщение: Харламов Вадим от 13.04.2009 :: 12:31:43:

Разве мы о системах? Мне казалось, речь о MS SQL.

Движок системы может использовать SQL по разному. У одних движок хранит только таблицы, у других вся бизнес-логика выполняется в хран. процедурах и триггерах.

Вообще сама MS не советует использовать курсоры...
 
Так о чем вообще речь?
 
Если о том, что вы создали WMS, то я вам верю.
 
Изначально разговор был о том, что обычные ERP системы не подходят для построения на их базе WMS. Если взять платформу и создать новое решение - можно, если дописать к существующему не меняя архитектуры - проблематично.
 
Как происходит обработка заказа в ERP? Примерно так: система начинает транзакцию, делает один запрос с вхождением товара в список товара из табличной части, получает большую выборку и начинает с ней работать. Как все обработано - данные записываются и транзакция фиксируется. В итоге какое-то время (от пары секунд до минут) запасы по товарам из табличной части заблокированы.
 
Для WMS такой подход применять нельзя - нужно всю обработку делить на минимальные кванты, так чтобы транзакции занимали минимальное количество времени позволяя параллельно выполнять задачи комплектовщиками на ТСД.

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

Процитировано сообщение: Соломатин Владимир от 14.04.2009 :: 13:42:25:

 
Согласен, что просто "быстрее" - не результат, "велосипед" должен отвечать дисциплине, в которой он участвует. На шоссейнике не поедишь даунхил, хотя по трассе он быстрее...
 
Так и WMS строит определенные требования по быстродействию, параллельной работе, функционалу и гибкости настройки.
И эти требования не всегда как "Лучше и быстрее". Например, для WMS гораздо выгодней заказ проводить построчно и на каждую из 100 строк затратить по секунде имея возможность в перервые проводить другие операции, когда для КИС лучше провести все строки разом за 50 секунд.

Могу привести еще один пример. Как-то раз работал с системой БЭСТ-Про 4, она была клиент-серверной, но хранились данные в формате b-trieve, кроме стандартных отчетов, получить что-либо было сложно, тормоза после года эксплуатации чистой БД увеличивались в несколько раз, поэтому приходилось архивировать все и начинать БД с нуля каждый год. Пленирование и оперативный производственный учет хромали, а код системы был закрыт для переделок. Пытался даже писать модуль по выгрузке данных, их планировани и загрузки обратно в БЭСТ (как это делается в отдельных системах). В результате убедил руководство о необходимости смены системы и было всем счастье!
Так если опираться на мой опыт с БЭСТ Про и применять его ко всем системам (как это делаете Вы), то можно сказать, что MRP II системы вообще не  годятся для планирования производства, в основном из-за их форматов данных и закрытого кода.