Как правильно организовать складской учет в приложении Django?

Question

[WITT]

нужен совет как в приложении организовать логику приложения для учета склада (приход, продажи и т. д.)
С помощью DRF я сделал список товаров, документов и возможность добавлять приходные накладные но сейчас я в тупике
Что есть: Сейчас в БД есть таблицы с товарами(наименование, остаток, последняя приходная цена, розничная цена), товарами в документах (закупка, розница, товар(с привязкой к таблице "товары")документ(с привязкой к таблице "документы")) и сами документы
Проблема: Я не понимаю как мне сделать так, что-бы при создании документа с типом "приход" увеличивалось количество товара в таблице "товары" то есть остаток на складе, а когда документ "расход" то наоборот - уменьшалось, то же самое с розничной и закупочной ценой (чтобы в таблице "товар" данные всегда были актуальными)
Мои предположения:

1. Я думал сделать так что при создании или обновлении документов (то есть при каждом выполнении "POST" или "PATCH") данные из документов отправлялись бы в таблицу "товары", но это дополнительные запросы в БД, та и с "последней закупкой" могут быть проблемы
   
2. Или получить последнюю запись цены каждого товара из БД и относительно неё уже обновлять данные. А количество получать путём суммирования всех приходных документов, и вычитания всех расходных. Но к сожалению тут я вообще не понимаю как это сделать
   

Comments

[Dimonchik]

мда, ну и каша

[WITT]

Dr. Bacon, DRF только для взаимодействия с js (отображение и запись данных) например, чтобы при выборе поставщика или клиента сразу на странице показать и его баланс
Как такое сделать нативно на Джанго, увы я не знаю

[WITT]

Dr. Bacon, Что вы имеете ввиду под "Начни с разделения DRF и бизнес логики"?

[776166]

1) К DRF это отношения не имеет. Запрос к DRF должен изменить содержание БД, а уж что и как поменяется, не так важно и это не DRF. DRF нужен для удобства работы с API.
2) Если есть опасность сохранения консистентности данных, то можно использовать транзакции, они в Django есть.
3) По кошерному, POST создаёт ресурс, PATCH меняет его, а PUT меняет, если есть и создаёт, если нет (и нигде не сказано, что по дороге не может поменяться какой-то другой ресурс).

Судя по всему, у вас мало опыта, набирайте его, многие вопросы отпадут сами собой.

4) Запрос по DRF, как правильно написали выше, должен запускать условную функцию, которая сама всё сделает так, как нужно, без оглядки на число запросов в базу. Это и есть бизнес-логика.

Answer 1

[Dimonchik]

по п.2 тебе надо бухгалтерский взгляд: двойная запись т.н.
+ от программера - понятие транзакции ( там появится суть, Datetime, status)

и тогда те самые актуальные цифры будут результатом aggregate / annotate функций ORM
и никак иначе

по п.1 надо изучить отношения One-to-Many , many to many и вообще, чтобы изменения в модели Документы приводили к изменениям связанной модели Товары

Comments

[WITT]

Для получения остатка сделал (сума приходов) - (сума расходов) = остаток на складе. При таком варианте транзакции думаю не понадобятся, но стаёт вопрос.из производительностью, если к примеру будет 100 000 записей мне кажется это будет считать слишком долго и "дорого"
Как думаете?

[Dimonchik]

индексы, 100к справится сервер

а вот с (сума приходов) - (сума расходов) = остаток на складе могут быть сюрпризы, но в целом можно и так