Электронная очередь в 1С. #806691

Всем привет. Помогите советом. Пилим электронную очередь через веб-сервис. в 1С получаем данные: номер талона, тип талона и т.д. А как в 1С это реализовать, какими объектами? Т.е. например есть форма обработки, в котором должна отображаться эта очередь автоматически. Как это реализовать? Как вариант: регистр сведений - все талоны. А как сделать чтобы в обработке автоматически обновлялся список?

в 1С тоже есть веб-сервисы

Через обработку ожидания

HTTPСоедниение

[чтобы в обработке автоматически обновлялся список] - у списка есть свойства АвтоОбновление и ПериодАвтообновления.

ок. понял. всем спасибо. курю)

Курить вредно.

еще помощь нужна) все сделал, работает: записи регистра сведений из веб-сервиса создаются, написал обработку, в ней подключил обработчик ожидания, по которой заполняется табличная часть из этого регистра, прописал действия по обработке очереди (строк табличной части). вопрос такой: как сделать так, чтобы операторы не могли взять в работу один талон одновременно. (сейчас сделано так, что оператор сам выбирает какой талон из очереди обрабатывать). т.е. можно ли сделать так, чтобы заблокировать конкретную запись регистра? Пытался делать через управляемые блокировки, там все блокируется(

у талона (в регистре?) д.б. четыре статуса, к каждому статусу д.б. маркер "ДАТАВРЕМЯ" статусы: - Запланирован (время когда поступил в систему) - Выполняется (талон взяли в работу, соотв. датавремя) - Завершен (обслуживание по талону завершено, соотв.датавремя) - Отменен (талон аннулирован). . если талон "статус <> Запланирован" - то оператор попускает талон. . как заблокировать конкретную запись в т.ч. и на чтение на время "взятия" талона в работу - тут хз., смотреть блокировки 1Сные как ставить...

непонятно как оператор "берет талон в работу"...? он физически его берет? сканирует штрихкод талона? - тогда нечего морочиться с блокировками - так как очевидно, что два разных физических талона с одинаковыми штрихкодами быть не могут, единственное - при взятии проверить что "статус=запланирован", если это не так - значит талон или в работе и вам его подсунули ПОВТОРНО (не дубль, а повторно) или талон завершен и его не выкинули нафиг а повторно подсунули (не дубль, а повторно)

если оператор "берет" талон в работу не физически, а воздушно-капельным путем посредством сначала получения какого-то списка талонов (где статус=запланирован), потом из списка выбирает талон - в этот момент - начинаем работать с блокировками - ставим блокировку и на чтение и на запись, соотв. выбранному талону, читаем статус талона, если статус=запланирован - ставим статус=выполняется, записываем запись, снимаем блокировку (если статус <> запланирован - значит талон взял уже кто-то дургой - даем отлуп). если блокировку в самом начале не удалось поставить - значит этот талон только что взял в работу кто-то другой, даем отлуп. . примерно так я себе представляю. тонкости с блокировками - не ко мне... 8-(

Я бы вообще на бп и задачах это сделал бы.

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

талон = задача?

блокировки не забудь, а то 2 (или n) оператора схватят один талон

"Талон" — это запрос на обслуживание. Оно, обычно, в каком-то окружении существует. Так что БП — самое оно. Пользователь взял талон => стартовал БП. Взяли талон в работу => активировали задачу. Отработали талон => закрыли задачу. Там развесистую систему можно нарисовать. С передачей "талона" по ответственным и всё такое.

ага, понятно. идейно примерно как я описал. а в каких понятиях в 1с это дело реализовать - тут надо сильный колдун, чтоб оценил какой вариант взять... . а чем вариант на БП лучше/хуже чем типа как я описал (добавить еще ответственного/исполнителя)..? на задачах удобнее в том смысле, что меньше ваять? или еще что? (интересно в части понимания что да как делать правильно)

Можно нарисовать схему БП обработки талона, она и будет тебе сразу статусы. Можно воспользоваться встроенным механизмом адресации (правда, я еще ни разу не видел, чтобы его применяли на практике).

а отчеты по таким "талонам"-БП как собирать? есть такая возможность? типа сколько стартанутых задач, скольо активированных и т.д...? типа как в ...?

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

ну.. тут вместо системы м.б. оператор выбирает для обслуживания.. а может быть клиент подходит к оператору с талоном и тот его "выбирает" сканированием или еще как.. хз что там у ТС за БП

Таблицы БП и задач в запросах доступны.