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

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

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

Количество версий компонента251
Количество рещенных задач584
Последная дата обработки компонента2023-12-16 20:17:41
Последная дата файла2023-12-16 17:31:33
Последная версия9.1.152.0

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

F_SOPRHOZ
102.121306
F_SOPRHOZ ( 9.1.006.0 )

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

при привязке ДО слетает ссылка на товарный ПКП

Описание :

Платежное поручение

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


при привязке ДО слетает ссылка на товарный ПКП

Есть Договор в котором 2 финансовых и 1 товарный GRG/
фин №1 авансовый с 01.01.2013 по 10.01.2013 500
фин №2 авансовый с 01.01.2013 по 10.01.2013 1000
тов №3 по факту через 5 дней после фин №2

В фин №1 и фин №2 в схеме указан тов №3.
По фин №1 и фин №2 сформированы ДО на предоплату закупки.
По тов №3 сформирован ДО на закупку.

Формируем ПП на сумму 1500.
Вяжем предоплатные ДО в хозоперации. Получаем 2 ХО на 500 и 1000.
Смотрим на закладке Договор: две записи, в обеих ссылки на тов №3 и на разные финансовые - фин №1 и фин №2. Это верно

Привяжем в обеих ХО ДО на закупку. После на закладке Договор видим, что вместо товарного ПКП тов №3 в обеих записях проставился фин №2.

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


Исправлено. При привязке ДО на предоплату и ДО на
закупку/продажу ссылка на товарный ПКП проставляется
корректно.
F_SOPRHOZ
104.20049
F_SOPRHOZ ( 9.1.006.0 )

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

Обновление поля ТХО в платежном поручении

Описание :

Платежное поручение

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


Обновление поля ТХО в платежном поручении.
Условия проявления проблемы:
1. Устанавливаем значение настройки - "Настройки Галактики \ Бухгалтерский контур \ Обработка документов \
Распределение платежа по ДО \ Изменять ссылку на ДО в поле "Основание" платежного документа" - Нет.
2. Привязываем к платежному поручению ДО.
3. Привязываем ТХО к документу в поле "ТХО" в шапке документа
В результате в системе формируются проводки, на закладке "Хозоперации" в нижней части документа ТХО
привязана (поле SoprHoz.cHozOper), но в поле "ТХО" (поле PlPor.cHozOper) запись не появляется. И
появляется только после того как фокус будет переведен на нижние закладки и назад в шапку.
Просьба исправить данную ошибку.

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


Исправлено.
F_SOPRHOZ
180.5852
F_SOPRHOZ ( 9.1.006.0 )

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

Связь ФОБ с платежным поручением

Описание :

"Платежный календарь" в целом

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


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

Формализовано проблема выглядит следующим образом:
0. Платежный документ (ПД), разнесен по ФОБ. Обычно это выглядит так: одна хозоперация (ХО) разнесена по одной финоперации (ФОП). Период, в котором существует ФОП - в ПК закрыт. Пока все хорошо.
1. Через некоторое время, возникает потребность переразнести ПД по ХО. Обычно, это разделение существующей ХО на несколько ХО. Причем клиент делает переразноску следующим образом: сначала удаляет старую ХО, а потом создает новые ХО.
2. В результате п.1. теряется разноска ПД по ФОБ:
2.1. Новые ХО не разнесены по ФОП
2.2. У прежней ФОП сумма "факт" = 0. И т.к. ФОП находится в "закрытом периоде ПК", то ее сумма в "остатках по счетам" отражается как 0-вая. Что приводит к неверному ведению "остатков по счетам"
3. Ситуация усугубляется, тем что как правило, разделение ХО в п.1., производит "бухгалтер", а не "финансист". В ответственности "финансиста" лежит контроль над корректной разноской ПД по ФОП, "бухгалтер" может не представлять как именно требуется разносить ПД по ФОП.
4. Чтобы исправить ситуацию, приходится повторно производить разноску ПД по ФОБ, а в ситуации двойственной ответственности, практически всегда будут возникать ошибки разноски, когда "бухгалтер" откорректировал разноску ПД по ХО, а "финансист" не произвел соответствующие корректировки по разноске ХО по ФОП.

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


Для решения проблемы, были сделаны следующие доработки:
1. На закладке "ХозОперации" и в окне редактирования хозоперации
(интерфейс F_SOPRHOZ::DOCSOPRHOZ), добавлены функции локального меню:
- Разделение хозоперации
- Объединение хозопераций

2. Разделение хозоперации
Разделить можно хозоперацию, которая доступна для редактирования
и еще не распределена по спецификации накладных.
При вызове функции система просит указать новую сумму
данной хозоперации. Новая сумма не должна превышать текущую сумму.

При разделении пересчитываются налоги, если по хозоперации
еще не сформирована счет-фактура.
Ссылки на ДО, ДО на предоплату, Счет-фактуру наследуется.
Внешние КАУ также наследуются.
Поле "примечание" сохраняется.
Если хозоперация распределена по Финансовым операциям
Платежного календаря, то при разделении исполнение также
делится автоматически.

3. Объединение хозопераций.
Объединять можно помеченные хозоперации.
При этом все хозоперации должны быть
- доступны для редактирования
- не распределены по спецификации накладных
- имеют одинаковое распределение по ДО (либо все не распределены по ДО)
- ссылаться на один и тот же СФ (либо СФ не сформирован ни по одной из ХО)
- без проводок

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

4. При ручном удалении хозоперации добавлена проверка
(предупреждение) на наличие распределения по Платежному
календарю. При групповом удалении предупреждение не выдается.

5. Функция "Распределение по платежному календарю - Alt+R"
Доработано распределение хозопераций с валютным эквивалентом.
Если документ не является валютным, система не требует
распределять его по валютным операциям.



Кроме использования данной доработки, можно использовать решения существующими средствами:
Решение 0:
Для контроля корректности разноски ПД по ФОБ можно пользоваться отчетом: "Платежный календарь | Операции | Распределение платежных документов"
Решение 1:
Разделение ХО на несколько ХО производить, не удаляя "старое" ХО, а уменьшая его сумму. Тогда хоть в одном ХО останется разноска по ФОП. Что будет служить информацией, как надо потом разнести "новые" ХО. В этом варианте все равно надо будет делать разноску ХО по ФОП, но будет намного легче (совместно с "Решение 0").
Решение 2:
"Бухгалтеру" не следует изменять "старое" ХО, а просто в нем поставить признак "не входит в сумму документа" - его разноска по ФОП останется. А "новые" ХО создавать, так как хочется - они не должны быть разнесены по ФОП. Предполагается, что "новые" ХО - "входят в сумма по документу".
F_SOPRHOZ
180.7279
F_SOPRHOZ ( 9.1.006.0 )

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

Заполнение поля DataOt в проводках

Описание :

Не знаю, какая именно часть модуля "ФРО", научите

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


В данный момент складывается неоднозначная ситуация с заполнением поля DataOt в таблице Oborot.
1. При формировании новых проводок данное поле заполняется равным дате проводок (DataOt = DatOb).
2. При копировании бухсправок - DataOt = DatOb
3. При копировании проводок поле DataOt копируется из копируемой проводки (непонятно какое отношение
к текущей проводке итеет исходная проводка, видимо просто недоработка функции копирования).
4. При изменении даты проводки поле DataOt остается неизменным (старая дата).
5. При изменениии даты оплаты по п/п или бухсправке - поле DataOt стается неизменным, поле DatOb
меняется (получается ситуация, когда результат операции зависит от последовательности операций:
если меняем дату оплаты и потом привязываем ТХО или привязываем ТХО и меняем дату оплаты).

Поле DataOt используется в типовом проектном решении для системы Транснефть.
Предлагаю доработать функции, указанные в пунктах 3, 4, 5 для того чтобы поле DataOt менялось
в соответствии с DatOb.
Вариант с тригером нам не подходит, основная проблема в том, что для решения п.3 необходимо делать
тригер before insert, а он замедляет процесс создания проводок примерно на 50% (проверялось на
вставке 6000 проводок). Быстродействие для нас критично.

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


Добавлена настройка "Настройки Галактики \
Бухгалтерский контур \ Обработка документов \
Хозяйственные операции и бухгалтерские проводки \
Синхронизировать дату отчета с датой проводки".
Если данная настройка включена, то в следующих
случаях происходит синхронизация поля "Дата отчета" с
полем "Дата проводки":
- при копировании проводок;
- при изменении поля "Дата обработки" платежного
документа;
- при изменении поля "Дата операции" текущей
хозоперации;
- при изменении даты проводки.

Поле "Дата отчета" можно увидеть в Авансовом
отчете, на закладке "Проводки", в экранном режиме
отображения полей (Alt+S).

9.1.152.09.1.151.09.1.150.09.1.149.09.1.148.09.1.147.09.1.146.09.1.145.09.1.144.09.1.143.09.1.142.09.1.141.09.1.140.09.1.139.09.1.138.09.1.137.09.1.136.09.1.135.09.1.134.09.1.133.09.1.132.09.1.131.09.1.130.09.1.129.09.1.128.09.1.127.09.1.126.09.1.125.09.1.124.09.1.123.09.1.122.09.1.121.09.1.120.09.1.119.09.1.118.09.1.117.09.1.116.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.099.09.1.99.09.1.98.09.1.098.09.1.097.09.1.97.09.1.96.09.1.095.09.1.95.09.1.94.09.1.094.09.1.093.09.1.93.09.1.92.09.1.092.09.1.091.09.1.91.09.1.090.09.1.90.09.1.89.09.1.089.09.1.88.09.1.088.09.1.87.09.1.087.09.1.086.09.1.86.09.1.85.09.1.085.09.1.84.09.1.084.09.1.83.09.1.083.09.1.082.09.1.82.09.1.81.09.1.081.09.1.080.09.1.80.09.1.079.09.1.79.09.1.78.09.1.078.09.1.77.09.1.077.09.1.76.09.1.076.09.1.075.09.1.75.09.1.074.09.1.74.09.1.73.09.1.073.09.1.72.09.1.072.09.1.71.09.1.071.09.1.070.09.1.70.09.1.069.09.1.69.09.1.068.09.1.68.09.1.067.09.1.67.09.1.66.19.1.066.09.1.66.09.1.065.09.1.65.09.1.064.09.1.64.09.1.063.09.1.63.09.1.062.09.1.62.09.1.061.09.1.61.09.1.060.09.1.60.09.1.059.09.1.59.09.1.058.09.1.58.09.1.057.09.1.57.09.1.56.09.1.056.09.1.55.09.1.055.09.1.054.09.1.54.09.1.053.09.1.53.09.1.052.09.1.52.09.1.051.09.1.51.09.1.050.09.1.50.09.1.049.09.1.49.09.1.48.09.1.048.09.1.047.09.1.47.09.1.046.09.1.46.09.1.45.09.1.045.09.1.44.09.1.044.09.1.43.09.1.043.09.1.42.09.1.042.09.1.41.09.1.041.09.1.040.09.1.40.09.1.39.09.1.039.09.1.38.09.1.038.09.1.037.09.1.37.09.1.36.09.1.036.09.1.035.09.1.35.09.1.34.09.1.034.09.1.33.09.1.033.09.1.032.09.1.32.09.1.31.09.1.031.09.1.030.09.1.30.09.1.29.09.1.029.09.1.028.09.1.28.09.1.27.09.1.027.09.1.26.09.1.026.09.1.25.09.1.025.09.1.24.09.1.024.09.1.023.09.1.23.09.1.22.09.1.022.09.1.021.09.1.21.09.1.20.09.1.020.09.1.19.09.1.18.09.1.018.09.1.017.09.1.17.09.1.16.09.1.016.09.1.015.09.1.15.09.1.14.09.1.014.09.1.13.09.1.013.09.1.012.09.1.12.09.1.11.09.1.011.09.1.10.09.1.010.09.1.009.09.1.9.09.1.008.09.1.8.09.1.7.09.1.007.09.1.6.09.1.006.09.1.5.09.1.005.09.1.004.09.1.4.09.1.3.09.1.003.09.1.2.09.1.002.09.1.1.09.1.001.0