F_OFP
Краткое описание :
Форматирование представления данных в ПКОписание :
Платежные календариЧто измененно :
В интерфейсе ПК в каждый момент времени видно
довольно много показателей. В результате восприятие ПК
в достаточной степени затруднено. Часть показателей в
любой момент времени равна нулю - это, в частности,
строки по которым не может существовать остатков
средств и т.п.
Необходима настройка форматирования представления
показателей. Лучше всего ее добавить в интерфейс
настройки видимости колонок. Настройка каждой колонки,
помимо видимости, должна включать хотя бы следующие
настройки:
- не отображать нулевые значения;
- красный цвет для отрицательных значений;
- жирный шрифт.
Как измененно :
Доработан интерфейс "Платежный календарь":
1. Нули в ПК не выводятся.
2. Критические значения выделяются фиолетовым цветом.
Критические значения - это:
2.1. Отрицательные:
2.1.1. "Остатки"
2.1.2. "Приход", "Расход"
2.2. Положительный:
3.2.1. "Дефицит"
F_OFP
Краткое описание :
Перенос из ДО в Фин. обязательство кау (целевое назначение)Описание :
Журнал обязательствЧто измененно :
В Объекте целевого учета настраиваем уровень КАУ - Статьи
планов (бюджетов). В ДО привязываем статью бюджета к каждой позиции счета.
Необходим механизм автоматического разбиения сумм ФОБ по статьям бюджетов.
Также нужен механизм сопоставления других уровней КАУ целевого учета со
статьями бюджета (таблица соответствий (возможно с приоритетами)) для
автоматического разбиения суммы ФОБ по статьям бюджета.
Как измененно :
1.Разработаны алгоритмы формирования разноски по статьям
бюджета по целевому учету ДО (договора, ПКП). Напрямую из статей и через
таблицу соответствий.
2.Также разработаны алгоритмы получения полей
- Контрагент
- Объект строительства
- ЦО
- Сотрудник
из целевого учета (первая спецификация)
F_OFP
Краткое описание :
Плохая визуализация на вкладке финансовые операцииОписание :
Журнал обязательствЧто измененно :
Платежный календарь - Документы - Журнал обязательств
Плохая визуализация на вкладке финансовые операции:
1)Создаем Фоб;
2)Перемещаем курсор в нижнее окно журнала обязательств
на вкладку фин.операции -> не сформированная фин.операция
подсвечивается серым -> все верно;
3) Cнова перемещаем курсор в верхнее окно ФОБ -> фин.
опреация подсвечивается черным цветом как
сформированная -> что неверно.
Если выйти из интерфейса журнала обязательств и
зайти снова по данному ФОБ фин. операция фактически не
сформирована.
Аналогичная проблема в окне редактирования ФОБ.
Как измененно :
исправлено
F_OFP
Краткое описание :
Необходим расчет остаток нач. /остаток конечный по
вышестоящему уровнюОписание :
Платежные календариЧто измененно :
Необходим расчет остаток нач. /остаток конечный по
вышестоящему уровню если в группировку включено платежное средство.
Как измененно :
Теперь в ПК данные по "Остатку начальному", "Остатку конечному"
и "Дефициту" выводятся для всех вышестоящих уровней. Для уровней группировки:
"ПС", "Вид ПС", "Валюта ФОП" и "Периоды" - остатки рассчитываются как и раньше.
Для остальных полей они агрегируются по нижестоящим данным с учетом валют.
F_OFP
Краткое описание :
Не информативное сообщение в протоколе проверкиОписание :
Проверка таблиц Платежного календаряЧто измененно :
Неинформативное сообщение в протоколе проверки
Выполняли проверку: Платежный календарь / Настройка /Администратор /
Проверка целостности таблиц / Проверка таблиц платежного календаря с
параметром финансовые операции и получили
результат проверки: в котором встретилась следующая
ошибка (скрин привожу во вложении): "Не найдено ФО
(nRec = )", при этом нрек не указан и ситуация не
исправляется.
Как измененно :
Платежный календарь | Настройка | Администратор | Проверка
целостности таблиц | Проверка таблиц Платежного календаря
Доработана проверка таблицы Финансовых операций.
Добавлена проверка на наличие ФОБ на которое ссылается ФОП.
Если ФОБ не найдено, в протокол выводится предупреждение.
Если были обнаружены отвязанные ФОП, то после выполнения проверки
открывается список всех таких ФОП, при этом пользователь должен сам
оценить ситуацию и при необходимости удалить отвязанные записи.
Удаление отвязанных записей ФОП может повлиять на
остатки платежных средств!
Для избежания пересчета необходимо ввести фиксированные остатки.
F_OFP
Краткое описание :
При возврате платежа сумма по ФОб увеличивается, а должна
минусоватьсяОписание :
Журнал обязательствЧто измененно :
При возврате платежа сумма по ФОб увеличивается, а должна
минусоваться.
У клиента возникла необходимость привязки стороннего платежного поручения к
ФОБу на расход, когда происходит возврат денежных средств, перечисленных по
неправильным реквизитам.
Стороннее платежное поручение к ФОБу привязалось без проблем, но вместо того,
чтобы сминусоваться, сумма по ФОБ увеличилась.
Необходимо, чтобы при привязке платежного поручения, противоположного
направлению ФОба, сумма по ФОБ минусовалась для того, чтобы по этому ФОБу
повторно оплатить, а также видеть всю историю по ФОБ.
Как измененно :
1. Сумма исполнения, фактическая сумма финансового обязательства
рассчитывается с учетом направления финансовой операции.
3. В проверку таблиц платежного календаря добавлена опция для проверки
"Исполнения финансовых операций"
2.Доработано заполнение поля Direct таблицы исполнения (AktPerf).
Для обновления поля в ранее созданных документах необходимо запустить проверку
таблиц Платежного календаря.
F_OFP
Краткое описание :
Необходима групповая замена статьи в финансовых
обязательствах.Описание :
Журнал обязательствЧто измененно :
Необходима групповая замена статьи в финансовых обязательствах
согласно соответствию из модуля "Хозоперации"
Как измененно :
Разработаны алгоритмы для получения аналитики из соответствий
модуля "Хозоперации" для формирования полей документов модуля "Платежный
календарь"
F_OFP
Краткое описание :
Формирование финансовых обязательствОписание :
Журнал обязательствЧто измененно :
При ведении ФОБ по ДО, в случае использования из ПД
функции "Формирование финансовых обязательств",
могут возникнуть ситуации дублирования ФОБ.
Т.е. когда по одному и тому же ДО, в итоге
формируется 2-а практически одинаковых ФОБ:
1.ФОБ, где в качестве "основания", указано вышеупомянутое ДО
2.ФОБ, где в качестве "основания", ничего не указано,
а вышеупомянутое ДО - один из атрибутов ФОБ
Вариант использования 1
1.На основании ДО, сформировано "оформляемое" ФОБ:
1.1.либо автоматически по настройке "Настройки Галактики \
Управление финансами \ Платежный календарь \ Формирование заявок
и обязательств \ Автоматическое формирование обязательств
предприятия по ДО" = "при создании ДО"
1.2.либо из самого ДО
1.3.либо из интерфейса "Образование обязательств"
1.4.либо в интерфейсе ФОБ, установили в качестве основания указанное ДО
2.Из ДО, сформирован ПД
3.Из ПД, по функции "Формирование финансовых обязательств",
формируем ФОБ - сформировано "исполняемое" ФОБ
(где ДО указано не как "основание")
Вариант использования 2
1.На основании ДО, сформировано "оформляемое" ФОБ:
1.1.либо автоматически по настройке "Настройки Галактики \
Управление финансами \ Платежный календарь \ Формирование заявок
и обязательств \ Автоматическое формирование обязательств
предприятия по ДО" = "при создании ДО"
1.2.либо из самого ДО
1.3.либо из интерфейса "Образование обязательств"
1.4.либо в интерфейсе ФОБ, установили в качестве основания указанное ДО
2.Вручную создан ПД
3.Вручную к ХО привязываем ДО:
3.1.либо в интерфейсе ПД
3.2.либо в интерфейсе "Расчеты с поставщиками и получателями
| Операции | Пакетное распределение платежей"
4.В результате привязки автоматически:
4.1.ФОБ переводится в статус "исполняемый"
4.2.ХО привязывается к ФОП
4.Из ПД, по функции "Формирование финансовых обязательств",
формируем ФОБ - ничего не формируется - это хорошо.
Однако "все хорошо", происходит только в случае если ХО
полностью разнесена по ФОП. Если ХО разнесена не полностью,
то на "остаток" формируется "исполняемое" ФОБ
(где ДО указано не как "основание").
Предлагаемое решение
Если на "основании" ДО, было создано ФОБ, то только это ФОБ
должно использоваться для отражения "исполнения" этого ДО, а именно:
1.Реакция на событие изменения ДО в ХО, должна быть везде одинаковой:
1.1.При появлении в системе ХО, разнесенной по ДО, либо при разноске
ХО по ДО, надо искать ФОБ, где в качестве основания - указанное ДО:
1.1.1.ФОП искать подходящую, если не найдено - создавать. В текущей
реализации так обрабатывается событие "ручной" разноски ХО по ДО
(в интерфейсе ПД и в интерфейсе "Пакетное распределение платежей").
Точно также надо сделать и для остальных событий.
2.Алгоритм отработки функции "Формирование финансовых обязательств",
запускаемой из интерфейса ПД, должен быть изменен, для случая, когда ХО
разнесена по ДО.
2.1.В случае, если не было ФОБ, сформированного на "основании" ДО, то должно
быть создано ФОБ с "основанием" по ДО
2.2.В случае, если уже есть ФОБ, сформированного на "основании" ДО, то нужно
корректировать его ФОП, по принципу: "искать подходящую, если не найдено -
создавать".
Дополнительная Проблема
Если ХО "не входит в сумму платежа" - то зачем ее в ФОП распределять?
По крайней мере, она не должна входить в суммы: "исполнение", "факт".
Возможно в этом случае следует ФОП делать - "не активной"
Как измененно :
1.Алгоритм формирования ФОБ по ХО платежных документов.
1.1.Если ХО разнесена по ДО, на основании которого сформировано ФОБ, то
выполняется поиск подходящей ФОП по этому ФОБ и формируется исполнение.
Если ФОП не найдена - формируется новая.
1.2.Если подходящее ФОБ через ДО не найдено, формируется новое. При этом по
каждой ХО формируется свое ФОБ.
1.2.1 Если ХО разнесена по ДО, то ФОБ формируется по алгоритмам ДО.
Если на основании ДО еще не было сформировано ФОБ, то ДО считаем
основанием ФОБ, иначе основание не заполняется. Тип по валюте определяется из
ДО. Сумма ровна не распределенной сумме ХО.
1.2.2 Если ХО не разнесена по ДО, то ФОБ формируется по алгоритмам ХО.
Основание ФОБ не заполняется, тип по валюте определяется на основании ХО, сумма
ровна не распределенной сумме ХО.
2.Доработаны параметры формирования ФОБ на основании ХО платежных
документов.
Отдельно можно задать алгоритмы формирования полей для документов
разнесенных по ДО и не разнесенных.
Согласно алгоритмам формируются поля :
- Дескриптор (по умолчанию дескриптор пользователя)
- Группа (по умолчанию группа дескрипторов пользователя)
- Вид платежа (по умолчанию "регламентный")
- Статус (по умолчанию "оформляемый")
- Приоритет (из системных настроек)
- Дата формирования (по умолчанию текущая дата)
- Первоначальная дата (по умолчанию дата ХО)
- Дата погашения (по умолчанию дата ХО)
- Контрагент (по умолчанию контрагент ХО)
- Объект строительства (не формируется)
- Центр ответственности (из системных настроек)
- Статья бюджета (не формируется)
- Куратор (сотрудник по ПД)
- Назначение (не формируется)
- Примечание (не формируется)
- Группа ФОБ (не формируется)
- Сводное ФОБ (не формируется)
При этом для выбора при формировании по ХО, разнесенной по ДО,
доступны все алгоритмы ДО.
Если Сводное ФОБ формируется по алгоритму <авто - формировать сводное ФОБ> то
при выполнении процесса все новые ФОБ группируются по направлению в два сводных.
Если по алгоритму <явно, с учетом направления>, то ниже в параметрах
формирования необходимо выбрать сводные ФОБ для обоих направлений,
для добавления туда новых ФОБ.
Если ХО не входит в сумму документа, то по ФОБ по ней не формируется
F_OFP
Краткое описание :
Алгоритмы формирования полей документов ПКОписание :
"Платежный календарь" в целомЧто измененно :
Требуется разработать единый функционал настройки и
отработки алгоритмов формирования полей документов ПК.
Как измененно :
Разработан единый функционал настройки и отработки
алгоритмов формирования полей документов модуля
"Платежный календарь".
Настройку алгоритмов формирования полей документов можно
копировать стандартными методами через "Администратор настроек"
F_OFP
Краткое описание :
БДДС - задваивает входящее сальдоОписание :
Исполнение бюджета денежных средствЧто измененно :
БДДС - "задваивает" входящее сальдо, при появлении
движения денежных средств (ДС). Происходит это если в
настройках БДДС: "Выводить ПС" = "Не выводить".
Локализация:
0. В "марте" есть "исходящее сальдо" = 460
0.1. 01/04/2012, движений ДС не было: Денежный
поток ДП=0.
0.1. 02/04/2012, движения были: ДП =-10.
1. Строим БДДС за "апрель", и анализируем информацию
остатки по дням:
1.1. "ОСТАТОК НА НАЧАЛО"
1.1.1. 01/04/2012 сумма 460 - правильно
1.1.2. 02/04/2012 сумма 460 - правильно
1.1.3. 03/04/2012 сумма 910 - НЕ правильно! Похоже
эта сумма была вычислена как (460*2)-10
1.1.4. далее все не правильно...
1.2. "ОСТАТОК НА КОНЕЦ"
1.2.1. 01/04/2012 сумма 460 - правильно
1.2.2. 02/04/2012 сумма 910 - НЕ правильно!
1.2.2. далее все не правильно...
Как измененно :
Теперь в указанной ситуации, остатки по дням считаются
корректно.
F_OFP
Краткое описание :
Интерфейс выбора финансовых обязательствОписание :
Cводные обязательстваЧто измененно :
Заменить интерфейс выбора финансовых обязательств для сводных
обязательств (F_OFP::OFPJOURNSEL) на аналогичный интерфейс выбора с фильтрами
(F_OFP::GETAKTOFP)
Как измененно :
Для выбора оформляемых финансовых обязательств при формировании
сводных обязательств теперь используется интерфейс F_OFP::GETMARKAKTOFP
(возможность множественного выбора, фильтры).
F_OFP
Краткое описание :
Интерфейс выбора финансовых операций для распределения
платежаОписание :
Разноска хоз. операций по фин. операциямЧто измененно :
Доработать интерфейс выбора финансовых операций для
распределения платежа.
1. Убрать дублирующуюся колонку "Гр./Дескр"
2. Доработать фильтры
3. Добавить возможность множественного выбора финансовых операций
4. Ускорить
5. Доработать права доступа
Как измененно :
1. Для выбора финансовых операций для распределения платежа
теперь используется интерфейс F_OFP::GETMARKCLEARINGBYSH.
1.1 Добавлены новые параметры фильтрации (аналогично всем интерфейсам выбора
финансовых обязательств)
1.2 Доработана возможность множественного выбора финансовых операций.
1.3 Доработаны права доступа.
2.Для всех интерфейсов выбора добавлена возможность установить фильтр по:
- Статье бюджета
- Валюте операции
- Типу платежного средства
F_OFP
Краткое описание :
Формирование нового варианта бюджета при печати платежной
заякиОписание :
Расходование средствЧто измененно :
Обнаружилось следующее:
При установленных настройках
Настройки Галактики\Управление финансами\Платежный календарь\Связь с
бюджетом\Передача данных в бюджет:
. Суммы в бюджете ведутся (5409) - нет
. Приемник данных (5410) - бюджет
. Разрешить формирование плана (5411) - да
Настройки Галактики\Управление финансами\Платежный календарь\Связь с
бюджетом\Идентификация бюджета:
. Тип периода бюджета (5412) - Год
. Вариант (5413) -
. Стадия (5414) -
При запуске на печать платежной заявки формируется еще один вариант бюджета
с типом - год, без варианта и стадии (согласно настроек раздела "Идентификация
бюджета"). Может быть это и логично, но установлена настройка "Суммы в бюджете
ведутся (5409) - НЕТ".
Протестировали и вот результат:
Если настройки раздела "Идентификация бюджета" не заполнены - то новый бюджет
не создается. Также не создается в случае если существует бюджет с типом
периода, вариантом и стадией указанных в настройках "Идентификация бюджета".
Так же проявляется и в заявках на расходование средств.
Как измененно :
Будем считать что связь с бюджетом не настроена,
если не установлена хотя бы одна из настроек
"Настройки Галактики\Управление финансами\Платежный календарь\
Связь с бюджетом\Идентификация бюджета:
. Тип периода бюджета
. Вариант
. Стадия
Доработаны печатные формы документов.
1. Если связь с бюджетом не установлена, то в печатные формы заявок
с разноской по статьям бюджета не выводится сумма "Свободно"
2. Если связь с бюджетом установлена, то при печати обязательств
доступны все три печатные формы: "краткая", "лимиты по статьям",
"разноска по статьям". Если связь не установлена, то форма
"лимиты по статьям" не доступна.
3. Если связь с бюджетом не установлена, то при печати сводного
обязательства с ФОБ и разноской по статьям сумма "Свободно"
не выводится.
Т.о. если связь с бюджетом не установлена, то при печати нет
обращений к бюджетам.
F_OFP
Краткое описание :
Убрать возможность разделить финоперацию если нет прав
доступа на редактированиеОписание :
Журнал обязательствЧто измененно :
Убрать возможность разделить финоперацию (объединить с другой)
если у пользователя нет прав доступа на редактирование обязательства.
Как измененно :
1. Если у пользователя нет прав на редактирование финансового
обязательства, функции "Разделить финоперацию",
"Объединить с другой финоперацией" недоступны.
2. Увеличен размер окна выбора финоперации для объединения.
F_OFP
Краткое описание :
Синхронизация ЦО документа и разноски по статьямОписание :
Расходование средствЧто измененно :
Доработать синхронизацию ЦО заявки и разноски по статьям,
аналогично журналу обязательств.
При значении настройки :
"Настройки Галактики \ Управление финансами \ Платежный календарь \
Права доступа \ Разрешать доступ к смене ЦО в разноске по статьям"
= "Нет" при изменении ЦО документа, значение должно автоматически переносится
в разноску
= "Да" изменять ЦО в разноске по запросу.
Как измененно :
Доработана синхронизация ЦО заявки и разноски по статьям.
При значении настройки :
"Настройки Галактики \ Управление финансами \ Платежный календарь \
Права доступа \ Разрешать доступ к смене ЦО в разноске по статьям"
= "Нет" при изменении ЦО документа, значение переносится в разноску
= "Да" при изменении ЦО документа, ЦО в разноске изменяется по запросу.
Доработка касается ручного изменения ЦО по SHIFT+F3
F_OFP
Краткое описание :
Не работает PgUp-PgDn в поле ПримечаниеОписание :
Заявки на расходование средствЧто измененно :
Не работает PgUp-PgDn в поле Примечание в шапке заявки,
в остальных полях происходит переход на соседнюю заявку.
Как измененно :
Добавлена обработка PageUp PageDown на поле "Примечание" в
заявках
F_OFP
Краткое описание :
Не выполняется расчет оплаченных налогов при формировании
п/п из ПКОписание :
Журнал обязательствЧто измененно :
Не выполняется расчет оплаченных налогов при
формировании п/п из ПК
Как измененно :
Доработан расчет налогов при формировании платежных документов
по
финансовым обязательствам в зависимости от настройки
"Настройки Галактики \ Бухгалтерский контур \ Обработка документов \
Параметры работы с документами различных типов"
F_OFP
Краткое описание :
Запретить формирование платежек по ФОП, если ПС не
взаимодействует с ПКОписание :
Журнал обязательствЧто измененно :
ПК - Документы - Журнал обязательств
Установлена настройка:
"Настройки Галактики \ Управление финансами \
Платежный календарь \ Формирование заявок и
обязательств \ При заполнении ПС учитывать настройки из
раздела "Бухгалтерский учет"=да
Если автоматически привязываемое ПС не
взаимодействует с модулем ПК по настройке:
"Настройки Галактики \ Управление финансами \
Платежный календарь \ Формирование платежных документов
\ Взаимодействие с документами системы",
то при формировании платежных документов по таким
ФОП - не проставляется факт оплаты в Журнале
обязательств ($-оплачено полностью).
Надо запретить формирование платежных документов
по ФОП, ПС которых не взаимодействует с модулем ПК.
Как измененно :
Если у ФОП указано платежное средство, которое не
взаимодействует с
ПК, то при формировании документов (Alt+I)такие ФОП не обрабатываются.
F_OFP
Краткое описание :
Не определяется тип ПС для ФОП взаимозачетаОписание :
Платежные календариЧто измененно :
ПК - Операции - Платежные календари
При построении ПК с группировкой по ПС - не определяется тип ПС =
Дебиторская /Кредиторская задолженность
Как измененно :
Для операции взаимозачета с направлением "расход"
устанавливается
платежное средство "Кредиторская задолженность"
Для направления "приход" соответственно "Дебиторская задолженность"
F_OFP
Краткое описание :
Документы, формируемые по умолчанию по ФОП: авизоОписание :
Настройки модуля ПК в "Настройке"Что измененно :
Настройка ПК: "Настройки Галактики \ Управление
финансами \ Платежный календарь \ Формирование
платежных документов \ Документы, формируемые по
умолчанию по ФОП".
Для ФОП "Передача средств: Расчеты по авизо"
приходный документ по умолчанию = Исходящее авизо.
Должно быть = Входящее авизо.
Как измененно :
для приходного документа по умолчанию устанавливается "Входящее
авизо"