Это константы для сплиттинга, имеется ввиду что Вы их не руками вколачиваете в проводку, т.е. на 50-м должно быть в любом случае указано 901. Даже если вы в позицию с контрагентом вколотите 602 или 603, все равно в сплиттинге пройдет та константа, которая будет указана в настройках AKONT

Т.е. я в варианте сплиттинга AKON для Item category 0200 Customer должен указать константу AKONT1 у которой указана ФП1 602, для Item category 0300 Vendor константу AKONT2 у которой указана ФП2 603 и для Item category 0400 Cash Account константу AKONT3 у которой указана ФП3 901?
И ФП1, ФП2, ФП3 должны быть не уже существующие, созданные для конкретных счетов ГК: Контрольного по Дебитору, Контрольного по Кредитору и 50-го счета (Счета кассы), а именно технические (специально дополнительно созданные) и к тому же статистические?

Думал что нужно использовать для всех Item category: 0200 Customer, 0300 Vendor и 0400 Cash Account, то что Вы советовали:

в настройках константы AKONT прописываете с типом 30 и индикатором статистики, но это не значит, что в проводке ручками в позицию 50-м счетом нужно вбивать эту ФП. Это разные вещи. В позицию с 50-м счетом в проводке ставите 90/1

я имела ввиду те ФП, которые Вы указываете в проводке, а не в настройках константы AKONT (для AKONT указываете конечно с типом 30 статистическую, как и обсуждалось ранее)

А теперь понял о чем Вы говорите! Да конечно в проводке ФП я руками не меняю, я вообще никогда не вбиваю ФП в документ FI, т.к. в FMDERIVE у меня все равно ФП просаживается из счета ГК.

Посмотрел что у меня сохраняется в обоих случаях:

1. для документа DX (бизнес операция: 1000 платеж, вариант: AKON Payment on account for online Update FM)
в ФП у входящего платежа в FI-документе - там все нормально
Дт касса ФП сооответствующая счету кассы 901
Кт ДЗ ФП сооответствующая счету ДЗ 602
а вот в таблице FAGL_SPLINFO, как я и писал прописываются
1-ая позиция HKONT(счет ГК) = Касса, FIPOS (ФП) = ФП прописанная в константе AKONT 30/2 статистическая
2-ая позиция HKONT(счет ГК) = Дебиторская задолженность, FIPOS (ФП) = ФП прописанная в константе AKONT 30/2

2. для документа DZ (бизнес операция: 1000 платеж, вариант: 0001 стандарт)
в ФП у входящего платежа в FI-документе - все так же как у документа DX
Дт касса ФП сооответствующая счету кассы 901
Кт ДЗ ФП сооответствующая счету ДЗ 602
а вот в таблице FAGL_SPLINFO, как я и писал прописываются
1-ая позиция HKONT(счет ГК) = Касса, FIPOS (ФП) = ФП сооответствующая счету ДЗ 602
2-ая позиция HKONT(счет ГК) = Дебиторская задолженность, FIPOS (ФП) = ФП сооответствующая счету ДЗ 602

Т.к. ни по:
a) ФП прописанной в константе AKONT 30/2 статистическая
b) ФП сооответствующой счету ДЗ 602
не создается в УБ позиций для платежей ни для типа DX ни для типа DZ, и при выравнивании платежа любого из этих типов пишется одинаковое предупреждения: "Найти счет-фактуру УБ для <БЕ> <№ платежа> 2009 002 было невозможно. № сообщения FICUSTOM114"
Игнорируя в обоих случаях предупреждение, получаем в УБ одинаково правильные проводки.
Вот и возник вопрос - как все таки правильней проводить такой платеж? Как DX(платеж без ссылки на счет) или как DZ(стандартный платеж) и если как DХ, то что нам дает просадка в Fagl_Splinfo FIPOS (ФП) = ФП прописанная в константе AKONT 30/2 статистическая?
Или я что не донастроил и различия между DX и DZ должны быть в чем то другом?

Спасибо большое Delicia, за то что уделяете на помощь так много своего времени!

Может быть что-то недонастроили, у меня тоже поначалу было такое сообщение, но после окончания всех настроек ушло.
Но из-за него не нужно беспокоиться, оно из класса настраиваемых и можно настройками его не выводить.
Вы правы, здесь в УБ позиций не будет, а в сплиттинговых таблицах нужен адрес, в случае если захотите отчетность какую-нить строить по таким операциям и т.д.


Велкам )) Вообще лучше все-таки постоплату создавать сразу выравнивая на фактуру, либо проводить как аванс

Да, как отключить сообщение я нашел, - но посчитал что если отключу, получу где нибудь не правильную просадку информации . Видимо придется все таки отключать.
А насчет получения отчетности, подскажите плиз, в каких таблицах (за исключением FAGL_SPLINFO) я могу взять информацию по проводкам сделанным на ФП, прописанную в константе AKONT 30/2, и заведенную как статистическая?
И еще, в чем то схожий вопрос: а по ФП 901, 602, 603 можно в какой либо таблице посмотреть какие по ним проводки выполнялись?
А то сейчас я могу смотреть только проводки в УБ на ФП 302, 303 и соответственно выстраивать отчетность только по ним.


Не получается, т.к. мы делаем автоматическую загрузку банковской выписки, при которой и создаются такие платежи, зато затем можем запустить автоматическое выравнивание - либо F-13, либо J3RCALD и выравнять все платежи и с/ф дебиторов скопом, а не создавать каждый платеж с выравниванием со с/ф дебитора вручную.
Точнее получается, но для нас этот вариант наоборот исключение - когда нужно что то дозавести без загрузки банковской выписки.

так сходу только она приходит на ум, по крайней мере в ней есть самое главное


только в FI-х таблицах получается будет что-то по ним


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

Получается, если мне отчетность по ФП, прописанной в константе AKONT 30/2, не нужна (а т.к. если ее формировать можно только из FAGL_SPLINFO, - то она мне точно не нужна), то смысла платеж Дт касса Кт Дебитор, нет никакого смысла привязывать к бизнес операции: 1000 платеж, вариант AKON? Т.к. бизнес операция 1000 платеж и вариант 0001 Стандарт: a) документы УБ формирует так же, b) в FI документах оставляет те же ФП c) и только в позициях Fagl_Splinfo просаживает другие ФП (ФП, соответсвующие ДЗ 603, а не ФП, прописанные в константе AKONT 30/2 статистические).

Но в одном случае четко увидел ситуацию в которой без бизнес операции: 1000 Платеж и варианта: AKON, не обойтись - когда делал выравнивание платежа (пробовал создавать обоими вариантами и AKN1(в константа проставлял ФП для вход платежей) и 0001 стандарт) с счет фактурой, то при проводке документа выравнивания DO (бизнес операция: 0000 Неспецифицировано, вариант: 0001) система писала ошибку: "константа AKONT не настроена для таблицы итоговых записей", когда правило с бизнес операцией: 1000 платеж, вариант AKON у меня не было создано. При создании же этого правила, посмотрел в моделировании сплитинга у меня начало подтягиваться автоматически правило основанное на бизнес операции: 1010 Транзакции выравнивания (ведение счета), вариант: 0001 стандарт, хотя у меня, как я и писал выше, для DO у меня было присвоена бизнес операция: 0000 Неспецифицировано, вариант: 0001. Где отработало правило с бизнес операцией: 1000 платеж, вариант AKON, я так и не понял, но факт остается фактом что без этого правила документ выравнивания не проводится, а вылетает в ошибку.


грустно, зачем тогда так тщательно продумывать какую финоперацию проставлять у ФП 90, 60 или 50, если нигде в УБ это нельзя использовать. Проставил любое значение, главное не 30, и пользуйся , - все же равно одинаково будет отрабатывать: в УБ ничего создаваться не будет, в FI документах на ФП с какой финоперацией она создано не просмотришь - если какую то отчетность с уетом финоперации делать, то только через ABAP-разработку. Думал что в УБ, на этот счет, хотя бы по ФП с финоперациями 90 и 60 что то задействовано .


ну если есть достаточная инфа для автовыравнивания, то тогда можно настроить автовыравнивание прямо при загрузке банковской выписки[/quote]
К сожалению критериев для автовыравнивания не всегда хватает для автовыравнивания при загрузке банковской выписки - насколько объяснил консультант, настраивавший у нас банковскую выписку, при загрузке можно использовать только F-13, а если сумма платежа не совпадает с суммой выравниваемой(ых) счет фактур ДЗ, то выравнивание не произойдет, мы в таком случае используем пост выравнивание J3RCALD, который позволяет выравнивать с позицией остатка (как нам нужно).

смысл есть, так как при определенных операциях уже сейчас будут проблемы (как в примере, который Вы описали ниже). К тому же после наката пакетов поведение системы может измениться и корректные настройки станут критичны для тех операций которые до обновлений проходили вроде как нормально. Такое часто бывает, когда после наката какой-нить ноты вдруг другой процесс, который вроде как отрабатывал нормально, начинает вести себя некорректно, вот тут и выясняется что кто-то забыл или не знал, что надо было сделать по стандарту полностью настройки. Так что лучше не рисковать, особенно со сплиттингом в newGL. Сап считает критичным менять настройки сплиттинга, если были проводки.


Не советую использовать "любое значение, главное не 30", от фин.операции зависит то, как регистр будет воспринимать сокращения и платежи при выравнивании. Есть существенная разница между 90 и 80 или 60. Если не хочется потом проблем при выравниваниях и отменах со сторно и выстраивании цепочек документов, опять же при накатах патчей, необходимо соблюдать определенные правила

Если брать сочетание фин.операций 90 и 60, то оно означает что для Вас эта операции незначима до тех пор, пока Вы не выравняетесь с фактурой. Дальше логика простая, указали что не значима - значит и отчетность собирать не надо, зачем засорять регистр.
Если нужна отчетность, значит определяйте как значимую (аванс, выравнивание и т.д.), тогда и в регистре все будет и отчетность будет можно собрать стандартом без ABAP-а. Необходимо все-таки реализовывать свои потребности теми средствами, которые для этого предназначены и больше подходят

Да, о таком развитии событий не подумал . Спасибо, что предупредили!
Тогда ответьте пожалуйста на следующий вопрос - я собирался для платежей без ссылки на счет создать 3-варианта бизнес-операции 1000 Платеж:
1. Вариант для входящих платежей - AKN1 с присвоенной константой AKNT1 имеющей ФП входящие платежи без ссылки на счет 30/2 статистическая, и затем определить этот вариант для документа входящих платежей без ссылки на счет - тип DX
2. Вариант для исходящих платежей - AKN2 с присвоенной константой AKNT2, имеющей ФП исходящие платежи без ссылки на счет 30/3 статистическая, и затем определить этот вариант для документа исходящих платежей без ссылки на счет - тип KX
3. Вариант описанный в документе Payment Update Online - AKON с присвоенной константой AKONT, имеющей ФП платежа без ссылки на счет 30/2 (тип ФП поставил первый попавшийся) статистическая, - как описывал выше даже не определяя этот вариант он у меня все равно требуется при выравнивании.
Но сейчас задумался, может и в 1-ом и во 2-ом пункте все таки правильней было присвоить для DX и KX тот же вариант AKON? А то вдруг где то неправильно отыграется то, что входящие платежи без ссылки на счет, сформированные вариантом AKNT1, в Fagl_Splinfo будут иметь не те ФП, что ФП используемая в варианте AKON, который каким то образом отрабатывает при выравнивание этого входящего платежа и счет фактуры дебитору. Сейчас пробовал создавать DX и с вариантом AKN1 и AKON, затем выравнивать - никакой разницы в работе не заметил - одинаково вылетает предупреждение: "Найти счет-фактуру УБ для <БЕ> <№ платежа> 2009 002 было невозможно. № сообщения FICUSTOM114". Игнорируя которое в обоих случаях, получаю в УБ одинаково правильные проводки.



Тогда точно, для правильной логики работы Бюджетирования, финоперации 90,60 в самом деле очень важная вещь. Но я еще надеялся что по ним еще и стандартная отчетность какая то предусмотрена. Спасибо, большое за исчерпывающие ответы, в голове хоть что то начинает более менее упорядочиваться!

И еще, если можно, ответьте пожалуйста на один вопрос:
Когда мы создаем ФП для константы AKONT как статистическую, а затем при проведении платежей используем ее в платежах без ссылки на счет, не происходит ли у нас неучета в Платежном бюджете (ПлБ) прихода/расхода денег?

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

Или может я как то не правильно интерпритирую ситуацию?

в бюджетах не отразится движение, опять же потому что операция назначимая


если правильно все провести, то, конечно, выплаты отразятся. Для АПП должна быть ОП, чтобы выплатить что-то - это будет либо ТАП (в УБ пройдет все по нему и будут потреблены), либо начисление - будет платеж с видом суммы 250.
Если же у Вас безакцепт, тогда зависит от того как организуете, на что посадить деньги в бюджете.


по статистической потребления не будет. Имеется ввиду что Вы такие платежи без ссылки проводите отдельным видом дока, чтобы потом обработать, когда будет достаточно для этого информации.
Зависит, конечно, от того как идут бизнес-процессы на конкретном предприятии, обычно деньги просто так не платят, есть некие процедуры согласования и акцепты и в этом процессе как раз бюджет у Вас и потребляется. Выписка - это уже постфактум, деньги уже ушли ранее. При обработке выписки просто меняется статус на подтвержденный выпиской платеж

imho мне кажется можно не париться и обойтись одним AKONT