F_SOPRHOZ
Краткое описание :
Больше одного раза спрашивать о расчете налогаОписание :
Платежное поручениеЧто измененно :
При первой привязке ТХО в платежках, сразу после
создания появляется запрос на расчет налогов, если
выбрать нет и отвязать ТХО, то при повторной привязке
запрос не появляется. Нужно что бы появлялся при каждой
привязке.
Как измененно :
Добавлена системная настройка "Настройки Галактики
\ Бухгалтерский контур \ Обработка документов \
Значения полей по умолчанию \ Авизо входящие \ Расчет
налогов при привязке ТXO на филиальных БД" со значением
по умолчанию "нет". На не филиальных БД, при попытке
изменить значение настройки выдается сообщение "Текущая
база данных не является филиальной. Изменение настройки
невозможно".
В случае если на филиальной БД, данная настройка
включена, то во входящих авизо, при привязке ТХО (как
из документа, так и из конкретной хозоперации),
предварительно будут рассчитаны налоги, в соответствии
с текущими настройками системы.
F_SOPRHOZ
Краткое описание :
Распрелеление платежа - Налоги в акте при обработке суммовой разницы не верныОписание :
Платежное поручениеЧто измененно :
Установлены следующие настройки:
"Настройки Галактики \ Логистика \ Налоги, документы для учета НДС \ Услуга по суммовой разнице" - определена услуга, для которой привязана группа налогов.
"Настройки Галактики \ Бухгалтерский контур \ Обработка документов \ Параметры работы с документами различных типов" - установлен признак обработки суммовых разниц.
"Настройки Галактики \ Логистика \ Документы \ Управление снабжением \ Входимость налогов по умолчанию" - не входят (!) - распространяется на документы (KATSOPR.VIDSOPR=111)
При распределении платежа по вал-руб ДО формируется хозоперация на суммовую разницу, после чего автоматически создается акт на услуги (KATSOPR.VIDSOPR=111). В данном акте в соответствии с настройкой налоги берутся сверх суммы хозоперации - в результате сумма акта не равна сумме хозоперации.
Необходимо создавать акт со значением "налоги входят".
Как измененно :
Вне зависимости от значения настройки "Настройки
Галактики \ Логистика \ Документы \ Управление
снабжением \ Входимость налогов по умолчанию", в акте
на услуги, сформированном при обработке суммовой
разницы, параметр "Входимость налогов в цену слуг"
всегда принимает значение "входят в цену услуг".
F_SOPRHOZ
Краткое описание :
платежгные документы не имеют разноски ЦУОписание :
Объекты строительстваЧто измененно :
Для нашего клиента очень важно в объектах строительства иметь сведения об оплате.
Но на закладке Документы>Платежи Данные появляются только если платежные документы привязаны к ДО, в котором
и есть либо связь с договором и объектом строительства либо разноска целевого учета в ДО, которую наследует платежный документ.
Так как ведением договоров и ДО у клиента занимается совсем другая служба,ТЭК очень хочет иметь разноску ЦУ в платежных документах
( собств. пл.поручение и бухгалтерская справка как минимум) в явном виде как в ДО.
Как измененно :
В окне редактирования хозяйственной операции
платежного документа, на закладках "Оплата МЦ/услуг
накл" и "Оплата МЦ/услуг ДО" выведены поля целевого
учета (Объект ЦУ и и 10 полей КАУ). Так же эти поля
выведены в окне распределения по позициям ДО.
Видимостью полей управляет настройка "Настройки
Галактики \ Общие настройки системы \ Работа с МЦ,
услугами \ Целевое назначение МТР \ Отображать поля КАУ
в спецификации документов".
F_SOPRHOZ
Краткое описание :
Перепривязка ТХО в документеОписание :
Разноска ТХО "Все документы"Что измененно :
Добрый день!
При привязке (перепривязке) ТХО в любом документе происходит ситуация, описанная во вложении.
Прилагаю отчет о рабочей станции, полный отчет, сводный отчет
Как измененно :
При привязке/перепривязке ТХО вызывается функция
подсчета количества хозопераций у документа. Данная
функция имеет смысл только при привязке ТХО в платежных
документах. При привязке тхо в документах логистики,
вызов данной функции приводил к существенному
замедлению, по причине того, что снимались текущие
ограничения на таблицу SoprHoz и запрос к БД возвращал
все записи таблицы, вместо того что бы вернуть одну
запись. Кроме этого, в случае когда включен протект (а
у клиента он включен), выгруженные данные
упорядочиваются по полям индекса. В данном случае по
4-м полям. Это и приводило к замедлению быстродействия
у пользователя.
Повторить проблему у нас, не удалось. На правильно
настроенном сервере БД, такие "тяжелые" запросы
отрабатывают быстро. А так как у клиента проблемы с
быстродействием возникли на тестовой БД, то существует
большая вероятность того, что сервер БД не корректно
настроен.
Но в любом случае, код, вызывающий замедления, в
данном интерфейсе не нужен и необходимости в нем уже
нет. Поэтому функция была удалена.