Текущие компоненты

Название продукта Название компонента Тип Последняя версия Дата выхода
Галактика ERP 9.1F_PODOTRES

Справка по компоненту.

Количество версий компонента127
Количество рещенных задач366
Последная дата обработки компонента2023-12-16 20:05:33
Последная дата файла2023-12-16 17:31:32
Последная версия9.1.126.0

Новые задачи в этом компоненте

F_PODOT
102.119938
F_PODOT ( 9.1.8.0 )

Краткое описание :

Формирование платежных документов

Описание :

Командировки сотрудников

Что измененно :

Необходимо реализовать возможность Формирования платежных
документов по реестрам, созданным по приказу на командировку.
При этом необходимо чтобы банковские реквизиты в платежном документе
автоматически подставлялись из лицевого счета сотрудника.
Клиент пишет: "нашему бухгалтеру просто нецелесообразно формировать
платежные поручения через приказы на командировку. Наш бухгалтер формирует
платежи и реестры на командировочные расходы в ФРО, при этом связь между
командировочными документами либо необходимо настраивать вручную, либо вообще
отсутствует."

Как измененно :

Добавлена возможность формирования реестров по
текущему приказу или по помеченным приказам на
командировки с разбивкой по банкам из лицевых счетов
сотрудников.
В окно формирования реестров (вызывается из
локального меню в списке приказов "Формирование реестра
по перечислениям") добавлено поле "Группировать по
банкам из лицевых счетов сотрудников". Если поставить
галочку - поля для указания организации и банка
скрываются, а реестры формируются с разбивкой по банкам
из лицевых счетов сотрудников.
Реализовано как для текущего приказа, так и для
помеченных приказов.
По окончанию формирования реестров выдается
соответствующее сообщение.
F_PODOT
102.122707
F_PODOT ( 9.1.8.0 )

Краткое описание :

Необходим анализ дат командировок при редактировании приказа, если табель закрыт

Описание :

Командировки

Что измененно :

При редактировании приказа анализируются настройки:
'Запретить ввод системных неявок на период защищенных
табелей'
'Защитить проверенные табели от модификации'
'Защитить проверенные табели от обновления'
При закрытом табеле редактирование приказа на
командировку не допускается, что неправильно.
Например, человек находится в командировке с конца
февраля по 10 марта. Защищён от модификации только
февральский табель, и необходимо откорректировать дату
окончания командировки (продлить либо сократить на пару
дней). Программа, не разбираясь в деталях происходящего,
просто запрещает редактировать данный приказ, а ведь
изменения никоим образом не затрагивают данные февральского
табеля. Такой алгоритм считаем неправильным. Необходимо
анализировать относятся ли редактируемые данные к закрытому
табелю.

Как измененно :

При изменении сроков командировки анализируется период
командировки на попадание в закрытый табель.
F_PODOT
102.124274
F_PODOT ( 9.1.8.0 )

Краткое описание :

Некорректный подсчет дней в пути в многоэтапных приказах на командировку

Описание :

Командировки

Что измененно :

Установлены следующие общесистемные настройки:
1. Настройки Галактики \ Бухгалтерский контур \ Обработка документов \ Значения
полей по умолчанию \ Приказы на командировку Срок командировки в формируемом
приказе на командировку : Значение 0;
2. Настройки Галактики \ Бухгалтерский контур \ Обработка документов \ Значения
полей по умолчанию \ Приказы на командировку Время нахождения в пути в
формируемом приказе на командировку : значение 0.

При создании нового приказа на командировку в поле "Дата с" Система проставляет
текущую дату, в поле "командировка на" устанавливается значение 0,
в поле "из них в пути" значение 0.

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

Как измененно :

Подсчет дней командировки ведется корректно.
F_PODOT
102.124576
F_PODOT ( 9.1.8.0 )

Краткое описание :

В неверной валюте формируются реестры по перечислениям из приказа на командировку

Описание :

Приказы на командировки

Что измененно :

В неверной валюте формируются реестры по перечислениям из
приказа на командировку

В приказе на командировку в спецификации в поле "В валюте статьи расходов"
отличается от аналогичного поля "В валюте аванса".
Например, статья расхода "НДЕ", аванса - "евро".
Формирую реестр по перечислениям по данному приказу, с параметром "Формировать
- в разрезе валют".
В реестр заносится сумма из поля НДЕ, а валюта реестра указывается "евро".
При последующем формировании из такого реестра платежного документа в него
переносится сумма НДЕ в поле валюты, и, соответственно, пересчитывается в
рубли. Что приводит к формировании платежки на неверную сумму в рублях и валюте.

Как измененно :

Реестры в разрезе валют формируются в сумме и валюте статьи
расходов.

Если в приказе валютой статьи расходов являеися НДЕ, то в режиме "в разрезе
валют" реестр формируется в НДЕ.
F_PODOT
102.124605
F_PODOT ( 9.1.8.0 )

Краткое описание :

В новой редакции форма командировочного удостоверения РБ

Описание :

Приказы на командировки

Что измененно :

Постановление Минфина РБ от 4.02.2013 г. №4
утвердила новую редакцию Инструкции о порядке и
размерах возмещения расходов при служебных
командировках в пределах РБ.
Соответственно, в новой редакции утверждена форма
КОМАНДИРОВОЧНОГО УДОСТОВЕРЕНИЯ.
Изменения в форме только по тексту
командировочного удостоверения.
Ссылка в форме должна быть уже на новое
постановление.

Как измененно :

Форма командировочного удостоверения РБ доработана в
соответствии с требованиями.
Доработаны отчеты командировочного удостоверения в формате RTF, Fast-report.
F_PODOT
102.124607
F_PODOT ( 9.1.8.0 )

Краткое описание :

Необходимо реализовать групповое командировочное удостоверение РБ

Описание :

Приказы на командировки

Что измененно :

Постановление Минфина РБ от 4.02.2013 №4
утверждена форма командировочного удостоверения при
направлении в служебную командировку группы работников.

Как измененно :

В печать групповых документов добавлена печать формы группового
командировочного удостоверения постановления МинФина РБ от 04.02.2013г. №4

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

Сформировать групповое командировочное удостоверение возможно по помеченным
сотрудникам как в одноэтапных так и в многоэтапных приказах. Если ничего не
помечать - печатается текущая запись (Аналогично других форм Т9а)
& УНАСЛЕДОВАННЫЕ ИЗМЕНЕНИЯ БАЗОВЫХ ФОРМ:
FORMT9A
F_PODOT
102.124610
F_PODOT ( 9.1.8.0 )

Краткое описание :

Новая редакция журнала учета работников,выбывающих в служебные командировки РБ

Описание :

Приказы на командировки

Что измененно :

Постановлением Минфина РБ от 4.02.2013 №4 в новой
редакции изложена форма журнала учета работников,
выбывающих в служебные командировки.

Как измененно :

Форма журнала учета работников, выбывающих в служебные
командировки доработана в соответствии с требованиями.
F_PODOT
102.124771
F_PODOT ( 9.1.8.0 )

Краткое описание :

ошибка при формировании командировки на основании имеющейся

Описание :

Командировки

Что измененно :

Ошибка при формировании командировки на основании имеющейся.
При формировании командировки на основании
имеющейся, Галактика выдает ошибку.

Как измененно :

Если в номере приказа на командировку отсутствуют цифровые
символы, то при создании приказа к номеру добавляется цифра "1" для возможности
последующей нумерации.
F_PODOT
102.126016
F_PODOT ( 9.1.8.0 )

Краткое описание :

При продлении командировки удаляется предыдущий переход в межпериод.

Описание :

Командировки

Что измененно :

При продлении командировки удаляется предыдущий переход в
межпериод.

Как измененно :

При создании приказа на основании имеющегося переход в
межпериод старого приказа остается неизменным. Для нового приказа, при
необходимости, переход создается через локальное меню "Переход в межпериод".
F_PODOT
102.126538
F_PODOT ( 9.1.8.0 )

Краткое описание :

Доработать печатную форму командировочного удостоверения в бизнес-тексте

Описание :

Приказы на командировки

Что измененно :

Постановление Минфина РБ от 4.02.2013 г. №4
утвердила новую редакцию Инструкции о порядке и
размерах возмещения расходов при служебных
командировках в пределах РБ.

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

Как измененно :

Доработана форма командировочного удостоверения для Беларуси
согласно требованиям в формате Бизнес-текст.
F_PODOT
101.40881
F_PODOT ( 9.1.8.0 )

Краткое описание :

Функция GetFIO не сокращает имя и отчество

Описание :

Интерфейс картотеки

Что измененно :

Необходимо функцию формирования сокращенной записи ФИО
перенести в отдельный метод объектного интерфейса.

Как измененно :

Выполнен рефакторинг кода - реализован новый метод,
преобразующий ФИО в формат "Фамилия И.О.". Функциональность системы не
изменялась.
F_PODOT
102.109377
F_PODOT ( 9.1.8.0 )

Краткое описание :

Необходима возможность ручного заполнения организации в спецификации АО

Описание :

Авансовый отчет

Что измененно :

В настоящее время заполнить организацию в спецификации АО можно
только 1 способом:
- установить значение настройки "Синхронизировать
спецификацию авансового отчета с хозоперацией" в "да";
- выбрать в спецификации АО норму с заполненной
организацией и ТХО;
- произвести формирование хозоперации по ctrl + enter;
- по F4 зайти в редактирование расходов и перевыбрать нужную организацию.

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

Как измененно :

В 9.1 изменилось заполнение организации в спецификации АО.

Краткое описание изменений
--------------------------

В версии 9.1 в словарь добавлено новое поле RashDoc.cOrg для хранения
контрагента по статье расходов и реализован функционал по данному полю.

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

А также решается задача разграничения прав разных пользователей системы с
разными правами по работе с АО. Сейчас контрагент в спецификации АО будет
заполняться при выборе нормы так же, как и страна, и город. И до формирования
хозопераций можно его менять любым способом. Т.е. пользователь, который только
заполняет спецификацию АО, может внести требуемую информацию полностью, и
следующий пользователь, который формирует хозоперации, может не беспокоиться о
том, как на основании внесённых предыдущим пользователем данных сформируются
хозоперации, проводки и счета-фактуры - он просто их формирует, ничего не
переделывая.

Подробное описание изменений
----------------------------

1. Доработано отображение и изменение контрагента.

В окне редактирования и в браузере спецификации АО отображается новое поле -
контрагент статьи расходов.

Поле можно редактировать:
- выбирать контрагента по F3 из справочника организаций;
- сбрасывать его значение Del-ом.

Поле доступно для изменений всегда, вне зависимости от условий для
синхронизации, которые ранее были обязательными для его отображения: значение
настройки "Синхронизировать спецификацию авансового отчета с хозоперацией" и
заполненность ссылки на хозоперацию по норме (RashDoc.cKredCard) теперь не
влияют на отображение контрагента в спецификации.

Но указанные условия по-прежнему срабатывают при любом изменении контрагента в
спецификации (выбор значения, удаление). При выполнении вышеперечисленных
условий выполняется синхронизация статьи расходов спецификации с хозоперацией и
записью на закладке "ДокОснования" - а именно, контрагент из спецификации
копируется в хозоперацию и запись BaseFin: ссылки SoprHoz.cOrg и BaseFin.cOrg
становятся равными RashDoc.cOrg. В противном случае, как и ранее, синхронизация
не производится.

В РКО, ВРКО контрагент по-прежнему скрывается и не отображается в браузере
спецификации (у АО, РКО, ВРКО браузер общий).

2. Добавлено заполнение организации при выборе нормы.

2.1. При выборе нормы расходов заполняется контрагент в спецификации.

Если был групповой выбор норм, то контрагент, соответственно, заполняется во
всех статьях расходов, созданных по данным нормам, а не только в текущей статье
расходов.

2.2. При этом, в текущей статье расходов, если выполняются условия для
синхронизации, производится копирование заполненного после выбора нормы
контрагента спецификации в хозоперацию и в запись на закладке "ДокОснования".
Ранее такая синхронизация после выбора нормы не производилась: чтобы обновить
контрагента, необходимо было переформировать хозоперации по спецификации.

3. Доработано формирование хозопераций по спецификации АО.

При формировании хозопераций по спецификации АО контрагент берётся из статьи
расходов.

Алгоритм определения контрагента для хозоперации и записи BaseFin:

1) Наибольший приоритет имеет контрагент в статье расходов. Если поле
"Контрагент" в окне редактирования статьи расходов заполнено, то его значение
подставляется в формируемую хозоперацию.

2) Если контрагент в статье расходов не заполнен, алгоритм проверяет
заполненность поля "Организация" в норме расходов, привязанной к статье
расходов. Если данное поле заполнено, оно подставляется в хозоперацию.

3) Последний приоритет имеет контрагент из документа (поле "Организация" в окне
редактирования АО). Данная организация подставляется в хозоперацию, если не
сработали пункты 1) и 2), а также в случаях, когда:
- синхронизация выключена (настройка "Синхронизировать спецификацию авансового
отчета с хозоперацией" установлена в значение 'нет');
- включена настройка "Сворачивать одноименные операции в авансовых отчетах".

Примечание. Если по спецификации документа не нашлось ни одной ТХО в нормах
расходов, по спецификации формируется одна пустая хозоперация - контрагент в
этом случае, как и прежде, берётся из документа.

Таким образом, если необходимо, чтобы при формировании хозопераций по
спецификации в хозоперацию и в запись на закладке "ДокОснования" подставлялся
контрагент из статьи расходов спецификации АО, нужно, чтобы:
- настройка "Синхронизировать спецификацию авансового отчета с хозоперацией"
была установлена в значение 'да';
- настройка "Сворачивать одноименные операции в авансовых отчетах" была
установлена в значение 'нет';
- контрагент в статье расходов был заполнен.

9.1.126.09.1.125.09.1.124.09.1.123.09.1.122.09.1.121.09.1.119.09.1.118.09.1.116.09.1.120.09.1.117.09.1.115.09.1.114.09.1.113.09.1.112.09.1.111.09.1.110.09.1.109.09.1.108.09.1.107.09.1.106.09.1.105.09.1.104.09.1.103.09.1.102.09.1.101.09.1.100.09.1.99.09.1.98.09.1.97.09.1.96.09.1.95.09.1.94.09.1.93.09.1.92.09.1.91.09.1.90.09.1.89.09.1.88.09.1.87.09.1.86.09.1.85.09.1.84.09.1.83.09.1.82.09.1.81.09.1.80.09.1.79.09.1.78.09.1.77.09.1.76.09.1.75.09.1.74.09.1.73.09.1.72.09.1.71.09.1.70.09.1.69.09.1.68.09.1.67.09.1.66.09.1.65.09.1.64.09.1.63.09.1.62.09.1.61.09.1.60.09.1.59.09.1.58.09.1.57.09.1.56.09.1.55.09.1.54.09.1.53.09.1.52.09.1.51.09.1.50.09.1.49.09.1.48.09.1.47.09.1.46.09.1.45.09.1.44.09.1.43.09.1.42.09.1.41.09.1.40.09.1.39.09.1.38.09.1.37.09.1.36.09.1.35.09.1.34.09.1.33.09.1.32.09.1.31.09.1.30.09.1.29.09.1.28.09.1.27.09.1.26.09.1.25.09.1.24.09.1.23.09.1.22.09.1.21.09.1.20.09.1.19.09.1.18.09.1.17.09.1.16.09.1.15.09.1.14.09.1.13.09.1.12.09.1.11.09.1.10.09.1.9.19.1.9.09.1.8.09.1.7.09.1.6.09.1.5.09.1.4.09.1.3.09.1.2.09.1.1.0