контроль возврата оригиналов первичных документов #756493

необходимо организовать: контроль возврата/получения оригиналов первичных документов на базе текущей 1С. текущая 1С УПП 1.3 У кого есть какие соображения. П.С. Моя идея. 1. Завести регистр сведений под это дело в котором будет храниться состояние документа. 2. сделать журнал документов в котором как раз и переключать состояние документов. 3. потом соответственно отчетик по регистру сделать. Может уже есть каие решения?

Штатного решения нет Предлагаю РС и штрихкодирование документов с соответствующей приёмкой

в БП3 - РС

1. заведи свойство документа. 2. проставлять групповой обработкой 3. любой отчет по документам

ты рано за реализацию взялся. Бизнес процесс этого контроля где-то описан? Кто и что из числа пользователей должен делать, чтобы этот контроль осуществлялся?

я еще не начал. пока прощупываю что да как уже кто сделал. А где это прописано если не секрет? не пойдет. Еще вопрос: А как быть с входящими документами от поставщика? Погляжу.

Вот. Работает великолепно. Мало того, в случае изменений маршрута всё делается лёгким движением мышки.

РС с галками в реализации + отчет. пока хватает

так к чему ты пришел то в итоге так там и не сказал ))

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

а какая у вас конфигурация?

Если простой вариант то используя свойства объектов, задаешь свойства объектов типа булево и проставляешь истина Конда оригинал получен. Просмотр результатов через отчет продажи, закупки с использованием свойств.

мало! требуется более функционально, например Статус = "Оригинал получен ПРОБЛЕМА"    ПРОБЛЕМА="подпись лица, не имеющего право подписи"    ПРОБЛЕМА="дата подписи не соответсвует логике документа"    ПРОБЛЕМА="еще хрень какая-то" Статус = "Оригинал получен НОРМА"

это должно быть прописано в описании задачи

епт... Заведи реквизит в документе с типом справочник и справочник. Клепай там статусов хоть миллиард. Все в журнале сразу будет видно с отборами и так далее.

что делать с твоим реквизтом, если подпись без прав И дата кривая?

Маня, ты дятел. даже не дятел, а тукан. Нафейхоа мне визуализация, нужна максимальная автоматизация. . Анекдот от Марианны Контора, старый одинэсник учит молодого: - пользователи делятся на два класса - дятлы и туканы; дятел он все ходит к тебе и долбит.. долбит.. долбитт - а тукан? - а тукан - это тот же дятел, только клюв у него мощнее и входит глубже

лови почту

автоматизация ведения факта получения оригинала документа от клиента. жесть. не неси...

как раз тут визуализация - главная постановка задачи. Бух выгребает доки и судорожно звонить клиентам - пришли мля мне мои документы.

а прав...

статуса достаточно одного - "проблема". А список проблем -  в комментариях к документу.

Важен баланс автоматики и ручного ввода, потому в и был задан вопрос про бизнес процесс (кто, как, когда и при каких условиях выставляет статус). Например, отправка по эл.почте идёт из 1С, соответственно можно документу автоматически выставить статус "Отправлено по эл.почте", но сразу возникает вопрос "Что отправлено?" скан оригинала или просто печатная копия, это уже 2 поля "Статус" (автоматический) и "пояснения" (руками пользователь). Мало того, часть Статусов может выставляться руками. Начинай не с вопроса "Как реализовать?", а с вопроса "Как должно быть?" - т.е. бизнес процесса присвоения статусов иначе будешь переделывать и не один раз. Возможно и достаточно, без полного описания хотелки бухов(начальства) сложно что-то сказать.

22+ Начинается всё безобидно "Нужно одно поле статуса", а заканчивается целой гроздью связанных в различных вариантах нескольких полей статусов и требовании систематизировать сие безобразие.

.3 математически - достаточно одного статуса "проблема", и набора квалификаторов  проблем. поэтому сначала разрабатывается бизнес-процессом, а уэ потом он автоматизируется.

Не несите бред. Я сказал заведи справочник и заведи там статусы. Не более 10. Больше 10 уже никто шарить не будет чо ставить. Самое оптимальное вообще не более 5.

В журнале сделать кнопки и поле для изменения статусов не заходя в документ и не перепроводя его. Вот и все.

Все остальное - вагон каки х то проблем писать - все бред. делать регистр - еще хуже. лепить какие то извращения - отчеты рисовать - еще хуже некуда.

маня, ты феерический тукан...

сам ты дятел.

Из мухи слона развить только дятлы могут.

статусы пилить - гиблое дело надо РС (или доп реквизиты) + штрихкодирование доков + сканер результат в отчет

да тут тукан ты) нафига проблема, если есть "квалификатор"  проблемы?

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

Дебиллушко, проблем может быть больше одной. А замечания могут быть проблемными и не проблемными.

Дебиллушко, то есть описание проблемы для тебя не признак проблемы?))))

"математически - достаточно одного статуса "проблема", и набора квалификаторов  проблем. " "А замечания могут быть проблемными и не проблемными." То есть статус проблема и непроблемное замечание?)))

А шо, птиц наш гордый, где-то описана проблема? И даже сумма ожидаемая?

если надеяться на бухов - мы бы все еще со счетами сидели и километровые простыни крыжили. А сейчас они даже не представляют что именно надо крыжить в случае крайней необходимости.. а вы "пусть они..." - самим не смешно...?

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

вообще то он и предлагает сделать статус проблема и к нему "квалификатор" с описанием проблем. Вопрос зачем ему статус и описание, если можно сразу лепить описание. Сумма ожидаемая чего?

все неправильно.

снова демонстрируешь тупость? Это лишнее, с первого раза уже понятно...

насчет статусов согласен - в районе 5 - у меня в принципе так и получается..., а вот "допквалификатор" и нужен по возможности для автоконтроля и прохождения исправления документа

ты свой ум уже продемонстрировал)

я согласен. но простые решения рулят при адекватном персонале. а народ просто "тупит", ну не привык он классифицировать и решать задачи по устранению проблем самостоятельно - это же надо целую цепочку одно-за одним выстроить...

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

Короче, "скучно с вами, уродами".. ;-) я пошел домой...

УПП

У меня при приёме документов возникает вопрос: "Док корректен?" Если да, то ничего не нужно, а если нет обязательно заполнение комментария. Отбор в списке задач по документу показывает и список всех комментариев. Бред. Если , то по технологии франча: написал, показал заказчику, а там трава не расти. Это уже годный вариант. Если не нужна история изменения статусов.

конфигуратор/документ/данные/характеристики

Плохо. Нужно открывать документ и изменять в нём поля. Интересно, документ перепроводится или нет? У формы модифицированность точно в ИСТИНА устанавливается.

документ перезаписывать не надо, запись в РС интерактивно про установке/снятии галки. А в документе бухам легче, его надо им открыть,посмотреть.

+ модифицированость не ставиться

реализовано уже в УПП, мною, еще в 2012 году. Через свойства документов все прекрасно видно. В свойства как раз и проставляются фактические даты получения копий/оригиналов с выводом соответствующего управленческого отчета, в котором рассчитывается туева куча различных показателей.

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

объясните зачем статус проблема? Документы или есть и с нём все хорошо, или с ним проблема (его нет, нет печати и т.д.) Какая разница, что он есть если он не оформлен корректно (нет печати, нет исправления?)

есть документом проблема - у него только один статус ЕГО НЕТ

+1 так же делали. Работало всё отлично.

неправильным можно только подтерется - несмотря на любую проблему в нем.

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

Все зависит от цели Если цель которая озвучена ТС, т.е. "контроль возврата оригиналов первичных документов" то какая разница где находиться документ у водителя в машине или у менеджера в ящике? Конечная наша цель знать, есть ли подписанный документ с которым можно пойти в суд, или его нет (он не подписан, подписан, но нет печати и т.п.). Для этого достаточно 2 статуса - есть/нет Если цель контролировать прохождения документа, т.е. месяц назад документы отдали менеджеру на подпись, а он до сих пор не вернул их или отдали водителю нужно проконтролировать возвращения при возврате водителя с рейса, тогда нужен огород со статусами, типа вернулся но не подписан

Я тоже пока смотрел на это со стороны думал про 1001 статус, но в конечном итоги когда лично начал щупать это дело, то понял что для целей контроля наличия подписанных первичных документов достаточно булева. Мне проще отобрать раз в месяц список отсутствующих документов послать на печать и раздать менеджерам на подпись, а всякие статусы, "отдали менеджеру ждем возвращения" для целей контроля наличия подписанных документов и нафиг не нужно

по-хорошему, нужно организовывать наиболее полное решение. ибо объем предварительной подготовительной работы примерно одинаков. Ну а полное решение можно использовать лишь частично. А вот наеборот - не получится... у меня такая система работает с 2008 года. Сначала воспринималась в штыки как "слишком сложная", после нескольких "разборок", в кончном итоге съэкономивших компании немало денег, была принята официально, и все работало по ней. Да, статусы и бизнес-процессы были для _всех_ документов. включая в т.ч. "входящие"

Полный, не полный... Какая разница, сколько элементов в перечислении? )))

некоторые предлагают "булево перечисление" :-)

Ну, тут уж я не психопаталогоанатом, я не могу ставить диагноз...

Можно подробнее. Например добавил свойство для документов "Оригинал" и два значения свойства "Получен" "Не получен" получается теперь для каждого документа который я планирую контролировать нужно заполнить это свойство. А как вы его проставляете для документов? Поделитесь механизмом? Чтобы мне не изобретать велосипед

вот у меня простая обработина для УТ 11

Спасибо сейчас гляну. П.С. у вас тут управляемая форма? у меня в обычном режиме 1С работает.

ты просил пример, я тебе дал.

это уже что-то. Спасибо большое.

Тип не определен (ОписаниеОповещения)         Оп = Новый <<?>>ОписаниеОповещения( видать и конфа у меня старая.

это для 8.3. На 8.2 работать не будет. И это для УТ11

ок другой вопрос. Первоначальное свойство документа когда устанавливается?

надо ручками завести общее свойство для типа документов. Название есть в обработке

У Нас данный механизм доработан. Печатаем в накладных штрихкоды. По ним и "пишем" в регистр сведений состояния документов.

а по входящим документа без штрихкодов как?

клеишь предварительно напечатанные...

Всё зависит от целей. В хорошо написал. Согласен на 99% )) Номер на них есть? Пусть по номеру шукают.

ну так просто некоторые не асилили вопрос "контроль возврата/получения оригиналов первичных документов", но считающие себя самыми умными, достойными обзывать других и начали городить статус проблема и классификатор к нему))) +100500 "по-хорошему, нужно организовывать наиболее полное решение. ибо объем предварительной подготовительной работы примерно одинаков. Ну а полное решение можно использовать лишь частично. " это вообще феерично. был бы ты сотрудником франча, цены бы тебе не было. Вызвал клиент, говорит у меня магазинчик одежды, мне нужно вести учет остатков товаров и суммы выручки. и тут  "несварщик": - розница для туканов и сварщиков, покупайте УПП с внедрением на 20 000 000, предварительные подготовительной работы для внедрения одинаковые   что розницу запустить, что упп или ерп. Ну а УПП можно использовать лишь частично.

Всё зависит от целей. Если в организации несколько подразделений галки мало. Нужна фамилия поставившего статус. Документ обычно возвращают туда, откуда забрали товар, а потом внутренний курьер пересылает в бухгалтерию. По фамилии и статусу можно будет определить: кто потерял - водитель, сотрудник офиса или документы неверно оформлены и снова поехали к клиенту и не вернулись. Если всё в одном здании (склад, бухгалтерия, офис продаж), то, возможно, галки пришло/не пришло достаточно. Реквизит не совсем верно, конечно. Нужно дополнительные сведения или РС (измерение - документ, ресурс - булево)

Так как мне только 2 вида документов обрабатывать я сделал доп. реквизит, доп обработку (через печатные формы) и отчетик. В принципе просто не хотел с РС заморачиваться. но можно и через него.