Пришлось столкнуться с проблемой реализации Заявок и Резервов.
Что-то как-то сложненько.... Может кто знает? ... - как грамотно эту тему реализовать в ТиС ???? Плис...
Я знаю.
Что именно интересует?
Полазай по порталу (у меня в профиле в программиах и статьях, еще в других авторах) - полезные вещи есть.
иденис Денин правильно говорит? начинать надо со "схемы проджаи", т.е. "формализовать" последовательность ваших типовых процессов продаж.
Например заявка и резерв:
1 Клиент заказал товар, его не хватило, он готов подождать вот тебе и отгрузка и отрицательный резерв для последующей закупки товара и для анализа (если разрешить отрицательные остатки)
2 За резервами надо следить, времена не те, причем клиенту или менеджеру я просто говорю "НЕТ" это продавать не будеш и снимаю резервы, спорить он не будет, так же и цены на хороший товар поднимаю не стесняясь, если клиент отказался, :-) не проблема завтра купит, но дороже.
3 Для розницы назовем онлайн резерв, по нему вычислиш свободный товар остатки-резерв, либо работа по каким то остаткам, но на момент подбора товара и закрытия чека желательно товар резервировать
4 Вариант работа виртуального склада товара нет вообще время доставки 1-2 дня, время доставки от поставщика 1 день, соответственно все заявки дефектурные, обрабатываются закупками
Виды резервов - как придумаеш, но главное не надо усложнять схему
В целом как показывает практика все сложности отражаются на работе сотрудников с низким уровнем оплаты труда.
Все должно быть просто :-)
Все дело в том, что в Типовой ТиС - нет полной реализации данной проблемы.
Денис, Стратегия Заявок и Резервов разработана нами как для стандартных операций оптовой торговли (то есть ничего сверх-естественного).
Просто хотелось реализовать без изменения конфы (дабы не заморачиваться при обновлении).
Сергей, обязательно посмотрю твои разработки (по-моему, Монитор Заявок - называется..., если мне память не изменяет)
ValentinV, очень надо, поищи, пожалуйста!
das пишет:
Все дело в том, что в Типовой ТиС - нет полной реализации данной проблемы.
ничего не понял - какая ИМЕННО проблема обсуждается?
Стратегия Заявок и Резервов разработана нами как для стандартных операций оптовой торговли (то есть ничего сверх-естественного). Просто хотелось реализовать без изменения конфы (дабы не заморачиваться при обновлении).
- что именно реализовано? чем принципиально отличается от штатной схемы?
...
так ничего и не понял... что надо автору.
штатная тисовская система кажется "замороченной", но при работе "по регламенту" - все выходит на раз! причем разные схемы... мелкие "нестыковки" правятся пару строчками кода.
..
просьба автору стучаться в личку если что
ПОдскажите пожалуйста, у кого нибудь реализована такая система, чтобы резерв снимался в 1С автоматически, например через 5 дней? так как у нас например 5 дней не может лежать резерв, а каждый раз искать человека который его поставил проблематично, а тут еще и отгрузка.... а вот если бы автоматически снимался.... ??
(8) если бы вы почитали комменты этой темы и не поленились полазить у меня в профиле то вопрос решился бы практически мгновенно:
.
http://www.infostart.ru/public/20827/ 1C v.7.7 Готовое решение. Не требует настройки. Не требует допрограммирования. Обработка предназначена для автоснятия просроченных заявок(резервов) покупателей. Скачать и использовать можно даром, то есь безвозмездно. (но цена все-таки пристутвует = 1000 р, кушать хочется)
.
Обработка вызывается автоматически при старте 1С первый раз в день (под любым пользователем).
Определяются просроченные заявки покупателей и производится их "закрытие" документом "Отмена заявок покупателей" (снимаются все резервы!). Для каждой фирмы (нашей, по которой ведем учет!) формируется отдельный документ снятия заявок.
Задержка первого старта 1С (в текущем дне), связанная с выполнением регламентных действий по автоснятию просроченных заявок, - незначительная. При особо больших потоках заявок и большом количестве строк в них задержка первого старта 1С может составить 15-20 секунд.
Просроченными считаются следующие заявки (в порядке убывания приоритета перечисленных ниже условий):
если текущая дата больше даты отгрузки (штатная работа всегда гарантирует заполнение поля "дата отгрузки");
если просрочена дата оплаты для предоплатных заявок; если дата оплаты просрочена, но оплата присутствует - такая заявка остается активной; заявки с незаполненным полем даты оплаты считаются "бессрочными" и остаются активными.
Обработка производящая поиск просроченных резерв пишется быстро. Можно для неё добавить функцию автоматического удаления Заявки покупателя. Но сложность в том, что резервы могут существовать по причине неполноты отгрузки!
Часто бывает вопрос и с реальными резервами которые не надо снимать!
Мы в УпрТорг 10ю2 модификации подверли Реализацию (снимается весь резерв заказа) и доработанный документ закрытия заказов (заполняется просроченными).
Разумеется это планируемая дата. Заказ могут не собрать и/или не доставить покупателю по разным причинам.
В случае недоставки, у нас ставят отметку в МаршЛисте, что развоз закончен итогда все недоставленные (без отметки доставки) заказы - для них распроводят Реализации.