Возврат ранее уплаченного аванса с точки зрения FM

Бывают ситуации когда перечислили деньги поставщику, а услуга не была оказана и поставщик возвращает вам деньги. С точки зрения FI все понятно, провели через банковскую выписку выровняли исходящий платеж с входящим, открытые позиции на счете кредитора при это закрылись и все хорошо. Но что при этом происходит в FM?
Интересно? Тогда об этом и будет сегодняшний пост.

Итак, имеем следующие условия: заключили договор с поставщиком, создали Заказ на поставку, создали Требование авансового платежа, Оплатили (загрузили выписку в систему).

Технические настройки в модуле FM: 350-й профиль обновления, два регистра АКН - 9H и 9I. В АКН участвуют следующие документы: Заказ на поставку, Счет-фактура - БО; ТАП и Платеж - БП.

Итого, после всего ранее проделанного, на момент платежа у нас по бюджетам БО и БП виден расход на сумму Заказа на поставку для БО, Платежа для БП. Т.е. бюджет потреблен.

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

Но не забывайте, что в БО у вас тоже денежные средства израсходованы. Чтобы их вернуть идем в Заказ на поставку и на вкладке "Счет-фактура" поднимаем галочку "Последний счет".

После этого проверяем БО и БП - все должно быть ОК.

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

Таблица для хранения контировок FM в договорах сбыта

Собственно таблица FMZUOB.

Ввод данных в поле ZUONR при проводке банковской выписки

У нас на проекте поле ZUONR для позиций дебиторов заполняется номером договора. Возникла необходимость дать возможность бухгалтеру, при проводке банковской выписки в автоматическом режиме, возможность указать номер договора.

В качестве решения предлагаю использовать ФМ POPUP_GET_VALUES, который будет выдавать пользователю окошко для ввода номера договора и затем класть этот номер в ZUONR.

Для вызова этого ФМ можно воспользоваться замещениями GGB1. Настроить на заполнение поля ZUONR по определенному виду документа и коду проводки (можете указать доп. данные для более точного указания позиции). ZUONR будет замещаться пользовательской программой, в моем случае это U007, которую я создал. Для замещений у меня используется программа ZRGGBS000 (копия RGGBS0000).

Код подпрограммы U007:

FORM u007.
  " По
  message 'Укажите номер договора в поле Присвоение!' type 'I'.
  BREAK-POINT.
  DATA: I_DIALOG LIKE sval OCCURS 0 WITH HEADER LINE.
  DATA RETURNCODE    TYPE Char18.
    I_DIALOG-TABNAME    = 'BSEG'.
    I_DIALOG-fieldname   = 'ZUONR'.
    APPEND I_DIALOG.

    CALL FUNCTION 'POPUP_GET_VALUES'
     EXPORTING
        NO_VALUE_CHECK = ''
        popup_title  = 'Укажите номер договора'
        START_COLUMN = '5'
        START_ROW    = '15'

     TABLES
        FIELDS  = I_DIALOG.

* I_DIALOG-VALUE - это табельный номер
BSEG-ZUONR = I_DIALOG-VALUE.

ENDFORM.

При тестировании я вставил вызов message и брейк-поинт. Для использования в продуктиве их можно и нужно убрать.

P.S. Идею можно дальше развить и использовать по своему усмотрению.

BAPI для работы с основными средствами в SAP

Зачастую в своих программах, которые работают с ОС использую следующие BAPI:
BAPI_ASSET_ACQUISITION_POST - поступление
BAPI_ASSET_POSTCAP_POST - оприходование задним числом
BAPI_ASSET_RETIREMENT_POST - выбытие
BAPI_ASSET_REVERSAL_POST - сторно документа

При выбытие ОС заполняется следующая структура:

GENERALPOSTINGDATA

USERNAME - Логин пользователя

DO - Вид документа

DOC_DATE - Дата документа

PSTNG_DATE - Дата проводки

FI - Период проводки

       TRANS_DATE - Дата пересчета

       COMP - Балансовая единица

       ASSETMAINO - Номер ОС

       ASSE - Субномер

       ASS Вид движения

Пример использования:

DATA : GENERAL LIKE BAPIFAPO_GEN_INFO, 

RETIREMENT LIKE BAPIFAPO_RET, 

DOCUMENTREFERENCE LIKE BAPIFAPO_DOC_REF, 

RETURN LIKE BAPIRET2. 

GENERAL-DOC_DATE = '19991201'. 

GENERAL-PSTNG_DATE = '19991201'. 

GENERAL-COMP_CODE = '011'. 

GENERAL-ASSETMAINO = '000000391866'. 

GENERAL-ASSETSUBNO = '0000'. 

RETIREMENT-REV_ON_RET = '300'. 

RETIREMENT-VALUEDATE = '19991201'. 

CALL FUNCTION 'BAPI_ASSET_RETIREMENT_POST' 

EXPORTING 

ORIGINDOCREFERENCE = 

GENERALPOSTINGDATA = GENERAL 

RETIREMENTDATA = RETIREMENT 

ACCOUNTASSIGNMENTS = 

FURTHERPOSTINGDATA = 

IMPORTING 

DOCUMENTREFERENCE = DOCUMENTREFERENCE 

RETURN = RETURN 

. 

IF RETURN-TYPE 'E' or RETURN-TYPE 'A' . 

CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' 

EXPORTING 

WAIT = 'X' . 

WRITE :/ RETURN-MESSAGE. 

ELSE. 

WRITE :/ RETURN-MESSAGE. 

ENDIF.

Реестр платежей в SAP ERP

Те, кто давно работает в SAP знают, что в SAP ERP до сих пор не реализован такой необходимый каждому нормальному бизнесу функционал, как "реестр платежей".

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

Введение

Реестр платежей в простом варианте включает в себя обязательства предприятия по уплате денежных средств, т.е. это кому, сколько и когда. Это необходимо для того, чтобы предприятие ориентируясь на данный отчет рассчитывало свою платежеспособность и вовремя исполняло обязательства.

Способы реализации

На просторах интернета я встречал несколько упоминаний о том, как же все таки реализовать этот реестр, среди них следующие:

1. на документах ТАП;
2. с помощью компонента DMS;
3. через технические заказы на поставку;
4. на документах выделения средств (FI-FM).

Признаюсь, первоначально я склонялся к первому варианту, но потом отказался от него в силу сложности и того, что увидел 4-й способ.

Второй вариант отпал сам - DMS у нас не поднят.

Третий вариант я отмел тоже сразу же, в силу того, что лепить технические заказы на каждое желание заплатить кому то денег (а это могут быть и платежи по кредитам, и расчеты по налогам и т.д) это не серьезно, тем более, что функционал создания ЗнП это все таки инструмент снабженцев и им не надо понимать и тем более знать, что есть платеж за кредит и сколько за это нужно платить.

А вот о четвертом варианте следует поговорить. В своем варианте я рассматриваю документ ассигнования средств (АС). Ссылка на документ выделения средств присутствует во многих документах SAP, в частности, в нужных нам заказе на закупку, требовании авансового платежа. При данном подходе вырисовывается следующая схема для закупки (примерная):

1. Создание ММ-договора;
2. Создание АС с указанием в качестве позиций всех платежей согласно графику в приложении (это и есть элемент реестра платежей);
3. Создание ММ-заказа на поставку со ссылкой на АС и конкретную позицию;
4. Создание Требования авансового платежа со ссылкой на АС и конкретную позицию.
5. Оплата.

Документ ассигнования средств

Таким образом, в позициях документах ассигнования средств у нас содержатся нужные нам данные:

1. Дата платежа;
2. Сумма платежа;
3. Бюджетный адрес.

К тому же, в одном документе АС сгруппированы все платежи по одному договору (см. рисунок). Поэтому остановимся пока на том, что исходными данными для нашего реестра будут позиции документа Ассигнования средств.

На сегодня всё.

Как оно бывает

Сторно отдельных позиций банковской выписки

П.С. Публикую одну из заметок собственного ранее написанного хелпа.

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

1) В таблице FEBKO меняем значение поля ASTAT на 3. VB2OK очищаем.
2) В таблице FEBEP очищаем EPERL, VB2OK, NBBLN.
3) Перепроводим позицию выписки.

а можно написать маленькую программку

SE508 Ошибка при присвоении контировки

Создавая акт в транзакции ML81N наткнулся на ошибку  SE508 Ошибка при присвоении контировки. Поискал на service.sap.com решение - нота 1680030.

Если кратко, то решение в следующем:

Go to transaction ME22N and select the Purchase Order referenced in Service Entry Sheet.
Select such Purchase Order Item and click on "Delete" (DO NOT SAVE THE DOCUMENT YET).
Now click on "Unblock/Undelete".
Save the document.
It will rebuild the references among the Purchase Order Item and Services tables, correcting the wrong value on ESKL table.

F-48: авансовый платеж

Попытался сделать авансовый платеж кредитору на ТАП (требование авансового платежа) по которому сформировано платежное поручение, оказывается это сделать невозможно. F110 проставляет признак в документ ТАП о том, что сформировано ПП и документ не выбирается в транзакции F-48, как основание для авансового платежа.

Поэтому после формирования ТАП можно либо делать авансовый платеж через F-48, либо формировать ПП через F110 и потом платеж проводить через банковскую выписку.

Перегенерация документов FI-FM

Делая выравнивание, натолкнулся на ошибку FMUP137 "Запрещенная бизнес-операция", которая не дает провести документ. Оказалось, что в документах загрузки остатков по счетам проставили неправильные фин. позиции.

Более подробно ошибка расписана здесь (не мной).

Итого, имеем порядка 300-400 документов некорректных с точки зрения FM. Сторно никакое делать не пришлось. Работники SAP предусмотрительно создали пару транзакций на такой случай.

1) RFFMUPFI - меняем бюджетные контировки;

2) RFFMRPFI - перегенерируем FM-документ;

3) И в конце необходимо не забыть перезапустить процедуру реинициализации АКН (автоматический контроль наличия), для тех у кого он работает, - FMAVCREINIT.

Управление командировками

Компания SAP в EHP5 представила некое дополненное решение в области управления командировками, в частности, они добавили программу HRUUTRV0, которая позволяет печатать приказ Т-10, а также выводит всю сводную информацию по состоянию командировки.
В рамках функционала FI-TV мы у себя внедряем следующее:
1. заявка на командировку;
2. план командировки;
3. авансовый расчет;
4. перенос проводок в FI.
Новая программа позволила нам после создания и утверждения заявки запустить из своего окна преднастроенное мероприятие (HR), в котором мы как раз и настроили печать Т-10 и Т-9. Кстати, можно настроить чтобы формирование приказа происходило в диалоговом режиме, в противном случае придется настроить динамические мероприятия.
Пока из обновлений это все, в принципе удобный функционал, не знаю почему в России так мало его используют.