2 Тяп-ляп
Если не секрет, Ваша система работает сама по себе, или тянет данные из управленческой?
2 SpiritWalker
У нас есть габариты всех объектов (товаров и мест хранения), по которым считается объем в литрах. У объемов есть коэффициенты на "утряску". Соотношения упаковка - ячейка возможны лишь при небольшом определенном количестве тех и других.
Сложность перемещения зависит от того, хочешь ли ты корректировать физические ошибки количества.
У нас есть объект похожий на проводку, МХ1-МХ2-Товар-Количество
Который хранит плановое количество и фактическое.
Упаковки товаров и товары, если они характеризуются штрих кодами, то должны быть связаны и иметь механизм проверки шк (битый, новый).
Во всех этих моментах основные данные нужно искать в предметной области. Если начнешь раздувать логическую схему - она будет очень трудно затачиваться под конкретные условия. Мне кажется бессмысленно спрашивать о мелких деталях. Вот в общих вопросах - это да, любопытно. Например должны ли ячейки планироваться по объему, или хватит регистрации размещенного товара, делать ли свои документы прихода или воспользоваться бухгалтерскими, должна ли информация попадающая в СУС быть достоверной или есть возможность корректировать неправильный ввод данных на месте. Это да, это можно было бы пообсуждать.

2 Тяп-ляп
Бухгалтерия тоже работает в вашей системе? И приходные проставшика вбиваются одновременно и для бухов и для склада?
2 YBW
Хе-хе, дельта то да. Однако сделать регистрацию, когда пользователь берет товар, размещает на стеллажах, сканирует штрих код стеллажа проще, чем измерить _весь_ входящий товар, все ячейки на стеллажах, написать оптимизатор кототорый будет планировать и корректировку остатков в случае пересорта (если в ячейке лежит другой товар не учтенный системой). Поэтому если сроки горят, то проще сделать регистрацию, запустить, показать заказчику а потом доделать планирование. :-)

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

YBW
сроки горят всегда...

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

YBW
экстремальный случаи, когла проще сделать как проще, а не как надо, стараюсь не рассматривать (по возможности, конечно)


Что там говорил Воланд про планирование человеком? Если как надо - это сложнее, то чаще всего сделать как проще. Журавль, синица и все такое.

YBW
экстермальные ситуации в качестве аргумента в дискусии стараюсь не рассматривать (по возможности, конечно)

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

YBW
ИМХО Вы подобные возможности упустили

Хе-хе. Все что ни делается - к лучшему. Все что я не рассматриваю в дисскуссии я делаю сам или пользуюсь поиском. :-)