Изменение контрольного счёта при загрузке электронной банковской выписки

ПетрП

Насколько я знаю на данный момент есть 2 способа изменить контрольный счёт в проводке входящего платежа при загрузке банковской выписке: это замещение и коды ОГК
Вопрос: а нельзя ли заменить контрольный счёт дебитора или кредитора с помощью расширения FEB00001, предварительно подав его в каком-либо поле фала MULTICASH?
Может кто-то решал данную проблему таким способом?

darkduck

Скажу честно, ни раз не работал с Multicash вообще, и не использовал данное расширение. Но несколько общих мыслей...
Насколько я вижу, данное расширение работает только с таблицами банковской выписки (FEBCL, FEBKO, FEBRE...). Напрямую в таблицы проводок расширение ничего написать не сможет.
НО! Часть полей из этих таблиц (FEB*) потом так или иначе наследуется в проводку. Таким образом, Вы можете с помощью расширения положить номер счета (или какой-то индикатор) в поле, наследуемое в проводку, а потом FI-замещением (OBBH) подставить нужный счет. Вот такой вот мат в 3 хода... :wink:

Экспериментируйте, пробуйте!

Sedlo

Вопрос про консерваторию:
а в чем идея вообще использовать замещения в банковской выписке? может, ответ найдется где-то на более ранних стадиях?

ПетрП

Sedlo написал:

Вопрос про консерваторию:
а в чем идея вообще использовать замещения в банковской выписке? может, ответ найдется где-то на более ранних стадиях?

Идея в том, что в зависимости от вида платежа необходимо сделать входящий платёж не с контрольного счёта указанного в основной записи дебитора или кредитора (сч 62 или 60), а с 76, если это, например, бонус от поставщика или оплата претензии. При этом пользователь может сам указать контрольный счёт, который затем попадёт в файл MULTICASH

darkduck

ПетрП написал(а):

Sedlo написал:

Вопрос про консерваторию:
а в чем идея вообще использовать замещения в банковской выписке? может, ответ найдется где-то на более ранних стадиях?

Идея в том, что в зависимости от вида платежа необходимо сделать входящий платёж не с контрольного счёта указанного в основной записи дебитора или кредитора (сч 62 или 60), а с 76, если это, например, бонус от поставщитпкка или оплата претензии. При этом пользователь может сам указать. контрольный счёт, который затем попадёт в файл MULTICASH

Так.... что-то я не понял...
Пользователь будет РУКАМИ править файл выписки, пришедший из банка??? Ой, боюсь я услышать ответ ваших аудиторов...

Sedlo

ПетрП написал(а):

Идея в том, что в зависимости от вида платежа необходимо сделать входящий платёж не с контрольного счёта указанного в основной записи дебитора или кредитора (сч 62 или 60), а с 76, если это, например, бонус от поставщика или оплата претензии. При этом пользователь может сам указать контрольный счёт, который затем попадёт в файл MULTICASH

Ну, тогда все проще.
Настраиваете входящие платежи на алгоритм интерпретации по полю XBLNR алгоритм 021. Когда в подполе 7 поля 61 СВИФТа (ну или еще как аналогичным образом) вам приходит номер СД-шной фактуры - фактура выравнивается автоматически. Когда номер не находится, юзер из FEBAN проваливается в FB05. Система не находит сама дебитора. Поэтому юзер указывает согласно операционной инструкции, где прописана конкретно данная операция поступления денежного бонуса или претензия от поставщика: какой код проводки, ОГК, счет ГК и все прочее проставить для данного случая. Никакой взлом стандарта не требуется.

darkduck

Еще можно попробовать поиграть со строками поиска...

ПетрП

darkduck написал:

Так.... что-то я не понял...
Пользователь будет РУКАМИ править файл выписки, пришедший из банка??? Ой, боюсь я услышать ответ ваших аудиторов...

Нет, пользователь не будет руками править файл выписки.

Sedlo написал:

Ну, тогда все проще.
Настраиваете входящие платежи на алгоритм интерпретации по полю XBLNR алгоритм 021. Когда в подполе 7 поля 61 СВИФТа (ну или еще как аналогичным образом) вам приходит номер СД-шной фактуры - фактура выравнивается автоматически. Когда номер не находится, юзер из FEBAN проваливается в FB05. Система не находит сама дебитора. Поэтому юзер указывает согласно операционной инструкции, где прописана конкретно данная операция поступления денежного бонуса или претензия от поставщика: какой код проводки, ОГК, счет ГК и все прочее проставить для данного случая. Никакой взлом стандарта не требуется.

В момент конвертации файла из клиент-банка в формат MULTICASH есть промежуточная обработка платежей. В этой обработке пользователь ставит код операции, например, входящий платёж от кредитора и ставит номер контрольного счёта, например, 7601 - бонус от поставщика. После этого данный счёт записываеться в отведённое поле в файл MULTICASH. Не хочется после этого ещё постобработку выписки делать, потому что все данные уже есть и лишь надо придумать как этот счёт воткнуть в поле пакетника, который формируеться программой RFEBKA00.
Может кто-то заменял данные поля расширением?
Для стандартных платежей в принципе можно использовать код ОГК, но когда, например, идёт возврат денежных средств от кредиторов по разным субсчетам!

darkduck

Именно строки поиска позволяют менять поля пакетника.

Sedlo

ПетрП написал(а):

В момент конвертации файла из клиент-банка в формат MULTICASH есть промежуточная обработка платежей. В этой обработке пользователь ставит код операции, например, входящий платёж от кредитора и ставит номер контрольного счёта, например, 7601 - бонус от поставщика. После этого данный счёт записываеться в отведённое поле в файл MULTICASH. Не хочется после этого ещё постобработку выписки делать, потому что все данные уже есть и лишь надо придумать как этот счёт воткнуть в поле пакетника, который формируеться программой RFEBKA00.
Может кто-то заменял данные поля расширением?
Для стандартных платежей в принципе можно использовать код ОГК, но когда, например, идёт возврат денежных средств от кредиторов по разным субсчетам!

а что мешает сделать счет ОГК для бонусов, настроить его в разблюдовке 2 области проводок и пришить к отдельному внешнему коду операции? Вы прямо по тесту выписки по кодам ведь можете догадаться, что это бонус от поставщика? Тем более что сами конвертите исходник в мультикэш.

ПетрП

Код ОГК в некоторых случаях не подходит, пользователю проще указать контрольный счёт для не стандартной операции, чем создавать правило проводки и код ОГК

Расширение FEB00001 позволяет менять поля пакетника с помощью специальных полей структуры,например, я рисую такой код
e_febep-fnam1 = 'BSEG-MWSKZ'.
e_febep-fval1 = 'AC'.
e_febep-fkoa1 = '3'.
и у меня меняеться поле код налога на заданный в коде расширения, всё нормально,
но если я пытаюсь заменить контрольный счёт, пример
e_febep-fnam1 = 'BSEG-HKONT'.
e_febep-fval1 = '0076010000'.
e_febep-fkoa1 = '3'.
то у меня выдаёт ошибку: "поле BSEG-HKONT перенесено 2 раза", если правило проводки без кода ОГК и "перенесено более двух счетов", если правило проводки с кодом ОГК.
Может кто-нибудь сталкивался с такой проблемой?

feat

да, через расширение не получится - идёт системная проверка на кол-во передаваемых HKONTов..
я делал замещением - анализировал вид операции (через febep), далее кейсом подставлял нужный контрольный счёт

ПетрП

feat написал(а):

да, через расширение не получится - идёт системная проверка на кол-во передаваемых HKONTов..
я делал замещением - анализировал вид операции (через febep), далее кейсом подставлял нужный контрольный счёт

А можно поподробнее как произвести анализ вида операции через FEBEP для замещения?

feat

у меня такая ситуация: контрольный счёт 6001.
в зависимости от операции, нужно менять его на тот или другой, причём код ОГК не подходит.
при проводке БВ некоторые значения пишутся автоматом в поля позиций.. так, я пользую зуонр в своём документе, и сравнваю его с зуонром банковской операции (идентифицирую позицию в febep по датам, реквизитам выписки и как раз таки зуонру), и анализирую вид операции. далее из замещения работает exit с кейсом по виду операции.

Creatory

ПетрП написал(а):

feat написал(а):

да, через расширение не получится - идёт системная проверка на кол-во передаваемых HKONTов..
я делал замещением - анализировал вид операции (через febep), далее кейсом подставлял нужный контрольный счёт

А можно поподробнее как произвести анализ вида операции через FEBEP для замещения?

Контрольный счёт, например, меняю в замещении для позиции документа. Предпосылка такая будет:

Code:

 SYST-TCODE = 'FB01' AND ( BSEG-LIFNR <> '' OR
 BSEG-KUNNR <> '' ) AND BKPF-BLART = 'ZP' AND
 BSEG-ZUONR <> '' AND
 SYST-BINPT <> ''

подпрограмма для HKONT (хранится в польз. таблице):

Code:

form u008 using hkont.
  data: i_hkont like bseg-hkont,  "счет Главной книги
        i_vgext like febep-vgext, "номер внеш операции
        i_kukey like febep-kukey, "к/ключ
        i_esnum like febep-esnum. "номер осн записи в выписке

  clear: i_hkont, i_vgext, i_kukey, i_esnum.
* Поиск внешней операции по присвоению в буфере эл выписок FEBEP
  i_kukey = bseg-zuonr(8).
  i_esnum = bseg-zuonr+9(5).
*  BREAK-POINT.
  select single vgext from febep
    into (i_vgext)
    where kukey = i_kukey and esnum = i_esnum.

  if i_vgext is initial.
  select single vgman from febep
    into (i_vgext)
    where kukey = i_kukey and esnum = i_esnum.
  endif.
  if i_vgext is not initial. "нашли
* Поиск доп информации к внеш операции в ZVIP_FIPOS
    select single hkont from zvip_fipos
      into (i_hkont)
      where kodvo = i_vgext.
    if sy-subrc = 0 and i_hkont is not initial.
      hkont = i_hkont.
    endif.
  endif.
endform.                                                    "U008

Изменение контрольного счёта при загрузке электронной банковской выписки

Кто сейчас на конференции