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

Пробовал делать по разному. влюбом случае считал два вида остатка: фактический (с учетом всех накладных и позиций и в т.ч. тех что в буфере) теоретический (без учета накладных и позиций буфера)
1 вар:
в шапке расходной накладной вводил признак F_BUFER показывающий что накладная в буфере и значит ее в теоретическом остатке не учитываем. При сохранении каждой накладной считал фактический остаток на текщую дату и если он выходил в минус хоть по одной позиции - всю накладную выкидвал в буфер. После сохранения каждой накладной считал фактический остатокпо каждому товару что есть в буферных накладных, когда все на всех буферных товарах появлась достаточный для списания остаток - списывал накладную из буфера.
недостатки: если внакладной на 50 озиций по одной из них не хватает кол-ва - вся накладная висела в буфере, в рез-тате теоретический остаток в большинстве времени не отражал соостояние склада, в фактическйи был в минусах - это было неуддобно
2 вар:
в позициях накладной , поле кол-во поделил на KOLVO и KOLVO_BUFER
при вводе позиций считал фактический остаток на текущю дату и если введенное колво создавало отрицательный остаток - то разбивал его на две части так чтобы теоретический остаток был всегд >= 0
при сохранении всех накладных, просчитывал опять остатки по товарам имеющим KOLVO_BUFER >0 и если остаток позволял , частями перекидывал кол-во из KOLVP_BUFER в KOLVO, этотоже тупиковый вариант, т.к. при этом накладная меняла свое состояние с течением времени а истории изменений у меня небыло. При разбооре полетов я почти повесился ...((

перед опробыванием третьего варинат решил спросить у публики, как корректно работать с заказами товара, как их оттуда списывать .

основные моменты:
- если в накладной на 50 позиций не хватает товара по одной из них - все позиции кроме той где нехватет остатка должны быть проведены по складу полностью,
- сумма накладной должна расчитываться сразу и на все выписываемое кол-во товра и не меняться с теченем времени и после списания буфера товаров
- хотца прозрачности в накладных ,для разбора полетов ,когда кому и сколько

просьба не стебаться, действительно прошу совета

sergey888В чем проблема?


проблема в том что:
1. нельзя допускать отрицательных остатков из-за косяков которые будут при расчете финансовой части:
5 штук остатка товара№1 * 10 руб его текущей цены + (-10 штук остатка товара№2 * 10 руб его цены) = - 50 руб , это получится стоимость склада на текущую дату (((

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

Сергей Васкецов фактических документах расхода сырья и материалов в производство ценам и суммам вообще нечего делать, если честно.

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

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

что-тоя не понял,
в накладной на изготоление говорится что со склада №1 на клиента Васю (это в шапке) отдаются такие то товары и ему считаются такие-то работы.
накладную посчитали, распечатали , подписали и менять ее больше мы не должны, как тут связать доп виртуальный склад и списание с него в момент прихода товара? добавьте плиз еще пару строчек пояснения

sqllexЗабудьте об отрицательных остатках вообще. Наличие минусов в учетной системе - это бред.

вот и хочется от них уйти не допускать

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

sergey888Добавить в таблицу остатков поле типа "выписано сверх остатка" и писать туда к-во, которого не хватило на складе при отгрузке.
Затем при поступлении товара вычесть к-во, взятое со склата "сверх остатка"

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

в накладной при этом мы ставим общее кол-во расхода или тольок то что допустимо для остатка >= 0 ? ставить частичное кол-во в накладную а частичное в отдельную таблицу нельзя т.е. по кол-ву в накладной считается сумма позиции (а с нее потом еще и скидки счтается) и сумма самой налкданой

далее: "..Затем при поступлении товара вычесть к-во, взятое со склата "сверх остатка" ..."
т.е. сделали накладную на изготовление, записали в спец таблицу что нехватает 5 шт товара, затем оприходвали 3 штуки, списали из той таблицы недостающего товара 3 штутки ( списали т.е. уменьшили количество или ввели новую строку о списании?, если просто помнять значение - то теряется история, и потом как откатывать если удаляется(меняется) накладная прихода по которой списывается то недостающее кол-во ?

сколькоя думал, у меня получается продумать последовательность действия вперед, т.е. выписали расход -> учли буфер -> ввели приход -> списали буфер
НО косяки начинаются когда надо изменить (удалить) приходную накладную когда уже списан буфер, или когда надо изменить (удалить) расходну накладную, когда уже введен приход и списан буфер

(((

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

sqllex Вариант 1 ...

у нас в системе (она конечно не мега система, но ...) нет счетов фактуры,
дизайнер рисует проект, затем садится за комп и вводит накладную, указывает кол-во, подтягиваются цены прайса на тот момент. эта накладная выполняет роль документа расчета цены заказа + она же попадает на склад для получания товара на изготовления + она же потом учитыватеся в графиках установок и + в расчете з\п,+ в анализе продаж + в расчете заказов на поставку и т.д. ... ну это лирика

т.е. вариант с тем что счет делает одно действие по учетов (полного кол-ва) а накладная - другое (учет остатков >=0) мне не подойдет

надо за один раз указать в документе что выдать в производство к пример 5 шт товара при наличии 3-х... а 2 недостоящие штуки я должен видеть в потребонстях вплоть до оформленя прихода на 2 или более штук того товора

вот момент где есть проблема:
создали накладную на 5 шт приналичии только 3-х, записали на вирт склад потребности 2 штуки
затем изменили другую расходную накладную в сторону уменьшения кол-во того товара что в потребностях висит.. теперь остаток на складе стал равен 2, но ведь и в потребностях висит 2 штуки ? как учесть, что появившиеся 2 штуки компенсируют 2 штуки в потребностях ? каким документом?

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

sergey888
Если хотите чтобы было такое историрование, то вместо поля остатка введите 2 поля
1.Дебет - получение товара
2.Кредит - расход товара.

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

так гораздо удобнее считать остатки (sum(колво * цена * знак операции (+1 или -1)) и показывать движение (имха конечно же)


sergey888
Остаток товара рассчитывайте на определенную дату или на конец рабочего дня например и складывайте в таблицу истории остатков на складе.

таким образом убиваете 3 зайцев
1.Расход не связан с остатком
2.Остается возможность отката. При откате операции удаляете/редактируете запись либо добавляете еще одну запись по принципу Сторно.
3.Ведение истории остатка товаров.

О как придумал.

и при таком подходе скокак надо перелопачивать данных при изменении накладной на 2 недельной давности, при десятках накладных в течение дня ?

и что нам даст сохранение в отдельной накладной остатков на каждый день, кроме разбухания базы, инеобходимости при каждом сохранени накладной из прощлых периодов пересчитывать кучу остатков ??

"..Расход не связан с остатком.." - тоже как-то не понял ? как это не связан? на основани расходе же считается остаток ? (ну и еще приходов , возвратов, дефектов,списаний, инвентаризаций и т.д.)

sergey888неверный подход в том, что меняется выписанная и проведенная накладная.

Выходы
1.Не списывать товар со склада до тех пор, пока накладная не будет полностью оформлена.

что считать полностью оформленной накладной?
- вводим накладную 1
- вводим накладную 2 , при вводе накладной 2 мы ж должны учесть уменьшение остатка товара сделанное накладной 1? как же тогда не вести остатки online? ведь тогда глядя что с утра было 10 штук товара№1 можно его навыписывать кучу и увидеть красные остатки только вечером ? или что-то не понял ?

sergey888
2.Запретить редактирование накладных, а товар списывать другой корректирующей накладной.

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

да и в любой момент при разборе полетов может выяснится что ввели ошибочнео числов накладную.. ее нао корректировать все равно

работаем уже почти 7 лет в этом всем и не удается уйти от изменения накладных за неделю назад как минимум

Сергей Васкецов
Опять же задумайтесь над цепочкой документов . Накладные (1-ю и 2-ю) проще вводить не вручную, а генерить из некоего документа ... с сохранением связи между документами (отмечу, что в данном случае необходима "построчная" связь, а не между заголовками).

допустим:
имеем ЛЗК, это как я понимаю перечень необходимых материлов для выполнения заказа, + доп работы, в ней мы можем уже посчитать суму заказа (транпортные услуги при отгрузке мы не учитываем, поэтом затрат по заказу после отгрузки заказ мы не имеем, ну кроме дефектных накладных которые легко учитываются)

введенные позиции в ЛЗК не изменяют остатка на складе а служат лиш набором позиций для заказа, затем жмем кнопку "провести заказ", формруем автоматом накладные для списания доступного кол-во со склада, недоступное кол-во остается несписанным, висит в заказе, так?

ждем прихода, вводим его, после его сохранения автоматом запускаем допроведение всех заказов с датой До даты прихода, что можем списываем, что не можем - оставляем на потом, так?

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