Вопросы по Управлению автотранспортом

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

1) По табличной части "Задания" приняни пожелания к сведению.
2) Пожелание по добавлению учета пробуксовки зарегестрировано, но, к сожалению, в настоящий момент нельзя назвать сроки его реализации. На текущий момент это первое обращение с подобной просьбой.
3) Закрытые модули расчета ГСМ это вынужденная мера используемая из-за уровня "пиратства" и позволяющая нам защищить свою интеллектуальную собственность.

Точно такая же проблема относится к еще более часто встречающейся ситуации.
1). Когда ТСву необходимо проехать туда-обратно 100км, из которых, например:
ТУДА - первые 10 км пути - это порожний проезд по городу (с коэффициентом для города), потом следуют 40 км трассы (на которую не требуется коэффициент) до пункта назначения,
ОБРАТНО - 40 км с грузом по трассе (без коэффициента) и последние 10 км пути с грузом по городу (с коэффициентом для города).
Соответственно тоже приходится дробить задание. Что влечет за собой минимум удвоение веса перевезенного груза в таблице выработки.

2). Заодно у меня еще вопрос. Каков смысл реквизита "кол-во рейсов" в таблице выработки? Его только вручную исправлять? Поскольку в задании возможности указать кол-во рейсов нет. И каково его отличие от реквизита "количество ездок"?

3). К слову, если вынужденно дробить табличную часть "задание" (см. п.1), то "количество ездок" тоже пропорционально растет, что не есть правильно.

Просим вас как можно скорее разобраться с возникшими вопросами.

Здравствуйте!
 В настоящий момент мы пытаемся найти решение описанной проблемы которое вписывалось бы в существующий продукт не ломая уже сложившиеся схемы. К сожалению пока не все так просто и очевидно.
 Количество рейсов это, фактически, служебный параметр выработки предназначенный для учета количества путевых листов по которым отработало ТС (поэтому в ПЛ он всегда равен 1). Параметр количество ездок используется для упрощения ввода повторяющихся звеньев маршрутов.

Здравствуйте!
Спасибо за информацию!
Описанная в пункте первом ситуация является ошибкой. Она зарегистрирована будет исправлена в ближайшем релизе.

По пункту второму. В случае, если НДС включена в стоимость, сумма 762,71руб. будет верной. Для того, чтобы НДС насчитывалась сверху, нужно зайти в выбранном документе в "Цены и валюта" и снять галку Сумма вкл. НДС.

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

Добрый день!
1) Обмен УАТ - Бух Корп. Официально такой возможности нет, но есть возможность выгрузки данных в конфигурацию "Бухгалтерия предприятия 2.0". Как показывает практика, использование этого обмена позволяет выгружать данные в "Бухгалтерию Корп 2.0" без особых проблем. Работа с версия Бухгалтерии 3.0 пока не поддерживается.
Обмен УАТ - ЗУП. Такая возможность есть. В этом случае в ЗУП выгружаются только данные документов "Начисление зарплаты" и связанная с ними справочная информация.
2) Выгрузка данных в Бухгалтерию и ЗУП осуществляется встроенными обработками конфигурации, которые вызываются из главного меню:
Сервис -> Регламентные операции УАТ -> Выгрузка в конфигурацию "Бухгалтерия предприятия",
Сервис -> Регламентные операции УАТ -> Выгрузка в конфигурацию "Зарплата и управление персоналом"
порядок работы с этими обработками описан в справочной информации к обработкам
3) в УАТ Стандарт пока нет возможности загрузки данных из "Бухгалтерии предприятия", планируется реализовать загрузку нормативно-справочной информации в следующем релизе 1.0.6. Из "Бух Корп" опять таки возможность загрузки данных остается пока неофициальной (также как и выгрузки из УАТ в Бух Корп). Есть также вариант объединения типового решения с УАТ Стандарт, но опять же только Бухгалтерии 2.0 (возможность объединения Бух Корп 2.0 и УАТ Стандарт официально пока не реализована, но проводился ряд тестов в этом направлении, в целом работа такой связки корректна)
4) этот вопрос немного непонятен. В УАТ никакая часть ЗУП не встроена, просто есть некий примитивный блок начислений зарплаты водителям по тарифам. Также существуют способы расчета, такие как "Сдельный по выработке", "Процентом от выручки", "Фиксированной суммой" и т.п. Что имеется ввиду под "Сделкой"? Уточните пожалуйста этот вопрос.

1) абсолютно верно.
2) к сожалению не получится, обмен с ЗУП односторонний - только выгрузка "Начислений зарплаты" из УАТ в ЗУП
всегда пожалуйста

Доброго дня!
1) Список выгружаемых в ЗУП объектов можно увидеть таким образом:
открываем обработку "Выгрузка в конфигурацию "Зарплата и управление персоналом"" , нажимаем кнопку "Загрузить правила обмена" и ниже в таблице будет список.
- Справочник "Физ. лица" сопоставляется по реквизиту "Наименование". Что это значит: есть например, физ. лицо Петров В.В. в УАТе, а в ЗУПе его нет - тогда он выгрузится полностью. Теперь, взяли изменили например дату рождения Петрова в УАТе. И снова выгружаем в ЗУП. Система увидит что в ЗУП уже есть Петров В.В. и не будет создавать новый элемент, а изменит старый - запишет новую дату рождения.
- А вот документ "Начисление з/п" сопоставляется по уникальному внутреннему идентификатору (ID). ID - это абсолютно уникальный номер объекта в базе, то есть двух любых объектов с одним ID существовать не может. Выгрузили в первый раз документ УАТ, он появился в ЗУП. Далее, что-то наменяли в документе УАТ и выгружаем его повторно. Система теперь сопоставит документы по ID и внесет изменения в документ ЗУП с таким же ID. То есть не будет произведен поиск ни по каким другим полям, ни по номеру, ни по дате документа, а только по ID. ID - это служебное свойство объекта (ссылка на объект собственно и является ID) и генерируется системой автоматически при записи нового объекта в базу.
- также, существует настройка "Не замещать справочники/документы". По умолчанию флажки сняты, это значит, что найденные (по ID, по коду и т.п.) объекты в ЗУП будут замещаться выгруженными из УАТ, если установить флажки - то не будут замещаться. Но новые объекты в ЗУП в любом случае будут созданы.
2) расчет з/п в УАТ производится примерно так:
- задаются и настраиваются тарифы з/п, тарифные планы,
- у сотрудников/водителей указываются эти тарифы/планы,
- в путевых/ремонтных листах задается выработка сотрудников,
- рассчитываются итоги в путевом листе или производится расчет з/п в ремонтном листе,
- документы проводятся, начисления отражаются в регистре расчета Основные начисления УАТ
- вводятся документы Начисление зарплаты, и наконец заполняются по данным начислений
- теперь данные документов "Начисление зарплаты" можно выгрузить в ЗУП
3) Сдельный наряд в УАТ отсутствует. Хотя в ремонтном листе нечто подобное реализовано: есть материалы, работы и исполнители. Но сумму между ними мы не распределяем, а используем начисления по тарифам просто по времени в ремонте. Отработал 4 часа по тарифу 50 руб, получил 200 руб.

Еще такой вопрос.
есть 8 отнгосительно твердых маршрутов. но расстояние меняется, допустим, каждые 2 недели.
кроме этитх маршрутов, есть огромное количество точек (в реале - делянки в лесу) как нормальным образом отразить движение ТС по Маршруту
база - точный маршрут - делянка - база?
проблема в том, что есть допустим 3 Участка. у этих участков в работе 3 квартала по 4 делянки. и эти делянки меняются с неизвестным интервалом (то есть может быть 3 дня, а может месяц не менятся)
расстояния между всеми точками - величина переменная. то есть вообще нет твердо приязанных точек.
теперь подскажите, как вести в этом случае учет.
допустим мы начнем создавать точки формата 12-03-01_У1_3/4 то есть 3/4 - это сокращение квартал/делянка
то есть получается сначала идет дата. потом уже название самого места. но это получиться просто огромное количество точек...
это достаточно неудобно - так количество точек достаточно большое и меняются они тоже достаточно часто.
подскажите как быть в этом случае.

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

Здравствуйте!
УАТ Проф является развитием решения УАТ Стандарт, то есть, все объекты конфигурации, которые есть в Стандарте, есть и в Профе. Единственное что - Проф не стоит на поддержке от Стандарта. Поэтому при переходе необходимо полностью снять с поддержки всю конфигурацию и загрузить в нее конфигурацию поставки УАТ Проф (меню Конфигурация -> Загрузить конфигурацию из файла ...). Таким образом мы "снимаемся" с поддержки от УАТ Стандарт и встаем на поддержку от УАТ Проф.
Учет по спидометру и по моточасам: если основное ТС имеет спидометр, то пробег рассчитывается по разности показаний спидометра (выезда и возврата), а моточасы вводятся вручную в таблицу Задание (добавляем строку с указанием "Времени работы"), Если, наоборот, основное ТС имеет счетчик моточасов, то  время в работе рассчитывается по разности показаний счетчика (выезда и возврата), а пробег вручную заносится в таблицу Задание.
По поводу простоев - да в системе нет контроля например на то, что простой будет 25 часов, когда в сутках всего 24 Но это оставлено на откуп пользователям, количество часов системой дополнительно не контролируется, сколько ввели столько и будет отражено в выработке по параметру "Время в простое".
По отчету по простоям - пожалуйста приведите скриншот ошибки и опишите как должен отчет правильно выглядеть.