Коллеги,

При выравнивании аванса со счетом-фактурой (f-44) выходит сообщение FMUP044 "Данные разделения документа в документе выравнивания противоречивы". Никто не сталкивался с такой проблемой?

Соообщение предупреждающее. При его игнорировании система создает-таки документ обновления: Тип значения - авансовые платежи, сумма - с минусом, вид - оригинал.
В документе обновления фактуры при этом ничего не изменилось.

У нас ERR 6.0, активировано on-line обновление. Сплиттинг тоже активирован.

Буду благодарен за совет.

Это значит у Вас нота накатилась с одним из пакетов, которая понизила статус сообщения до Warning, раньше это сообщение шло как ошибка. Само сообщение означает, что в одном из выравниваемых доков, при их формировании сплиттинг прошел неудачно в части признаков разделения для PSM. Проверьте фактуру, все ли там нормально в части контировок? прошла ли по ней расплиттовка полностью?

Как проверить все ли нормально в счет-фактуре? Как расплитовку проверить?

Я обычно рассплиттовку для определенного документа проверяю прямо в таблице FAGL-SPLINFO. Самые интересные поля с точки зрения бюджета: FIPOS, FISTL, GEBER, KNBELNR, VOBELNR.

Добрый день.
сегодня с утра тоже появились сообщения fmup026, ficustom100 при проводке счет-фактуры дебитора, авансового платежа через тап, выравнивании аванса и счет-фактуры. Поборолась с ошибкой тем что на 68 поменяла позицию на Т502 с Т603. Причем никакие другие ухищрения по сплиттингу не помогали. Теперь при выравнивании аванса дебитора и счет-фактуры выдает FMUP027. У меня BCS, сплиттинг активирован, пятерка, в тапах стоит 1000, 0001, в платеже 1000, AKON, в счет-фактуре 0200, 001, все счета прописаны. Ситуация зеркальна, но это доход. Вы решили для себя эту проблему?

У меня та же проблема при выравнивании авансового платежа со счет-фактурой. Выскакивает предупреждение FMUP044. Если проигнорировать то аванс не сокращает с/ф а ложиться в бюджет с некорректными данными.
Сплитинг настроен в соответствии с руководством. Система ERP6.0

При проводке счет-фактура выглядит следующим образом:

КП Счет Сумма ПФМ ФП Фонд
31 Кредитор 1180- T1(тех) 60.1(тех) Ф1
86 15* 600 П1(реал) ФП1(реал) Ф1
86 15* 400 П2(реал) ФП2(реал) Ф1
40 Т19*(НДС) 180 T1(тех) 30.3(тех) Ф1

Сплитуется вроде тоже правильно. В FAGL_SPLINFO выглядит так:

Док. Поз. ПФМ ФП Фонд Д/К К/П Сумма
N1 1 П1(реал) ФП1(реал) Ф1 H 31 72-
N1 1 П1(реал) ФП1(реал) Ф1 H 31 400-
N1 1 П2(реал) ФП2(реал) Ф1 H 31 600-
N1 1 П2(реал) ФП2(реал) Ф1 H 31 108-
N1 4 П2(реал) ФП2(реал) Ф1 S 40 108
N1 4 П1(реал) ФП1(реал) Ф1 S 40 72

Платеж делаю через АПП на основании ТАП. В позиции ТАП проставляется техническая контировка. Так как если поставить реальную с первой позиции заказа, будет перерасход бюджета (Будет включет АКН).

КП Счет Сумма ПФМ ФП Фонд
29 Кредитор 1180 T1(тех) 30.3(тех) Ф1
50 51* 1180- T1(тех) 90.1(тех) Ф1
40 Т19*(НДС) 180 T1(тех) 30.3(тех) Ф1
50 Т19*(НДС) 180- T1(тех) 30.3(тех) Ф1

Сплитуется вроде тоже правильно. В FAGL_SPLINFO выглядит так:

Док. Поз. ПФМ ФП Фонд Д/К К/П Сумма
N2 1 T1(тех) 30.3(тех) Ф1 S 29 1180
N2 2 T1(тех) 30.3(тех) Ф1 H 50 1180-
N2 3 T1(тех) 30.3(тех) Ф1 S 40 180
N2 4 T1(тех) 30.3(тех) Ф1 H 50 180-

Далее делаю выравнивание через FB05 как частичный платеж.
Помогите разобраться и найти ошибку…

КП Счет Сумма ПФМ ФП Фонд
29 Кредитор 1180 T1(тех) 30.3(тех) Ф1
50 51* 1180- T1(тех) 90.1(тех) Ф1
40 Т19*(НДС) 180 T1(тех) 30.3(тех) Ф1
50 Т19*(НДС) 180- T1(тех) 30.3(тех) Ф1

на мой скромный взгляд платеж некорректен
как минимум вот так должно быть

КП Счет Сумма ПФМ ФП Фонд
29 Кредитор 1180 T1(тех) 60.3(тех) Ф1
50 51* 1180- T1(тех) 90.1(тех) Ф1
40 Т19*(НДС) 180 T1(тех) 30.3(тех) Ф1
50 Т19*(НДС) 180- T1(тех) 30.3(тех) Ф1

Что-то я не понимаю! Зачем в контрольную позицию аванса, пихать технические контировки? Или учет авансов не нужен?

Учет авансов нужен. Техническая кнтирова тянется из ТАПа. ТАП создатеся со ссылкой на заказ. Заказы у нас как правило имеют моножественную кониторовку. У нас планируется включать АКН. Из-за того что система требует указать еще и позицию зказа (чтобы проставить туда только однку реальную контировку) проставляем техническую. Дабы не было перерасхода бюджета. Бюджет деблокиреется еженедельно от того выделенные суммы малы.
Если я что делаю не правильно на более ранноем этапе. Поправьте.

Когда попытался сформировать данный документ через тр. FB01 -получил следующий результат:
1. В начале вылезло предупреждение "Позиция 0000000001 содержит финансовую позицию с фин. операцией, неравной 30". Пропустил сообщение.
2. Далее вылезла "ошибка FI057 (NO INVOICE KEY,LFMPU_RF14)".

Так что быстро проверить не могу. Пошел в глубокий дебаг. Все ноты по данной проблемме не ревантны. EA-PS 6.0 уровень 0011.
Если кто знает как победить сообщите...

1. А нельзя формировать заказы специально по одинаковым ФП (чтобы там в заказе было хотя бы несколько различных позиций)
Вопрос кстати (у нас такого нет просто): а если в заказе куча позиций по 1 ФП они же в ТАПе суммируются и пойдут одной суммой???
2. Как у вас вообще бюджет деблокируется (или хотите это сделать): не по позициям что ли? Тогда всё равно придётся ТАПы делать по позициям.
3. Если вам всё-таки не важна позиция в ТАП, а важна лишь сумма, можно же делать ТАП с привязываться только к первой позиции заказа, будет конечно ФП из этой первой позиции, и сумма не к орректна, но тут уж ничего не поделаешь...провести даст:)
Можно вообще делать ТАП с реальной позицией, без связи с заказом. Правда ведь потом выравнивать придётся аванс с СФ.
В итоге чтобы вы ни делали, при полной оплате по СФ авансовый платёж ваш (с любой позицией:)) выравняется и сократится, а платёж получится из СФ.
Как вы планируете контрль средств без реальных ФП в ТАПе? а СФ вы позиции не из заказа тянете?

Формировать заказы таким образом, чтобы он целиком был на одну бюджетную статью невозможно. Такова жизнь.

Бюджет деблокируется согласно плану оплат на неделю. ТАП создается на один авансовый платеж. Рассматривал вариант формирования ТАПа с несколькими позициями чтобы указывать реальные контировки из позиций заказа. - Не подходит. После прогона АПП документов оплаты формируется столько же сколько и позиций в ТАП.

Сейчас так и делаю. ТАП привязываю к первой позиции заказа. Контировка в нем становится не важна по причине того, что в этом случае сумма ТАП как правило больше суммы по первой позиции. В этой связи думаю сделать обновление ТАП в бюджете статистическим.
На этапе пока платеж не выровнен со с/ф проблема с отчетностью решается с помощью доп. разработок. В этом случае мы вводим понятие «Предварительный факт». Как только поступает в систему с/ф (с правильными контировками) авансы должны быть выровнены с ней (вот тут у меня и возникают ошибки). После выравнивания авансов мы считаем эих как «окончательный факт».
Контроль средств без реальных контировок в ТАПе планируется делать на этапе предварительных документов облиго. Просто ТАП будет их сокращать статистически.

А как он будет их сокращать если там техническая ФП? Я думаю, что нужна реальная статист ФП.

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

В общем то я и тестирую сейчас примерно в таком режиме. ТАП не создаю. Просто ввожу авансовый платеж через fb01 с технической контировкой (формируемые документы описаны мною выше) пытаюсь его выровнять со с/ф. вываливается ошибка. Мне кажется что система всеже должна сделать все правильно.
Как сокращать документы облиго это отдельная песня... Думаю выкрутится с помощью доп разработок и отчетов. Это сейчас не главное, как мне кажется...

Задам еще вопрос. ФП какого типа у вас стоит в настройке по обработке констант для неприсвоенных процессов. При включенном сплитинге. От этого сильно зависит поведение системы при вводе платежа и выравнивания.

Вот в этом то и дело! Я думаю аванс нужно вводить с реальной статист позицией. Вот тогда ошибки наверное не будет.

Сплитигна у нас нет. Что то тестим, что то работает. Вот так точно всё без ошибок: для поступлений всё садится на 1 позицию авансов (реал. стат), потом при выравнивании со СФ аванс сокращается, а при прогоне программы обновления платежей СФ становится платежом. У вас по идее примерно тоже для выплат должно получиться, только без прогона программы.