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

Philip писал(а): ↑23 ноя 2021, 14:51 А нужно получить остаток на складе, сумму с средней ценой с учетом списания, т.е. не учитывать в средней цене себестоимости количество списанного в приходе, по среднему списанию еще как-то можно реализовать но по методу фифо, т.е. не учитывать в расчете средней цены себестоимости первые по поступлению, т.е. уже списанные.

тогда к товару можно добавить поле список (в наличии , списан (скрыть это поле из формы чтобы не мешало) после продажи статус товара меняется на списан. и пользоваться этим статусом при расчете.

Думал такой вариант со статусом, но товар может быть в накладной 2шт. или в 100кг., а списаться 1 шт. или 50кг. например, даже и не знаю как реализовать, пока думаю над решением.

Тут не все так просто, как оказалось) Скорее всего нужно делать поле для средней стоимости товара по медтоду ФИФО. Т.е. чтобы в момент прихода/рсхода в это поле помещалась рассчитанная стоимость и фиксировалась там. Это должно быть не динамическое поле, а числовое скорее всего. Т.к. все расчеты по приходу - расходу будут непрерывно расти (а это напрямую влияет на последнюю цену ФИФО), в какой-то момент система "устанет" высчитывать все возможные итерации приход-расход для вывода текущей цены по ФИФО. Т,е. по логике системе нужно постоянно высчитывать цену исходя из всех-всех приходов и расходов, как-то "минусовать" списанные из "приходованных" остатков цены, а потом с учетом новой средней цены рассчитывать уже новую с учетом текущих остатков (приходов-списаний). Это если я правильно понял.

Нужно подробно расписать варианты прихода, расхода с текущими ценами и периодами. Как система должна записать среднюю цену на момент прихода, списания. Потом как должна быть записана средняя цена по новому приходу... В общем тут без "промежуточных" сущностей наверное не обойтись, чтобы не нагородить супер-запрос. Хотя я может что-то не так понимаю.

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

Получается учет остатков работает, а вот сумма остатков и средние цены, со временем будут непонятно какие.

Philip писал(а): ↑23 ноя 2021, 16:55 Получается учет остатков работает, а вот сумма остатков и средние цены, со временем будут непонятно какие.

Тема для меня тоже актуальная, штурмую её уже долго...
Причём у меня учёт склада готовой продукции ведётся и ещё склад материалов.
И необходимость FIFO я тоже ощутил.
У меня количество считается, а стоимость нет...

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

Philip писал(а): ↑25 ноя 2021, 16:34 Да, пока думаем над решением, тоже требуется видеть правильные суммы остатков на складах.
Пока решили сделать отдельную сущность "Учет складов" по структуре сущности как "товары в накладных", в которую будет происходить клонирование данных после сохранения товаров в накладных, а уже раз в день например менять пачкой статус списанные у первых поступивших например, то количество которое реально было списано, и считать средние цены уже исходя из этой таблицы, но это все в ручном режиме может и будет работать, пока других решений не вижу, пока пробуем реализовать, снова же возникает вопрос в случае редактирования товара в накладной или удаления, пока данное решение открыто...

Что-то мне подсказывает, что для метода FIFO должна быть отдельная сущность, на основании которой строятся данные для отчётов о состоянии остатков.
При этом, настроив связь с сущностью "Накладные", можно будет отказаться от использования под-сущности "Товары в накладной".
Потом, через автоматизацию, добавлять товары в накладную, чтобы связь с накладной автоматически устанавливалась и технические поля правильно заполнялись.

Да...
Куча мыслей, надо делать!