[Расширение] Контроль отрицательных остатков по регистру бухгалтерии при проведении
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
Тестировали кейс при работе обработки перепроведения документов, нормально перепроводятся ? А что будет в таком случае:
1.) Вашего расширения нет, бух провел докумен, который сделал минуса
2.) Потом поступлениями этот минус выправили
3.) Установли ваше расширение, теперь бух в минус не проводит
4.) Гл.бух закрывает месяц и перепроводит все документы, включая док из 1. Что будет ?
1.) Вашего расширения нет, бух провел докумен, который сделал минуса
2.) Потом поступлениями этот минус выправили
3.) Установли ваше расширение, теперь бух в минус не проводит
4.) Гл.бух закрывает месяц и перепроводит все документы, включая док из 1. Что будет ?
(1) shibanovan, Вопросы вполне корректные.
Да, при попытке повторного проведения документ не проведется. Тут вообще-то правильнее все-таки поменять порядок документов. В БП желательно все-таки соблюдать порядок ввода. Если есть необходимость все-таки провести такой документ в виде исключения, то его может провести ключевой пользователь, для которого проверка отключена.
Еще стоит учесть, что контроль выполняется только при проведении из формы документа. Т.е. при массовом перепроведении бухгалтером групповой обработкой контроль выполняться не будет.
Наиболее логичное использование расширения это дополнительный контроль при вводе документов рядовыми пользователями. Главному бухгалтеру правильнее разрешить все и выполнять контроль данных вцелом отчетами.
Да, при попытке повторного проведения документ не проведется. Тут вообще-то правильнее все-таки поменять порядок документов. В БП желательно все-таки соблюдать порядок ввода. Если есть необходимость все-таки провести такой документ в виде исключения, то его может провести ключевой пользователь, для которого проверка отключена.
Еще стоит учесть, что контроль выполняется только при проведении из формы документа. Т.е. при массовом перепроведении бухгалтером групповой обработкой контроль выполняться не будет.
Наиболее логичное использование расширения это дополнительный контроль при вводе документов рядовыми пользователями. Главному бухгалтеру правильнее разрешить все и выполнять контроль данных вцелом отчетами.
(9) CheBurator, На отмену проведения, думаю, лишний.
Если документ некорректен, то его в любом случае нужно отменить. Независимо от того, появляются ли при этом отрицательные остатки.
По периоду контроля.
В принципе возможно даже логичнее использовать контроль на текущий момент, а не на момент документа. Т.е. пренебрегаем промежуточными остатками, но контролируем итоговые. Или на конец месяца.
По контролю на весь период от текущего документа. Теоретически возможно, но запрос достаточно тяжелый получается, если все промежуточные остатки проверять.
Т.е. тут 4 возможных варианта:
1. На момент документа;
2. Итоговые остатки на текущий момент;
3. На конец месяца;
4. Контролировать весь период от момента документа до текущего времени.
Не факт, какой кому более подходящий.
ИМХО, контроль на момент документа наиболее понятный пользователю.
Если документ некорректен, то его в любом случае нужно отменить. Независимо от того, появляются ли при этом отрицательные остатки.
По периоду контроля.
В принципе возможно даже логичнее использовать контроль на текущий момент, а не на момент документа. Т.е. пренебрегаем промежуточными остатками, но контролируем итоговые. Или на конец месяца.
По контролю на весь период от текущего документа. Теоретически возможно, но запрос достаточно тяжелый получается, если все промежуточные остатки проверять.
Т.е. тут 4 возможных варианта:
1. На момент документа;
2. Итоговые остатки на текущий момент;
3. На конец месяца;
4. Контролировать весь период от момента документа до текущего времени.
Не факт, какой кому более подходящий.
ИМХО, контроль на момент документа наиболее понятный пользователю.
(10) контроль на весь период получается просто и совсем ненапряжно, результат практически мгновенно. Но это требует доработки типовой конфы и в большинстве случаев невостребовано. Решается путем разложения осциллирующей функции остатков на сумму монотоно убывающих функций
(14) CheBurator, Честно говоря, я не поняла, что имелось в виду под фразой "Решается путем разложения осциллирующей функции остатков на сумму монотоно убывающих функций" и написала в ответ какой-то бред.
А что все-таки имелось в виду в (11) ?
А что все-таки имелось в виду в (11) ?
(16) pumbaE, Смысл в том, что отрицательные остатки могут быть по самым разным причинам.
Мы не можем менять все операции.
Теоретически достаточно делать запрос к таблице ОстаткиИОбороты с детализацией по регистратору и проверять промежуточные минуса.
Но это достаточно тяжелый запрос, чтобы делать его ради этой проверки.
И я так и не поняла, что такое "разложения осциллирующей функции остатков на сумму монотоно убывающих функций"
Можно эту фразу расписать попроще?
Мы не можем менять все операции.
Теоретически достаточно делать запрос к таблице ОстаткиИОбороты с детализацией по регистратору и проверять промежуточные минуса.
Но это достаточно тяжелый запрос, чтобы делать его ради этой проверки.
И я так и не поняла, что такое "разложения осциллирующей функции остатков на сумму монотоно убывающих функций"
Можно эту фразу расписать попроще?
(17) принцип в том, что партиобразующие движение всегда убывали. Т.е. самый простой пример, возврат не делает по партии движения приход * -1, а образует уже новую партию и она потом опять таки продолжает списываться. Временной ряд с остатками по партии 10 ...7 ... 3 ... 0, но ни как не 10 ...7...8...4...0. Тогда можем проверять остаток на дату документа по партиям дата которых меньше чем дата документа.
(15) если взять функцию остатков и развернуть ее по времени - получится хаотичная пила где остатки по "измерение" скачут вверх-вниз. никакого другого варианта для такого представления функции остатков кроме как прогнать тяжелый запрос на точку каждого регистратора изменения остатков ведущих остаток в минус - нет. мы вынуждены проверять каждый регистратор, который проводит изменение остатков вниз потому что мы не знаем прыжков вверх. если мы добавим !Дополнительное! измерение в функцию остатков (назовем это "партия" - и пусть пока это будет СЛУЖЕБНОЕ ИЗМЕРЕНИЕЯ, которое схлопывается везде в отчетах и не видно пользователю) - то осциллирующую пилу остатков мы можем представить как сумму остатков монотонно убывающих партий (ясен пень партия в точке своего возникновения сингулярна - из ниоткуда внезапно стало N). Теперь, чтобы проконтролировать а не ушли ли остатки в "минус" от любой точки заднего числа до сейчас - достаточно получить остатки по нашим служебным "партиям" на сейчас - это делается практически мгновенно. И если среди этих партий есть пратии с остатками < 0 - можно СРАЗУ СКАЗАТЬ что изменение остатков задним числом ОДНОЗНАЧНО приводит к нарушению НОРМАЛЬНОГО УЧЕТА - остатки ушли в минус, на складе было -3шт. (или в кассе -100 рублей). Этот вариант неоднократно обсуждался на мисте и здесь на Исе я также его упоминал в обсуждениях. такая концепция работает у меня на количественном учете ГТД и практически мгновенно, без всякой нагрузки на систему "блокирует" k.s,st халявные телодвижения, приводящие к траблам
(20) CheBurator, делал такое несколько раз. Очень удобно, если есть возможность изменять конфу - хранить остатки по "партиям" (где "партия" - это совокупность всех измерений контролируемого регистра-источника, однозначно идентифицирующая конкретную сущность - строку, то есть по сути - укникальный ключ) в отдельно регистре накопления (остатков), писать туда приходы и расходы подпиской на событие, в конце транзакции контролировать возникновение отрицательного остатка на текущий момент, а точнее на "конец времен". Единственное, я всегда предусматриваю в процедуре контроля возможность НЕ контролировать остатки по "партиям", передав туда нужный флаг, для возможного перепроведения задним числом в регламентных целях.
Купил сегодня обработку, хотел обрадоваться но не вышло.
БП Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.43.223)
Не хочет контролировать остатки. Никаких ошибок не выдает.
Выбрал в настройках только контроль по 41 счету, по всем пользователям, документ реализация товаров и услуг.
Специально задал такие условия: Товар1 продал под 0 сегодняшним числом. Создал копию документа с тем же товаром и количеством "на вчера ", все со свистом провелось.
Как быть?
БП Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.43.223)
Не хочет контролировать остатки. Никаких ошибок не выдает.
Выбрал в настройках только контроль по 41 счету, по всем пользователям, документ реализация товаров и услуг.
Специально задал такие условия: Товар1 продал под 0 сегодняшним числом. Создал копию документа с тем же товаром и количеством "на вчера ", все со свистом провелось.
Как быть?
(23)
Я так понимаю что если некоторые негодяи-пользователи проводят расходные будущим числом(им так удобно, на завтра типа) то в текущем дне будет черт знает что. Или если "поправят" в прошлом.
Смысл тогда в этой обработке? Я расчитывал что при проведении задним числом она пересчитает цепочку "до победного конца" и если где-то будет переход через 0 то ругнется. Вот это было бы совсем другое дело.
Я так понимаю что если некоторые негодяи-пользователи проводят расходные будущим числом(им так удобно, на завтра типа) то в текущем дне будет черт знает что. Или если "поправят" в прошлом.
Смысл тогда в этой обработке? Я расчитывал что при проведении задним числом она пересчитает цепочку "до победного конца" и если где-то будет переход через 0 то ругнется. Вот это было бы совсем другое дело.
(24) kepka, Я об этом уже писала в (10).
По моей оценке проверять всю цепочку при проведении каждого документа это слишком тяжелая проверка, чтобы выполнять ее при проведении каждого документа.
Просто вопрос скорости выполнения.
Подумаю еще. Может, со временем добавлю отдельной опцией.
По моей оценке проверять всю цепочку при проведении каждого документа это слишком тяжелая проверка, чтобы выполнять ее при проведении каждого документа.
Просто вопрос скорости выполнения.
Подумаю еще. Может, со временем добавлю отдельной опцией.