CRM Руководитель - Форум

Добрый день. Ведь все хотят устанавливать CRM-руководитель за минуту? Разработчику направляем предложение создать образ в Докере. Всех, кто поддерживает, отпишитесь под сообщением. Вот кто-то старался https://github.com/filipmilasinovic/RukovoditelInDocker https://github.com/mchojrin/rukovoditel

Докер, это что-то на подобии композера для автоматической установки скрипта и определенного окружения (php нужной версии, mysql).

Сразу вопросы технического характера.

• Будет ли использоваться паттерн MVC?
• Человеческий роутинг?
• Наличие нормального построителя запросов/PDO/маппера. Хоть чего нибудь.
• Шаблонизатор? Шаблонизатор для формул?
• Полноценные события?

Fait писал(а): ↑08 май 2024, 17:45 Ревизия - процедура пересчёта товара, а также иногда и переопределение их стоимости.

Стандартная реализация. Учет минус Фактическое. Результат в базу.

Fait писал(а): ↑08 май 2024, 17:33 Не так просто, как кажется.
Попробуйте его реализовать, и сами увидите)

А что подразумевается под словом ревизия?

Fait писал(а): ↑08 май 2024, 17:25 Да, конечно же, так и есть.
Но, этот способ исключает возможность использования ревизий, а это очень важный функционал.

Ревизий? А что им может помешать? Новый столбец для нового типа движения. И все.

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

Fait писал(а): ↑08 май 2024, 16:46 Я не совсем понимаю, о чём речь...
Но у меня точно не так сделано.
В складском учёте в моём варианте участвует 5 сущностей.

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

Fait писал(а): ↑07 май 2024, 23:26 У меня есть складской учёт, проверенный на нескольких системах.
Я до идеального рабочего варианта шёл довольно долго, примерно 2 года.
А до этого всё костыли да костыли были

Используете единую плоскую таблицу для транзакций, где каждый столбец это тип движения товара?

Зачем что-то усложнять, если нужен всего лишь составной индекс на entities_id и items_id
Точнее даже items_id и entities_id (потому-что чего меньше, тот и первый в индексе)