Manual payments process

Hello Experts,
We're creating a new local solution (web based) in order to manage "Manual Payments", so, we need to integrate it with our Sap. For this integration we detected 4Outbound Master data interface (from Sap vs Web solution), 1 extraction program for Bank, and 1 inbound interface with releated batch input creation.
Inbound Interface:
Manual Payment accounting (Inbound interface)
An interface is required in order to upload in Sap a file containing manual payment requests.
The program should read an input txt file containing for every manual payment a header row information and two or more rows with detailed item information.
The manual payment document will be created according the document type and transaction type inserted in the header.
Two different transaction types are required:
FB01   Post Document
F-48   Post Vendor Down Payment
The interface should be scheduled to capture every new input file inserted on a local FTP server.
In detail the program must perform the following activities:
1) Read a test input file
2) reate batch input session to post Manual Payment document for every manual payment request (header record ) according transaction code header field (F-48 or FB01)
3) Maintain request history (custom table)
Outbound Interfaces
Vendor master data, Cost Centre master data, Internal Order master data, wbs element master data.
In detail the program must perform the following activities:
1) Select Vendor/CC/IO/WBS element Master Data according defined criteria
2) Create output file.txt
Extraction Programme
Payment Medium for Bank (Outbound interface)
An interface is required in order to create Payment information to the bank via Home Banking .
A similar solution is in charge for Automatic payment , see pgm   ZITFU_RFFOIT_B (FA_DD_451_LIT).
In detail the program must perform the following activities:
1) Read accounting document for manual payment according selection criteria
2) Create DME file
3) Create Letter for Bank and vendor
4) Create Summury list
5) Create return file with Protocol Number vs WEB to confirm payment
Please suggest how to achieve this..
your inputs will be rewarded..
Thanks in advance,
Satya

Hi,
This is not question to give answer, this is requirement for inbound and outbound interfaces
Mainly you have to concentrate on interfaces is
Inbound
What are the selection screen parameter (like company code etc whether it is select option or parameter and is it required or optional) and you need to check with customer that any validation required on selection screen
You need to sit with an abaper to write BDC to update SAP data (you need to decide which fields are required in BDC recording)
You need to decide the input file format (colums, rows, Char or numc and their length)
You need to map input file fields into sap fields
Outbound
What are the selection screen parameter (like company code etc whether it is select option or parameter and is it required or optional) and you need to check with customer that any validation required on selection screen
You neeed to decide the output file format (colums, rows, Char or numc and their length) and you need to decide from which sap fields data should be pick
Where the output file shold palce
Moreover you need to sit with sr abaper to design the document Flow (FDD)
Reg
Vishnu

Similar Messages

Manual/automatic payment process

Dear sir.
Help me explain the difference between manual payment process and automatic payment process and please give examples.
Thanks
hangvt

Question not clear as per my knowleges
Manual payment that means u have to clear the open itmes manually
example if vendor invoice through f-53
and also automatic payment program
u have to run the app and automatically invoice pick and cleared
i hope now clear

Open item management_part payment with partial clearing_post outgoing payment process open items

In this scenario of post outgoing payment process open items , i' m facing a error titled as below
The difference is too large for clearing
Message no. F5263
Diagnosis
A non-assigned difference exists for the specified clearing amount.
The difference for an automatic difference posting must not be greater than the difference permitted for the user, nor greater than the difference permitted for the tolerance group that is contained in the customer/vendor master record.
System Response
It is not possible to automatically charge off the difference.
Procedure
You can charge off the difference manually using the function "Clear differences". You define the upper limits for automatically clearing differences in the tolerance group assigned to the user.
Change tolerance groups for user
I gave the specifications in (OBA4 screen) i.e., change tolerance groups for users/employees are as follows
Amount per document : 9999999999
Amount per open item account item : 9999999999
Cash discount per line item : 10%
Permitted payment differences left blank
What else do i need to execute ?
Please aid me in resolving the error....
Thanks in advance,
Heamanthkkumar.

Hi,
it seems you want to make a partial payment of 15000, select the line item against which you want to make the payment. On the payment amount field put -15000 and then simulate. It will credit the bank account and debit you expense account. Pls refer the screen shot.
best regds
Subha

Vendor Down payment processing

Hi friends,
Can anyone give me idea how down payment for vendors work in SAP.
I am not sure about the procedure, and we are following the below procedure, let me know how it should go and what we are doing wrong.
we do F-47, and F110 then after, I dont know if I should do MIRO, F-54 and F-44 thenafter to pay the remaining balance or just MIRO and F-54.
Please let me know its urgent

HI Shefford
The business flow of advance payment can be like this.
1.prepare an advance payment request(F-47)
2Convert the advance payment request to advance payment either by F-48 or F110.U can also go for F-48 individually also without going for F-47 route.
3. Goods receipt or the vendor liability creation as per the business practice,That means which is happening first.Goods receipt through MIGo and the liability craetion through MIRO.
4. If u have paid 100% advance to ur vendor and ur advance is equal to the supply amount just clear the advance with the supply amount by F-54.
5.If there is difference between advance and the supply amount just clear the advanvce by F-44 and pay the rest balance either by F110 or F-53/F-58 (Both manual payment method.)
This is all abount the process.
Thanks
Surendra

How to automatically confirm check pay run (payment process request) in R12

Payment Method = check
The payment process profile (ppp) settings are as follows:
Processing Type=Printed
Payment Completion Point = When the Payment Instruction is Formatted
Default Payment Document= blank/null
Payment File=Send to File
My question is this. Is it possible or how do you configure oracle payments (PAYMENT PROCESS PROFILE [PPP] and/or PAYMENT PROCESS REQUEST [PPR])for check payments created as a file output like you have in 'EFT' instead of printing the checks and CONFIRM the PPR/payments AUTOMATICALLY after the checks/payments have been formatted.
The reason we are doing this is because we want an external agency to print the checks for my organisation.
What is happening at the moment is that the PPR runs and the payments file is created successfully. At this point, the PPR is in 'FORMATTED - READY FOR RECORDING' status. The PPR then remain in this status until it is manually confirmed by clicking the 'Take Action' icon in the 'payment instruction' tab and then clicking on 'CONFIRM'.
If the PPR is left in the above status, then the next submitted check pay run errors because the payment document(s) are still locked by the pay run that is in the 'Formatted - Ready for Recording' state.
If it is not possible to configure Oracle payments to auto confirm the check pay run of this type, is an API available that can be called to confirm check payments - once they are in the formatted status.
I've looked at the following notes in 'My Oracle Support', but they are not much use.
Note 1097547.1 is related to bug 8781032 which talks about "Automatic Initiate when Payment Process Request is Complete".
and then Note 1215392.1 relates to enhancement request.
Bug 10142423: GIVE AN OPTION IN PAYMENT PROCESS PROFILE TO SUBMIT POSITIVE PAY FILE AUTOMATIC
Thanks.

Try running this SQL
SELECT
r.calling_app_id,
r.created_by,
r.payment_service_request_id,
r.creation_date,
r.call_app_pay_service_req_code,
fa.application_name,
fu.user_name,
r.payment_service_request_status
FROM
iby_pay_service_requests r,
fnd_application_vl fa,
fnd_user fu
WHERE r.payment_service_request_id = <<your concurrent request ID>>
AND r.calling_app_id = fa.application_id(+)
AND r.created_by = fu.user_id(+)

Check Payment Processing Across Multiple Operating Units

Hi There
We are currently implementing Oracle R12 at the company I work for. Our solution implementer has informed us that you cannot process one check (cheque) payment across multiple operating units and that this is an outstanding enhancement with Oracle. Therefore (if we accept) this we will have to process a seperate check per operating unit which will increase our payment processing significantly.
Can anyone out there:
A. Confirm this is indeed an issue
B. Are you aware if Oracle are doing anything about it and
C. Is there any workaround that we could consider to lessen the impact.
Thanks

Hi,
Scenario 1
If you are going to make Single check payment to the same supplier having different sites under various operating units, oracle has provided a workaround, i.e. to make a manual payment in payables module, however it would not generate any payment instruction.
Scenario 2
If you are going to make single check payment to various suppliers in different/same operating units, it is not allowed by Oracle, as there is no logic behind it. You cannot have 1 check generated for different suppliers ...
I am assuming you are referring to Scenario 1, in which case, i would say there is an WORKAROUND suggested by Oracle to make use of MANUAL PAYMENT method, which you could discuss with your Solution Implementer.
Regards,
Ivruksha

How to stop clearing open items with manual payment block.

Dear,
Even though we have set "manual payment block" on payment block indicator in OB27,
I can process to clear open items manually in F-44 though.
Actually user wants to NOT allow to clear once payment block's set in an open items.
SAP documentation says,
"Indicator that documents which are flagged with the relevant blocking key cannot also be cleared during manual entry of incoming payments or outgoing payments.".
Can you advise me why this configuration does not work ?
Kind regards,
Desperate FI con.

Include - MF05BFO0
FORM op_pruefen
Context:
          WHEN 'K'.
           ENHANCEMENT-POINT mf05bfo0_02 SPOTS es_sapmf05b.
Create an enhancement here and add this code
               IF SY-TCODE = 'FB1K'.
                     T041A-AUGLV = 'AUSGZAHL'.
               ENDIF.

Payment terms in automatic payment process

Dear Experts,
Can anyone tell me,how to make it sure,payment terms assigned in documents are not considered in automatic payment process.Per example,If one pyment term is of 15 days due net,it will not allow us to make the payment before the due date.
I can assign payment terma immediately due net in the vendor master.This is the secondary thing.If already we have end number of documents posted with the payment term with 15 days due net,then how to go about it.Now there is an option of changing it manually one by one,which is tedious.
Please advice
Regards
Partha

Hi,
From FBL1N, you can chnage the baseline date through MASS change option.
From FBL1N, select the documents for which you want to chnage the terms. Click on the Mass Change icon. From the pop up screen, input a baseline date as required and execute. All the documents will be updated with the given baseline date.
For example, if you give a baselline date of 30 days back, the invoices (with 15 days payment terms) will fall due immediately as of today.
Regards,
Mike

Down payment process

Hi guru's,
I am working on a downpayment process, where i created a material as per down payment process and changed required custom settings as per milestone billing process. as of business requirement 40% percent need to get advance from customer otherwise billing will not happened,
How can i enter this 40% amount in my sandbox where am creating dummy sales order cycle to test how the plan will work,
I finished till deliver , but i need bill that document , i have to show the amount where it received as advance , how can post that money received.
Please advice me.
thanks & regards
chandra sheker c

hi,
http://help.sap.com/saphelp_470/helpdata/en/14/c8af5ad21411d2acc70000e8a5bd28/frameset.htm
http://help.sap.com/saphelp_470/helpdata/en/01/a9c74e455711d182b40000e829fbfe/frameset.htm
The following Customizing settings have to be made for down payment processing:
Settings for the billing plan - To activate the billing plan function, maintain the materials, for which you wish to process down payments, with item category group 0005 (milestone billing). This gives the item type TAO via item type determination. The item type TAO calls up the billing plan function.
You need to implement the following activities in the billing plan for down payments:
Maintain deadline category - This determines the billing rule (percentage or value down payment) for the down payment request. The system assigns billing type FAZ (payment request) defined in the standard system with billing category P. (For the billing type FAZ there is the cancellation billing document type FAS in the standard system).
Maintain the deadline proposal - Use the down payments that are due for the proposed deadlines.
Maintaining a Pricing Procedure with the Condition Type AZWR:
In the standard system the condition type AZWR is delivered for the down payment value already provided but which has not yet been calculated. You must include this condition type in the relevant pricing procedure before output tax.
Enter condition 2 (item with pricing) and the calculation formula 48 (down payment clearing value must not be bigger than the item value) for the condition type AZWR.
Before the condition AZWR you can create a subtotal with the base value calculation formula 2 (net value). If the condition AZWR is changed manually, you can get information on the original system proposal from the subtotal.
Maintain the printing indicator - The pricing procedure can not be marked as a transaction-specific pricing procedure (field Spec.proc.) The condition type AZWR has the calculation type B (fixed amount) and the condition category E (down payment request / clearing).
Maintaining the Billing Document - In the standard system there is the billing type FAZ (down payment request) and the billing type FAS for canceling . The down payment is controlled using the billing category P of the billing type. A billing type becomes a down payment request when the billing category P is assigned. You have to maintain blocking reason 02 (complete confirmation missing) for the billing documents and assign it to billing type FAZ.
Copying control - Copying requirement 20 must be entered in copying control at item level for the down payment request. In the standard system the order type TA for copying control is set up according to the billing type FAZ for the item category TAO.
Copying requirement 23 must be entered in copying control at item level for down payment clearing. In the standard system the order type TA for copying control is set up according to the billing type F2 for the item category TAO.
Financial Accounting settings - A prerequisite for down payment processing is that the account is assigned to the underlying sales document. To do this, change the field status settings in Customizing as follows:
Set reconciliation accounts (transaction OBXR) - For the `received down payments' and `down payment requests' from
the G/L accounts you have selected, you should assign the field status definition G031.
Maintain accounting configuration (transaction OBXB) - For the down payments (posting key ANZ in the standard system) and the output tax clearing (posting key MVA in the standard system), you must maintain the posting key.
You must also carry out a G/L account number assignment for the tax account.
Maintain the posting key (transaction OB41) - For posting key 19, set the sales order as an optional field !!!
Maintain the field status definition (transaction OB14) - For field status variant 0001, field status group G031, set the
sales order as an optional field !!!
Assign the company code to the field status variants (transaction OBC5)
KAPIL

Down payment process for Poland, new business process or not ?

Hello,
I'm a little bit confused about implementation down payment process for Poland.
The OSS-notes 818079 and 1007635 describe a solution for this.
How do I have to implement the correct down payment process for Poland ? Do I have to create an extra business process with new sales order type, new billing type, separate calculation procedure, new output type and so on ?
Or is it possible to use existing business processes in sales and distribution for down payment processes ?
Thanks in advance
Holger

hi,
Check the process for down payment processing
The following Customizing settings have to be made for down payment processing:
Settings for the billing plan - To activate the billing plan function, maintain the materials, for which you wish to process down payments, with item category group 0005 (milestone billing). This gives the item type TAO via item type determination. The item type TAO calls up the billing plan function.
You need to implement the following activities in the billing plan for down payments:
Maintain deadline category - This determines the billing rule (percentage or value down payment) for the down payment request. The system assigns billing type FAZ (payment request) defined in the standard system with billing category P. (For the billing type FAZ there is the cancellation billing document type FAS in the standard system).
Maintain the deadline proposal - Use the down payments that are due for the proposed deadlines.
Maintaining a Pricing Procedure with the Condition Type AZWR:
In the standard system the condition type AZWR is delivered for the down payment value already provided but which has not yet been calculated. You must include this condition type in the relevant pricing procedure before output tax.
Enter condition 2 (item with pricing) and the calculation formula 48 (down payment clearing value must not be bigger than the item value) for the condition type AZWR.
Before the condition AZWR you can create a subtotal with the base value calculation formula 2 (net value). If the condition AZWR is changed manually, you can get information on the original system proposal from the subtotal.
Maintain the printing indicator - The pricing procedure can not be marked as a transaction-specific pricing procedure (field Spec.proc.) The condition type AZWR has the calculation type B (fixed amount) and the condition category E (down payment request / clearing).
Maintaining the Billing Document - In the standard system there is the billing type FAZ (down payment request) and the billing type FAS for canceling . The down payment is controlled using the billing category P of the billing type. A billing type becomes a down payment request when the billing category P is assigned. You have to maintain blocking reason 02 (complete confirmation missing) for the billing documents and assign it to billing type FAZ.
Copying control - Copying requirement 20 must be entered in copying control at item level for the down payment request. In the standard system the order type TA for copying control is set up according to the billing type FAZ for the item category TAO.
Copying requirement 23 must be entered in copying control at item level for down payment clearing. In the standard system the order type TA for copying control is set up according to the billing type F2 for the item category TAO.
Financial Accounting settings - A prerequisite for down payment processing is that the account is assigned to the underlying sales document. To do this, change the field status settings in Customizing as follows:
Set reconciliation accounts (transaction OBXR) - For the `received down payments' and `down payment requests' from
the G/L accounts you have selected, you should assign the field status definition G031.
Maintain accounting configuration (transaction OBXB) - For the down payments (posting key ANZ in the standard system) and the output tax clearing (posting key MVA in the standard system), you must maintain the posting key.
You must also carry out a G/L account number assignment for the tax account.
Maintain the posting key (transaction OB41) - For posting key 19, set the sales order as an optional field !!!
Maintain the field status definition (transaction OB14) - For field status variant 0001, field status group G031, set the
sales order as an optional field !!!
Assign the company code to the field status variants (transaction OBC5)
chandu

Down Payment Processing in Milestone billing

I have created sales order that does milestone billing. The down payment is 10 % of amount - Billing type FAZ and condition type AZWR is included in Pricing Procedure and ERL is asigned.
I also have done all the required settings from the help file at:
http://help.sap.com/saphelp_47x200/helpdata/en/4a/ac853478616434e10000009b38f83b/frameset.htm.
But the sales order still says G/L account not found and not saving. Is the G/L account need to found at sales order itself ? If so, where in sales oredr type I have to assigne account determination like KOFI00 etc ? Can any explain this ?
Does the down payment in sales order do the account determination to find G/L account as in case of regeualr billing docs ?

The following Customizing settings have to be made for down payment processing:
Settings for the billing plan - To activate the billing plan function, maintain the materials, for which you wish to process down payments, with item category group 0005 (milestone billing). This gives the item type TAO via item type determination. The item type TAO calls up the billing plan function.
You need to implement the following activities in the billing plan for down payments:
Maintain deadline category - This determines the billing rule (percentage or value down payment) for the down payment request. The system assigns billing type FAZ (payment request) defined in the standard system with billing category P. (For the billing type FAZ there is the cancellation billing document type FAS in the standard system).
Maintain the deadline proposal - Use the down payments that are due for the proposed deadlines.
Maintaining a Pricing Procedure with the Condition Type AZWR:
In the standard system the condition type AZWR is delivered for the down payment value already provided but which has not yet been calculated. You must include this condition type in the relevant pricing procedure before output tax.
Enter condition 2 (item with pricing) and the calculation formula 48 (down payment clearing value must not be bigger than the item value) for the condition type AZWR.
Before the condition AZWR you can create a subtotal with the base value calculation formula 2 (net value). If the condition AZWR is changed manually, you can get information on the original system proposal from the subtotal.
Maintain the printing indicator - The pricing procedure can not be marked as a transaction-specific pricing procedure (field Spec.proc.) The condition type AZWR has the calculation type B (fixed amount) and the condition category E (down payment request / clearing).
Maintaining the Billing Document - In the standard system there is the billing type FAZ (down payment request) and the billing type FAS for canceling . The down payment is controlled using the billing category P of the billing type. A billing type becomes a down payment request when the billing category P is assigned. You have to maintain blocking reason 02 (complete confirmation missing) for the billing documents and assign it to billing type FAZ.
Copying control - Copying requirement 20 must be entered in copying control at item level for the down payment request. In the standard system the order type TA for copying control is set up according to the billing type FAZ for the item category TAO.
Copying requirement 23 must be entered in copying control at item level for down payment clearing. In the standard system the order type TA for copying control is set up according to the billing type F2 for the item category TAO.
Financial Accounting settings - A prerequisite for down payment processing is that the account is assigned to the underlying sales document. To do this, change the field status settings in Customizing as follows:
Set reconciliation accounts (transaction OBXR) - For the `received down payments' and `down payment requests' from
the G/L accounts you have selected, you should assign the field status definition G031.
Maintain accounting configuration (transaction OBXB) - For the down payments (posting key ANZ in the standard system) and the output tax clearing (posting key MVA in the standard system), you must maintain the posting key.
You must also carry out a G/L account number assignment for the tax account.
Maintain the posting key (transaction OB41) - For posting key 19, set the sales order as an optional field !!!
Maintain the field status definition (transaction OB14) - For field status variant 0001, field status group G031, set the
sales order as an optional field !!!
Assign the company code to the field status variants (transaction OBC5)
By useing tcode---> VKOA assing the G/L accounts for account deteramination

Down payment processing

Hi Friends,
Could somebody throw light on as how Down payment process is carried out in general. Provide flow for the same.
Thanks

The following Customizing settings have to be made for down payment processing:
Settings for the billing plan - To activate the billing plan function, maintain the materials, for which you wish to process down payments, with item category group 0005 (milestone billing). This gives the item type TAO via item type determination. The item type TAO calls up the billing plan function.
You need to implement the following activities in the billing plan for down payments:
Maintain deadline category - This determines the billing rule (percentage or value down payment) for the down payment request. The system assigns billing type FAZ (payment request) defined in the standard system with billing category P. (For the billing type FAZ there is the cancellation billing document type FAS in the standard system).
Maintain the deadline proposal - Use the down payments that are due for the proposed deadlines.
Maintaining a Pricing Procedure with the Condition Type AZWR:
In the standard system the condition type AZWR is delivered for the down payment value already provided but which has not yet been calculated. You must include this condition type in the relevant pricing procedure before output tax.
Enter condition 2 (item with pricing) and the calculation formula 48 (down payment clearing value must not be bigger than the item value) for the condition type AZWR.
Before the condition AZWR you can create a subtotal with the base value calculation formula 2 (net value). If the condition AZWR is changed manually, you can get information on the original system proposal from the subtotal.
Maintain the printing indicator - The pricing procedure can not be marked as a transaction-specific pricing procedure (field Spec.proc.) The condition type AZWR has the calculation type B (fixed amount) and the condition category E (down payment request / clearing).
Maintaining the Billing Document - In the standard system there is the billing type FAZ (down payment request) and the billing type FAS for canceling . The down payment is controlled using the billing category P of the billing type. A billing type becomes a down payment request when the billing category P is assigned. You have to maintain blocking reason 02 (complete confirmation missing) for the billing documents and assign it to billing type FAZ.
Copying control - Copying requirement 20 must be entered in copying control at item level for the down payment request. In the standard system the order type TA for copying control is set up according to the billing type FAZ for the item category TAO.
Copying requirement 23 must be entered in copying control at item level for down payment clearing. In the standard system the order type TA for copying control is set up according to the billing type F2 for the item category TAO.
Financial Accounting settings - A prerequisite for down payment processing is that the account is assigned to the underlying sales document. To do this, change the field status settings in Customizing as follows:
Set reconciliation accounts (transaction OBXR) - For the `received down payments' and `down payment requests' from
the G/L accounts you have selected, you should assign the field status definition G031.
Maintain accounting configuration (transaction OBXB) - For the down payments (posting key ANZ in the standard system) and the output tax clearing (posting key MVA in the standard system), you must maintain the posting key.
You must also carry out a G/L account number assignment for the tax account.
Maintain the posting key (transaction OB41) - For posting key 19, set the sales order as an optional field !!!
Maintain the field status definition (transaction OB14) - For field status variant 0001, field status group G031, set the
sales order as an optional field !!!
Assign the company code to the field status variants (transaction OBC5)

Down Payment processing for Sales orders using Milestone Billing Plan

Hi,
The business scenario is as follows.
The delivery for the sales orders are to be created only after the pre payment( a percentage of the total sales order value) is made by the customer.
Hence the sales orders while creation are blocked for delivery creation using credit block by means of a userexit.
The credit manager checks the blocked sales orders using VKM1 transaction and verify if there are any payments made by the customer to cover this pre payment to be made.
If it is enough to cover then he releases the sales order manually for delivery creation.This is a complex process since there are too many sales orders and the payments made by the customer may not match the amount to be paid(it can be greater or lesser).The customer just pays a huge amount which is to be distributed among the sales orders for pre payments.
Later, when the invoice is created, the customer account is cleared manually using F-32 transaction for the oldest open invoices.
Here again there is a huge manual effort involved since he need to distribute the amount against the invoices using oldest open item principle.
As a solution we are planning to implement "Down Payment processing for Sales orders using Milestone Billing Plan".
Is this the right solution?
Can you please give the steps in detail to implement this functionality for above scenario?
We are using SAP 4.7 version without Project Systems.
Thanks in advance.
Regards,
Ragesh

Hi Ragesh
Check the links where you will get the entire down-payment configuration
[https://forums.sdn.sap.com/post!replydownpayments ]
Regards
Srinath

Alternate Payee Number not capture during Manual payment posting (FBZ2)

Dear Friend,
Appreciate if anyone can help me with below issue.
Scenario:
- Vendor master already been updated with the alternative payee number.
- I have create a vendor invoice with payee data in the field BSEG-EMPFB.
Problem:
When I perform FBZ2 - post outgoing payment and select the invoice created, the payee field was not updated automatically neither based from the original invoice nor vendor master. Furthermore, the field was greyed out during payment posting.
Pls help how can I cantured the payee number based from the original invoice during post outgoing payment.
Thx.

Hi Kiran,
Here is my answer to your Q.
1. Have you given alternate payee in vendor master
- YES, at the genral data->payment transaction and also at alternative payee in doc. I already insert the payee number.
2. While doing FBZ2 in account give the alternate payee and when you go inside it tells no open items found
-NOT exactly, coz i dont use the alternate payee number for choosing open item. I use the same vendor code as per invoice.
3. Click other items and click process open items there you will find the open invoice of the the vendors.
-NOT applicable as i already select the vendor based from the invoice to be made.
When I choose open item during FBZ2, entered the main vendor code as per invoice to be made. In the invoice, the alternate payee number is there already. Just during FBZ2 the field is greayed out, hence the payee number from invoice wav not adopted when manual payment was done.
I notice if i use the FBZ2, the payee field is not open for entry.
Pls help.
Thanks.

Customer Down Payment Process Russia

Hi,
We are currently in the process of implementing our Russian subsidiary into SAP ECC 6.0. In this process we are struggeling to find the correct setup for a specific business process:
For a lot of our customers we are requesting prepayment. We want to handle this in SAP via the down payment process (as in Russia VAT needs to be paid on down payments). So steps are:
We create down payment request for a specific amount.
Customer does down payment + down payment is posted in SAP.
Customer places an order.
We deliver the product and issue invoice (invoice needs link to down payment against which the invoice will be cleared).
Down payment needs to be cleared.
The part we are struggling with is that the down payment the customer does is not for a specific order. It is a lump sum amount which could cover 1 or more futur orders. So for instance down payment can be cleared partially with 1 invoice or serveral invoices can clear 1 down payment.
Question is: How can we handle this correctly in the system? How can we link the down payment to the customer invoice (there needs to be a reference of the down payment in the customer invoice)?

The customer invoice will not be in FI but will be triggered from SD. Russian requirement is that the down payment against which the invoice will be cleared needs to be printed on the invoice.
Also, this seems a lot of manual work (manually transfer the dow payment F-39, manually clear the invoice with transferred down payment F-32, at the end also manually clear the original down payment with the down payment transfers F-32).
If there are only a limited number of such customers this is feasible, but if there are a lot then it becomes cumbersum).
One way of doing it more efficient, I thought, was to manually clear the invoice directly with the down payment via F-32. You can then post the open difference for the down payment surplus again as a down payment. But again this only works manually. I think there is no way to do this automatically (clear invoice with down payment based on amount and against latest down payment + post difference to down payment reconciliation account). I tried via transaction J3RCALD, but this does not seem to work.

Manual payments process

Similar Messages

Maybe you are looking for