Комментарии 38
Совсем не очевидно, как правильнее. Если мы говорим о неоперативном вводе информации, то какой смысл блокировать документ? На нем подпись стоит? Стоит. Значит 2 кладовщика подтвердили, что эти ТМЦ (табуреты) были переданы. Почему это нельзя отразить в системе? Другой вопрос, что при возникновении такой ситуации нужно инициировать процедуру разбора полетов. Кому недогрузили табуреты? Кому руки оторвать?.. Ну или, на крайний случай, инвентаризацию замутить.
Статья из серии — зимой ABS увеличивает тормозной путь — нужно предохранитель вытащить и всю зиму ездить без ненужной системы. Контроль остатков при оперативном проведении работает максимально быстро использует специально подготовленную таблицу итогов. Волшебный «хак» системы предложенный вами приведет к снижению производительности системы, в итоге и получаем пользователей, которые кричат — 1С тормозит и глючит. В данном случае вопрос должен звучать так — почему вообще документы проводятся в неоперативном режиме и корректировать не программу, а бизнес-процесс компании, где поступление товара на склад происходит задним числом. Практика показывает, что запрет проведения задним числом в первое время раздражает, а затем воспринимается как само собой разумеющееся.
Всё ещё хуже, на мой взгляд. Проведение «задним числом» должно преследовать одну цель — исправление существующих данных в системе и приведение их в соответствие с реальными учётными данными. Надо ответить себе на вопрос — что происходит, если контроль остатков в неоперативном режиме покажет, что списание происходит «в минус»? Наиболее очевидный ответ — документ не будет проведён. Что мы получим в этом случае? А вот что — остаток, получаемый в оперативном режиме будет больше реального, то есть мы не исправляем проблему, а вместо неё получаем другую — товар, который должен был быть списан отмененным документом, может теперь быть списан другим документом, введённым оперативно, пока мы будем исправлять наш «неправильный» неоперативный документ. Очевидно, что чтобы этого избежать — нужно проводить неоперативное списание в любом случае, даже если оно происходит «в минус». А если так — то зачем вообще при неоперативном проведении контролировать остатки? Зачем исправлять кажущуюся проблему, чтобы взамен получить проблему реальную?
С МоментомВремени криво сделали. При оперативном проведении не стоит указывать Текущаядата(). В этом случае лучше оставить запрос как он был без МоментаВремени, тогда отрабатывать будет быстрее (остатки без даты извлекаются быстрее)
Гениально.
«отмечу лишь тот факт что контролировать остатки только в оперативном режиме мало подходит для реального документооборота. Зачастую документы вносятся по мере их поступления и как правило задним числом.»
Вот в 1С удивятся. Придумывали они придумывали механизм неоперативного проведения, а тут оказывается все напрасно.
Ну если автору не подходит современное решение УПП, то зачем его использовать. Есть отличная программа Комплексаная кофигурация на 7.7. Там именно такой режим проведения и был как того желает minchenko.
Итак, поясню то, что «забыл» написать в статье автор. При неоперативном, которое как правильно было замечено, отражает свершившийся факт, а это значит, что непроведение документа из-за осутствия товара на складе пользователя не устроит. То есть грубо говоря, задача пользователя просто ввести документ не задумываясь глубоко над его последствиями, ведь то что он вводит по факту уже свершившееся событие, оспаривать которое ни система ни он не может. Самое интересное должно происходить уже после такого проведения. В УПП существует механизм последовательностей документов, который будет сообщать нам, что некий документ нарушил последовательность и ее нужно восстановить. И вот здесь уже специально обученный человек должен заниматься выявлением пересортицы, исправлением ее, раздачей пряников и плеток. Замечу, что этим должен заниматься специально обученный человек, а не оператор, который хорошо умеет нажимать на кнопки и предполагается, что это происходит не в авральном режиме, когда нужно срочно ввести все данные. Идея же контролировать отрицательные остатки когда нужно срочно ввести большой объем документов кажется шуткой на уровне анекдота.
«отмечу лишь тот факт что контролировать остатки только в оперативном режиме мало подходит для реального документооборота. Зачастую документы вносятся по мере их поступления и как правило задним числом.»
Вот в 1С удивятся. Придумывали они придумывали механизм неоперативного проведения, а тут оказывается все напрасно.
Ну если автору не подходит современное решение УПП, то зачем его использовать. Есть отличная программа Комплексаная кофигурация на 7.7. Там именно такой режим проведения и был как того желает minchenko.
Итак, поясню то, что «забыл» написать в статье автор. При неоперативном, которое как правильно было замечено, отражает свершившийся факт, а это значит, что непроведение документа из-за осутствия товара на складе пользователя не устроит. То есть грубо говоря, задача пользователя просто ввести документ не задумываясь глубоко над его последствиями, ведь то что он вводит по факту уже свершившееся событие, оспаривать которое ни система ни он не может. Самое интересное должно происходить уже после такого проведения. В УПП существует механизм последовательностей документов, который будет сообщать нам, что некий документ нарушил последовательность и ее нужно восстановить. И вот здесь уже специально обученный человек должен заниматься выявлением пересортицы, исправлением ее, раздачей пряников и плеток. Замечу, что этим должен заниматься специально обученный человек, а не оператор, который хорошо умеет нажимать на кнопки и предполагается, что это происходит не в авральном режиме, когда нужно срочно ввести все данные. Идея же контролировать отрицательные остатки когда нужно срочно ввести большой объем документов кажется шуткой на уровне анекдота.
PS: все таки не РУАЗ(расширенных учет аналитики затрат)
а РАУЗ (расширенная аналитика учета затрат), поскольку учитываем мы в системе не аналитику, а затраты. А то получается автоматизация ради учета аналитики, автоматизация ради автоматизации. Переставили всего два слова местами, а смысл кардинально меняется.
а РАУЗ (расширенная аналитика учета затрат), поскольку учитываем мы в системе не аналитику, а затраты. А то получается автоматизация ради учета аналитики, автоматизация ради автоматизации. Переставили всего два слова местами, а смысл кардинально меняется.
сколько ж вас таких… не разберутся толком ни в методике, ни в сути, и давай курочить механизмы типовых.
Поставил минус.
Вы не разобрались в идеологии метода контроля.
Все документы должны вноситься в оперативном режиме, это так. Если на фирме работают люди, которые не обучены режимам проведения, то стоит переписать права доступа, заблокировав возможность неоперативного проведения у неквалифицированных пользователей.
Ваши изменения приводят к нарушению последовательности регистрации в регистрах накопления, т.к. записи проверяются на текущий момент, а вносятся от даты документа, т.е. задним числом. Вы не просто нарушаете последовательность документов (при неоперативном проведении граница последовательности всегда сдвигается вниз на дату документа, проведенного неоперативно), вы делаете невозможным исправлять ошибки, которые возникают при неоперативном проведении, типовыми документами.
Вы не разобрались в идеологии метода контроля.
Все документы должны вноситься в оперативном режиме, это так. Если на фирме работают люди, которые не обучены режимам проведения, то стоит переписать права доступа, заблокировав возможность неоперативного проведения у неквалифицированных пользователей.
Ваши изменения приводят к нарушению последовательности регистрации в регистрах накопления, т.к. записи проверяются на текущий момент, а вносятся от даты документа, т.е. задним числом. Вы не просто нарушаете последовательность документов (при неоперативном проведении граница последовательности всегда сдвигается вниз на дату документа, проведенного неоперативно), вы делаете невозможным исправлять ошибки, которые возникают при неоперативном проведении, типовыми документами.
Ваша фамилия, случайно, не Осипов?.. «усовершенствование» как раз в его «гениальном» стиле.
Кстати, ещё штришок относительно последствий Вашего «усовершенствования».
Анализ остатка на хронологический момент документа (с запретом проведения если не хватит — или даже просто с помещением такого документа и его автора в категорию «подозрительных») — источник «номенклатурных войн продажников». Ибо позволяет «задвинув» свой документ перед расходующим то же самое — «перехватить» продажу заканчивающихся товаров. Тот самый хрестоматийный случай «лишней информации».
Кстати, ещё штришок относительно последствий Вашего «усовершенствования».
Анализ остатка на хронологический момент документа (с запретом проведения если не хватит — или даже просто с помещением такого документа и его автора в категорию «подозрительных») — источник «номенклатурных войн продажников». Ибо позволяет «задвинув» свой документ перед расходующим то же самое — «перехватить» продажу заканчивающихся товаров. Тот самый хрестоматийный случай «лишней информации».
если кому-то интересно, то вот развитие темы на мисте www.forum.mista.ru/topic.php?id=658828, в частности, с пояснениями, почему то, что предлагает автор, плохо
Я так и не понял из той ветки почему это плохо. Быстродействие несколько пострадает, но в остальном хуже от этого не будет. Если какой-то документ в прошлом ругается, то это уже звоночек — либо какой-то документ поступления изменился (серия, номенклатура, количество изменены неправильно), без изменения последующих реализаций, либо неправильно вписали количество также задним числом в другой реализации, либо проведение каких-либо документов отменено. И разбираться лучше не дожидаясь инвентаризации, чтобы не бегать потом с горящими глазами «аааа, кошмар, у нас ничего не сходится, у нас ничего не работает!!111!». Методики, разработанные 1С это хорошо, но истинной в последней инстанции являться не могут.
а давайте Вы сами попробуете сравнить:
1) оперативный ввод документа, расходующего товары, будет служить основанием для отгрузки со склада;
2) неоперативный ввод документов «задним числом» — вводится по результатам фактически выполненной отгрузки товаров со склада.
Разницу, касающуюся необходимсти контроля остатков — заметили?
Двлее. По п.2 возможны разночтения — для того, чтобы не допустить элементарных ошибок (пересорта, например) в исполнении оператора, возможно, и следует выполнять контроль остатков. НО. Это — уже другой пункт регламента, другая операция (в отличие от оперативного ввода), совмещение которой с проведением документа (при том, что это может привести к существенному замедлению основного потока ввода документов) — вряд ли разумно.
Особенно если учесть тот факт, что контроль при проведении «задним числом» должен быть несколько иным, нежели автор нарисовал, НЕ «калькой» с контроля при оперативном проведении. Контроль при неоперативном проведении должен контролировать остатки не только на хронологическую позицию проводимого документа, но и на хронологические моменты всех(!!!) «следующих» доккументов. Что ещё более замедлит работу.
как-то так.
1) оперативный ввод документа, расходующего товары, будет служить основанием для отгрузки со склада;
2) неоперативный ввод документов «задним числом» — вводится по результатам фактически выполненной отгрузки товаров со склада.
Разницу, касающуюся необходимсти контроля остатков — заметили?
Двлее. По п.2 возможны разночтения — для того, чтобы не допустить элементарных ошибок (пересорта, например) в исполнении оператора, возможно, и следует выполнять контроль остатков. НО. Это — уже другой пункт регламента, другая операция (в отличие от оперативного ввода), совмещение которой с проведением документа (при том, что это может привести к существенному замедлению основного потока ввода документов) — вряд ли разумно.
Особенно если учесть тот факт, что контроль при проведении «задним числом» должен быть несколько иным, нежели автор нарисовал, НЕ «калькой» с контроля при оперативном проведении. Контроль при неоперативном проведении должен контролировать остатки не только на хронологическую позицию проводимого документа, но и на хронологические моменты всех(!!!) «следующих» доккументов. Что ещё более замедлит работу.
как-то так.
Разницу между оперативным вводом и неоперативным я знаю. Однако из вашего комментария я не понял почему при вводе документов остатки нужно контролировать, а при исправлении нет. Работу замедлит, но если сервер берется с запасом, то не так уж значительно, т.к. при проведении в любом случае производятся множество других не менее ресурсоемких запросов к базе (списание партий при партионном учете, движение по регистрам УСН, взаиморасчетам и т.д.).
На хронологические моменты всех следующих документов проверять в момент проведения не вижу смысла, достаточно, чтобы оператор понимал, что такая ошибка служит сигналом для восстановления последовательности документов. Но последовательность нужно будет восстанавливать и без контроля остатков.
На хронологические моменты всех следующих документов проверять в момент проведения не вижу смысла, достаточно, чтобы оператор понимал, что такая ошибка служит сигналом для восстановления последовательности документов. Но последовательность нужно будет восстанавливать и без контроля остатков.
мнда… ну не поняли и не поняли, не трагедия.
можете также не понять следующие факты, также почерпнутые из практики
при указанном вами «не вижу смысла»: все-таки включенный контроль остатков в виде «кальки» с оперативного — на практике очень часто выливается в «номенклатурные войны» менеджеров — в случае непроведения по причине нехватки остатка менеджер спокойно «задвигает» свой документ перед уже проведенным документом, расходующим «дефицитную» номенклатурную позицию (ну, мотивация у продажников такая — так или иначе зависит от объемов продаж. такая бедулька))).
и следующий, в принципе довольно простой факт: отказ проведения документа в связи с нехваткой учетных остатков по одной из позиции — по сути ведёт к искажению актуальных остатков (точнее — к сохранению их неактуальности), причем логика оператора в таком случае проста и логична (в рамках его штатных обязанностей и мотивации) — «я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы».
и — «сервер с запасом» — это, простите, фантастика. не в том смысле, что такие сервера, а в том смысле, что такая 1с-ина.
но, повторюсь, можете спокойно и дальше «не понимать» — не трагедия ни полраза. обеспечите работой других одинэснитов — только и делов. )))
можете также не понять следующие факты, также почерпнутые из практики
при указанном вами «не вижу смысла»: все-таки включенный контроль остатков в виде «кальки» с оперативного — на практике очень часто выливается в «номенклатурные войны» менеджеров — в случае непроведения по причине нехватки остатка менеджер спокойно «задвигает» свой документ перед уже проведенным документом, расходующим «дефицитную» номенклатурную позицию (ну, мотивация у продажников такая — так или иначе зависит от объемов продаж. такая бедулька))).
и следующий, в принципе довольно простой факт: отказ проведения документа в связи с нехваткой учетных остатков по одной из позиции — по сути ведёт к искажению актуальных остатков (точнее — к сохранению их неактуальности), причем логика оператора в таком случае проста и логична (в рамках его штатных обязанностей и мотивации) — «я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы».
и — «сервер с запасом» — это, простите, фантастика. не в том смысле, что такие сервера, а в том смысле, что такая 1с-ина.
но, повторюсь, можете спокойно и дальше «не понимать» — не трагедия ни полраза. обеспечите работой других одинэснитов — только и делов. )))
>>все-таки включенный контроль остатков в виде «кальки» с оперативного — на практике очень часто выливается в «номенклатурные войны» менеджеров — в случае непроведения по причине нехватки остатка менеджер спокойно «задвигает» свой документ перед уже проведенным документом, расходующим «дефицитную» номенклатурную позицию
Каким образом!? Если он проведет сегодняшнюю реализацию вчерашним днем, нарушая последовательность и нумерацию документов, то тут медицина бессильна, в этом случае отсутствие контроля остатков при неоперативном проведении вас никак не спасет, все равно.
>>«я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы»
Нет, это его проблема, а не программы. Если эта реализация по факту была, а по учету товар уходит в минус, значит какая-то другая реализация или поступление оформлены неверно и нужно поднимать и сверять документы, иначе потом все еще больше поплывет
Каким образом!? Если он проведет сегодняшнюю реализацию вчерашним днем, нарушая последовательность и нумерацию документов, то тут медицина бессильна, в этом случае отсутствие контроля остатков при неоперативном проведении вас никак не спасет, все равно.
>>«я ввожу то, что уже было отгружено фактически. а то, что ваша программа не дает это ввести — не моя проблема, а проблема программы»
Нет, это его проблема, а не программы. Если эта реализация по факту была, а по учету товар уходит в минус, значит какая-то другая реализация или поступление оформлены неверно и нужно поднимать и сверять документы, иначе потом все еще больше поплывет
Чо значит «каким образом»?.. если он (пи дефолтном оперативном режиме создания новых документов) может ввести информацию «задним числом» (откорректировать дату документа, например) — значит имеет возможность изменять позицию документа. нет, спасёт. при отдельном регламенте по-документного контроля остатков в случае выявления(регистрации) фактов корректировки документов «задним числом».
Да вот нихрена это не его проблема. Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором. Если ты этого не понимаешь — то мне остается только руками развести и свернуть диалог, уж извини.
Да вот нихрена это не его проблема. Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором. Если ты этого не понимаешь — то мне остается только руками развести и свернуть диалог, уж извини.
А по рукам бить не пробовали менеджеров, которые хотят 31 марта ввести реализацию товаров, с датой 30 марта? Во всех типовых конфигурациях пользователь имеет возможность ввести документ вчерашним днем, это почему-то никого не смущает. Разрешить добавлять документы только оперативно можно, но это создаст дополнительные проблемы и это совсем другая история А вот если при этом еще и остаток контролировать, то почему-то сразу караул нужно кричать.
>>Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором
Ну и пусть с другим оператором разбираются почему тот корректировки внес. Он же не изолированно в вакууме работает, может и поинтересоваться, не растает
>>Потому что он кристально честно вводит факт. а уход в минус происходит по причине корректировок, внесенных другим оператором
Ну и пусть с другим оператором разбираются почему тот корректировки внес. Он же не изолированно в вакууме работает, может и поинтересоваться, не растает
Бить по рукам — основания нужны. какая буква в «при отдельном регламенте по-документного контроля остатков в случае выявления(регистрации) фактов корректировки документов «задним числом».» тебе непонятна?..
О том, чтобы добавлять только оперативно — я и не заикался. по кругу бегать — тоже желания мало, на «почему-то» отвечено вполне по-русски выше.
«с другим оператором разбираются» — весьма вредно для процесса (точнее — для целевой функции), а также для морального климата — не говоря уж о том, что «другого» сначала найти надо, и «кто первый начал» — вопрос в подобных конфликтах слабо решаемый. а уж о том, чтобы вменять менеджеру-продажнику в обязанности «с другими операторами разбираться» — и говорить, простите, смешно.
О том, чтобы добавлять только оперативно — я и не заикался. по кругу бегать — тоже желания мало, на «почему-то» отвечено вполне по-русски выше.
«с другим оператором разбираются» — весьма вредно для процесса (точнее — для целевой функции), а также для морального климата — не говоря уж о том, что «другого» сначала найти надо, и «кто первый начал» — вопрос в подобных конфликтах слабо решаемый. а уж о том, чтобы вменять менеджеру-продажнику в обязанности «с другими операторами разбираться» — и говорить, простите, смешно.
>>Бить по рукам — основания нужны
Если устно не понимают, то можно внести в регламент запрет на создание документов реализации за вчерашний день (можно и программно закрыть к этому доступ). В качестве исключений оставить только форс-мажорные обстоятельства, которые я с ходу даже и придумать не могу. Реализации за сегодняшний день в любом случае проводятся оперативно и в них время просто так невозможно изменить, платформа всё равно выставит текущее время.
>>«с другим оператором разбираются» — весьма вредно для процесса
А если менеджер Вася отгрузит сегодня литр спирта со склада, который по факту есть, а потом пойдет выписывать накладную, а программа ему не даст это сделать, потому что по учету спирта не оказалось. Он к кому пойдет ругаться — к программисту, что у него программа неправильно работает или всё-таки к кладовщику или оператору лучше пойти и с ним поговорить?
Если устно не понимают, то можно внести в регламент запрет на создание документов реализации за вчерашний день (можно и программно закрыть к этому доступ). В качестве исключений оставить только форс-мажорные обстоятельства, которые я с ходу даже и придумать не могу. Реализации за сегодняшний день в любом случае проводятся оперативно и в них время просто так невозможно изменить, платформа всё равно выставит текущее время.
>>«с другим оператором разбираются» — весьма вредно для процесса
А если менеджер Вася отгрузит сегодня литр спирта со склада, который по факту есть, а потом пойдет выписывать накладную, а программа ему не даст это сделать, потому что по учету спирта не оказалось. Он к кому пойдет ругаться — к программисту, что у него программа неправильно работает или всё-таки к кладовщику или оператору лучше пойти и с ним поговорить?
Реализации за сегодняшний день в любом случае проводятся оперативно
Это не так. У пользователей с правом неоперативного проведения при проведении документа текущим числом, если он уже введен в систему (исправлении), выползет вопрос «Хотите провести документ неоперативно? Да, Нет», если нажать «Да», проведется неоперативно, если «Нет», исправит дату и проведется оперативно, при проведении за вчерашний день проведен сразу неоперативно. При проведении без права неоперативного проведения сегодня — документ изменит дату и проведется оперативно, за вчерашнее число без права неоперативного проведения не проведется вообще. Проверено УТ 10.3.
У моих все проблемы исчезли после того, как я заблокировал неоперативное проведение как таковое. После проведения документ доступен только для просмотра. Задним числом (как и будущим) вводить запрещено. Вводить задним числом и исправлять могут только ответственные менеджеры, которые исправят все остальные документы, в случае расхождения оперативных остатков. Для заказов покупателей есть документ корректировки заказа, для реализаций — корректировки реализации. Снятие установка резервов только документом установки резервов. Неудобно смотреть на множество введенных данных, начинаете путаться в том, что есть в заказе в что исключили? Не проблема — отдельное рабочее место с получением корректных данных из регистра заказы покупателей и кнопочками ввести исправление — создает заказ корректировки, создать новый — понятно что установить или снять резерв — так же понятно что, разные способы атозаполнения документов. плюс вспомогательные колоночки о том что есть на каком складе что когда можно привести и насколько текущий заказ готов к отгрузке.
Больше никаких проблем с нарушением последовательности не возникает (=
Больше никаких проблем с нарушением последовательности не возникает (=
>Разницу между оперативным вводом и неоперативным я знаю. Однако из вашего комментария я не понял почему при вводе документов >остатки нужно контролировать, а при исправлении нет.
Это говорит о том, что вы не понимаете разницу между оперативным вводом и неоперативным.
Исправление или ввод документа предыдущим периодом, это отражение в программе свершившегося факта. Что тут вообще контролировать? Вы отдали со склада 4 ящика товара, и какая разница что в тот момент было на остатках в программе, если вы их физически отдали? Если остаток товара в программе при этом не совпадает с реальным, то вы ССЗБ.
Это говорит о том, что вы не понимаете разницу между оперативным вводом и неоперативным.
Исправление или ввод документа предыдущим периодом, это отражение в программе свершившегося факта. Что тут вообще контролировать? Вы отдали со склада 4 ящика товара, и какая разница что в тот момент было на остатках в программе, если вы их физически отдали? Если остаток товара в программе при этом не совпадает с реальным, то вы ССЗБ.
Спасибо, эту мантру я уже читал, знаю наизусть. А говорил я о том, что если в 1С сделали программу по определенной методике и если она логична и понятна, то это еще не значит, что она идеально, лишена недостатков и подходит для всех организаций. Много лет работали и еще работают в семерке с контролем остатков на дату документа и ничего, все живы.
>>Вы отдали со склада 4 ящика товара, и какая разница что в тот момент было на остатках в программе, если вы их физически отдали?
А если не отдали или отдали, но не их, или отдали, но не 4 ящика или отдали, но не те 4 ящика, а другие с другой серией и сроком годности?
>>Если остаток товара в программе при этом не совпадает с реальным, то вы ССЗБ.
Я то да, буду ССЗБ, но кроме меня пострадают еще и менеджеры по продажам, которые скажут клиенту, что товара нет, хотя он будет на складе валяться. Пострадают еще менеджеры по закупке, которые кинутся докупать товар, который еще есть на складе. В бухгалтерии неправильно рассчитается себестоимость и налоги. А финансисты подадут руководству отчет с неправильными цифрами.
>>Вы отдали со склада 4 ящика товара, и какая разница что в тот момент было на остатках в программе, если вы их физически отдали?
А если не отдали или отдали, но не их, или отдали, но не 4 ящика или отдали, но не те 4 ящика, а другие с другой серией и сроком годности?
>>Если остаток товара в программе при этом не совпадает с реальным, то вы ССЗБ.
Я то да, буду ССЗБ, но кроме меня пострадают еще и менеджеры по продажам, которые скажут клиенту, что товара нет, хотя он будет на складе валяться. Пострадают еще менеджеры по закупке, которые кинутся докупать товар, который еще есть на складе. В бухгалтерии неправильно рассчитается себестоимость и налоги. А финансисты подадут руководству отчет с неправильными цифрами.
>это еще не значит, что она идеально, лишена недостатков и подходит для всех организаций
Вот только не надо тут передергивать. Никто не говорит что 1С идеальна и подходит для всех. Не для всех, но для подавляющего большинства.
>А если не отдали или отдали, но не их, или отдали, но не 4 ящика или отдали, но не те 4 ящика, а другие с другой серией и сроком годности?
А это тут при чем? Неоперативное проведение, это отражение свершившегося факта. При чем тут гадания кофейной гуще? Давайте тогда еще включим варианты «а если кладовщик запил и просто отдает коробки направо и на лево не глядя» или «Экспедитор тупо сжег весь товар в канаве и недовез его клиенту» или еще какой бред…
Если у вас сотрудники настолько тупые, что отдают товар не глядя ни на что, то ни 1С ни какая либо другая программа тут бессильна. Ибо даже если включить контроль остатков, то никто не гарантирует что со склада отдадут именно то, что проконтролировали. Поэтому и говорю, что ССЗБ. Басню про мартышку и очки помните? Вот та самая ситуация, идиотам ничего не поможет. У них любая прога будет плохой.
>Я то да, буду ССЗБ, но кроме меня пострадают еще и менеджеры по продажам, которые скажут клиенту, что товара нет, хотя он будет на складе валяться… и т.д.
Опять же при чем тут это? Как не оперативный контроль остатков в программе, может гарантировать, что необходимый товар на складе будет присутствовать физически и в нужном объеме? По программе, все будет четко, а при инвентаризации будете удивляться и говорить что и не оперативный контроль остатков полное говно и 1С вообще не помогает контролировать товар?
Вот только не надо тут передергивать. Никто не говорит что 1С идеальна и подходит для всех. Не для всех, но для подавляющего большинства.
>А если не отдали или отдали, но не их, или отдали, но не 4 ящика или отдали, но не те 4 ящика, а другие с другой серией и сроком годности?
А это тут при чем? Неоперативное проведение, это отражение свершившегося факта. При чем тут гадания кофейной гуще? Давайте тогда еще включим варианты «а если кладовщик запил и просто отдает коробки направо и на лево не глядя» или «Экспедитор тупо сжег весь товар в канаве и недовез его клиенту» или еще какой бред…
Если у вас сотрудники настолько тупые, что отдают товар не глядя ни на что, то ни 1С ни какая либо другая программа тут бессильна. Ибо даже если включить контроль остатков, то никто не гарантирует что со склада отдадут именно то, что проконтролировали. Поэтому и говорю, что ССЗБ. Басню про мартышку и очки помните? Вот та самая ситуация, идиотам ничего не поможет. У них любая прога будет плохой.
>Я то да, буду ССЗБ, но кроме меня пострадают еще и менеджеры по продажам, которые скажут клиенту, что товара нет, хотя он будет на складе валяться… и т.д.
Опять же при чем тут это? Как не оперативный контроль остатков в программе, может гарантировать, что необходимый товар на складе будет присутствовать физически и в нужном объеме? По программе, все будет четко, а при инвентаризации будете удивляться и говорить что и не оперативный контроль остатков полное говно и 1С вообще не помогает контролировать товар?
Гарантировать программа ничего не может, если в нее вбиваются неверные данные. Но программа может и помогать в контроле правильности ввода, если включен контроль остатков, а может не помогать, если выключен контроль остатков, а может еще и немного вредить, если неправильно вносить данные.
Конечно контроль остатков не решит всех проблем возникающих с отгрузкой, но будет служить индикатором того, что данные в программе не соответствуют действительности.
>>Если у вас сотрудники настолько тупые, что отдают товар не глядя ни на что, то ни 1С ни какая либо другая программа тут бессильна.
Речь не про то как отдают, а про то как заносят данные в программу. Ситуация, когда привезли товар одной серии, потом его продали, а потом оказалось, что ошиблись где-нибудь, например в серии не так уж редка.
Конечно контроль остатков не решит всех проблем возникающих с отгрузкой, но будет служить индикатором того, что данные в программе не соответствуют действительности.
>>Если у вас сотрудники настолько тупые, что отдают товар не глядя ни на что, то ни 1С ни какая либо другая программа тут бессильна.
Речь не про то как отдают, а про то как заносят данные в программу. Ситуация, когда привезли товар одной серии, потом его продали, а потом оказалось, что ошиблись где-нибудь, например в серии не так уж редка.
Вот вам простой пример, который встречается очень часто.
Оператор проводит документ от 12 числа, 25 числа, т.е. прошлым периодом.
Ваша очень умная программа, с проверкой остатков, не дает этого сделать, т.к. товара нет в программе на тот момент.
Оператор первым делом переводит документ на начало дня и проводит документ. Т.к. в обед 12-го числа был отгружен аналогичный товар, а переведя документ «чуть по раньше» оператор «решил свою проблему».
Идея понятна?
А таких ситуаций будет дофига, ибо если фирме потребовалась УПП, это уже подразумевает определенные, не мальнькие обороты. Отгрузки товаров идут каждый день, и в период с даты документа до текущего дня, как правило отгружается масса аналогичного товара. И таким образом легко получить необходимые остатки на дату документа.
И что в итоге? Оператор доволен, его документ провелся «с контролем», вы довольны, у вас супер-пупер программа контролирующая остатки. И только отделу контролирующему остатки геморой, т.к. проблема никуда не делась, вы просто ее «размазали» во времени. И перепроведение документов все равно не выполнится из-за отсутствия товара.
Это такой же мифический контроль, как и например гомеопатия. Люди верят и думают что оно действительно работает.
Тем более, что на первый взгляд оно и правда работает…
Оператор проводит документ от 12 числа, 25 числа, т.е. прошлым периодом.
Ваша очень умная программа, с проверкой остатков, не дает этого сделать, т.к. товара нет в программе на тот момент.
Оператор первым делом переводит документ на начало дня и проводит документ. Т.к. в обед 12-го числа был отгружен аналогичный товар, а переведя документ «чуть по раньше» оператор «решил свою проблему».
Идея понятна?
А таких ситуаций будет дофига, ибо если фирме потребовалась УПП, это уже подразумевает определенные, не мальнькие обороты. Отгрузки товаров идут каждый день, и в период с даты документа до текущего дня, как правило отгружается масса аналогичного товара. И таким образом легко получить необходимые остатки на дату документа.
И что в итоге? Оператор доволен, его документ провелся «с контролем», вы довольны, у вас супер-пупер программа контролирующая остатки. И только отделу контролирующему остатки геморой, т.к. проблема никуда не делась, вы просто ее «размазали» во времени. И перепроведение документов все равно не выполнится из-за отсутствия товара.
Это такой же мифический контроль, как и например гомеопатия. Люди верят и думают что оно действительно работает.
Тем более, что на первый взгляд оно и правда работает…
Похоже на идиосинкразию. Давайте ппробуем ещё раз, по слогам.
1) основной поток ввода — выписка и оперативное проведение документов, расходующих товары — безусловно необходим конроль отрицательных остатков при проведении, поскольку оформляемые документы являются основанием для выполнения отгрузки.
2) не(!)основной поток ввода — редактирование и ввод документов «задним числом» — по факту уже выполненной отгрузки товаров. ЕСЛИ контролировать остатки и запрещать проведение при недостаче на учетных остатках какой-то (одной) позиции — патологию ведь не рассматриваем, верно? — получится, что по всем остальным позициям остатки, на основании которых выполняется оперативный ввод данных (см.п.1) станут (останутся) неверными — что приведет к ещё большему практическому(!) ущербу, нежели ты так живенько описывал.
3) не(!)основной ввод данных — «задним числом» — является как-бы-мини-фор-мажором, и для проверки корректности внесенных изменений «задним числом» требуется не такой же контроль, как при оперативном вводе — подокументный контроль от текущего до последнего. причем по результатам такого контроля (и с целью приведения оперативных остатков в актуальное состояние) требуются немного совершенно не такие действия, как при оперативном (просто не проводить такие документы — не подходит, поскольку ошибка в актуальных остатках при тупо непроведенном таком документе — существенно больше, чем при проведенном даже в минус).
т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
и — ещё раз, по слогам: непроведение документов, которые вводятся или корректируются «задним числом» ведет к гораздо большей неактуальности оперативных остатков (используемых для контроля при оперативном вводе), нежели их безусловное проведение. точка.
1) основной поток ввода — выписка и оперативное проведение документов, расходующих товары — безусловно необходим конроль отрицательных остатков при проведении, поскольку оформляемые документы являются основанием для выполнения отгрузки.
2) не(!)основной поток ввода — редактирование и ввод документов «задним числом» — по факту уже выполненной отгрузки товаров. ЕСЛИ контролировать остатки и запрещать проведение при недостаче на учетных остатках какой-то (одной) позиции — патологию ведь не рассматриваем, верно? — получится, что по всем остальным позициям остатки, на основании которых выполняется оперативный ввод данных (см.п.1) станут (останутся) неверными — что приведет к ещё большему практическому(!) ущербу, нежели ты так живенько описывал.
3) не(!)основной ввод данных — «задним числом» — является как-бы-мини-фор-мажором, и для проверки корректности внесенных изменений «задним числом» требуется не такой же контроль, как при оперативном вводе — подокументный контроль от текущего до последнего. причем по результатам такого контроля (и с целью приведения оперативных остатков в актуальное состояние) требуются немного совершенно не такие действия, как при оперативном (просто не проводить такие документы — не подходит, поскольку ошибка в актуальных остатках при тупо непроведенном таком документе — существенно больше, чем при проведенном даже в минус).
т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
и — ещё раз, по слогам: непроведение документов, которые вводятся или корректируются «задним числом» ведет к гораздо большей неактуальности оперативных остатков (используемых для контроля при оперативном вводе), нежели их безусловное проведение. точка.
Опять какая-то чушь… ))
Как связаны реакции по типу аллергии, со складскими остатками?
1) Тут все логично.
2) Во первых, что такое «неосновной поток ввода»? Опять воду в ступе толчем? Какое это имеет отношение к остаткам?
ну и вообще, все утверждение чушь. Если в водимом документе 1 товар «уходит в минус», а остальные не уходят, то как ты можешь гарантировать, что остатки по этим товарам обязательно будут неверными? И где доказательства, что в в случае наличия этих гарантий, практический ущерб будет больше? Опять доморощенные теоретики?
3) КЭП в атаке )). Ты сам то понял о чем вообще говоришь, и чего доказываешь?
Я с самого начала говорил, что при не оперативном проведении контроль остатков не нужен, надо проводить документ как есть и потом уже разбираться по факту наличия проблем с остатками.
В итоге ты сам «по слогам» показал, что при не оперативном проведении, контролировать остатки не надо, надо проводить документ и потом разбираться… :)
Как связаны реакции по типу аллергии, со складскими остатками?
1) Тут все логично.
2) Во первых, что такое «неосновной поток ввода»? Опять воду в ступе толчем? Какое это имеет отношение к остаткам?
ну и вообще, все утверждение чушь. Если в водимом документе 1 товар «уходит в минус», а остальные не уходят, то как ты можешь гарантировать, что остатки по этим товарам обязательно будут неверными? И где доказательства, что в в случае наличия этих гарантий, практический ущерб будет больше? Опять доморощенные теоретики?
3) КЭП в атаке )). Ты сам то понял о чем вообще говоришь, и чего доказываешь?
Я с самого начала говорил, что при не оперативном проведении контроль остатков не нужен, надо проводить документ как есть и потом уже разбираться по факту наличия проблем с остатками.
В итоге ты сам «по слогам» показал, что при не оперативном проведении, контролировать остатки не надо, надо проводить документ и потом разбираться… :)
>>ЕСЛИ контролировать остатки и запрещать проведение при недостаче на учетных остатках какой-то (одной) позиции — патологию ведь не рассматриваем, верно? — получится, что по всем остальным позициям остатки, на основании которых выполняется оперативный ввод данных (см.п.1) станут (останутся) неверными
Ввода реализаций задним числом вообще быть не должно. При перепроведении или редакторивании задним числом в случае отказа программа не отменяет проведение документа, остатки по остальным позициям не изменятся.
>>т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
Тоже вариант
Ввода реализаций задним числом вообще быть не должно. При перепроведении или редакторивании задним числом в случае отказа программа не отменяет проведение документа, остатки по остальным позициям не изменятся.
>>т.о. более оптимальным, нежели непроведение при нехватке остатков для документов, корректируемых «задним числом» (напомню — по факту отгрузки!) будет безусловное из проведение с включением в список документов для последующего регламентного контроля корректности их оформления.
Тоже вариант
Вопрос к противникам контроля остатков в прошлых периодах — как вы относитесь к тому, что в УТ 11 остатки контролируются независимо от даты документа? Стали бы вы это исправлять при внедрении УТ 11?
Ух, какой холивар.
Правильно это или не правильно — исправлять систему контроля остатков — это один вопрос, а вот нужно это или не нужно — другой!
ТЕОРЕТИЧЕСКИ понятно, что все документы необходимо вводить сегодняшним числом, и исправлять ситуацию с остатками, резервами и прочими остатками нужно сегодняшним числом. Но есть много всяких НО когда сталкиваешься в работе с, мягко сказать, неквалифицированными сотрудниками, или с неправильно выстроенным процессом.
Взять просто случай. Есть склад, на котором в субботу работает только грузчик, который компьютер не видел ни разу, и есть покупатель, который приехал за своим товаром. Грузчику в пятницу вечером привезли бумажные документы из созданного, но не проведенного документа в 1С. Провести этот документ в пятницу — нельзя, т.к. товар на складе. В субботу — некому, т.к. офис не работает, а грузчик не умеет. Остается только понедельник. Но так как товар отгружен в субботу, реализация должна пройти в субботу. Поэтому документ проводится в понедельник субботой.
И тут возникает дилемма: позволить пользователю провести документ «как бог на душу положит», т.к. контроля остатков нет вообще ни каких, тем самым списав из резерва, когда резерва нет, или наоброт, со склада, «повесив» резерв при нулевом остатке и породив кучу проблем в дальнейшем учёте, или списать вообще не то что отгрузил, а «похожий товар», или же проконтролировать то что он делает «задним числом», использовав приведенный в данной статье метод.
Я выбираю второе, т.к. три месяца борьбы с пользователями, остатками, резервами, доступностью товаров, пересортом и прочими интересными вещами, которые позволяет сделать «правильная система 1С» задним числом, показывают, что этот вариант более правильный.
Правильно это или не правильно — исправлять систему контроля остатков — это один вопрос, а вот нужно это или не нужно — другой!
ТЕОРЕТИЧЕСКИ понятно, что все документы необходимо вводить сегодняшним числом, и исправлять ситуацию с остатками, резервами и прочими остатками нужно сегодняшним числом. Но есть много всяких НО когда сталкиваешься в работе с, мягко сказать, неквалифицированными сотрудниками, или с неправильно выстроенным процессом.
Взять просто случай. Есть склад, на котором в субботу работает только грузчик, который компьютер не видел ни разу, и есть покупатель, который приехал за своим товаром. Грузчику в пятницу вечером привезли бумажные документы из созданного, но не проведенного документа в 1С. Провести этот документ в пятницу — нельзя, т.к. товар на складе. В субботу — некому, т.к. офис не работает, а грузчик не умеет. Остается только понедельник. Но так как товар отгружен в субботу, реализация должна пройти в субботу. Поэтому документ проводится в понедельник субботой.
И тут возникает дилемма: позволить пользователю провести документ «как бог на душу положит», т.к. контроля остатков нет вообще ни каких, тем самым списав из резерва, когда резерва нет, или наоброт, со склада, «повесив» резерв при нулевом остатке и породив кучу проблем в дальнейшем учёте, или списать вообще не то что отгрузил, а «похожий товар», или же проконтролировать то что он делает «задним числом», использовав приведенный в данной статье метод.
Я выбираю второе, т.к. три месяца борьбы с пользователями, остатками, резервами, доступностью товаров, пересортом и прочими интересными вещами, которые позволяет сделать «правильная система 1С» задним числом, показывают, что этот вариант более правильный.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контроль товарных остатков в системах 1С