Евгений Ромашкан, Например, нашли на складе неучтенный товар. Или в уходе - позвонили и сказали, что не дошло, при проверке оказалось, что вещь на складе. Ну, например, сегодня я сохранял операцию и нужно ее изменить - это ок. Вчера - тоже вроде может такое быть. Почему тогда не сделать, чтобы все операции можно было редактировать?
ThunderCat, для того, чтобы каждый раз не высчитывать количество из миллионов полей, а иметь оперативный доступ к нему. Или это не нужно? Тогда не нужно, тем более, и хранение истории наличия.
ThunderCat, когда я обновляю, например, приход, мне нужно вычислить для каждой позиции на сколько я изменил количество и обновить соответствующие позиции в истории наличия и актуальном наличии. Корректно ли для каждой позиции из массива делать запрос и формировать новый массив уже не с количеством пришедших единиц, а с количеством, на которое нужно изменить таблицы истории наличия и актуального наличия исходя из реального количества пришедших единиц и тем, что по ошибке уже введено в таблицу операций?
Я не представляю, как без хранения истории наличия высчитывать "было" и "стало", не обходя все записи таблицы операций с запуска проекта.
Все примерно так и есть. Проблема возникает в момент, когда операция уже сохранена, например: product_id = 1, count = 10, status = 1, а я её хочу обновить и отправить в таблицу: product_id = 1, count = 12, status = 1.
Для этого, как я понимаю, мне нужно определить разницу между count=10 (в БД) и count_new=12 (в массиве в скрипте). В таблице операций я просто обновляю count, но в таблице истории наличия и актуального наличия я должен добавить разницу count, которое было добавлено ранее, при сохранении операции (взять можно из таблицы операций по id текущей операции) и cunt, которое я добавляю в текущей операции (обновляю операцию).
В любом случае плагин его перезаписывает, не так ли? Почему значение плагина по умолчанию не отображается на странице, даже если я ввожу его вручную, а любое другое отображается?
Пардон, не уточнил. В таблицу движений только вставлять. Вставлять/удалять в таблицу остатков я имел в виду. Чтобы:
1. Не придумывать логику, по какой цене списывать товар, если есть разные цены или если списывается больше, чем есть по одной цене, но меньше, чем есть всего. Просто хранить в каждой строке в том числе и цену и удалять нужное количество строк в любом порядке, который можно в любое время легко поменять.
2. Не просчитывать количество товаров с одинаковыми ценами во время сохранения операций.
3. При формировании отчетов проще сортировать, суммировать позиции построчным обходом.
То есть допустимо убрать поле количество и хранить каждую единицу товара, даже одного размера и цвета в отдельной строке, так как цена может быть разной? В случае прихода 3-х единиц, например, вставлять 3 строки, а в случае расхода удалять?
Спасибо за отклик! По структуре понятно более или менее. Грубо, наличие может содержать 300 000 строк без группировки единиц товара по ценам (amount = 1 для каждой позиции) и, скажем, 10к - 30к строк, если сгруппировать позиции с одинаковыми ценами. Лог раз в месяц - это Х12. Операций, если хранить построчно каждую единицу или даже объединяя по одинаковой цене, будет тоже очень много. Внутри движения тоже может отказаться разная цена, поэтому я предполагал хранить каждую позицию отдельной строкой. Но объем данных в любом случае довольно большой. Это допустимо?
