Контроль количества в складских операциях

← →
Tormoz (2005-02-17 12:46) [0]

Уважаемые Коллеги!

Вот такая тема:

Есть складская программа. Рассмотрим метод списания товара со склада по FIFO(принципиально даже не FIFO, а то что товар лежит на складе "докучи").

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

Чем определяются Допустимый диапазон списания по количеству?

Если это списание последнее по дате для данного товара,
то допустимый Максимум - это кол-во требуемого товара на складе( Весь приход "минус" Весь расход) .

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

Допустимый Минимум по кол-ву списываемого товара - это Сумма кол-ва всех возвратов по тек. строке текущего расходного документа.

Такой метод контроля укладывается в рамки реализации на SQL.
Что есть очень хорошо, и очень быстро даже для большого-пребольшого склада: отсутствует построчная обработка данных.
То есть запрашивая остатки по складу, сразу получаешь и контрольные диапазоны для каждой товарной позиции.

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

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

В результате(если не рассмматривать возможность возвратов Поставщику ), получилось что-то на подобие сберегательной книжки:
ПРИХОД/РАСХОД/ОСТАТОК, где в цикле от тек. приходной строки я контролирую, чтобы остаток не ушел в минус.
Когда он уйдет в минус, Бог его знает?
Да и случится ли это вообще?

Поделитесь опытом, мыслями, если кто воплощал более красивую реализацию, буду признателен!

← →
Polevi © (2005-02-17 13:23) [1]

не надо контролировать "кол-ва редактируемой позиции в приходном документе"
у документа 2 состояние - не проведен и проведен
контроль остатков необходимо делать в момент проаедения, делается одним IF EXIST(SELECT ...)
редактирование списаных документов запрещать

← →
msguns © (2005-02-17 13:52) [2]

>Polevi © (17.02.05 13:23) [1]

Совершенно справедливо ! Работает безотказно в обоих общепринятых системах учета: по товарам и по поставкам (партионный учет).

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

Есть другой метод, используемый в учете "по товару". Это хранение сальдовых остатков по товару. В этом случае забор остатка осуществляется по описанной в [1] схеме, однако отсутствует понятие "проводка зависимых документов". Т.е. перед редактирование документа, товар как бы "возвращается" на склад (для приходов - убирается), а после изменения - забирается (поступает). При откатах и правках документов и выписке новых активно используются текущие (для документов прошлых периодов - сальдовые соотв.месяца), блокирующие снятие кол-ва, превышающее наличия либо на тек.момент (док-ты тек.периода) либо на конец месяца (док.прошлых месяцев).

← →
Petr V. Abramov © (2005-02-17 14:29) [3]

> делается одним IF EXIST(SELECT ...)
Лихо!
Ведь IB/FB - версионник, то, что exists в контексте одной транзакции, в контексте другой может уже давно не exists

← →
Polevi © (2005-02-17 14:32) [4]

>Petr V. Abramov © (17.02.05 14:29) [3]
я работаю с MS SQL и с чего ты взял что у автора поста IB

← →
Polevi © (2005-02-17 14:37) [5]

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

← →
Petr V. Abramov © (2005-02-17 14:37) [6]

Polevi © (17.02.05 14:32) [4]
Вай.... (:
А с чего ты взял, что не IB/FB и не Oracle? :))))

← →
Polevi © (2005-02-17 14:40) [7]

>Petr V. Abramov © (17.02.05 14:37) [6]
молодец, блеснул знаниями, возьми с полки пирожок

← →
Petr V. Abramov © (2005-02-17 14:54) [8]

Сам жуй

← →
raidan © (2005-02-17 14:57) [9]

>Petr V. Abramov © (17.02.05 14:37) [6]
Вай, родной...
В Оракле - уровень изолированности можно поставить. Serialize там...
В IB тоже, вероятно, есть подобная штука.
Потому простой IF EXISTS...

← →
Petr V. Abramov © (2005-02-17 15:03) [10]

1.
> В Оракле - уровень изолированности можно поставить. Serialize там...
Не употребляй слов, значение которых знаешь не очень твердо
2.
> В IB тоже, вероятно, есть подобная штука.
Потому простой IF EXISTS...
См. п.1

← →
Sergey13 © (2005-02-17 15:09) [11]

Вот так выставлением нужного уровня изоляции и выбора блокировочника/версионника и решается любая проблема и не только в бухгалтерии. 8-)

← →
Tormoz (2005-02-17 15:29) [12]

To Polevi ©

Я, в принципе, согласен со всем сказанным: закрыть и все тут!

Но вот был у меня опыт работы на крупном складе с мерным товаром (ткани): товарооборот жутко интенсивный, по 3 фуры в день на разгрузку, покупателей море, порядка 100 - 120 документов на отгрузку за день. 4 менеджера и 12 грузчиков в "мыле", ошибки естественны. Физическая инвентаризация раз в месяц - дело обычное.
Только провел отгрузку, пока проверял с покупателем метраж по позициям, два других "орла" уже тоже посгружали этот товар на других "компах", нашел ошибку: вперед! исправлять! Под венец рабочего дня выясняется, что портьерной ткани А аж 9910м. по данным программы. Бред, принимали 1 км, отгрузили суммарно всего 90 м! Открываем приходный документ, смотрим: кол-во А = 10 км. Все ясно, менеджер на порядок ошибся (нормальная по своей природе такая ошибка, дактильного характера, по причине усталости + серьезная интенсивность работы). Тут отвлекли телефоном и «возвратчик» в дверях менеджерской бесится. Ткнул по клавишам, опять блин не ту цифирь (1м.) вогнал в редактируемый приход, и тут Прога вполне внятно излагает, что сия цифирь мала после произведенных списаний. И это при том, что времени хотя уже начало седьмого вечера, с прогой/базой идет приличная по нагрузке работа.
Корректировки такие, бывало, производили позже, по прошествии нескольких дней и меня всегда приятно удивляло время реакции программы на неправильные действия. Это при том, что по данной товарной позиции были уже другие приходы и куча расходов.

Вот так! Нам эта программуля жизнь облегчала очень сильно, правильный подход создавшие ее программисты применили: Складская программа – это помошник, защищающий пользователя от таких случайных ошибок, а не «записная книжка» с красивым интерфейсом. Контроль непротиворечивости данных, однако…

← →
msguns © (2005-02-17 17:19) [13]

>Tormoz (17.02.05 15:29) [12]
>Открываем приходный документ, смотрим: кол-во А = 10 км. Все ясно, менеджер на порядок ошибся (нормальная по своей природе такая ошибка, дактильного характера, по причине усталости + серьезная интенсивность работы).

В корне неверно поставлен интерфейс работы с документами. Приходы - это особенный документ. При его вводе необходимо наличие обязательных полей типа "Контрольная сумма", "Контрольный НДС", "Кол-во позиций" и т.д. Документ не может быть проведен, пока расчетные суммы по фактуре не совпадут с контрольными.
Правда есть "мыльные" конторы типа тех, что ты описал, работающие "с колес". Для них, конечно, можно стругануть систему "живых документо-строк", когда только что запостенная строка документа тут же "кладется" на остатки и ее можно выписывать в счета и даже накладные отгрузки. И это при незаконченной обработке прихода !
Однако, 100%, что к концу месяца (а иногда и недели) на складе лежит одно, а в базе - нечто совершенно другое. И вот тогда начинаются всякие инвентаризации, пересортицы и прочая хрень. Я уж не говорю о массовых недовольствах покупателей, которым привезли (отгрузили) не то, что они заказывали (покупали). Короче, народ пашет по выходным и ночам. И все нахваливают твою программу ;))

← →
Polevi © (2005-02-17 17:24) [14]

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

← →
msguns © (2005-02-17 17:34) [15]

>Polevi © (17.02.05 17:24) [14]
>к тому же если на основе документа уже зарегестрирована счет-фактура откатить чтолибо невозможно по бух. соображениям

Наверное, имеется в виду фактура не счета, а все-таки накладной отгрузки ? Все равно бухгалтерия не возражает по коррекции документов в поточном месяце (пока не сданы отчеты и не закрыт месяц). Бухгалтерии вообще по большому счету фиолетово, что именно лежит на складе, что именно отгрузили заказчикам (покупателям) и т.д. Ей важны суммы. Вот они-то должны итти до копейки. Причем как движение (накладные), так и остатки на складе с Гл.книгой. Короче оборотка и сальдо по 41 (68) и его субсчетам, если используются. Если есть розница, то несколько дополнительных типа торговый наценки.

← →
Polevi © (2005-02-17 17:43) [16]

>msguns © (17.02.05 17:34) [15]
все правильно, но при изменении документа в подавляющем большинстве случаев меняется его сумма

← →
Tormoz (2005-02-17 18:09) [17]

To Polevi ©

1. Вот уж чего я не пытаюсь, так это чего-либо доказать:)

>у тебя в системе возможны откаты ?

Я рассматриваю такую возможность из своего прошлого личного опыта работы на складе со складской программой. Необходимость - это другой вопрос.
Более того, я считаю, возможность откатов хоть на некоторый непродолжительный отрезок времени назад должна быть!!! Юзеры ошибаются! Все мы человеки!

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

Менеджмент, однако...Везет же некоторым! Дикий Запад какой-то! :)

Вот еще такой вопрос (Я не ёрничаю, мне это действительно интересно). В обрисованой Тобой системе Некто (Ответственный)
заводит (централизовано!) приход. Вот он ошибся на порядок в большую сторону и не заметил этого. "Откатить чтолибо невозможно по бух. соображениям". В бухгалтерии тоже не заметили (Корпоративная/поотдельная попойка). Пошли списания с этой позиции. Через нек. время смотрят, БА ! ОШИБКА.

ЧТО В ТВОЕМ СЛУЧАЕ ДЕЛАЕТСЯ ДАЛЬШЕ ? КАКОВ ВАШ СЦЕНАРИЙ ?

То есть Вы (уважаемые Polevi © и msguns ©) рекомендуете мне методику "Закрыл и Забыл"???

Ты читал про контрольные суммы ? А если читал, то что не понял ?
Система учета в любой торговой (и не только) организации должна быть такова:
Все материальные документы (приходы, отгрузки, возвраты, внутреннее перемещение, отпуск в розницу и т.д.) должны в обязательном порядке регистрироваться в спец.журнале учета накладных (обычно для каждого вида документов свой журнал). Причем ручками. В смысле шариковыми или перьевыми. За это отвечает главбух лично, а кому он там это поручит - его дело.
Так вот, когда делается запись в эти журналы, то тот, кто пишет, смотрит не в комп, а в бумагу, срисовывая в нее контрольные цифры (итоги). В случае с приходом в журнал будут записаны верные суммы.
Далее "бумага" вводится в комп (продолжаем рассматривать обработку именно приходов). В конце дня с компа дается выборка отчета "Поступления за день" и суммы по отчету сверяются с суммами, полученными на калькуляторе из журнала. Если возникает несоответствие, то ТУТ ЖЕ ищется и исправляется ошибка В КОМПЕ. Вылезет не только твой "порядок", а даже 1 (одна) копейка !
Далее. Когда юзер вводит приход, перед ним лежит бумага с указанными суммами, в т.ч. по каждой строке фактуры. Перед постом записи он ОБЯЗАН сверить ее с той, что на документе. Ну м в конце концов после правильного ввода всех строк фактуры сумма компьтерная должна совпасть с той, что в документе ДО КОПЕЙКИ !
Поверь, ошибиться так, чтоб суммы все-таки совпали, можно, но оооочень сложно.
Описанный тобой пожарный режим ввода приходов есть нонсенс и, если это соответствует истине, я не ошибусь, если предположу, что это "грязная" фирма, работающая либо с черным налом, либо в которой по-крупному воруют и бардак всем (кроме хозяев, ессно) выгоден. На приходах обычно сидит один или несколько специальных операторов, подчиняющихся либо товароведу, либо напрямую главбуху либо соотв.зам директора (Гл.менеджер). Саню со склада или Маню из торгового зала туда никто не допустит.
Поэтому, если такой ответственный чел "ошибся на порядок" и сам не нашел и быстренько не исправил свою ошибку и она "вылезла" у бухгалтера или кладовщика, то завтра его быстренько уберут на менее ответственный участок (мешки носить, если сильный парень, и кофе готорить, если симпатичная девушка, иначе - на фиг за порог).
То, что описал Polivi, не есть "Запад", это просто нормальная система учета, которая, кстати, была еще до революции и большевики нисколько ее не поломали. А бардак происходит не от того, в какой части света находится торговля, а совсем от другого.

ЗЫ. По поводу журналов, ведущихся "ручкой". Конечно, в фирмах, где учет поставлен, никто эти журналы ручками не пишет,- все дает программа. Однако оригиналы документов содержатся в подшивках. Либо по месяцу, либо по неделе или даже дню (зависит от объемов документооборота). Тем не менее сверка делается регулярно по нескольку раз в день. Это и понятно, лучше найти и исправить ошибку сразу, чем оставаться после работы. Я уж не говорю о том, что своевременное обнаружение и исправление ошибки сводит вероятность конфликтов с партнерами (поставщиками и особенно покупателями) к минимуму.

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

> менеджер на порядок ошибся
у нас было так:
менеджер (реально оператор) вводит документ. Склад при реальном поступлении (ведь не может быть так, что привезли/увезли что-то, про что не занет менеджер, это - криминал) подтверждает приход/отгрузку, посчитав и перенюхав. При вводе меняется планируемый остаток (к бухгалтерскому отношения не имеющий). При подтверждении складом - "реальный" (с которым работает бухгалтерия).
Конечно, остается вариант, когда на порядок ошиблись в большую сторону при вводе прихода, и этот планируемые товар уже навыписывали. Но тут уже виноватого искать не надо и ничего не плывет.

> бухгалетрия-счет-фактура
А не зря счет-фактура по закону выдается в течение 2-х недель после совершения сделки. Достаточный срок, чтоб сделку ввобще аннулировать в случае разгильдяйства

← →
Tormoz (2005-02-18 10:17) [20]

To Polevi © & msguns © Petr V. Abramov © ?

Народ, "плывем" по теме.

> Конечно, остается вариант, когда на порядок ошиблись в большую
> сторону при вводе прихода, и этот планируемые товар уже
> навыписывали.

Т а а а к, ошиблись в большую строну "и ничего не плывет"! Замечательно! Это как ?!

Не понимаю, ошибку в большую строну никто не будет исправлять/обозначать? Или чур ее, чур!!! Нехай на складе числится кол-во товара А большее реального!!!
Я не рассуждаю о том, какие фирмы как работают. И никого не куда не отправляю подтянуть знания! Я задал вопрос и не получил ответ:
ЧТО В ВАШЕМ СЛУЧАЕ ДЕЛАЕТСЯ ДАЛЬШЕ ? КАКОВ ВАШ СЦЕНАРИЙ ?

>Tormoz (18.02.05 10:17) [20]
>ЧТО В ВАШЕМ СЛУЧАЕ ДЕЛАЕТСЯ ДАЛЬШЕ ? КАКОВ ВАШ СЦЕНАРИЙ ?

Ты все же уперся в ситуацию, когда все же вместо 1 км ввели 10 и спрашиваешь, что будет делать наша система ?
А НИЧЕГО !
Я еще не видел программ (систем), которые имели бы глаза и руки и сами пересчитывали товар. Если менеждер ввел 10 км вместо 1 и:
а) не обратил внимания на сумму по строке в документе
б) не посмотрел на итоговую сумму документа
в) бухгалтерия прошлепала, что дневной приход в компе на порядок больше реального по первичке
г) операторы понавыписывали счетов и отгрузок на все эти 10км
д) кладовщик нажрался и уснул и не видел, что там грузчики погрузили вместо 9 км этой ткани
е) покупатели молча забрали вместо этой ткани какую-то другую
и т.д., то
ЧТО МОЖЕТ СДЕЛАТЬ ПРОГРАММА ?
И вообще, это уже не торговая фирма, а сказка "Алиса в стране чудес". Возможно, так работали на заре прихватизации, но сегодня месяц такой такого "хозяйствования" - и контора просто обанкротится. Или ее деятельность будет остановлена налоговой.

>Tormoz (18.02.05 10:17) [20]
менеджер по закупкам вводит приходную накладную в систему и ессно проверяет итоговую сумму с инвойсом
если он этого не делает его надо уволить

← →
Tormoz (2005-02-18 13:19) [23]

To Polevi ©

Ok!

Менеджера уволили: остаток по данным программы остался неправильный. Чего, он так и будет "висеть" на складе ?

>Tormoz (18.02.05 13:19) [23]
>Ok!
>Менеджера уволили: остаток по данным программы остался неправильный. Чего, он так и будет "висеть" на складе ?

Ну зачем же висеть ? Остаток правится :
1. Исправлением ошибки в документе и перепроводкой документа
2. Вводом и проводкой корректировочного документа (пересортица, коррекция остатков и т.д.)
3. Вводом сторновых документов (по схеме Polevi) либо коррекции и перепроводки старого документа с перепроводкой всех последующих(в случае партионного учета) в "тяжелых" случаях, т.е. когда ошибка выявилась через месяц и более. Но это уже ЧП и должны лететь головы. Как правило, кладовщика или менеджера склада.

← →
Tormoz (2005-02-18 17:05) [25]

To msguns © & Polevi ©

Слава Богу!

Все, разобрался. Я пречитал внимательно все Ваши сообщения и полностью согласен. Мне понравилось:

>для корректировок у меня существует специальный тип
>сторнирующих документов

Спасибо!

Контроль количества в складских операциях Найти похожие ветки