gifts2017

Механизм контроля отрицательных остатков по регистрам накопления

Опубликовал mikhail burlakov (burlakov) в раздел Отчеты - Анализ учета

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

Установка надстройки заключается в простом объединении конфигураций.

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

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

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

Право провести в минус имеет только человек с полными правами. Ему будет выданы предупреждения и задан вопрос, подтверждающий его намерения в случае если используется неуправляемое приложение. В управляемом приложении вопрос задавать в момент проведения не получается. Там действия будут заблокированы.

Этот механизм был успешно внедрен и прошел испытания реальной работой на предприятии с 250 активными пользователями в течении года на конфигурации упп редакции 1.3! Контроль ведется по десятку критичных регистров. Его применение обеспечивает решение многих проблем, влияющих на расчет себестоимости продукции и не только.

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

 

Версия 1.1

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

Исправлены выявленные ошибки, оптимизирован код.

Гарантия возврата денег

Гарантия возврата денег

ООО "Инфостарт" гарантирует Вам 100% возврат оплаты, если программа не соответствует заявленному функционалу из описания. Деньги можно вернуть в полном объеме, если вы заявите об этом течение 14-ти дней со дня поступления денег на наш счет.

Программа настолько проверена в работе, что мы с полной уверенностью можем дать такую гарантию. Мы хотим, чтобы все наши покупатели оставались довольны покупкой.

Для возврата оплаты просто свяжитесь с нами.

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Механизм контроля отрицательных остатков по регистрам накопления
25.12.2014
3000 руб.

Моментальная
доставка

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Konstantin Konstantin (KonstB) 19.10.12 16:58
(0) А с производительностью как? Т.е. если у меня ~10000 документов в день проводится, не "ляжет" у меня база?
2. Михаил Ражиков (tango) 19.10.12 17:06
соединяюсь с оратором
реальное решение трабла стоит много больше 1500
3. Алекс Ю (AlexO) 19.10.12 17:16
(2) tango,
Да Михаил, мы уже сколько тем обсудили с этим контролем - ну хочется автору громко заявить о себе, пусть пробует..
Конечно же, ясен пень, что у него обычное сравнение остатков на дату, а никакой не контроль с заднесписанными документами и зацикливанием расчета-поиска приход-расход...
А кто сомневается в стоимости настощего контроля остатков - вырежьте из УПП механизм восстановления последовательностей, и прикиньте его стоимость, хотя это всего лишь только костыль "прямого действия" для легитимизации заднесписочных остатков, а тоже далеко не МЕХАНИЗМ контроля....
4. Алекс Ю (AlexO) 19.10.12 17:16
(1) KonstB,
нет, вы просто все также не получите никаких реальных данных по отрицательным остаткам, зато автор получит свои денежки...
5. mikhail burlakov (burlakov) 19.10.12 17:30
на счет производительности. в нашей базе проводится порядка 2000 документов в день. база не ложится. на счет 10000 сказать не могу. просто нет такого опыта эксплуатации этой системы, но 2000 согласитесь тоже очень серьезно.

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

AlexO, критика должна быть конструктивной и справедливой, а не в стиле сама придумала, сама обиделась. не видя ничего не слишком ли смелое заявление? по поводу денег - у меня стоит 100% возврат.
6. Алекс Ю (AlexO) 19.10.12 17:46
(5) burlakov,
критика должна быть конструктивной и справедливой

ну если вы не видите в (3) конструктивной критики - то зачем же называть свою разработку "Контроль отрицательных остаков"?
Потому как вы понимаете одно, а пользователи ждут совершенно другого. А ваш "контроль" давно уже реализован в УПП, КА и УТ в качестве подбора остаков на складах, о чем вы - естественно, - как-то забыли упомянуть....
А для БП вроде где-то на ис мелькала...
7. mikhail burlakov (burlakov) 19.10.12 18:00
контроль осуществялется в зависимости от настроек. выполняется на каждую запись в регистре. пример. у нас есть на 01 число остаток по регистру 10. есть документ, который надо исправить в 01 числе. он списывает 3, хотя изначально списывал 1. итого остается 7. есть документ инвентаризация, который сделали 05 числом и который списывает некоторое количество по регистру допустим 9. мой контроль не даст провести такое исправление, сошлется на проблему в будущем. если такое где-то еще реализовано с удовольствием ознакомлюсь с другим опытом.
8. Алекс Ю (AlexO) 19.10.12 18:11
(7) burlakov,
не знаю, что вы придумали для себя в качестве метода проведения документов, но реально картина несколько иная:
Остаток
1. Приход 10 ноября 5 шт 5
2. Расход 11 ноября 3 шт 2
3. Приход 11 ноября 5 шт 7
4. Расход 12 ноября 8 шт не даст, ибо на складе столько нет
4. Расход 12 ноября 6 шт 1

Введем заднесписочный док:
1.1 Расход 10 ноября 5 шт 0
т.е. расход от 11 ноября быть не может (нет на складе), однако он возможен в этот же день чуть позже - после поступления новых 5, и вечером можно списать 3 шт. (остаток 2), однако расход 12 ноября уже невозможен по причине отсутствия на складе.
И тут появляется новый заднесписочный док - утренний приход 12 ноября...
Вот реальный алгоритм проведения документов (а их несколько видов) и принцип восстанволения последовательности на дату.
А что у вас - какие-то подгонки под результат с привязкой на некий док (инвентаризация).
9. mikhail burlakov (burlakov) 19.10.12 18:25
AlexO, такая практика ведения учета порочна сама по себе. если вы так работаете - ваше право, но не для всех это приемлемо. здесь реализована другая концепция. ЛЮБОЙ расход может быть ТОЛЬКО ПОСЛЕ прихода. минуса по регистрам НИКОГДА не возникают в принципе. вы ссылаетесь на восстановление последовательности. прочтите первый комментарий. у человека 10000 документов в день. и работа неверняка 24/7. сильно сомневаюсь, что он типовое восстановление последовательности использует. тут такие методы просто не работают. поэтому приходится поступать по другому.
применительно к вашему примеру. мой контроль даст провести ваш заднесписочный док 1.1 только после того, как будут проведены все приходы. можно конечно долго еще на эту тему дискутировать, но реальная практика показывает, что такой подход решает кучу проблем в учете.
10. Игорь Воронкин (Воронкин) 20.10.12 12:48
Две схеснувшиеся в споре концепции интересны в теме контроль отрицательных остатков, но не универсальны.

Лично я придерживаюсь третьей. Никаких "заднесписочных" документов создавать нельзя. Созданный "левый" документ поступления тянет за собой много проблем (это его оплата, взаиморасчеты с контрагентом и т.п).

Отрицательные остатки появляются а основном в двух случаях:
1. Операторские ошибки при вводе количества, даты, наименование наменклатуры и т.п.
2. Реализация перед поступлением, а не после.

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

Никогда не сталкивался с реальной базой по 10.000 документов в день, но почему типовое восстановление последовательности, по утверждению burlakov медленнее, чем его предлагаемая обработка.
11. mikhail burlakov (burlakov) 20.10.12 14:43
(10) Воронкин,

как я Вас прекрасно понимаю! но к сожалению без работы с задним числом наши люди жить не могут в массе своей. поэтому и приходится костыли всякие изобретать. к слову как-то говорил с представителями компании shott ag на эту тему. они в sap по всему миру работают. а вот в рф решили было упп внедрять и к sap привязывать. они от понятия "работа задним числом" вообще в натуральном шоке были. пришлось долго объяснять сам принцип.

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

но почему типовое восстановление последовательности, по утверждению burlakov медленнее, чем его предлагаемая обработка


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

касаемо восстановления последовательности. ну это оффтоп немного. если тема интересна, можно создать ветку и там подискутировать. могу сказать только, что за счет комплексных мер над удалось уйти практически от нее (контроль отрицательных остатков, запрет незаполненных сумм и количеств в регистрах ("движения сформировались без суммовой оценки" - бред писанный студентами!!!) и т.п.). типовой механизм не используем вообще. слишком медленно. у нас не отрабатывает даже за 12 часов. а надо обеспечить работу 24/7 и без того, что база ложится на бок. используем в итоге свой алгоритм. прогоняется он через другую мою обработку "Универсальное перепроведение по регистрам". но это решение к сожалению не универсально (в отличие от самой обработки). по сути наш самописный костыль делает тоже, что и типовой механизм, но за пару часов, применительно к нашей же самописной конфе на базе упп.
12. Игорь Воронкин (Воронкин) 20.10.12 15:10
Охотно бы поучавствовал в дисскусии по алгоритму (механизму) контроля и исправления отрицательных остатков, а не в обсуждении конкретной обработки, независимо от того, хороша она или плохая, или кто и как зарабатывает деньги.
Что бы выработать какую-то концепцию - в управленческой торговле, в производстве, в регламентированной бухгалтерии.
13. mikhail burlakov (burlakov) 20.10.12 15:31
(12) Воронкин,

создал отдельную ветку форума http://infostart.ru/profile/58328/forum/72723/
14. Владимир (hogik) 20.10.12 17:27
(11)(13)
"создал отдельную ветку форума"(с)
А давайте начнем (откроем) обсуждение в этой ветке с краткого Вашего описания ЧЕГО не могли долго понять "представители компании shott ag".
15. al petrov (petrov_al) 20.10.12 21:20
(7) burlakov, попытался обяснить главбуху нужность данного функционала. Недолго думая, а она женщина неглупая, высказалась резко отрицательно. Отсюда вывод ...в реале дорогой друг все не так как хочется. Нашим бухгалтерам на это плевать в течении месяца, а вот когда идет закрытие...другое дело. Так что может этот функционал и полезный, но для большинства он неподходит.
16. mikhail burlakov (burlakov) 21.10.12 11:07
(15) petrov_al, главбух озабочен в массе своей не реальным положением вещей на предприятии, а как подогнать цифры таким образом, чтобы меньше заплатить налогов, по возможности в рамках закона. наверняка привели аргументы из серии, что нам контрагенты документы вовремя не предоставляют и т.п. все это знакомо до боли. ровно как и "а что же нам теперь делать? месяц (квартал, год) закрывать надо!!! а у нас минуса...". поговорите с человеком, который заинтересован в видении реальной картины на предприятии. обычно этот человек отвечает за управленческий учет и видит предприятие как есть, а не так как его надо представить на обозрение в отличие от большинства главбухов. к тому же на многих предприятиях есть такое понятие как "утренний отчет руководству предприятия о состоянии дел". он как правило вбирает в себя оперативные данные именно упр. учета.
касаемо того, что многим не надо... может вы и правы конечно... пока есть только 1 масштабное успешное внедрение этой системы на крупном предприятии. но эффект наблюдаем от него колоссальный, поэтому и решил, что для массового применения тоже будет иметь успех.
в любом случае цена символическая, возврат денег гарантирован.
17. Василий Антонов (khaoos) 22.10.12 05:03
Помнится, в УТ 11 подобный механизм. Контролируются оперативные остатки при уменьшении прихода или увеличении расхода (новый документ удовлетворяет этим требованиям также).
18. Алекс Ю (AlexO) 22.10.12 10:59
(10) Воронкин,
Никаких "заднесписочных" документов создавать нельзя.

если вы вытащите этот краеугольный камень всего россиянского хохяйствования - вы обрушите весь россиянский учет.
Заднесписочные (заднечисловые) документы - это суровая необходимость нынешнего состояния учета, и аксиома, которую выпиливать нельзя никак - обрушишь весь функционирующий механизм.
burlakov; +1 Ответить
19. Михаил Ражиков (tango) 22.10.12 11:45
(9) burlakov,
такая практика ведения учета порочна сама по себе. если вы так работаете - ваше право, но не для всех это приемлемо. здесь реализована другая концепция.


Вы бы добавили эту оговорку в текст публикации. Тогда и подозрительно низкая цена будет понятна :)
20. Владимир (hogik) 22.10.12 18:57
(13) по предложению из (14).
Совершенно случайно обнаружил ТАМ Ваш ответ для меня.
Может лучше создать тему в "общем" форуме?
21. andrey dyak (dyak84) 22.01.13 14:04
Автор как быстродействие и блокировки у меня очень большая база и куча пользователей. Висяков не будет. Зарание спасибо за ответ
22. mikhail burlakov (burlakov) 09.08.13 15:29
(21) dyak84,
как можно на 100% ответить на ваш вопрос? я не знаю ни размера базы, ни количество пользователей, ни интенсивности их работы, ни параметры железа, на котором это все крутится. Даже не представляю Вашу версию платформы и какие регистры Вы контролировать собираетесь. а ведь все эти факторы оказывают заметное влияние. Могу сказать только, что у нас 250 пользователей, база 170ГБ, контролируются 10 регистров и проблем нет вообще никаких.
23. ZLENKO.PRO (ZLENKO) 06.11.13 11:38
(21) С избыточными блокировками в любом случае нужно бороться, быстродействие тоже улучшать. В нормальной (если у вас нормально настроен сервер 1С и оптимизирован код конфигурации) ситуации "тормозов" не будет. Как можно гарантировать отсутствие "тормозов" в общем случае ?
24. ZLENKO.PRO (ZLENKO) 06.11.13 11:41
(10) "Никогда не сталкивался с реальной базой по 10.000 документов в день"
Ну вот и не пишите ерунды раз не сталкивались. Без обид.
25. ZLENKO.PRO (ZLENKO) 06.11.13 11:49
Могу привести пример когда отрицательные остатки запретить нельзя. И практика показывает что совсем запретить отрицательные остатки нельзя :-( хотя очень хочется :-) В основном это связано с тем что операция совершена в другой системе или базе 1С и в любом случае должна быть загружена и проведена. Поэтому приходилось делать исключения из запрета на отрицательные остатки: по виду документа, по пользователю и т.п.
А в остальных случаях я двумя руками за запрет отрицательных остатков, в том числе "задним числом".
26. mikhail burlakov (burlakov) 06.11.13 12:34
(25) ZLENKO.PRO, да все верно! У нас также контролируются только некоторые регистры. Товары на складах например. Минуса например по взаиморасчетам - абсолютно нормальное явление. Вообще разработка хорошо подойдет тем, кто имеет кучу своих регистров и нуждается в общем механизме их контроля на отрицательные остатки.
27. Alexandr Климчук (undo) 10.11.13 09:03
У меня то же ряд пользователей работают с отрицательными остатками, т.к. работаем с весовой продукцией которая подвержена изменениям в весе в зависимости от внешних факторов, но при этом у нас установлен процентный лимит на превышение нулевого остатка. Такое дополнение в контроль то же будет полезным.
28. mikhail burlakov (burlakov) 10.11.13 10:53
(27) undo, Вы имеете ввиду неких механизм овердрафта? идея действительно интересная. пожалуй дополню в следующей версии. Спасибо!
29. Alexandr Климчук (undo) 10.11.13 11:45
да, можно назвать овердрафтом, такой привилегией у нас наделены ночные операторы которые редактируют накладные по фактически предоставленным складом данными.
30. mikhail burlakov (burlakov) 10.11.13 20:31
ок. я понял. доработаю опционарно. в текущей версии проводить в минус может только человек с полными правами. вот только как Вы будете определять размер овердрафта?
31. Vasiliy (dimisa) 07.02.14 18:16
(9) burlakov,
маузер или бейсбольная бита куда лучше решает проблему в учете еще на этапе проектирования бизнесспроцесса как такового.
32. Сергей Иванов (xten) 19.03.14 10:23
Подскажите, пожалуйста, это разработка в виде конфиги или внешней обработки?
33. mikhail burlakov (burlakov) 19.03.14 12:12
(32) xten, в виде конфы. объединяется с Вашей. решение полностью "сбоку". так что обновляемость не потеряете.
34. Сергей Иванов (xten) 19.03.14 14:28
35. Allexey (alex_4x) 28.04.14 09:09
Вызывается через подписку на события?

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

Ну так получается этот механизм контроля с любым другим механизмом может войти в конфликт?
36. mikhail burlakov (burlakov) 28.04.14 09:36
(35) alex_4x,

любой код с любым кодом может войти в конфликт. все зависит от того как его писать и потом использовать. контролировать с помощью моего механизма типовые регистры партионного учета не получится из-за особенностей их работы. в частности формирования записей через типовые механизмы модуля управление запасами партионный учет. это можно обойти, если написать свой механизм работы с этими регистрами, аналогично например, регистру "товары на складах". но это будет довольно большая переделка и Вы потеряете обновляемость. поэтому я и указываю это в тексте статьи. Вы можете прекрасно контролировать любые регистры кроме партионного учета с помощью моего механизма. в любом случае можно попробовать, а если не понравится, вернуть деньги. но как правило всем нравится :)
37. Allexey (alex_4x) 28.04.14 09:53
Я не оспариваю полезность данного решения, просто пытаюсь выяснить чем оно лучше простой проверки при проведении, которая делается достаточно просто и соответственно с учетом "особенностей" учета в конкретном случае.
Если говорить о универсальном механизме, то да, тут есть подводные камни - как то, запись движений в процессе проведения документа в различных типовых механизмах, различные разрозненные проверки на разных этапах. Если говорить о универсальном механизме проверки движений - тут не только отрицательные остатки, возможно еще проверка на логику заполнения измерений регистра - был бы полезен механизм, который отрабатывает после всех штатных механизмов и если надо - отменяет проведение. То есть данный механизм хорошо бы чтоб запоминал движения до начала проведения документа, делал проверки после проведения и в случае необходимости возвращал бы к состоянию "до проведения". При таком подходе он бы ни как не мог вступить в конфликт с другими проверками.
38. mikhail burlakov (burlakov) 28.04.14 10:21
(37) alex_4x,
это и есть проверка при проведении. но поскольку отрабатывает через подписи (а как иначе сделать решение сбоку?) выполняется после всех типовых механизмов. при этом проверка выполняется всей цепочки в зависимости от настроек. и на ТА и на документ и на все промежуточные записи между документом и ТА с анализом ситуации и выдачей результата где в каким местах появляются отрицательные остатки (см. скриншоты). "То есть данный механизм хорошо бы чтоб запоминал движения до начала проведения документа, делал проверки после проведения и в случае необходимости возвращал бы к состоянию "до проведения"" вот очень похоже на мою реализацию. только автоотката нет. если у человека нет прав проводить в минус, то идет возврат отказ = истина. и это же вызывает конфликт с проведением по партиям. там в модуле есть конструкция движения.записать(). мой механизм с ними работать не может, т.к. исчезают движения "до проведения". в этом и есть вся суть конфликта. есть идея как побороть и это. причем решение также оставить "сбоку". но разработка очень большая получится. пока просто руки не доходят.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа