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

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

1.Реальный масштаб времени обеспечивается оптимизацией на нескольких уровнях:
- способ хранения итоговой информации в базе даных (“суммирование от конца”, помесячные итоговый обороты, конечные остатки и т.д.)
- иеирархическая навигация клиента по базе данный (на подобие “NORTON COMMANDER”)
- обсчет документов непосредственно после их сохранения
- вычисление зависимостей при проведении документов “задним числом”
- расположение всей бизнес-логики на уровне сохраненных процедур SQL (Firebird) c ручной оптимизацией запросов (SET PLAN) и подбора структуры индексов
- размерность хранения аналитической информации в базе данных строго ограничена потребностями реализации предметной области.
- Тестирование производительности (на реальных данных, т.е. с достаточной энтропией и репрезентативностью) проводится на P133 МHz c IDE и 80 Мb RAM.
на такой машине работоспособно (с проведением задним числом и посчетом итогов, но правда с одним клиентом):
80'000 записей документов
200'000 записей проводок
100'000 записей оборотов
50'000 записей остатков
15'000 записей товаров
1'200 записей покупателей


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

3. Использование универсальной бухгалтерской модели позволило предварительно определить в системе так же универсальные отчеты, такие как прогнозный баланс, баланс(balans sheet), отчет о прибылях и убытках (profit & loss), отчет о движении денежных средств (cash float), отчет о дебиторах и отчет о кредиторах по срокам задолженности и заранее их оптимизировать

Полное описание, стоимость и демо-версия доступны на нашем ресурсе www.notematrix.ru

С уважением, Учетные системы ltd.

Уважаемый Влад, мы благодарим Вас за внимание, проявленное к нашему продукту и возможность изложить наши соображения.
VladSh Тестирование производительности (на реальных данных, т.е. с достаточной энтропией и репрезентативностью) проводится на P133 МHz c IDE и 80 Мb RAM.
Это прикол?

Нет. Время выполнения запроса в статистике SQL округляется до 0.0001 сек, и на более быстрых машинах не видно результатов оптимизации отдельных процедур. Конечно, реальная работа на таком компьютере с такой базой удовольствия не доставит, однако мы ведем оптимизацию до тех пор, пока реальная база данных не будет работоспособна на такой машине в целях разработки и тестирования. Мы руководствуемся тем, что 7 лет назад бизнес не был мельче, и существующие тогда компьютеры справлялись. Это один из методов менеджмента качества, используемых нами для реализации реального масштаба времени в системе.
VladSh
Очень смущает дешевизна решения от Учетные системы ltd.

Низкая стоимость наших решений (в случае абонементной формы оплаты) обусловлена их высокой предварительной готовностью, и низкой себестоимостью сопровождения. Фактически наш продукт является тиражируемым. Доработки для одного клиента выполняются таким образом, чтобы будущие клиенты могли ими пользоваться, но уже в стандартной поставке.
VladSh
Откуда взялась цифра 90% готовности?
Обследование клиента уже проведено?

Мы имеем представление о процессах на крупной плодово-овощной базе: четыре цеха, ж/д ветка, два внутренних и два наружных дебаркадера, участки фасовки и затаривания, поддоны и контейнеры, карщики рассыпающие поддоны, прокисание арбузов и биологическое горение репчатого лука в сетках, насколько десятков электрокаров (‘кара”) и несколько автокаров ( “вилы”, “лист”) и т.д. Таким образом приведенной информации нам достаточно для составления некоторого представления о задаче.

90% готовности получилось как 100% готовности минус 10% на непредвиденные обстоятельства.
VladSh
Так же на сайте www.notematrix.ru отсутствует информация о клиентах.

Мы не публикуем информацию о своих клиентах, иначе как по их желанию и в их интересах.

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

Сергей, позвольте прокомментировать.

VladSh
3) select sum(vidnum*kol) from t2 where id = :id and -- другие ограничения
into...


Такой оператор действительно может работать быстро (по крайней мере на Interbase/Firebird), но только в одном, частном случае: если квалифицированный в "where" набор строк достаточно мал (до 3 порядка) и выборка идет по индексу. (Например для выбора одного товара из таблицы прайс-листа, где товары не повторяются)

Firebird сначала по индексу возьмет в cash 100 записей с диска, и только за тем их сложит. Остальные 9 999 900 остануться лежать на диске, как будто-бы их не было вовсе (Правда, это заслуга разаработчиков Interbase/Firebird) . Однако, если "where" квалифицирует 10`000 записей (например для подсчета остатков по таблице с проводками) то замедление будет уже заметно, а на 100`000 квалифицированных записях замедление станет неприемлимым.

gardenmanА если остатки уже посчитаны на те даты, когда было движение товара?

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