Выравнивание оплачиваемых счетов-фактур с помощью функциональности обработки платежных поручений
При работе с функцией автоматической обработки платежей для оплаты непогашенных счетов-фактур, как правило, выполняется выравнивание обрабатываемого счета. Поэтому в списке открытых позиций кредитора эти счета как открытые позиции не отображаются. Однако в соответствии с требованиями в некоторых странах оплаченные счета-фактуры должны оставаться открытыми. В статье предлагается решение этой проблемы с помощью функциональности обработки платежных поручений в SAP-системе.
| Ключевое понятие |
| Для выполнения автоматических платежей без выравнивания оплаченных счетов-фактур компания SAP разработала функциональность платежного поручения. С помощью платежных поручений оплаченные счета-фактуры выравниваются только при обработке выписок из счета. Таким образом, выравнивание оплаченных счетов-фактур посредством платежного поручения отличается от стандартной процедуры выравнивания. |
В некоторых странах, например, в России и в скандинавских странах автоматически оплаченные счета-фактуры должны оставаться открытыми до подтверждения платежа посредством входящей выписки из счета. При таких условиях необходимо использовать так называемые платежные поручения для автоматических платежей.
Счета-фактуры, оплаченные с помощью платежных поручений, можно выровнять только после подтверждения платежа входящей выпиской из счета с использованием в качестве ссылочного документа платежного поручения. Входящие выписки из счета можно обработать вручную или электронным способом. Электронные выписки из счета обрабатываются с помощью кода транзакции FF_5; для выписок с обработкой вручную используется транзакция FF67; счета-фактуры, оплаченные посредством платежных поручений можно выровнять только с использованием платежного поручения в качестве ссылочного документа. Это означает, что для выравнивания счетов-фактур на базе платежных поручений требуется дополнительная настройка.
Рассмотрим способы конфигурирования платежных поручений и их применения для выполнения автоматических платежей. Кроме того, далее описан процесс выравнивания вручную счетов-фактур, оплаченных посредством платежных поручений, и обработка выписок из счета.
Оформите подписку sappro и получите полный доступ к материалам SAPPRO
Оформить подпискуУ вас уже есть подписка?
Войти
Обсуждения
3
Комментарий от
Артем Седловский
| 17 октября 2011, 19:31
Если хотите сделать иностранные статьи читабельными и читаемыми на Вашем ресурсе, пожалуйста, никогда не публикуйте их сразу после получения перевода из бюро переводов. Обязательно покажите кому-нибудь из русскоязычных консультантов. Судя по последнему абзацу, Кис ван Вестероп - не только грамотный, но и бывалый эксперт. То есть не только матчасть знает, но и умеет с целевой аудиторией общаться. А из статьи получается, что:
1. Он не понимает, для кого пишет статью - для полных чайников, или все-таки консультантов САП. Не для гуру, которые и так все изложенное знают, но для уже имеющих какой-то опыт специалистов.
2. Он не знает, что с помошью описанного им инструмента можно выравнивать не только счета-фактуры, но и счета на предоплату.
3. Он игнорирует правило хорошего тона, что в статьях следует давать ссылки на источники. Например, что алгоритм интерпретации 029 (как и все остальные стандартные) с правилом заполнением экрана в FF_5 описан в ноте 114713.
4. Он любит FF_5 и злостно игнорирует FF.5
5. FF_5 и FF.5, как и FF67 - это программы обработки выписки. На самом деле, обработка - их не главное назначение, а "бантики", а главное назначение - просто ввод. Да, из них можно выписки проводить и даже выравнивать, но можно даже и не проводить в бухгалтерский учет. Главная их задача - структурированно засунуть выписку в банковские таблицы FEB*. Вот транзакция FEBA и ее обновленная версия FEBAN - это действительно транзакции обработки.
6. Из самого заголовка следует, что выравнивание делается автоматической программой платежей, а из текста - и это правильно - не АПП, а программой обработки банковской выписки. Наверное, это самая главная несуразица статьи в представленном виде.
7. Автор с 20-летней практикой не считает нужным обратить внимание на организационные вопросы. Формулировка основного вопроса достаточно проста: чтобы использовать номер платежки для выравнивания кредиторских позиций на основании выписки, нужно объяснять банку, где именно в файле электронной выписки должен сидеть тот номер платежки, который вы хотите использовать для выравнивания. Я впервые столкнулся с хаосом в форматах именно на европейском проекте, не в России. И там тоже эта проблема есть: 50 обслуживающих банков - 50 трактовок, что есть формат SWIFT. Привести все трактовки к общему знаменателю для своего клиента - это совсем не настройка системы SAP, но этим надо заниматься. Не сказать, что время согласования прямо пропорционально количеству обслуживающих банков: кто-то просто соглашается с вашей трактовкой формата, кто-то начинает упираться. В моем случае Райффайзен-Вена по умолчанию выдавал необходимый мне формат, а Райффайзен-Одесса несколько месяцев мне объяснял что мои хотелки реализовать невозможно, а потом за неделю сделал нужный формат.
Уважаемая редакция!
У проекта вон сколько участников http://sapland.ru/club_sl/all/
Наверняка среди них найдутся желающие довести до ума статьи, переведенные профессиональными переводчиками, но еще сырые для публикации. Ведь всегда такие энтузиасты найдутся среди такого количества.
С уважением,
Артем Седловский
Комментарий от
Юрий Нечитайлов
| 18 октября 2011, 13:22
Мы постоянно работаем над улучшением качества перевода, прекрасно понимая, что переводчики, даже постоянно специализирующиеся на SAP текстах, но не владеющие сутью предмета, местами могут переводить неточно, и даже искажать материал.
Перед публикацией мы в обязательном порядке отдаем все тексты на вычитку русскоязычным консультантам. Однако, даже среди консультантов нередко встречаются разногласия по поводу перевода.
С другой стороны, мы не в праве вмешиваться в суть и характер самой статьи, опубликованной автором на английском языке. При этом, чтобы компенсировать выявленные неточности или особенности российской локализации, мы предлагаем русскоязычным консультантам сопровождать эти статьи предисловиями, послесловиями или построчными комментариями.
Пока, к сожалению, отношение устных или кратких замечаний к количеству поданных сопроводительных текстов показывает значительный перевес явно не в пользу последних.
Судя по Вашему отзыву, Вы способны четко структурировать предметную область, и излагать свои мысли во вполне понятной и корректной манере.
Мы будем очень рады, если Вы найдете возможность для сотрудничества с нашим изданием.
Первой ласточкой могла бы стать Ваша статья по мотивам опубликованного Вами отзыва.
С уважением,
Юрий Нечитайлов
Y.Nechitaylov@SAPpro.ru
Комментарий от
Александр Скородумов
| 13 декабря 2011, 05:40
Автор совершенно правильно описывает вариант реализации исходящих платежей для того случая, когда сотрудники финансовой службы в некоторых российских компаниях хотят делать проводки по банку только на основании банковской выписки.
К сожалению, в этом случае (АПП без проводок) настройка выписки чуть усложняется. Большинство компаний (и на Западе и в Росиии) старается все-таки использовать АПП с проводками. Однако если требования бухгалтерии жесткое – делать проводки по факту, нужно задуматься о том, как удобнее сделать реализацию выравнивания платежей по факту.
Автор описывает в статье два механизма – ручное выравнивания через транзакцию F-44 и автоматическое, в момент загрузки и разбора банковской выписки. Для большого количества исходящих платежей ручное выравнивание, конечно же, не очень удобно. Я бы предложил отслеживать, чтобы банк возвращал номера исходящих платежных поручений в одном из полей выписки и делать выравнивание в момент загрузки выписки. Однако и в этом случае могут возникнуть также сложности. Дело в том, что при анализе выписки система может искать номер платежного поручения необычным алгоритмом. Сначала анализирует все встречающиеся числа, разделенные любым нецифровым символом и заносит такие во внутреннюю таблицу. А потом каждое число из этой внутренней таблицы подлежит проверке, не является ли оно номером необработанного платежного поручения. Если такое платежное поручение существет, то создается запись в таблице FEBCL «Клиринговые данные к отдельной позиции ЭлектрВыпискиИзСчета». Проблема возникает в том случае,когда в выписке встречаются разные другие числовые значения (например, специальные внутренние номера банка) и если эти значения случайно совпадают с номером существующей необработанной платежки. А этом случае система будет пытаться выравнить существующую позицию с этим платежным поручением. Естественно, неудачно. Это редкий случай но тем не менее, он может встретиться на практике.