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

30.06.09

Задачи пользователя - Адаптация типовых решений

Решение проблемы которой не должно быть. Не должно быть, конечно же, проблемы... А она есть! Причем, имхо, проблема эта похожа на наглого суслика - вылазит в самый неподходящий момент. Поэтому - берем дуст и травим сусликов беспощадно...

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

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

ставим такую конструкцию:

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

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

+12 –

См. также

Улучшенная обработка "Внешние печатные формы" для типовых конфигураций на базе 1С 7.7

Печатные формы Адаптация типовых решений Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Приятное улучшение обработки "Внешние печатные формы" для типовых конфигураций на базе 1С 7.7 для более комфортной работы с "любимой семерочкой".

1 стартмани

04.02.2022 3316 1 igor7777 0

Расчет страховых взносов в 1С 7.7 "Учет и отчетность предпринимателя, ред. 1.2" с апреля 2020

Адаптация типовых решений Программист Платформа 1С v7.7 Конфигурации 1cv7 Россия Бухгалтерский учет ФОМС, ЕФС Бесплатно (free)

В этой статье описано, какие небольшие изменения можно внести в модуль документа Начисление налогов с ФОТ, чтобы правильно рассчитывались страховые взносы с 1 апреля 2020 г.

09.04.2020 20504 Юджин58 39

Дистрибьюция 7.7. Часть 1. Жизненный цикл заявки покупателя. Одна заявка покупателя, много адресов доставки.

Адаптация типовых решений Программист Платформа 1С v7.7 1С:Комплексная 7.7 1С:Торговля и склад 7.7 Управленческий учет Бесплатно (free)

Описан способ работы с учетом расписания с приоритетными покупателями - торговыми сетями (основными покупателями) в торговой или комплексной учетной системе на 1С 7.7. Множественная заявка покупателя на несколько торговых точек.

14.10.2019 6265 ksnik 14

Раздел 9 декларации по НДС за 1 квартал 2019

Адаптация типовых решений Оптовая торговля Производство готовой продукции (работ, услуг) Программист Бухгалтерский учет 7.7 1С:Комплексная 7.7 Россия Бухгалтерский учет Налоговый учет НДС Бесплатно (free)

Ошибка при формировании Раздела 9 декларации по НДС в 1С к.к. 7.70.577.

12.04.2019 8367 eroma 12

Как в торговле 7.7 печатать код ТНВЭД в счет-фактуре

Операции по ВЭД Адаптация типовых решений Программист Оперативный учет 7.7 1С:Торговля и склад 7.7 Россия Бухгалтерский учет НДС Бесплатно (free)

В данной статье хотел поделиться опытом, как в Торговле 7.7 ( релиз 994) сделать возможность выводить код ТНВЭД в печатную форму счета-фактуры. Сразу скажу, что нужно это только тем, кто осуществляет экспорт в страны таможенного союза. Остальные могут не волноваться.

15.11.2017 11998 AndKovalchuk 0

Доначисление страховых взносов на обязательное страхование от НС и ПЗ в Бухгалтерии 7.7 и УСН 7.7 для Договора подряда

Зарплата Адаптация типовых решений Программист Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 1С:Упрощенное налогообложение 7.7 Россия Бухгалтерский учет ФОМС, ЕФС Бесплатно (free)

Во всех источниках, которые мне встречались, написано, что Страховые взносы НС и ПФ нужно начислять, если это указано в Договоре подряда.

06.09.2017 11105 pentanom 0

Пилотный проект ФСС. Заявление, реестр, опись, выгрузка в формате xml версия 1.7.2.

Работа с интерфейсом Зарплата Адаптация типовых решений Программист Бухгалтер Расчет 7.7 1С:Зарплата и кадры 7.7 Россия ФОМС, ЕФС Абонемент ($m)

Типовые объекты конфигурации не изменены, поэтому подходит для любого релиза ЗиК.

1 стартмани

29.07.2016 16930 21 Cvetic 1

Предельные базы взносов в ПФР, ФСС, ФФОМС 2015 в 1С: Бухгалтерия 7.7

Зарплата Адаптация типовых решений Программист Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 Россия Бухгалтерский учет Абонемент ($m)

Реализация Постановления Правительства РФ 1316 от 04.12.14 для типовой конфигурации "Бухгалтерский учет 7.7" рел. 7.70.590

1 стартмани

31.12.2014 24026 9 Sergey1CSpb 2

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. sashulyT 201 14.11.07 07:54 Сейчас в теме

А что такое ZLOPUN?

2. CheBurator 2696 14.11.07 08:04 Сейчас в теме

Антоним Dobrop

3. vasilykushnir 63 14.11.07 08:46 Сейчас в теме

>в любом случае будут писать 10000 шт. на снятие резерва...

А зачем им давать такую возможность? Я прошу указать только период, в котором будут закрыватся резервы по заказам - а дальше работаю с конкретными доками и ессссно с конкретным количеством - юзер вообще нифига не видит, но уверен, что все будет ОК.

4. CheBurator 2696 14.11.07 08:55 Сейчас в теме

Речь идет о том, что давая слабину в списании резервов (показывая в документе ВЕРХНЮЮ планку снимаемого резерва) - эту слабину имеет только "админ"...

5. vasilykushnir 63 14.11.07 09:10 Сейчас в теме

(4) Тогда другое дело.
Тем не менее +1 за идею.

6. пользователь 14.11.07 11:37

Сообщение было скрыто модератором.

...

7. CheBurator 2696 14.11.07 11:59 Сейчас в теме

Ха! У меня в загашнике есть еще одна заточка - вот это будет всем заточкам заточка...
Вот еще вам для раздумий: кто-нибудь снятие резервов при возврате поставщику подправлял...?

8. vasilykushnir 63 14.11.07 12:04 Сейчас в теме

(7) Идею понял. Класс! Надо будет у себя забацать. Не допер - старею...

9. CheBurator 2696 14.11.07 12:43 Сейчас в теме

ЕСТЕСТВЕННО, В СТАТЬЕ ЕСТЬ МАЛЕНЬКАЯ ЗАСАДА -при таком рецепте данные в документе (колво снимаемого резерва) будут отличаться от данных в "учете".. ясен пень - кто любит строить отчеты по документам - тут может какие-нибудь грабли нащупать... если танцевать от регистров - все ок... тем более что навороченных отчетов по резервам-то и не встречал... потому как несущественное это дело...

10. alexdum12 15.11.07 09:06 Сейчас в теме

-1, ппц, действительно академики... хотел бы я на вас посмотреть, когда вы будете объяснять руководству почему это в документе одно количество, а в отчете другое.

11. CheBurator 2696 15.11.07 12:21 Сейчас в теме

Я, например, еще больше тащусь с академиков, которые мнят себя академиками. Я хочу на тебя посмотреть как ты предъявишь руководству нематериальную вещь "20 штук снятия с резерва" в принципе. Руководству я буду предъявлять отчеты, а не документы это раз. И, во-вторых, на сегодня 100 штук на складе числится по базе? В наличии 100 штук? если да - в чем проблемы?
И, я еще больше за тебя порадуюсь, когда необходимо будет перепровести документ - а он не проводится с сообщением "слишком много..." и вы измените количество для того чтоб документ провелся или, не дай бог, вообще его удалите - вот тут-то от руководства влетит по самое нехочу - есть документ бумажная копия, в ней - 100 штук, а в базе - 80. Кто виноват...?

Конечно, ПО БОЛЬШОМУ СЧЕТУ, надо добиваться соответсвия цифр в доках цифрам в отчетах. Но если по ряду причин такого соответствия нет и эти несоответствия не являются критичными для ведения упр/бух учета - не надо догматить бабушку.. ;-)

12. Al-X 15.11.07 13:37 Сейчас в теме

Интересная идейка. +1
Но, к сожелению, у меня с резервами другая проблема: в заявке на склад резерв стоит по одному складу. потом туп. менеджеры делают на основании ее реализацию, причем меняют склад на другой, и проводять. Ясно что потом в отчете по резервам при выборке по складам на одном будет +1, а на другом -1.

13. CheBurator 2696 15.11.07 16:25 Сейчас в теме

(12) если разговор идет о штатной ТиС, то так не будет. Туп.менеджер проводя реализацию - продает имеющийся в свобоном наличии товар на складе 2 (и списывает резерв по этому же 2 складу) резерв по второму складу в минус уйти не может в результате реализации. Просто на 1 складе останется висеть резерв и все. Для его снятия/контроля надо юхать отчет о резервах или чуть более удобный монитор резервов: http://infostart.ru/profile/174/projects/596/

16. CheBurator 2696 19.11.07 11:01 Сейчас в теме

(13) а не могли бы вы раскрыть, что с вашей точки зрения является "фигней" в сабже?

17. Mikeware 9 19.11.07 18:17 Сейчас в теме

(16) Сама постановка задачи. Ибо нефиг снимать чужие резервы, да и снятие своих "другим складом" делается либо одной строчкой (заменяется склад документа на склад докоснования), либо опять же нефиг...
А вообще, "разруха - в головах..."©

18. CheBurator 2696 19.11.07 18:31 Сейчас в теме

(16) Готов содержательно обсудить данный вопрос.
1. Чужие резервы не снимаются, снимаются "свои" резервы
2. Больше чем указано - не снимется.
- где криминал?
Что делать если вот так вот случилось, что при восстановлении ГП (да, иногда такое случается...) Документ "Снятие резерва" не проводится... с выдачей соотв.сообщения о слишом большом снимаемом резерве?
..
"снятие своих "другим складом" - вообще не понял, про что речь - поясните плиз... интересно...

14. Mikeware 9 19.11.07 07:41 Сейчас в теме

Фигня какя-то. Не ожидал от уважаемого чекловека такой глупости.

15. alexqc 150 19.11.07 10:27 Сейчас в теме

А у нас проблема решается проще - в доке-снятии указывается не снимаемое к-во, а ОСТАВЛЯЕМОЕ. Ставим 10 - на резерве останется 10. Если реально меньше - ну чтож, значит скока стока останется. Если ничего не ставим (0) - значит весь резерв уйдет.

19. Lesovik 19.11.07 21:20 Сейчас в теме

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

20. CheBurator 2696 19.11.07 21:39 Сейчас в теме

(19) Решение, описанное выше, предназначено в основном для предотвращения тормозов/затыков при массовом перепроведении документов.
Понятно, что в результате восстановления ГП итоговая "раскладка" резервов может вообще принципиально отличаться от той, которую видели менеджеры при "оперативной" работе (особенно если используются "Заявки на поставку"). Вопрос: при таком окончательном "раскладе" принципиальна та небольшая "бяка", которая получается в результате работы сабжа? имхо - нет... Понятно, что надо свести работу менеджеров только к режиму "только в ТА" или обеспечивать неизменность резервов (+сюда же в этом случае неизменность очередей заявок и очередей заявок под поставки) другими методами - а это уже совсем не одна строчка как в сабже... И как такую проблему (неизменность итогов/раскладки учета "по заявкам" обеспечить при работе задним числом при массовом перепроведении доков - это выливается в ГЛОБАЛЬНУЮ проблему...

21. Lesovik 20.11.07 17:27 Сейчас в теме

Это не выливается в глобальную проблему если использовать не типовое восстановление последовательности, а самописное... С возможностью распроведения документов, ограничением по времени работы и работе в немонопольном режиме.

22. CheBurator 2696 20.11.07 17:56 Сейчас в теме

(21) Согласен, но в моем случае, имхо, написание такого самописного восстановления абсолютно не оправдано ни по затраченному времени, ни по получаемому результату... Быстрее восстановится штатной ГП (тем более что такая необходимость возникает редко и не сильно далеко взад).

23. Lesovik 21.11.07 12:34 Сейчас в теме

Я под 7ку совершенно не чураюсь использовать чужие разработки, оптимизируя их под себя...
Время платформы уже ушло, так что писать под нее с нуля, ихмо, не актуально:))
Все что я описал валяется в сети, в том числе и на этом портале, хотя кусками:)

24. CheBurator 2696 21.11.07 12:43 Сейчас в теме

Самописные - как правило - "узкоспециализированные", и встраивать их в "свою" конфигу - может оказаться затратно. Поэтому в ДАННОМ случае используется штатная универсальная ГП..

25. konfed 07.12.07 10:27 Сейчас в теме

я вообще запретил пользоваться документом снятие резервов - пусть менеджер сам отслеживает какой -товар оставлять в резерве, какой нет - и соответственно оставить счет-фактуру проведенной или снять проводки