gifts2017

[ОБУЧАЛОВКА] ZLOPUN или как меня достали неснимающиеся резервы...

Опубликовал Сергей (Che) Коцюра (CheBurator) в раздел Программирование - Практика программирования

Решение проблемы которой не должно быть. Не должно быть, конечно же, проблемы... А она есть! Причем, имхо, проблема эта похожа на наглого суслика - вылазит в самый неподходящий момент. Поэтому - берем дуст и травим сусликов беспощадно...
В штатной ТиС есть неплохой документ "Снятие резерва", предназначенный для "закрытия" подвисших резервов. Этим документом частенько любят пользоваться манагеры, когда опиеративненько надо что-нибудь слямзить у соседа-менеджера и выгодно толкнуть (также этот документ подойдет для закрытия просроченных резервов и т.д.). Все хорошо. Плохо только одно. При восстановлении ГП на данные документы система частенько ругается (при барадке в ЗПС) типа так: "Количество снимаемого товара СУПЕР-ПУПЕР-ТОВРА превышает резерв...". Ну превышает и превышает - тебе то что? Сказано снять 100 штук - сними 100 штук! Не удалось снять 100 штук? Снимай сколько удается!
Короче: задрали меня эти сообщения... Оперативно полечил это так:
Вместо исходного кода типа
			СводныйРезерв =  ВремРезервы.СводныйОстаток(Фирма,Номенклатура,Склад,Договор,,"Количество");
Если СводныйРезерв < КоличествоБазовое Тогда
глНеПроводить(Контекст,"Количество снимаемого товара (" + Строка(Номенклатура) + ") превышает резерв по данному договору (" 
+ Строка(Договор.Владелец) + "; " + Строка(Договор) + ").");
				СтатусВозврата(0);
				ВОЗВРАТ;
КонецЕсли;

ставим такую конструкцию:
			СводныйРезерв =  ВремРезервы.СводныйОстаток(Фирма,Номенклатура,Склад,Договор,,"Количество");
Если СводныйРезерв < КоличествоБазовое Тогда
глСообщениеПроведения("Количество снимаемого товара (" + Строка(Номенклатура) + ") превышает резерв по данному договору (" 
+ Строка(Договор.Владелец) + "; " + Строка(Договор) + ").",ТекущийДокумент(),,,1);
				КоличествоБазовое = СводныйРезерв;
КонецЕсли;    

И все! Золотой ключик у нас в кармане! Теперь, при массовом перепроведении документов (восстановлении ГП и пр.) система не будет спотыкаться на каждом "лишнем" снятии резерва.
В развитие приведенной выше схемы возможно имеет смысл предусмотреть две ветки поведения алгоритма: штатный алгоритм отрабатывает при ТЕКУЩЕМ ПРОВЕДЕНИИ документа, а наш вариант - при неоперативных перепроведениях. Для чего? Чтобы манагеры не расслаблялись, а снимали документом "снятие резерва" при оперативной работе именно необходимое им количестов, а то манагеры есть зверьки хитрые и ленивые - считать не будут - в любом случае будут писать 10000 шт. на снятие резерва...

См. также

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

Комментарии

1. Александр (sashulyT) 14.11.07 07:54
2. Сhe Burashka (CheBurator) 14.11.07 08:04
3. VasilyKushnir (vasilykushnir) 14.11.07 08:46
>в любом случае будут писать 10000 шт. на снятие резерва...

А зачем им давать такую возможность? Я прошу указать только период, в котором будут закрыватся резервы по заказам - а дальше работаю с конкретными доками и ессссно с конкретным количеством - юзер вообще нифига не видит, но уверен, что все будет ОК.
4. Сhe Burashka (CheBurator) 14.11.07 08:55
Речь идет о том, что давая слабину в списании резервов (показывая в документе ВЕРХНЮЮ планку снимаемого резерва) - эту слабину имеет только "админ"...
5. VasilyKushnir (vasilykushnir) 14.11.07 09:10
(4) Тогда другое дело.
Тем не менее +1 за идею.
7. Сhe Burashka (CheBurator) 14.11.07 11:59
Ха! У меня в загашнике есть еще одна заточка - вот это будет всем заточкам заточка...
Вот еще вам для раздумий: кто-нибудь снятие резервов при возврате поставщику подправлял...?
8. VasilyKushnir (vasilykushnir) 14.11.07 12:04
(7) Идею понял. Класс! Надо будет у себя забацать. Не допер - старею...
9. Сhe Burashka (CheBurator) 14.11.07 12:43
ЕСТЕСТВЕННО, В СТАТЬЕ ЕСТЬ МАЛЕНЬКАЯ ЗАСАДА -при таком рецепте данные в документе (колво снимаемого резерва) будут отличаться от данных в "учете".. ясен пень - кто любит строить отчеты по документам - тут может какие-нибудь грабли нащупать... если танцевать от регистров - все ок... тем более что навороченных отчетов по резервам-то и не встречал... потому как несущественное это дело...
10. Алексей (alexdum12) 15.11.07 09:06
-1, ппц, действительно академики... хотел бы я на вас посмотреть, когда вы будете объяснять руководству почему это в документе одно количество, а в отчете другое.
11. Сhe Burashka (CheBurator) 15.11.07 12:21
Я, например, еще больше тащусь с академиков, которые мнят себя академиками. Я хочу на тебя посмотреть как ты предъявишь руководству нематериальную вещь "20 штук снятия с резерва" в принципе. Руководству я буду предъявлять отчеты, а не документы это раз. И, во-вторых, на сегодня 100 штук на складе числится по базе? В наличии 100 штук? если да - в чем проблемы?
И, я еще больше за тебя порадуюсь, когда необходимо будет перепровести документ - а он не проводится с сообщением "слишком много..." и вы измените количество для того чтоб документ провелся или, не дай бог, вообще его удалите - вот тут-то от руководства влетит по самое нехочу - есть документ бумажная копия, в ней - 100 штук, а в базе - 80. Кто виноват...?

Конечно, ПО БОЛЬШОМУ СЧЕТУ, надо добиваться соответсвия цифр в доках цифрам в отчетах. Но если по ряду причин такого соответствия нет и эти несоответствия не являются критичными для ведения упр/бух учета - не надо догматить бабушку.. ;-)
12. Алексей Опарихин (Al-X) 15.11.07 13:37
Интересная идейка. +1
Но, к сожелению, у меня с резервами другая проблема: в заявке на склад резерв стоит по одному складу. потом туп. менеджеры делают на основании ее реализацию, причем меняют склад на другой, и проводять. Ясно что потом в отчете по резервам при выборке по складам на одном будет +1, а на другом -1.
13. Сhe Burashka (CheBurator) 15.11.07 16:25
(12) если разговор идет о штатной ТиС, то так не будет. Туп.менеджер проводя реализацию - продает имеющийся в свобоном наличии товар на складе 2 (и списывает резерв по этому же 2 складу) резерв по второму складу в минус уйти не может в результате реализации. Просто на 1 складе останется висеть резерв и все. Для его снятия/контроля надо юхать отчет о резервах или чуть более удобный монитор резервов: http://infostart.ru/profile/174/projects/596/
14. Михаил (Mikeware) 19.11.07 07:41
Фигня какя-то. Не ожидал от уважаемого чекловека такой глупости.
15. AlexQC (alexqc) 19.11.07 10:27
А у нас проблема решается проще - в доке-снятии указывается не снимаемое к-во, а ОСТАВЛЯЕМОЕ. Ставим 10 - на резерве останется 10. Если реально меньше - ну чтож, значит скока стока останется. Если ничего не ставим (0) - значит весь резерв уйдет.
16. Сhe Burashka (CheBurator) 19.11.07 11:01
(13) а не могли бы вы раскрыть, что с вашей точки зрения является "фигней" в сабже?
17. Михаил (Mikeware) 19.11.07 18:17
(16) Сама постановка задачи. Ибо нефиг снимать чужие резервы, да и снятие своих "другим складом" делается либо одной строчкой (заменяется склад документа на склад докоснования), либо опять же нефиг...
А вообще, "разруха - в головах..."©
18. Сhe Burashka (CheBurator) 19.11.07 18:31
(16) Готов содержательно обсудить данный вопрос.
1. Чужие резервы не снимаются, снимаются "свои" резервы
2. Больше чем указано - не снимется.
- где криминал?
Что делать если вот так вот случилось, что при восстановлении ГП (да, иногда такое случается...) Документ "Снятие резерва" не проводится... с выдачей соотв.сообщения о слишом большом снимаемом резерве?
..
"снятие своих "другим складом" - вообще не понял, про что речь - поясните плиз... интересно...
19. Георгий (Lesovik) 19.11.07 21:20
Вопрос интерестный...
но решение слишком простое, для такой неприятной проблемы...
не универсальное, демагогию особо не разведешь, у всех давно все переписано под себя:)
20. Сhe Burashka (CheBurator) 19.11.07 21:39
(19) Решение, описанное выше, предназначено в основном для предотвращения тормозов/затыков при массовом перепроведении документов.
Понятно, что в результате восстановления ГП итоговая "раскладка" резервов может вообще принципиально отличаться от той, которую видели менеджеры при "оперативной" работе (особенно если используются "Заявки на поставку"). Вопрос: при таком окончательном "раскладе" принципиальна та небольшая "бяка", которая получается в результате работы сабжа? имхо - нет... Понятно, что надо свести работу менеджеров только к режиму "только в ТА" или обеспечивать неизменность резервов (+сюда же в этом случае неизменность очередей заявок и очередей заявок под поставки) другими методами - а это уже совсем не одна строчка как в сабже... И как такую проблему (неизменность итогов/раскладки учета "по заявкам" обеспечить при работе задним числом при массовом перепроведении доков - это выливается в ГЛОБАЛЬНУЮ проблему...
21. Георгий (Lesovik) 20.11.07 17:27
Это не выливается в глобальную проблему если использовать не типовое восстановление последовательности, а самописное... С возможностью распроведения документов, ограничением по времени работы и работе в немонопольном режиме.
22. Сhe Burashka (CheBurator) 20.11.07 17:56
(21) Согласен, но в моем случае, имхо, написание такого самописного восстановления абсолютно не оправдано ни по затраченному времени, ни по получаемому результату... Быстрее восстановится штатной ГП (тем более что такая необходимость возникает редко и не сильно далеко взад).
23. Георгий (Lesovik) 21.11.07 12:34
Я под 7ку совершенно не чураюсь использовать чужие разработки, оптимизируя их под себя...
Время платформы уже ушло, так что писать под нее с нуля, ихмо, не актуально:))
Все что я описал валяется в сети, в том числе и на этом портале, хотя кусками:)
24. Сhe Burashka (CheBurator) 21.11.07 12:43
Самописные - как правило - "узкоспециализированные", и встраивать их в "свою" конфигу - может оказаться затратно. Поэтому в ДАННОМ случае используется штатная универсальная ГП..
25. Konstantin _Konstantin (konfed) 07.12.07 10:27
я вообще запретил пользоваться документом снятие резервов - пусть менеджер сам отслеживает какой -товар оставлять в резерве, какой нет - и соответственно оставить счет-фактуру проведенной или снять проводки
26. Сhe Burashka (CheBurator) 07.12.07 11:44
(25) тут я не понял.. какое отношение счф имеет к резервам...
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа