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

Пробовал делать по разному. влюбом случае считал два вида остатка: фактический (с учетом всех накладных и позиций и в т.ч. тех что в буфере) теоретический (без учета накладных и позиций буфера)
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-ю) проще вводить не вручную, а генерить из некоего документа ... с сохранением связи между документами (отмечу, что в данном случае необходима "построчная" связь, а не между заголовками).

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

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

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

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

Сергей Васкецов
Не понял, Вы о дефектовках сырья и материала или готовой продукции?

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

Сергей Васкецов директор банально, но вежливо, посылается.

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


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

процессы в фирме отлажены в том виде в каком они есть, ломать их координально не будут, если б все было просто и подошла бы 1С - давно бы купили, а так как директор творческая личность, то и выдумываем как учесть все его хотелки

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

sergey888Пусть он это скажет налоговикам...

вы будете смеятся, но некоторое время назад он придумал такой регламент:
- база на HDD на салазках, в кабинете в дальнем углу офиса,
- ярлык на прогу на рабочих столах юзеров назвается типа "тетрикс" "калькулятор" и т.д.
- прога пускалась с шары в локалке
внимание:
в случае появление "госте" из налоговой, секретарша, сидевшая на ближайшем столе к входу, должна была подать знак директору (в дальней комнате) и минимум 1-2 минуты, личным обянием,красотой угрди и всеми другим способами удержать пришедших у себя, в это время диск вгорячую выдергивался в салазок и прятался ...
сколько было смеху при репетициях этого события, вы не поверите )))

правда часа иск так и не настало .. везет пока )))

как сделано счас, упрощенно:

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

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

имеем виды движения: приход, расход, списание буфера (упрощенно, в реальности их гораздо больше, разделяющих движение товара типу движения)

при появлении положительного остатка на текщую дату по товарам у которых колв-во в буфере > 0
создаем доп накладную списания буфера (со ссылками на основную расходную накладную и накладную вызвавшую появление положительного остатка, и со ссылкой на позицию основной расходной накладной по которой списываем буфер), кол-во в накладной списания буфера <= доступному положительному остатку и сумма позиций (по кол-ву) таких накладных списания буфера <= кол-ву в буфере в основной расходной накладной

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

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

счас перелопачиваю ее на firebird в связи с этим и хочется сделать буфер по правильному

iscrafmАвтору здесь недвусмысленно намекали на ЛЗК (или подобный документ, этап БД и т.п.)... Не все то, что считается (калькулируется) сразу должно быть списано со склада.

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

давай те еще раз расмотрим простую ситуацию и прошу коллег ответить кто и как ее решает в своих (полных или не полных) системах:

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

а на складе есть 3 ед товара

что вы сделаете ? вывалите сообщение что есть только 3 единицы и:
1. включите в накладную 3 ед
2. разобьете 5 ед на 3 ед(в накладную) и 2 ед (в закакз, по нашему мы называем это буфером)
3. вообще пошлете оператора нафиг решать орг вопросы?

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

про ЛЗК идея понятна, я ее думаю, но на вскидку - это приведет к тому что:надо сначала создать эту ЛЗК, потом ней делать документы списания со склада, делает этовсе 1 и тоже чел, он же потом сверяется с офисом и потому лишние документы = лишний этап в сверке = лишнее время = недовольстово начальства...

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

Сергей Васкецов[quot FinSoft]Представьте.... И ничего, работают так, что после начала производства рецепты корректировать нельзя, можно сделать новый...про сложность работы не надо мне рассказывать. Если навести порядок, то работать будет просто даже в Вашем несложном случае...

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

А когда фирма небольшая, оброт документов и товаров сравнительно не большой, оформлять кучу (без сомнения правильных) документов руководству не хотца, в этом и причина поиска облегченных путей учета, и поэтому не покупают 1С (она в нашем случае не даст той хитрости в учете которую хочет начальство и заставить делать опредленный набор правильных документов которые делать нехочется)

все имха ...

Сергей Васкецов
4. Однозначно документы склада (перемещение и/или расход) утверждаются только если есть на картотеке достаточное количество номенклатуры.
т.е. если в документе отпуска со склада 50 позиций и только одной не хватает в данный момент на складе - весь документ НЕ проводится, а тупо ждет появления нужного остатка на складе?, так?
думаю что для четкости учета, такое правильно , но это какраз один из моментов который не устраивает заказчика. Пока ВСЕ накладные на складе не проведены, нельзя получить фактические остатки на складе по которым например провести инвентаризацию, и значит из-за одной позиции винтиков могут не провестись накладных на изделия и остатки на складе сверять нельзя (у меня счас в системе есть только один вид остатков (по всем проведенным накладным), это одна из проблем.
согласно советам тут , я сделаю расчет остатков фактических (по всем проведенным накладным) и теоретических ( по всем требованиям на основании которых будут формироваться расходные накладные), тогда многие вопросы решатся


Сергей Васкецов
7. Если любой документ имеет хотя бы один дочерний документ, то разутвердить (и, соответственно, изменить) его нельзя, надо делать корректировку, корректировки не корректируются.

согласен