gifts2017

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

Опубликовал Денис (1cspecialist) в раздел Обработки - Обработка документов

Типовые конфигурации 1С, такие как "Управление торговлей" или "Управление производственным предприятием" контролируют остатки определенных регистров (например товарных регистров) только при оперативном проведении документов (текущим моментом времени). При неоперативном  же проведении (как правило "задним" числом, т.е. в прошлом) этот контроль считается бессмысленным с точки зрения 1С. Данная обработка призвана исправить эту ситуацию.

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

Давайте рассмотрим классический пример. Предположим, что на 01.01.10 на складе числится 10 единиц товара. 15.01.10 создана расходная накладная на 5 единиц товара. Итого, на конец дня 15.01.10 числится в остатке 5 единиц товара. Допустим "задним" числом 10.01.10 создаем еще одну расходную накладную на 8 единиц товара. Контроль при проведении такой накладной нам ничего бы не дал, т.к. на 10.01.10 на складе числится 10 единиц - достаточное количество для этого расхода. Но проблема возникает уже с последующим расходом 15.01.10 - для этого расхода на складе по учету нет достаточного количества товара. Таким образом проведение документа прошлой датой может сделать некорректным учет остатков последующих периодов.

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

PS. Для работы на 8.2 необходимо сконвертировать обработку.

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

Наименование Файл Версия Размер Кол. Скачив.
Обработка контроля отрицательных остатков
.zip 14,03Kb
23.08.10
1166
.zip 14,03Kb 1166 Скачать

См. также

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

Комментарии

1. Ирина Пятакова (Alraune) 23.08.10 11:11
Для реального использования неудобно, но за идею плюс.
2. fadeyson (1cspecialist) 23.08.10 12:00
Согласен, не совсем удобно. Но в помощь пойдет. В планах сделать более удобную вещь, которая будет делать такой контроль автоматом и отсылать результаты по почте или другим способом информировать.
3. Александр Медведев (anig99) 23.08.10 12:26
в любой типовой можно отключить проверку на оперативность и получим тоже систему контроля (со своими недостатками, но с громадным плюсом - минимальные изменения в конфе)
4. fadeyson (1cspecialist) 23.08.10 13:43
Такой системы контроля, которая контролирует все последующие движения, ни в одной типовой конфигурации нет. И хотелось бы узнать, что вы имеете ввиду, когда говорите про отключение проверки на оперативность?
5. Александр Медведев (anig99) 23.08.10 22:11
(4) в типовых есть процедуры контроля остатков. они вызываются только при оперативном проведении документов. если отключить проверку на оперативность проведения документа, то процедуры будут вызываться всегда. При этом все запросы выполняются на текущее время. Таким образом, получаем контроль за тем, чтобы исправления прошлых периодов не вогнали в минус текущие остатки. Минус, естественно, в том, что не проверяется возникновение минусов на всем временном промежутке, а только в конечной точке.
Но уж лучше такая проверка, чем идеалистическая логика 1с об оперативном проведение.
pvlunegov; +1 Ответить
6. fadeyson (1cspecialist) 23.08.10 22:37
(5) Я так понимаю, что отключать вы собрались изменяя код типовой конфигурации. Это самое страшное, что может сделать разработчик. Мне и в страшном сне не приснится менять код типовой конфигурации. Вы представляете себе, что вам постоянно придется контролировать, чтобы при обновлении не затереть все свои изменения? Овчинка выделки не стоит - изменить код типовой конфигурации, чтобы получить "недоконтроль". А 1С в этом случае не надо ругать, логика оперативного контроля абсолютно правильная. Если проверять все движения при проведении - это нагрузка на базу, поэтому 1с его и не делает.
7. Александр Медведев (anig99) 24.08.10 08:28
(6) хее... волков не боятся - в лес не ходить...
Доработка конфигурации под конкретные нужды - нормальная практика. Если Вы боитесь менять типовую - значит Вы плохо знаете основы и конкретную конфигурацию, а также механизмы её работы. Лично я, а также многие другие здесь не боятся дорабатывать конфигурации и потерять что-то при обновлении. Работаю и обновляю 1с УПП, Бухгалтерию, Комплексную с 8.0 версий (если поискать на инфостарт можно найти несколько статей о том, как можно эффективно вносить изменения для дальнейшего облегчения обновления)
В 1с сидят идеалисты, которые разрабатывают конфигурации для каких-то мифических компаний с неким шаблонным учетом. Практика контроля остатков только при оперативном проведение не выдерживает встречи с реальностью. Как и многие другие механизмы 1с. Не это ли Вас сподвигло на написание этой статьи?
Оперативный контроль остатков ВООБЩЕ не работает на практике, более того, он ВРЕДЕН. Я сразу указал, что мой способ имеет много минусов, но он уже ЛУЧШЕ для конкретного учета, чем преложенный способ от 1с, возросшая нагрузка, по сравнению с Вашим способом ничтожна, а изменения в конфигурации - минимальны.
Вопрос не в том, чей подход правильнее (1с, мой, Ваш), а в том, какой из них больше подходит для каждого конкретного случая.
www2000; VladT1969; BBons; vladir; UncleVader; Арчибальд; +6 Ответить 2
8. Игорь Исхаков (Ish_2) 24.08.10 08:48
В 1с сидят идеалисты, которые разрабатывают конфигурации для каких-то мифических компаний с неким шаблонным учетом. Практика контроля остатков только при оперативном проведение не выдерживает встречи с реальностью.


Ишь ты какой ! "идеалисты !"
Ты создаешь частное конкретное решение ("Для сэбэ") .
1с создает универсальное решение ("Для всех").
Разницу чувствуешь ?
Ты предложи общее решение и мы вместе похихикаем над его "идеальностью".
alexscamp; 1cspecialist; hulio; +3 1 Ответить 3
9. noprogrammer (noprogrammer) 24.08.10 08:58
Ты создаешь частное конкретное решение ("Для сэбэ") .
1с создает универсальное решение ("Для всех").
Разницу чувствуешь ?
Ты предложи общее решение и мы вместе похихикаем над его "идеальностью".


Решения от 1С совсем не универсальны, для универсальности необходимо делать возможность параметрических настроек, причем делаются они достаточно элементарно, так что "ругать" 1С есть за что (имхо)
sasedka; anig99; +2 Ответить 2
10. Игорь Исхаков (Ish_2) 24.08.10 09:27
(9) Параметрические настройки в 1с ЕСТЬ : Главное меню-Сервис-....
Потрясающее открытие.
Достаточны ли они ? Возможно , нет.
Поругаем 1с ? Давайте ...
11. Александр Медведев (anig99) 24.08.10 09:32
(8) в (9) правильно сказано... Делали бы решения "для всех", то в некоторых местах логика построения модуля была бы другой.
Для примера:
система резервирования... Тупо нет переключателя, чтобы отключить контроль резервов для реализации и оставить его для заказов - забыл менеджер снять резерв, ушел домой, а ночью отгрузка остановилась - не могут провести и распечатать документы.

Система скидок - скидки ВСЕГДА считаются от суммы, а те же торговые сети скидки считают от цены

Возможность штатного проведения будущим числом - ОЧЕНЬ иногда нужная вещь.

Указание цены при операциях с ответхранением

Отсутствие связи "Документ основание" между требованием-накладной и Отчетом производства

Механизм создания документа реализации на основе заказа - НАФУЯ НЕЛЬЗЯ ОТКЛЮЧИТЬ ТАМ КОНТРОЛЬ ОСТАТКОВ???

Возможность печати для непроведенных документов только определенных печатных форм - как мне печатать задание на погрузку? из заказа не подходит - некоторые заказанные товары грузить нельзя...из заказа их убрать тоже нельзя - нужно контролировать выполняемость заявок...
12. Александр Медведев (anig99) 24.08.10 09:37
ещё раз. 1с пишет не "для всех", а для "идеальной" торговой компании... которая в реальности загнется из-за отсутствия необходимой гибкости. Её просто обгонят конкуренты.
Valerich; +1 Ответить
13. Александр Медведев (anig99) 24.08.10 09:39
(10) ДА! Мало параметров! ОЧЕНЬ МАЛО.
endru; Ish_2; +2 Ответить 2
14. Игорь Исхаков (Ish_2) 24.08.10 09:45
(13) Отвечу тебе тяжелым плюсом.
15. noprogrammer (noprogrammer) 24.08.10 09:46
(10) Спорить не вижу смысла, так универсальные системы не пишут... Это не универсальная система получается а заготовка - мол вот вам ребята шаблончик дальше сами (шаблончик согласен - для всех) (имхо)
16. Александр Рытов (Арчибальд) 24.08.10 09:47
(8)
1с создает универсальное решение ("Для всех").
Прошу прощения, бред. Если бы 1С выделила нечто общее (для всех) и добавила варианты надстроек - цены б ей не было. А на самом деле решения 1С "заточены": зарплата - под офис (в табеле не факт, а отклонения), УПП - под "отверточное" производство. И все моноблоком.
Параметрическая настройка функционала должна была бы подключать к общему ядру нужную надстройку и отключать ненужную. А тут в лучшем случае дается возможность что-то выключить, причем без гарантий, что при этом заодно еще что-нибудь не отключится.
Valerich; +1 Ответить
17. Игорь Исхаков (Ish_2) 24.08.10 10:00
(16) Не будет тебе прощения. Ты передернул .
В посте (8) был призыв понять разницу в сложности решений "для сэбэ" и "для всех".
Но вовсе не утверждалось , что решения от 1с ("для всех") не обладают недостатками.
18. Александр Рытов (Арчибальд) 24.08.10 10:11
(17) Я же утверждаю, что решения 1С - это "для сэбэ". Они придумали некую модель (модели) фирмы, и пишут для нее. Тут речь не о недостатках идет, а об отсутствии методологии.
19. Михаил Ражиков (tango) 24.08.10 10:21
(6) "Мне и в страшном сне не приснится менять код типовой конфигурации."
ноу комментс :)
20. Михаил Ражиков (tango) 24.08.10 10:27
(11) "Механизм создания документа реализации на основе заказа - НАФУЯ НЕЛЬЗЯ ОТКЛЮЧИТЬ ТАМ КОНТРОЛЬ ОСТАТКОВ???"
имхо, если создаешь рнк на основе заказа И если он тебе помешал - он сделан не зря
21. vip (vip) 24.08.10 10:28
(18) В точку!
Опять сформулировал мои мутные мысли :)
22. Александр Рытов (Арчибальд) 24.08.10 10:30
23. fadeyson (1cspecialist) 24.08.10 10:46
(7) вот как раз те, кто "не очень знает" основы и типовые конфы и стремятся перепахивать типовой код и изменять его налево-напрово. Высший пилотаж - это когда вы без изменений типовых функций достигаете целей и заказчик с чувством полного удовлетворения платит вам деньги за работу. Заявления о том, что "я УПП обновляю" ничего не говорят... ну я тоже УПП обновляю и прекрасно знаю, что такое в УПП доработать тот или иной блок. Несмотря на то, что в конфе уйма доработок я обновляюсь в полностью автоматическом режиме, зная, что обновление ничего моего не затрет.
То, что вы не боитесь "потерять что-то при обновлении" - это похвально, но дело то не в боязни. Интересно, что скажет клиент, когда после вашего обновления он лишних пару миллионов налогов заплатит.
А насчет подхода, что каждая ситуация требует своего решения - с этим абсолютно согласен. И я допускаю, что могут быть ситуации, когда действительно нужно менять что-то типовое, но этого нужно избегать - так всем проще и правильнее жить - разработчику проще обновлять и поддерживать, клиенту спокойнее.
24. mosAdm (mosAdm) 24.08.10 10:51
Обработка правильная, жаль не для конечного пользователя.
Недавно пришлось решать именно эту задачу, изменение документов задним числом и контроль остатков уже проведенных документов, не много конфигурацию поменял на регистре "ТоварыОрганизаций" сделал ругалку и запрет записи.
За идею полюс.
25. Александр Рытов (Арчибальд) 24.08.10 10:54
(7) Смотри-ка, в (23) тебя похвалили :D
26. fadeyson (1cspecialist) 24.08.10 11:03
(24) а как бы вы ее видели для конечного пользователя? только именно обработку, без изменений в типовой конфигурации. мне кажется не очень хорошо, делать такой контроль именно при проведении документа, т.к. все-таки нагрузка на базу 1с - это слабое место, особенно в УПП и особенно когда много пользователей одновременно работают - сразу же риск нарваться на блокировки (снижается параллельность работы).
27. Александр Медведев (anig99) 24.08.10 11:16
(20) а мне вот нужно, чтобы заказ полностью переносился в реализацию - дальше разбираться будет склад и производство. Заказ менять нельзя - как иначе контролировать процент выполнения заказов? А в типовой этот долбанный контроль мешает мне в той ситуации, когда заказ есть, в производство товар запущен, через час выйдет и пойдет сразу в машину, а операторы вынуждены вручную набивать реализацию, чтобы подготовить её вовремя к отправлению машины. Вручную - потому что товар ещё не оприходован (производство то ещё не закончено), а ввод на основании не видя остатков трет им всё... И в типовой НЕТ галочки, чтобы отключить это.

(23) вообще-то к этому тоже стремлюсь, но стержень в за...це разработчиков типовых 1с сидит глубоко - гибкость конфы в некоторых местах нулевая, а возможность того или иного вида операций начисто отрицается - приходится комментить и добавлять пары строчек своих. Все мои изменения не носят глобальных характер. Если интересно - почитайте мою статью об облегчении обновления.
28. Михаил Ражиков (tango) 24.08.10 11:23
(27) проблема "набивать" тупо по-1сному решается заполнением тч. или у тебя 77?... "ввод на основании не видя остатков трет им всё" - ни разу ни понял. тебе надо отпустить клиента или списать непроизведенное?
29. mosAdm (mosAdm) 24.08.10 11:33
(26) Как внешнюю обработку скорее всего никак:
- Внешняя печатная форма не пойдет, вряд ли будут запускать
- Отчет за период, смысла вроде нет, есть "Проведение по партиям"

У меня задача была довольно простая:
в течении дня делают что хотят, а вот задним периодом надо проверять. Права с "полных прав" понижать нельзя.
а дальше все просто: проверка только на прошлую дату, проверка на открытую форму ну и потом проверка на коллизии.

А блокировки как-то вроде привилегированным режимом вроде и вылечиваются.
30. fadeyson (1cspecialist) 24.08.10 11:36
(27) если память не изменяет, то у документа реализации есть кнопка заполнить, где можно заполнить составом заказа, но даже если ошибаюсь, то всегда можно сделать свою обработку и не нужно будет вносить изменения в типовой код.

Насчет негибкости в некоторых местах - согласен. Уже долго 1с уговаривают, чтобы сделали подписки на события формы. Ну вроде бы для 8.2 Сергей Нуралиев обещал подумать. Скорее всего сделают. А вообще-то разработчиков платформы и типовых конфигураций тоже можно понять. Они разрабатывают не какую-нибудь филькину грамоту, а финансовые системы учета и думают о таких вещах, которые нам с вами и подавно в голову не придут. Бывают и ошибки. А вы мне покажите хоть какую-нибудь систему, где никогда не бывает ошибок.
31. Александр Медведев (anig99) 24.08.10 11:39
(28) Всё сводится к тому же - допиливать... Ведь можно было дописать 5 строчек кода... Нет. Возможности выбора не оставили. Нужно или править конфу или писать заполнение табличных частей, которая уже и так содержит 4-5-10 таких вот "доработок"...
А что нужно... Нужно, чтобы заказ остался нетронутым, а операторы получили реализацию, которую они отредактируют "по факту".
Процесс выглядит так:

1. Поступил заказ
2. Заказ проверен на наличие, если надо формируется заказ в производство (устный или в 1с - не важно)
3. На основе заказа формируется реализация (не проводится) откуда убирают заведомо недогруз (нет на складе и производить не будут).
4. Печатается наряд на погрузку (реализация не проведена - тут как раз и нужны печатные формы, которые можно печатать даже с штатным запретом на печать непроведенных...1с сейчас запрет поместило грамотно в соответствии со своей логикой - легкой правкой конфы не обойдшься - пришлось Заполнение табличных частей использовать).
5. Пока товар грузится проверяются цены и скидки, заполняются доп.поля (водитель, машина и т.д.)
6. Во время погрузки из цеха выходит продукция и её тоже грузят в машину. В это время мастер забивает отчет производства и кладовщик оприходует этот товар.
7. машина погружена
8. корректируется неучтенный недогруз, накладные проводятся и печатаются...
9.Машина ушла.

Накладных не 1-2, в а несколько десятков в день, по 10-20-40 позиций штучного и весового товара.
32. fadeyson (1cspecialist) 24.08.10 11:40
(29) позиция понятна. скорее всего моя обработка действительно неудобна в тех случаях, когда изменения задним числом имеют массовый характер и являются нормой. но я ее для этого и не писал. она скорее подойдет для людей, которых хотят подстраховаться в случае нечастых неоперативных проведениях.
33. Михаил Ражиков (tango) 24.08.10 11:42
"Они ... которые нам с вами и подавно в голову не придут"
однозначно плюса :) :{}
Арчибальд; +1 Ответить
34. Михаил Ражиков (tango) 24.08.10 11:46
35. Александр Медведев (anig99) 24.08.10 11:57
(30) именно поэтому разработкой занимается КОМАНДА. И в этой команде должны быть люди, которые отвечают за юзабилити... А они там лапти вяжут...
На уровне платформы юзабилит делают, а в конфе косячут...
Вот на кой ляд нужно ставить "Пропускать при вводе" на поле характеристика????
Заказ и реализацию обычно вводят на одной клаве...

Из заказа очень удобно формировать реализацию - одна кнопка... А в реализации указывать заказ уже неудобно - создать реализацию, проставить контрагента и договор, выбрать заказ, а потом уже щелкать мышью. Если из заказа делать реализацию, то нифига не эргономично снова нажимать на кнопку "Заполнить по заказу" - тем более, что она вызывает всё ту же обработку с контролем остатков
36. Александр Медведев (anig99) 24.08.10 12:02
(31) Именно...
Штатные механизмы - неэргономичны... Приходится допиливать по мелочи... В реализации уже несколько заполнялок табличных частей для разных целей. А иногда легче закомментить 1 строчку, чтобы работало как хочется.

З.Ы. Ещё раз. Я не говорю о доработках и изменениях идущих в разрез с законом или основных процессов. Просто некоторые мелочи очень затрудняют жизнь при вводе первички.
37. mosAdm (mosAdm) 24.08.10 14:28
(32)
Если рассматривать постановку задачи как
> "..для людей, которых хотят подстраховаться в случае нечастых неоперативных проведениях."
в этом случае мне кажется больше бы подошел отчет за период (с момента границы последовательности) с выводом коллизий и вариантами их разрешений по всем цепочкам документов. Но хлопотно это.

В этом виде, имхо, обработка интересна только специалистам. В типовых конфигурациях есть "Универсальная обработка справочников и документов", замечательный инструмент, но используют её, по моим наблюдениям, ничтожно малое количество пользователей. :-(
38. Артур Аюханов (artbear) 28.08.10 08:18
Обработка не жизнеспособна :(
Как правило, пользователям совершенно неудобно контролировать каждый документ :(
Намного проще сделать какой-то отчет, который покажет минуса в остатках по документам за какой-то период.
CheBurator; +1 Ответить 1
39. Аркадий Кучер (Abadonna) 28.08.10 08:30
(0), (38) А ежели так: при проведении задним числом проверяем еще и остаток на "на сейчас", вычитаем количество, списываемого товара данным ("задним") документом.
И если получаем отрицательный результат - запрещаем проведение.
Или сразу не запрещаем, а выводим вопрос с двумя кнопками: "Пох" и "Нах" :D
tadem; Alex_Nash; +2 Ответить 2
40. Сергей Троицкий (tsd) 28.08.10 08:50
(39) схему двойного контроля народ пользует давно. К сожалению, она не дает гарантии, что в промежутке датаДока-ТекущаяДата не появятся минуса.

ЗЫ: Вообще стоит задуматься, почему 1С изменила схему контроля остатков при работе задним числом, и попробовать понять эту логику.
41. Аркадий Кучер (Abadonna) 28.08.10 08:53
(40)
К сожалению, она не дает гарантии, что в промежутке датаДока-ТекущаяДата не появятся минуса.

Это точно, но хотя бы на текущую дату будем иметь нормальный остаток
42. Александр Медведев (anig99) 28.08.10 10:19
(39) чего можно достичь отключив проверку на оперативность проведения. В типовых проверка остатков при оперативном проведении осуществляется на текущий момент. А значит проводя задним числом будем проверять остатки на сейчас.
43. Аркадий Кучер (Abadonna) 28.08.10 10:21
(42) Я немного не про то. Надо остатки и на документ, и на сейчас
44. Александр Медведев (anig99) 28.08.10 15:45
(43) в принципе это достигается минимальными изменениями в конфе...
45. Аркадий Кучер (Abadonna) 28.08.10 15:47
46. Владимир (hogik) 28.08.10 16:27
(40)
"Вообще стоит задуматься, почему 1С изменила схему контроля остатков при работе задним числом, и попробовать понять эту логику."
- Они решают задачу учета документов, а не учета остатков... ;-)
CheBurator; Alex_Nash; +2 Ответить 1
47. Сергей (ildarovich) 28.08.10 22:14
(46)
Вот ответ одного из разработчиков 03.11.2004 22:24

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

И еще: конечно, для правильного учета надо стремиться вводить документы оперативно. Например, если накладные от поставщика придут только в конце месяца, то при реальном поступлении товара рекомендуется оформить приходный ордер.
48. Александр Медведев (anig99) 28.08.10 22:19
(47) оператор, видимо, для него - это кассир в магазине...
49. Владимир (hogik) 29.08.10 00:10
(47)
Мне кажется, что "ответ одного из разработчиков" подтверждает моё "предположение" ;-) из #46 сообщения. Т.е. они "автоматизируют" процесс "ввода документа". Раньше это называлось "перфорация" - операторы тупо колотили с бумажки (первичного документа) на перфокарты. А потом, в пакетном режиме, прогоняли через табулятор для подведения итогов. Это и есть автоматизация учета документов образца 1960 года. Непонятно, зачем тогда городить вот этот "огород": http://v8.1c.ru/metod/architecture/ И, думаю, не имеет смысла пытаться сделать автоматизацию, типа, из #32 сообщения. Кроме "гимора" пользователям это ничего не даст - не "документами с проведением" решаются подобные задачи... :evil:
50. Владимир (hogik) 29.08.10 01:58
(47)
Извините, не в тему напишу.
Этот "ответ одного из разработчиков" мне напомнил мой разговор с одним бухгалтером по поводу восстановления последовательности документов. Обсуждали "странное", на мой взгляд, отношение 1С-овцев к "заднему числу". Этот бухгалтер, вроде, со мной согласился и "пожаловался", что ему не удалось восстановить последовательность. Типа: "Она мне чЁто сказала. Я не понял. Больше не пытался восстановить.". На мой вопрос: "А как у них, при этом, обстоят дела с остатками". Я получил ответ: "А они и так никогда не сходятся на реальных складах. Зачем утруждаться - разбираться с восстановлением последовательностей?".
P.S. Этот бухгалтер, по совместительству, является хозяином фирмы. ;-)
51. Сергей (Che) Коцюра (CheBurator) 06.09.10 22:27
потому что наличие положительных остатков в прошлом на определенную дату вовсе не дает гарантии корректности учета последующих операций.

- дает, надо только правильно кошек приготовить.
.
как отмеченов (43): надо остатки на документ и на сейчас... добавлю: небольшой доделкой при приавльных исходных остатках на документ можно гарантировать неотрицательность (или по крайней мере мгновенно об этом уведомить) всей истории остатков...
52. Сергей (Che) Коцюра (CheBurator) 06.09.10 22:35
делаем просто: осцилирующую на оси времени функцию поведения остаткоа (по какой либо одно йноменклатуре) надо всего лишь разложить на сумму монотонно убывающих функций... в этом случае при проведении задним числом можно не только получить состояние остатков "на сейчас" (положительный или отрицательный), но и однозначно утверждать неортицательность остатков на всей истории...
53. Игорь Исхаков (Ish_2) 07.09.10 07:44
(52) Ух ты... "Монотонно убывающие" .
Ни слова не понял.
Пример приведи или тему создай э..э.. "про кошек".
Обещаю прочитать.
54. Сергей Троицкий (tsd) 07.09.10 08:07
55. Александр Рытов (Арчибальд) 07.09.10 08:21
(54) Он еще может поместить себе в карман металлический предмет, нагретый до полутора тысяч градусов. Я тоже ;)
(53) Возврат = отдельная партия :)
56. Игорь Исхаков (Ish_2) 07.09.10 08:24
(55) И ты , Арчибальд .. про "кошек" ?
" Возврат = отдельная партия" - Это о чем ?
57. Александр Рытов (Арчибальд) 07.09.10 08:42
(56) Это гарантия невозрастания остатка по каждой партии. А сумма остатков по партиям = остаток по номенклатуре.
58. Игорь Исхаков (Ish_2) 07.09.10 09:00
(57) Спору нет - вы с Чебуром знатоки по остаткам.
Так вы бы и разжевали нам "про кошек" , то бишь про использование "монотонно убывающих".
Дай Бог , чтобы после разбора примера в остатке остался смысл .
59. Сергей (Che) Коцюра (CheBurator) 07.09.10 09:13
вот сразу видно, что жизненный опыт - он есть у Арчибальда... ;-)
в (57) он правильно изложил.. и отсюда мгновенно при включении мозга вытекает, что если остатки по каждой "партии" убывающие - то имея на сейчас положительный остаток по партии - автоматом гарантируется положительные остатки на любой промежуток от возникновения партии до ее финиша... отсюда осталось немного до практической реализации: изменив в заднем числе (изменив количество в существующем доке или вставив новый расходный док) - можно практически мгновенно определить - выведет он СУММАРНО все партии остатков на сейчас в ноль - или нет (ясен пень, из остатков партий "на сейчас" надо выкинуть партии которые образовались позже редактируемого документа или например смягчить условие - в пределах дня считать ок)... на таком алгоритме у меня построен партионный КОЛИЧЕСТВЕННЫЙ учет ГТД у импортера... - все прекрасно работает с февраля месяца... А вот с суммовым учетом - тут в 7.7. сложнее - я не могу корректировать суммы проведенные по регистрам другими доков... в 8-ке - это вроде как можно и тогда корректировку сумм по партионному учету при проведении доков задним числом может быть можно и реализовать... - вполне возможно что это как раз будет похоже на идею РАУЗ...
.
просьба данные обсуждения/мысли не распространять направо/налево - все-таки это достаточно хорошее ноу/хау... и по крайне мере такого подхода к контролю остатков в заднем числе - нигде не озвучивалось... данный подход позволяет исключить расчет временных итогов при контроле остатков в заднем числе и заменить их получением остатков "по партиям" с отсечкой "ненужных" партий... т.е. на момент проведения дока выгружаем в ТЗ итоги по регистру (что на порядок быстрее расчета временных итогов) и отсекаем ненужные партии... получается очень быстро...
.
60. Александр Рытов (Арчибальд) 07.09.10 09:29
(58) Мне партии и остатки глубоко фиолетовы - не занимаюсь я торговлей. Чисто созерцательная позиция, как в кино - ага, вот здесь хорошо сделано, а вот тут - не очень. А там вон задумали как лучше, а получилось как всегда...
61. Игорь Исхаков (Ish_2) 08.09.10 08:30
(59) Принимается. Как ЧАСТНЫЙ случай учета по количеству ГТД.
Такой контроль , как я понял, нужен и для прих. накладных.
В накладной нельзя уменьшить приход , если это приведет в последующем к отрицат. остаткам. Так ?
Теперь общий случай. Проконтролировали - разрешили проводить - и что ?
Что делать с последующими документами ? Потом перепроводить по последовательности ?
Или при проведении текущего документа корректировать только движения последующих документов по регистру партий (в 8-ке это можно )?

Цитата :
"А вот с суммовым учетом - тут в 7.7. сложнее - я не могу корректировать суммы проведенные по регистрам другими доков"
Постой , а что в 7-ке с количественным учетом проще ? и можно корректировать ресурс "Количество" у других проведенных документов ?
62. Сергей (Che) Коцюра (CheBurator) 08.09.10 10:36
(61) это действует не как частный случай учета по количеству ГТД, это, по идее, работает в общем случае КОЛИЧЕСТВЕННОГО учета. Т.е. если ставить "акдаемическую" задачу беспроблемного поведения/контроля количественных остатков при работе та/задним числом, то ясно, что в последующих документах ничего делать не надо. Перепроведение последовательности остается, но чисто как 1.технологическая процедура 2.последовательность будет стопроцентно проводимой (затыка не будет) 3.и служит только для технологического закрытия регистров.
.
Речь о том, что имея в момент времени две партии остатков, может получиться что по первой партии =10, по второй =-2, итого = 8 - и это правильное количество. восстановление нужно только для технологического закрытия вот ситуации (10-2) котрое после восстановления будет =одна партия на 8 шт. в принципе последовательность можно и не восстанавливать вообще, но тогда будет туговато при открытии периодов.
.
по суммам - тут у меня решения нет пока...
63. Игорь Исхаков (Ish_2) 08.09.10 17:24
(62) Согласен. Для задачи контроля отрицательных остатков предложенный алгоритм является общим (при напоминании Арчиабльда и при условии контроля и приходных накладных).
Обычное перепроведение (для расчета сумм) тем не менее необходимо.
64. Сергей (Che) Коцюра (CheBurator) 08.09.10 18:01
(63) приходные накладные если они введены задним числом - хуже не сделают. если изменены задним числом (точно также как и расходные и возвраты и все прочее) - контроль один и тот же - если итоги на ТА (с учетом положения на оси времени исправляемого дока см.примечание ниже) - суммарно по всем партиям положительные - то значит ОК. если суммарно по всем партиям отрицательые - то бяка.
.
прим*: на Так анализируются только те партии, которые имеют смысл. т.е. для расходных накладных анализируются СУММА по партиям, которые были образованы до этого расходника... все...
65. Сергей (Che) Коцюра (CheBurator) 08.09.10 18:02
сейчас буду перетачивать фармацию кардинально - буду заодно весь партионный учет на этом строить - там даже проще, так как автосписания партий нет...
66. Артем Ватан (v.a.ryag) 08.09.11 12:56
67. IR IR (Artemuch2) 23.09.11 12:57
Если изменять типовую конфигурацию отключив проверку на оперативное проведение, все равно останется проблема когда при вводе документов задним числом эти остатки уже списаны в будущем. К сожалению проводить только оперативно документы в нашей действительности нереально. Поэтому самым лучшим вариантом на мой взгляд будет регламентно запускаемая обработка, которая проверяет остатки и еще сравнивает их с остатками по партиям. Тогда можно быть уверенным, более менее, что и остатки верные и себестоимость правильная
68. Андрей Литвинов (andreylitvinov) 17.10.11 20:07
идея хорошая, но мало применимая.
69. Вадим (Vadim37) 16.11.11 14:56
При групповом создании документов реализации ну хотя бы штук 500-600 такую вещь в топку. Но! Вот когда какой косяк операторов-менеджеров найти - идея нравиться. Поковыряю код.
70. Oksana Lebedeva (taelita) 21.11.11 16:33
хорошая обработка) помогла)
правда немного переписала под нашу базу
72. margo2007 (margo2007) 13.12.11 20:10
Доработка конфигурации под конкретные нужды.... - это очень удобно при почасовой оплате.
73. Алексей Антонюк (Bozhevilnoe) 31.01.12 22:21
Идея хорошая, но не рациональное исполнение. Короче не очень удобно.
74. Nikolay (Nikolay) 29.02.12 09:28
(31) anig99, факт! Контроль отрицательных остатков ведётся с использованием отчёта "Ведомость по учёту МПЗ" (используется РАУЗ). Особых проблем нет.
75. Андрей Николаев (Andruykha) 26.07.12 06:19
Спасибо 1С!, что в программах не все полностью автоматизировано, спасибо что не все так идеально. Спасибо что код понятный. Спасибо, что вы есть! Именно это нам и дает работу, деньги и смысл в этой работе.
И спасибо пользователям, что ленятся думать, а то и совсем не думают, каждый раз нас вспоминают.
76. Юрий Зайцев (Yury1001) 03.08.12 15:23
Напомнило как в 10.3 дорабатывал контроль остатка текущего момента при не оперативном проведении. Конечно это не спасает если приход был позже, но помогает избежать грубых ошибок. А на 7.7 сто раз уже так делал. Идея вполне рабочая.
77. Артем Ватан (v.a.ryag) 11.09.12 13:16
78. Дмитрий Луканов (TheGrr) 28.05.13 20:10
Спасибо за обработку. В плане концепции все классно. На продакшене в подписке на событие повесил ее на требуемые регистры. Добавил возможность игнора измерений, немного изменил вывод лога (все ж после массовых перепроведений документов легче все в одном месте видеть). Теперь хитропопые юзвери плачут.
79. Vlad (KillHunter) 28.05.13 20:26
Неплохая обработочка, и идейка хорошая, но всегда есть минусы:
согласен с мнением одного из коллег:
а)Неоперативное проведение не может помочь проконтролировать правильность ввода документа, потому что ошибка может быть (а чаще всего и есть) в другом документе, а не в том, на проведении которого остаток ушел "в минус" .
б)Для того, чтобы определить, что в какой-то момент остатки товаров вышли "в минус" совсем не обязательно перепроводить все документы с контролем остатков. Достаточно построить отчет (оборотную ведомость).
в) Не целесообразно останавливать работу оператора по вводу документов отказом от проведения документа, если ошибка отнюдь не в этом документе. Оператор, скорей всего, все равно не сможет найти ошибочный документ.

И еще: конечно, для правильного учета надо стремиться вводить документы оперативно. Например, если накладные от поставщика придут только в конце месяца, то при реальном поступлении товара рекомендуется оформить приходный ордер.
80. serge_focus (serge_focus) 12.07.13 20:49
Спасибо за обработку! Немного модифицировал для своих нужд- работает супер.
(23) - Это точно :). Порой такого наменяют - диву даешся. А потом при обновлннии лупят с бухгалтеров и директоров...
81. Z Lu (validat) 04.10.13 23:13
Если кому нужнен контроль отрицательных остатков, а также запрет проведения (при неоперативном проведении, и оперативном тоже), по складам и партиям. Опробовал на рабочей, доволен. Подсистема "Контроль отрицательных остатков" http://infostart.ru/public/182325/. Поянение методики для подключения есть, спрашивайте.
82. Z Lu (validat) 04.10.13 23:38
Автору спасибо. Хорошая обработка, необычный подход, важный момент, контролирует остатки всех последующих периодов,
попробую в работе, тогда отпишусь по конкретным достоинствам в рабочем процессе. В настоящее времи для запрета отрицательных остатков пользуюсь обработкой ( Подсистема "Контроль отрицательных остатков").
83. Sabfir Sabfir (Sabfir) 05.12.13 12:47
Спасибо большое за подсистему. Очень полезная вещь. Интегрирую, проверю, отпишусь.
84. Sabfir Sabfir (Sabfir) 05.12.13 15:02
К сожалению не всегда работает подсистема, так как ен учитывает свойство документа "Удаление двиежний".
В КА, чтобы поправить это дело проще всего дописать одну строчку кода, см. картинку во вложении.
Это увеличит время проведения документа, но зато функционал заработает корректно.
Прикрепленные файлы:
85. Петр Лунегов (pvlunegov) 10.07.15 07:19
Спасибо за обработку, хорошая вещь.
Эту вещь положу в свой золотой фонд.
Маст би фарева! Ну до тех пор, пока не усовершенствуют, конечно.

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

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