.png "Настройка контроля.png")
.png "Ошибка при контроле остатков")
Не требует изменения либо снятия с поддержки конфигурации.
Порядок использования:
1. В режиме предприятия подключаем расширение через меню «Все функции» — «Стандартные» — «Управление расширениями конфигурации»
2. Выбираем появившийся пункт меню «Администрирование» — «Сервис» — «Контроль отрицательных остатков» (либо «Все функции» — «Обработки» — «Контроль отрицательных остатков»)
3. Выбираем перечень счетов, для которых контролировать остатки, документы, при проведении которых контролировать остатки, и пользователей, для которых выполняется контроль.
4. Настройки работают сразу после сохранения. Никаких больше действий выполнять не нужно.
Контроль выполняется при проведении из формы документа. В случае, если после проведения документа появляются отрицательные остатки, проведение документа отменяется, и пользователю выдается подробное сообщение. Работает для всех документов, для которых разрешено проведение по регистру бухгалтерии, для всех активных и пассивных счетов.
Что в файлах:
КонтрольОтрицательныхОстатков_УниверсальныйШаблон.cfe — универсальный шаблон. Подключен только документ «Авансовый отчет», соответственно проверку остатков по счетам можно включить только для него. Подойдет для любой конфигурации, в которой есть документ «Авансовый отчет» и регистр бухгалтерии «Хозрасчетный». Любые другие документы можно подключить в конфигураторе самостоятельно аналогично авансовому отчету.
КонтрольОтрицательныхОстатков_БП3.0.41.cfe — готовый файл для БП 3.0. Никаких донастроек в конфигураторе не требуется. Сразу после подключения из режима Предприятия расширение работает со всеми документами, для которых разрешено проведение по регистру бухгалтерии. Проверялось на версии БП 3.0.41. Теоретически должно работать и для последующих версий, а также на базовой и ПРОФ.
Также рекоммендую из других моих универсальных разработок:
- [Расширение] Проверка ввода данных и события форм без изменения конфигурации (для БП, УТ, ЗУП, Розницы, ERP)
- Универсальная выгрузка/загрузка данных для отличающихся конфигураций (JSON)
- Комплексная проверка ведения учета в УТ10, УТ11, КА, УПП, ERP — простой отчет для проверки корректности ведения учета по всем разделам учета.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Тестировали кейс при работе обработки перепроведения документов, нормально перепроводятся ? А что будет в таком случае:
1.) Вашего расширения нет, бух провел докумен, который сделал минуса
2.) Потом поступлениями этот минус выправили
3.) Установли ваше расширение, теперь бух в минус не проводит
4.) Гл.бух закрывает месяц и перепроводит все документы, включая док из 1. Что будет ?
Блин, что-то на автора не посмотрел. Сообщение удалить не могу, но вообщем, вопрос снимаю, у автора пися подлиннее будет )
(1) shibanovan, Вопросы вполне корректные.
Да, при попытке повторного проведения документ не проведется. Тут вообще-то правильнее все-таки поменять порядок документов. В БП желательно все-таки соблюдать порядок ввода. Если есть необходимость все-таки провести такой документ в виде исключения, то его может провести ключевой пользователь, для которого проверка отключена.
Еще стоит учесть, что контроль выполняется только при проведении из формы документа. Т.е. при массовом перепроведении бухгалтером групповой обработкой контроль выполняться не будет.
Наиболее логичное использование расширения это дополнительный контроль при вводе документов рядовыми пользователями. Главному бухгалтеру правильнее разрешить все и выполнять контроль данных вцелом отчетами.
(3) а…вот это хорошо, что только при интерактивном проведении контролируется ! )
Во встроенном механизме конфигурации БП 3.0 есть опциональный контроль по счетам 10 и 41. В вашей обработке контроль происходит по всем количественным счетам?
(5) KSy, Контроль возможен по всем активным и пассивным счетам плана счетов по количественному и суммовому остатку.
Перечень контролируемых счетов настраивается пользователем.
(6) а на какую дату происходит контроль остатков? на дату документа?
(7) FireAlex, На момент времени после проведения документа.
Нужен пналогичный контроль и на событие отмены проведения
Причем контролироваться должно не на момент помле отмены проведения а как минимум на сейчас, как макимум — на всем промежутке от события до сейчас
(9) CheBurator, На отмену проведения, думаю, лишний.
Если документ некорректен, то его в любом случае нужно отменить. Независимо от того, появляются ли при этом отрицательные остатки.
По периоду контроля.
В принципе возможно даже логичнее использовать контроль на текущий момент, а не на момент документа. Т.е. пренебрегаем промежуточными остатками, но контролируем итоговые. Или на конец месяца.
По контролю на весь период от текущего документа. Теоретически возможно, но запрос достаточно тяжелый получается, если все промежуточные остатки проверять.
Т.е. тут 4 возможных варианта:
1. На момент документа;
2. Итоговые остатки на текущий момент;
3. На конец месяца;
4. Контролировать весь период от момента документа до текущего времени.
Не факт, какой кому более подходящий.
ИМХО, контроль на момент документа наиболее понятный пользователю.
(10) контроль на весь период получается просто и совсем ненапряжно, результат практически мгновенно. Но это требует доработки типовой конфы и в большинстве случаев невостребовано. Решается путем разложения осциллирующей функции остатков на сумму монотоно убывающих функций
(11) CheBurator, конфигурацию менять необязательно. Тут достаточно експоненциального расчета производной логарифма по основанию ~ё.
Ну или тупой простейший медленный запрос с детализацией по регистратору и отрицательными остатками 🙂
Плюс. Хорошо настраиваемое решение. Тестировал на Бухгалтерии.
Планирую по такой же системе добавить свои проверки.
(12) «Тут достаточно експоненциального расчета производной логарифма по основанию ~ё. »
— поясните, плиз, подробнее, если это возможно
(14) CheBurator, Честно говоря, я не поняла, что имелось в виду под фразой «Решается путем разложения осциллирующей функции остатков на сумму монотоно убывающих функций» и написала в ответ какой-то бред.
А что все-таки имелось в виду в (11) ?
(15) возрат не делает сторно(приход с минусом) а именно приход с плюсом, а дальше уже решается простым запросом. Но нужно менять конфигурацию.
(14) о как тебя… 🙂
(16) pumbaE, Смысл в том, что отрицательные остатки могут быть по самым разным причинам.
Мы не можем менять все операции.
Теоретически достаточно делать запрос к таблице ОстаткиИОбороты с детализацией по регистратору и проверять промежуточные минуса.
Но это достаточно тяжелый запрос, чтобы делать его ради этой проверки.
И я так и не поняла, что такое «разложения осциллирующей функции остатков на сумму монотоно убывающих функций»
Можно эту фразу расписать попроще?
(17) принцип в том, что партиобразующие движение всегда убывали. Т.е. самый простой пример, возврат не делает по партии движения приход * -1, а образует уже новую партию и она потом опять таки продолжает списываться. Временной ряд с остатками по партии 10 …7 … 3 … 0, но ни как не 10 …7…8…4…0. Тогда можем проверять остаток на дату документа по партиям дата которых меньше чем дата документа.
(18) pumbaE, Да, кажется, общую идею я поняла.
К сожалению, в данном случае мы не можем контролировать, из каких движению сформируются минуса.
Остаток может прыгать произвольно как в плюс, так и в минус.
(15) если взять функцию остатков и развернуть ее по времени — получится хаотичная пила где остатки по «измерение» скачут вверх-вниз. никакого другого варианта для такого представления функции остатков кроме как прогнать тяжелый запрос на точку каждого регистратора изменения остатков ведущих остаток в минус — нет. мы вынуждены проверять каждый регистратор, который проводит изменение остатков вниз потому что мы не знаем прыжков вверх. если мы добавим !Дополнительное! измерение в функцию остатков (назовем это «партия» — и пусть пока это будет СЛУЖЕБНОЕ ИЗМЕРЕНИЕЯ, которое схлопывается везде в отчетах и не видно пользователю) — то осциллирующую пилу остатков мы можем представить как сумму остатков монотонно убывающих партий (ясен пень партия в точке своего возникновения сингулярна — из ниоткуда внезапно стало N). Теперь, чтобы проконтролировать а не ушли ли остатки в «минус» от любой точки заднего числа до сейчас — достаточно получить остатки по нашим служебным «партиям» на сейчас — это делается практически мгновенно. И если среди этих партий есть пратии с остатками < 0 — можно СРАЗУ СКАЗАТЬ что изменение остатков задним числом ОДНОЗНАЧНО приводит к нарушению НОРМАЛЬНОГО УЧЕТА — остатки ушли в минус, на складе было -3шт. (или в кассе -100 рублей). Этот вариант неоднократно обсуждался на мисте и здесь на Исе я также его упоминал в обсуждениях. такая концепция работает у меня на количественном учете ГТД и практически мгновенно, без всякой нагрузки на систему «блокирует» k.s,st халявные телодвижения, приводящие к траблам
(20) CheBurator, делал такое несколько раз. Очень удобно, если есть возможность изменять конфу — хранить остатки по «партиям» (где «партия» — это совокупность всех измерений контролируемого регистра-источника, однозначно идентифицирующая конкретную сущность — строку, то есть по сути — укникальный ключ) в отдельно регистре накопления (остатков), писать туда приходы и расходы подпиской на событие, в конце транзакции контролировать возникновение отрицательного остатка на текущий момент, а точнее на «конец времен». Единственное, я всегда предусматриваю в процедуре контроля возможность НЕ контролировать остатки по «партиям», передав туда нужный флаг, для возможного перепроведения задним числом в регламентных целях.
Купил сегодня обработку, хотел обрадоваться но не вышло.
БП Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.43.223)
Не хочет контролировать остатки. Никаких ошибок не выдает.
Выбрал в настройках только контроль по 41 счету, по всем пользователям, документ реализация товаров и услуг.
Специально задал такие условия: Товар1 продал под 0 сегодняшним числом. Создал копию документа с тем же товаром и количеством «на вчера «, все со свистом провелось.
Как быть?
(22) kepka, Т.е. второй документ датой «вчера»?
Контроль выполняется на дату документа. Соответственно, если вчера товар был, то документ правильно провелся.
(23)
Я так понимаю что если некоторые негодяи-пользователи проводят расходные будущим числом(им так удобно, на завтра типа) то в текущем дне будет черт знает что. Или если «поправят» в прошлом.
Смысл тогда в этой обработке? Я расчитывал что при проведении задним числом она пересчитает цепочку «до победного конца» и если где-то будет переход через 0 то ругнется. Вот это было бы совсем другое дело.
Если так сможете доделать, хотя бы под мои потребности — пожму руку и позолочу.
Чебуратор, кажется про это именно и намекал))
(24) kepka, Я об этом уже писала в (10).
По моей оценке проверять всю цепочку при проведении каждого документа это слишком тяжелая проверка, чтобы выполнять ее при проведении каждого документа.
Просто вопрос скорости выполнения.
Подумаю еще. Может, со временем добавлю отдельной опцией.
В типовой — придется извращаться. а делать нетиповой — восьмерочников от этого тошнит и они теряют сознание… от страха наверное.. 😉
(23) вариант поставить два контроля, на дату документа и «на конец времён» позволит убрать хотя бы часть проблем.
Бухгалтерия предприятия, редакция 3.0 (3.0.67.70)
Расширения конфигурации:
— Контроль отрицательных остатков (1.1.1.2)
— не выдает сообщения, что нет в наличии
(30) — перезагрузил расширение за работало…