Друзья! Подскажите по процессу входящей банковской выписки.

Дано: есть файл в SWIFTe из банка с платежами - incoming и outgoing. С исходящей всё OK. Вопросы по входящей:

1. какая поцедура - надо ли по кастомерам прогонять пропоузал(f110) и пеймент???

2. в какой момент закачивается выписка? и куда падают входящие суммы - на один аккаунт или сразу на аккаунты каждого кастомера

3. Как и где настроить - чтобы пограмма закачки понимала какому кастомеру пренадлежит данная сумма

-----
кусок файла:
:86:066?00СБЕРБАНК ВХОДЯЩИЙ ПЕРЕВОД?20/PY/КОД КЛИЕНТА 13284. ОПЛА
ТА ЗА ТОВА ООО СП-ЮНИОН ?21 SBERBANK?30/OB/
A.C40702810?32/BO/A.C40702810050020101136

Как я понимаю - после "А.C" идёт номер счёта, с которого перечисляются деньги и именно это и есть идентификатор кастомера?

формат такой:

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

:61:0510171017CB2134300,00NTRF+SB051014F8TMB9//3729010218
:86:066?00СБЕРБАНК ВХОДЯЩИЙ ПЕРЕВОД?20/PY/13463. ОПЛАТА ЗА КОНДИТ
ЕРСКИЕ ИЗД ООО ЭЛИС ?21 SBERBANK?30/OB/
A.C40702810?32/BO/A.C40702810013390105649

по какому полю программа закачки сможет понять на какой счёт должны падать деньги?

У кого как настроено - падает вся входящая выписка на один (транзитный) счёт или сразу разносится по кастомерам?

Программа загрузки выписки корректно определяет дебитора по полю ?31. К примеру 31702810013390105649
У вас выписка со структурированным полем 86,но р/с дебитора в строке ?32 и формат какой-то непонятный (/ВО/А.С.)
Точно знаю, что для банка изменить структуру 86 поля не составляет большого труда.
В вашем случае, наверное, со сбербанком будет сложнее договориться.
По другим вопросам читайте курс "Управление наличностью" там все подробно расписано.

Действительно, здесь представлено структурированное 86 поле, для загрузки такой выписки лучше использовать формат оработки S, а для обработки операции - настроить 066.
В 61 поле - какая-то подозрительная дата
Проводку на клиента без выравнивания смысла делать нет. Насколько понятно из первого поста, 13463 - его номер. Выравнивание же нужно делать не по клиенту, а по конкретному документу. Если же постить без выравнивания на клиента, все равно нужно знать, платит клиент по фактуре или аванс. От этого зависит выбор контрольного счета и все заморочки с НДС. Если из выписки это не понятно, лучше сразу оставить такой тип операций на ручную постобработку. Иначе придется вручную переносить обороты между основным и авансовым контрольными счетами всякий раз, когда система что-то там неправильно догадается. Тем более что у нас на проектах часто не формируют ТАП по дебиторам. Поэтому клиенты сами правильно расчитывают и платят предусмотренную договором сумму, но в системе платеж выровнять не с чем. Опять же аргумент для постобработки.

если кто в курсе - как избавиться во входящей выписке от "/ВО/А.С" и "/ОB/А.С"??? есть какой-то юзер-екзит?
а то в систему выписка не ложится...

и правильно ли я понимаю - что выписка ложится в систему только по "?31" тагу, т.е. по полю BANKN в мастер данных вендора? и никак поменять нельзя...

Привет.
Сам процесс использования ЭБВ, и соответственно настроек очень сильно зависит от того как построен бизнес процесс на предприятии, и возможностей банков партнеров.


Обычно русские компании не используют данной функциональности, тем не менее, как её можно использовать -
После формирования счетов фактур делать прогон АПП формируя отдельные номера платежных требований, допустим для части предоплаты, и части обычного платежа.
Просим наших клиентов, обязательно указывать в note to pay номер платежного требования, и получаем уникальный реквизит для автовыравнивания.



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



Да есть Userexit, при этом лучше всего новое правило распознания (с учетом отсекания A.C) вешать на 901-910 интерпритационные алгоритмы...



Опять же зависит от того какой интерпритационный алгоритм используешь в случае стандарты анализируются Бик банка Дебитора и его расчетные счет, (те которые настроенны в основной записи дебитора), также можно анализировать по номеру счет фактуры например причем как FI шной так и SD шной...

С уважением, Илья.

Всем привет!!!

вопрос по строке:
:86:066?...

Наш банк говорит, что в позициях символов 066 может быть только константа. В нашем случае 000. Что это за поле по стандарту 940?

Заранее спасибо.

Добавлю ответ к моему вопросу, может кому пригодится:

три символа после :86: - это бизнесс код. Описан в формате (см. тех. описание формата http://www.multicash.ru/pdf_files/knowl ... -GB-10.pdf).

В данном случае 066 - Credit of cheque deposit (Export cheque settlement via GZS).

Значит ММБ просто ленится.