Электронная банковская выписка, очень небольшой вопрос

darkduck

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

ЭфАй

Здравствуйте!

Постараюсь, конечно, ответить на вопросы.. :oops:

Да, ТАП-ы дебиторские. Код ОГК у ТАП-ов- F.

При выравнивании формируется следующая проводка:

40 Банковский счет
19 A Счет дебитора

Хм.. Используем алгоритм 028 для выравнивания ТАП-ов. Вот, что ещё...

А, да, выравниваем по номеру заказа (XBLNR). Кое- как "заставили" FF_5 выравнивать по XBLNR (стат. позиции), но теперь это не работает для случаев, когда несколько ТАП-ов созданы к одному заказу.

darkduck

Таким образом, господа, все Ваши рассуждения по поводу возвратов дебиторов были обоснованы только на основании [s]меряния письками[/s] домыслов, а не реального вопроса.
Всем участвовавшим в обсуждении, особенно Yozhhhhh, последнее китайское предупреждение. Мне уже надоело читать Ваши бахвальства и рассуждения на пустом месте.

darkduck

ЭфАй написал(а):

Здравствуйте!

Постараюсь, конечно, ответить на вопросы.. :oops:

Да, ТАП-ы дебиторские. Код ОГК у ТАП-ов- F.

При выравнивании формируется следующая проводка:

40 Банковский счет
19 A Счет дебитора

Хм.. Используем алгоритм 028 для выравнивания ТАП-ов. Вот, что ещё...

А, да, выравниваем по номеру заказа (XBLNR). Кое- как "заставили" FF_5 выравнивать по XBLNR (стат. позиции), но теперь это не работает для случаев, когда несколько ТАП-ов созданы к одному заказу.

Я не думаю, что стандартный алгоритм Вам будет искать по двум разным параметрам.
И потом, иметь в системе несколько ТАПов с общим XBLNR как-то нелогично, с моей точки зрения.
XBLNR - это внешний номер документа. Вы дебитору, получается, отправили несколько счетов с одним номером, а теперь хотите, чтобы Вам система нашла правильный?

ЭфАй

В самой выписке по данной позиции есть и XBLNR/и правильный BELNR.

Вот, к примеру, вот так:

3100000/10000000

(31* -XBLNR; 10*- BELNR)

Смотрю FEBCL там следующие записи:

SELFD SELVON

BELNR 00100000112015
BELNR 00100000002015

Где 00100000112015- это другой ТАП с таким же XBLNR, но его этой выпиской мы не выравниваем. Странно, почему по BELNR сохранены записи в FEBCL... но не суть.

В общем, получается номер документа к выравниванию есть в выписке, но FF_5 ищет по XBLNR. Порядок строк поиска нужно поменять, наверное, да?

darkduck

ЭфАй написал(а):

Где 00100000112015- это другой ТАП с таким же XBLNR, но его этой выпиской мы не выравниваем. Странно, почему по BELNR сохранены записи в FEBCL... но не суть.

http://help.sap.com/saphelp_46c/helpdat ... ontent.htm

Цитата:

•028 (Reference number per MULTICASH conversion programs)

This algorithm is the same as algorithm 027. The account statement files are imported in MULTICASH format. The algorithm uses number range BELNR.

ЭфАй

darkduck, спасибо большое!!
Строку поиска по XBLNR изначально присвоили алгоритму 001, и поэтому ничего не работало :oops:

Говорю же, стыдно было и спрашивать.. :oops:

Поменяли на 028 и теперь всё ок.

Но ещё один небольшой вопрос в этой связи... в выписке попался ТАП, у которого нет ни BELNR ни XBLNR. Но есть внешний номер договора (этого номера нет в BSEG). В FB05, если указать дебитора, код ОГК, и в параметрах выбрать "None", то ТАП можно найти. Можно ли автоматически выровнять такой ТАП? Наверное, нет, потому что искать то, собственно, получается нечего.

В общем, ещё раз огромное спасибо за помощь!

Электронная банковская выписка, очень небольшой вопрос

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