Хочу в 1-м регистре фиксировать и движение машин на СТО (пришли на сервис, ушли с сервиса) и накапливать время, которое они провели на сервисе (в работе у механика, всего на СТО), и изменять статусы машин (в работе, ожидает ЗЧ, конец работы и т.д.).

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

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

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

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

Ок. Сейчас попробую сформулировать.

1. Нужно видеть сколько машин и какие именно на данный момент присутствует на СТО. Их количество нужно накапливать при заезде на сервис и убавлять при выезде с сервиса.
2. Нужно видеть, сколько времени эти машины пробыли на сервисе. Два показателя - сколько всего пробыли на сервисе, сколько из этого времени провели в цеху у механика.
3. Нужно фиксировать статус, в котором сейчас находится авто.

Регистратор для всего этого дела - обработка, которая хавает штрих коды (связка штрихкодов Пользователь-Заказ-Наряд-Статус) и проводит действия в регистры.

Я думал, что может быть можно сформулировать все с помощью одного регистра, как-то так:

Описываю строку записи в регистре сведений. Некоторые из этих параметров будут ресурсами, другие - измерениями, но принцип такой:


1. Вид записи (приход, расход)
2. Дата записи.
3. Документ, по которому пробивали штрих-код сканером (привязка к документу).
4. Статус
5. Количество (1, если нужно фиксировать изменение количества, или 0, если не нужно)
6. Время на сервисе (фиксируется разница времени между первой записью по этому документу и системной датой.
7. Время в цеху у механика (отдельный таймер, где копятся именно те действия, которые являются работой, а не простоем. Это фиксируется в статусах. Одни статусы накапливают время только по первому показателю, другие - по обоим).
8. Мастер - сотрудник, который вводил действие.
9. Организация (берется из документа).
10. Подразделение (берется из документа).
11. Цех(берется из документа).

Как-то так думал уместить все в 1 регистр, но запутался что-то )



Выше описал строку в регистре накопления, а не в регистре сведений.

Я останусь при своем мнении - использовать один оборотный регистр. Ресурсы: время на сервисе, время в цеху.
Определить сколько машин на сервисе можно по статусам.

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

А можно будет записывать данные в регистр накопления без регистратора, как такового? Ведь данные в регистр вносит обработка, а не документ. Или придется сделать какой-то транзитный документ, который будет создаваться и проводиться обработкой?

Нужен будет документ, и мне кажется это вполне логичным что бы был документ где всё фиксировалось, а уже необходимые (вычисляемые) данные из него попадали в регистр.

Принцип предстоящей работы осознал. Спасибо за помощь. Пошел реализовывать)

Ой... говорил с начальством. Переменили мне задачу. Скажите, насколько рационально сделать следующее:

1. Завести регистр накопления "Остатки на сервисе", на котором по ряду ресурсов будут копиться остатки 1. на территории СТО; 2. на сервисе; 3. в цеху. Остатки на том или ином ресурсе будут копиться в соответствии с логикой процесса.
2. Завести Регистр накопления "Остатки времени авто", который будет накапливать время, которое авто пробыло за время прохождения того или иного статуса работ. Опять таки с разбивкой - 1. на территории СТО; 2. на сервисе; 3. в цеху.
3. Завести Регистр сведений "Статусы Авто", который будет хранить записи о присваиваемых автомобилю статусах.

Мне нужно учитывать количество машин на территории, на сервисе, в цеху. (1 регистр для этого)
Нужно учитывать время, затраченное тем или иным мастером на фактическое выполнение ремонта. (2 регистр для этого)
Учитывать, на каком статусе выполнения работ сейчас находится тот или иной автомобиль. (3 регистр для этого)

Вся эта информация в последующем сводится в 2 отчета:
1. Отчет мастера цеха - показывает сколько машин сейчас находится на сервисе, на каком они статусе, кто последний присваивал новый статус, сколько машина находится на сервисе, сколько - в работе.
2. Отчет администрации - показывает информацию о КПД (сравнении нормативных и фактических данных по времени выполнении работ), информацию о количестве машин на сервисе, об их статусе и т.д. Наиболее полный отчет.

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

Это больше похоже на проблему ваших знаний по работе с запросами/отчетами, а не минус оборотного регистра.
Опять же останусь при своем, один оборотный регистр хранящий все необходимые данные.

+ для учета времени хотел бы сделать 2 транзитных документа:

1. Запуск этапа.
2. Окончание этапа.

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



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

Подскажите тогда. Вот я накапливаю количество приходов и уходов машин, как ресурс оборотного регистра. Как мне выбрать, сколько машин осталось на ту или иную дату на территории СТО, если регистр оборотный, не перебирая при этом весь регистр?

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

Пришествие машины на сервис осуществляется не по определенному статусу, а по любому первому записанному действию с этой машиной (все равно какой там будет статус). Уход машины с сервиса осуществляется статусом "Отдал авто клиенту". Так что определить чисто по статусам не выйдет. Можно конечно и тут логику наладить...

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

* регистр накопления типа остатки.

Много очень букв, но мне кажется, что на одном оборотном регистре это все делать - это изврат.

Вы тоже так считаете? Хух...))
Мне просто, как человеку не оч. ещё опытному легче все сделать так, как предусмотрено самой 1С, т.е. накопить информацию на тех видах регистров, которые предназначены по своей сути для сбора той или иной информации. Пусть их будет хоть 5, а не 1, если это нужно и целесообразно.

А должно быть не все равно, должен быть статус - пришла на сервис. И уже под это надо подстроить логику работы остальных.


вот вот!


Не нужно, если статус - измерение.


Я высказываю лишь свое мнение, т.е. я бы поступил так. Изврат? Может быть, но понятия "не изврат" по сути не существует

Ладно, делайте хоть стопятцот регистров раз вам так удобней, мне больше сказать по этой теме нечего.

Я попытаюсь разобраться во всем, что Вы и все другие мне сказали прежде, чем что-либо делать. Не думайте, что Вы отписывались тут зря! Я выискиваю в ответах зацепки на знания, и рою в потом в ту сторону. Спасибо за свои ответы! ))

Вам, как начинающему 1С-программисту, я бы рекомендовал использовать несколько регистров.
Чем прозрачнее логика, тем будет лучше.
На один регистр можете потом переделать, если вас что-то не устроит. У вас же не высоконагруженая БД?
Распишите какие регистры будете использовать (измерения, ресурсы, реквизиты) и документы с реквизитами и движениями по регистрам - посмотрим что получится.

Вы знаете, я программист не начинающий, но я всеравно придерживаюсь принципа:

В принципе, решил не нагружать Вас кучей букв и заняться делом. Логика вышла двоякая. Она прозрачная, но в ней много нюансов.

1.Я ввел общий модуль "СистемаШК", куда прописал все основные функции раздачи и распознавания штрих кодов. Штрих-код присваивается сотруднику, заказ-наряду, действию. Продумана система выделения уникальных штрих-кодов на базе реквизитов документа (шифрование номера, даты и прочего).
2. Ввел 1 документ - "Документ_Системы_Штрих_Кодирования". Он фиксирует всю распознанную информацию по связке штрих-кодов "Пользователь,Документ,Действие" и проводит данные по 3-м регистрам. Работает в 2-х режимах - начало этапа и конец этапа. Т.к. мне нужно знать сколько длился тот или иной этап работ, то нужно открывать новый этап, фиксируя наличие нового этапа и изменения количества машин на том или ином уровне иерархии СТО, и закрывать предыдущий этап, фиксируя - сколько же времени он длился. В документе ввел поле родитель. Если документ фиксирует конец этапа, то он записывает в себя так же и ссылку на документ начало этапа, чтоб потом легко было сваять запрос.

3. Ввел 3 регистра: Регистр сведений Статусы, с Ресурсами - статус, сотрудник и общими измерениями (подразделение, организация, цех и т.д.)
Регистр накопления "Остатки авто" с ресурсами - Время в работе, Время на сервисе, Время на Территории и опять таки общими измерениями.
Регистр сведений "Обороты_Время_по_ШК", где фиксируется время, затраченное на тот или иной этап. Ресурсы - ВремяВРаботе, ВремяНаСервисе, ВремяВЦеху.

+ Написал обработку, которая будет выводить информацию о наличии машин на СТО с фильтрацией по цехам и о времени, которое они пробыли на СТО. Она же будет хавать штрих-коды со сканера и выдавать мессаги-подсказки. Предусмотрел все возможные ошибки. Приезд машины на СТО фиксируется любым первым присвоенным статусом (люди могут не соблюдать порядок действий, но это тоже должно фиксироваться). Если машина уехала с СТО, она не может вернуться по этому же документу. А то приемщики могут и ксеронуть штрих-код с левого документу и попытаться по второму разу завести машину. У штрих-кода "отпуск авто" сделал право на использование. Использовать сможет только охрана, нач. СТО и гарантийный администратор.

Короче плодотворно поработал. Спасибо всем за советы!)) Без Вас бы дольше мучился.))

А этот регистр зачем?


А почему это регистр сведений?

Регистр Обороты_Время_по_ШК - регистр накопления времени. Не регистр сведений)
Остатки авто" - регистр накопления с ресурсами - остатки машин в работе, на сервисе, на территории.

Сори. в прошлом посте напутал это, а редактировать нельзя))

А зачем для остатка машин столько ресурсов в нем? Где и как вы их используете?

Ну считайте, что есть на СТО 3 уровня. Сначала машина попадает на территорию, потом на сервис, потом в работу. У каждого статуса есть признак "местонахождения автомобиля", который определяет, находится ли машина на территории, на сервисе или в работе в данный момент. Соответственно есть 3 ресурса в регистре.

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

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

Показатель "время в работе" будет сравниваться с количеством часов в акте. Факт время / план время = КПД сотрудника. В общем примерно такой концепт.

svlad-90, "Остатки авто" оборотный регистр?

Остатки авто - "Регистр остатков", не оборотный.

Когда машина заехала куда-то - то получается плюс по регистру. А когда будет минус?

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

Когда авто переходит из статуса в статус, то фиксируются и минусы по соответствующим иерархиям, если авто в них больше не находится. Одно из действий имеет признак УходАвтомобиляССТО. Если происходит оно, то минус происходит со всех ресурсов, где по этой машине есть остаток "1".

Фактически таблица сл-щая:

№ действия ВРаботе НаСервисе НаТерритории

+1 _ _ 1 - авто заехало на территорию
+2 _ 1 _ - авто взято на сервис
+3 1 _ _ - авто зашло в работу
-4 1 _ _ - работа закончена
-5 _ 1 1 - авто покидает территорию СТО

Всем ещё раз привет. Дошел я со своей темой таки до начальства сегодня. Посмотрели и сказали закупать компы сотрудникам и внедрять на местах. Получил первые премиальные!!! (размером, кстати, с полуторамесячный оклад) ))) Спасибо ещё раз всем! Не думал, что таки смогу доделать все это коварство.)))

Что было сделано за месяц:

1. Разработан (наполовину подсмотрен) и внедрен способ использовать сканер штрих кодов в обход стандартной реализации данного функционала в 1С.
2. Разработан общий модуль функций, содержащий около 20 функций, отвечающих за выдачу и распознавание уникальных штрих кодов документов типа «заказ-наряд», элементов справочника «сотрудники», и элементов справочника «действия». Выдаваемые штрих коды не пересекаются с системой международного штрих кодирования товаров. Использована система штрих кодирования EAN-13. Штрих коды уникальны. В дальнейшем наработку можно использовать для выдачи штрих кодов для любой другой документации. Всего можно закодировать 10 документов и 10 справочников.
3. Доработаны модули объектов «заказ-наряд», «сотрудники», «действия», а так же их печатные формы под вывод и распечатку штрих кодов. Система способна выдержать нагрузку в 99 999 заказ-нарядов в год.
4. Разработана обработка-отчет, которая отлавливает действия сканера и проводит по регистрам проводки, учитывающие количество машин на СТО, их статусы, а так же время их пребывания на СТО. В связи с этим были созданы 2 регистра накопления и 1 регистр сведений, а так же транзитный документ «Документ системы штрих кодирования».
5. Разработан интеллектуальный отчет «Анализ эффективности сотрудников», рассчитывающий КПД сотрудника по тому или иному акту.
6. Разработаны упрощенные отчеты «Остатки авто на предприятии» и «Статусы Автомобиля». Они включены в основную обработку-отчет и вызываются по нажатию на активизирующие элементы. Отчет «Статусы автомобиля» так же внедрен в форму списка документа «Заказ-Наряд».
7. Разработана система выдачи пользователям прав на то или иное действие.

Работа заняла 4 недели, около 30 исписанных листов блокнота и 40 страниц кода 8-м шрифтом (измерял чисто ради интереса =)).

Поздравляю