You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 36 Next »


Table of Content

2. Objective and Scope 

The purpose of this document is to describe the flow to handle payments received from third party customers and how to search all the necessary information for cash allocation process.

The payments are received on SOLVAY SA's bank accounts and OTC AR matches those payments that could not be matched automatically by the system. This procedure describes which steps should be followed in order to track all the necessary information for the cash allocation process.

This operating procedure (OP) applies to the account receivables of SOLVAY SA.

3. Definitions  

  • SBS: In the current document, “Solvay Business Services” will be replaced by its abbreviation “SBS”.
  • OTC AR: Order to cash Accounts Receivable
  • OTC CM: Order to cash Credit Management
  • CSR: Customer Service Representative
  • OP: Operating procedure
  • 0231: PI system for handling Cash Allocation
  • DZ: Customer  payment

Scope


 

ERP


 

References


Attachments


Details missing templates.xls

4. Cash allocation

4.1. Print bank statements

On a daily basis, the “Coda files” which are the Bank electronic files with information about the amounts received on SOLVAY SA bank accounts are uploaded into SAP. The system does the first sorting and processes the payments in which there is some valid and correct information displayed on the bank statement. Therefore, all the payments that could not be processed by the system have to be allocated manually by OTC AR.

The first thing to do is to print the Coda files as soon as the files are available in SAP coda transaction.

Remark : Not all the files arrive at the same time. OTC AR should check it regularly and after 10:00 (PT time) if some file is missing, OTC AR should send an email to CICC BO (bo.cicc@solvay.com

Open  in  PI1 .

This screen appears:


Click on ‘Get Variant’ 

Remove what is written in ‘Created by’ field.

Click on  ‘Execute’  .


The Coda files list will appear. There are variants divided by country.

Double click on the line corresponding to the country variant and print it. Repeat this step for all variants above.

Warning

For Exports, GB and CH we should check if all the currencies are already available to be printed in the variant. If not, check the correspondent sub-account and verify if the missing currency was automaticaly posted.

4.2. Feba transaction

After printing all bank statement files, payments have to be posted on customer accounts using FEBA transaction. 

Warning

  • In case we are missing details to perform the payment reconciliation, we should send an email from Freshdesk to the customer asking more details. Please check file attached to this OP with the templates with several languages. There is then a daily task performed by the team to send a reminder to the customer after 2 working days and to transfer to collections team in case of no answer received after 4 working days. The case should be closed and a dispute should be created in the unmatched with AR user and Open as status.
  • If we receive a payment for an invoice that is already cleared against a credit note, we should re-open the credit note and clear the invoice with the payment. The credit note can be deducted by the customer on the next payment.
  • In case we have more than one invoice with the same amount on customer account and no information is given on the bank statement, we should send an email to customer to ask payment details. It might be that a credit note is expected or that the oldest invoice has a due date issue.

Open  Feba  transaction:    

This screen has to be filled in as follows: 

  • Company code: 0231
  • Statement status: 7 “Incompletely Posted” (It only gives the entries that still need to be processed) 

Remark: In case there is the need to search a payment already posted, choose status 8.

     

With Status 7 selected, click on the icon Execute  to get all the payments to be posted for all the Regions:

This gives an overview of the bank accounts where remained payments that need to be posted by OTC AR. There are two available statuses: 

  • To be posted - to be processed by OTC AR
  • Posted - already processed 


Based on the list of entries not yet posted (red items), the bank and the currency that has to be processed should be selected by double clicking on the item. 

Example:

Remark : As soon as the payments are posted, the amounts become green on FEBA statement. See example below:

To process a payment, click twice on the concerned line and afterwards on the floppy disk . This will have to be done for each red item. 

At this stage, 5 possibilities can occur:

  1. the customer account was automatically found by the system
  2. the system finds a  customer account which is wrong
  3. the system doesn’t find the customer account
  4. The system opens more than one customer account
  5. The system opens only some items

1. Customer account was automatically found by the system

 

Having the name of the customer or the invoice number, the system is able to identify the customer account itself. However if all the details are not displayed in the statement, the system is not able to perform the matching.

In the bank statement below, there is mentioned the customer name.

Therefore, the following screen appears suggesting already the customer number in the Account field:

Thus, we should select the correct invoice by double-clicking on the amount in the “EUR Gross” column.

The amount is now displayed in blue. 

At the bottom of the screen, the “Amount entered” (corresponding to the amount of the payment) is equal to the “Assigned” amount (our invoice selection), meaning that the payment matches perfectly with the invoice. In this case, the “Not assigned” field (at the bottom of the screen) is equal to “0”, meaning that the transaction can be validated by clicking on the floppy disk  (at the top of the screen). 

If the “Not assigned” field does not equal to “0”, different explanations are possible:

The amount could be a banking fee, a discount (star), etc. Therefore an analysis should be done to find the reason of the discrepancy

(star) The difference must be posted by using the procedure “Management of Payment discrepancies”

 

 

2. Wrong customer account

It might happen that due to wrong information on bank statement, system will open a wrong customer account. We should always confirm if the account opened by the system is the correct one checking the information available on bank statement as customer name, address or some invoice numbers. Thus, a new search should be executed. Please refer to “Account not found” chapter, where all the possibilities of finding a customer are described.

 

3. Account not found

In case system cannot identify customer account due to lack of information, there are several possibilities to find it but the most common one is searching: 

  1. by invoice number  (star)

  2. by customer name

  3. by customer details (Address attributes, VAT Reg, Sales group, amount)

  4. using “Customers and Regions Specificities” Database

(star)  Sometimes a part of the invoice is missing or a number is wrong. However, we can try to focus the search on the document using * and trying different numbers in order to find the correct customer

 

a. Search by invoice number

 

Open “Z3F_FA_CNTR_DISPLAY” transaction. 

The first screen that appears is the following: “Factoring contract display”.

This screen should be filled in as follows:

Affiliate document number – Invoice number

Then click on the Execute button  

 


All details regarding the invoice number are displayed on the following screen: 

The image is divided by colours to easily explain the fields. Therefore: 

Red: In this box, we can find the customer name, the document (invoice or credit note) and its amount

Green: Here we can find the contract status (open, closed, etc.) and creation dates

Yellow : In these fields, we can see information regarding the affiliate as the company code, document (Invoice reference), reference and PO Ref. Also the customer number in local company is visible here

Blue: Information of the document in 0231. Again the inv. Reference available and customer number is in 0231.

Pink: On the left side, all the information regarding dates for affiliate and factoring side. On the right side, it is displayed all the information related to payment status (open or closed in Cc 0231, payment method and discount terms

b. Search by customer name

 

Click on the floppy disk on the payment. The following screen appears: 

To search for the customer number, click on the icon . Following screen appears:

 

This screen enables us to search for a customer by country, by name, etc.

Advise:  Use upper case letters and if you are not sure of the entire name, type a part of the name, surrounded by asterisks, as in the upper example and then click on .

When the system finds a result, following screen appears:

 

Click on   or double-click on the customer name to automatically return to the previous screen – “Post with Clearing Select open items”.  The “Account” field is automatically filled in with the customer number as follows:

 

 

 

Click on “Process open items”. (star)

(star) Open items= list of invoices not yet paid in the customer account

 

c. Search by customer details

 

 

On  FEBA  transaction, click on   button:

Afterwards, the most common search is by “ Cust. search using addr. attrib. ” to search by name or address, or using “ Account Number or Key of a Worklist ” to search by VAT number. See below:

 

 

To have the possibility to choose a different search layout, close the search option and click on the button below. This way, you can choose the search option that is more suitable for each case.

d. Search using “Customers and Regions specificities” Database

All specificities regarding customer and Regions can be found in the Google drive or in the following link:

Warning

This database should be consulted before any dispute creation so that we can assure all specificities are taken into account.


4. The system opens more than one customer account

In the case showed below, the system suggests two customers’ accounts that have the same invoice number but in different company codes. In such cases, we should enter in both invoices to find out to which one belongs to the payment (it can be checked by customer name). If by selecting the correct invoice matching cannot be done, you should go back and copy the correct customer number in order to open all open items on the account.

5. The system opens only some items

 

The documents proposed by the system do not necessarily correspond to the total number of items opened in the account of the customer. The reason is quite simple: when the system identifies the invoices concerned by the payment (document numbers given in the payment details), it proposes only those documents. The rest of the account doesn’t appear.

To obtain all customer open items, click on the back button  (at the top of the screen) and the following screen appears:

Click on Choose open items” on the screen above, insert code “A” in "Special G/L ind" field in order to open all items (payments in advance included) and then click on “Process open items” on the following screen:

The customer account is then displayed with all open documents and the rest of the documents indicated on bank statement can be selected. 

Validate the transaction by clicking on the floppy disk   (at the top of the screen).

4.3. Posting a payment as DZ on customer account

Sometimes there are payments received from identified customers but without any payment details (invoice numbers). Those amounts cannot be matched on customer’s accounts against the invoices but they must be applied on the customer’s account as a DZ document. Then, a dispute and a Freshdesk case (when needed) should be created to obtain the payment details. 

In order to leave the payment open on customer’s account, we should proceed as follows: 

We should click on Save button on the payment screen on FEBA transaction:

Click on the green arrow at the top of the screen . Following screen appears:

This screen must be filled in as follows: 

  • PstKy: 15 (for credit movement on customer account – Incoming payment)
  • Account: Customer Number


Afterwards, click on  ‘Enter’.  The following screen appears:

In this screen, the Business Area (if possible to identify the correct one) and amount must be indicated.  

In order to insert the amount, simply type asterisk  “* “in the Amount field and press Enter  to avoid errors (more accurate). The item can be now validated by clicking on the floppy disk 

4.3.1. Search the Business Area


How to see the correct Business Area depends on the Company Code of the invoice.  

 

If company is from PF1, we can check it in the local system, by simply adding Business Area column to the layout.

If we know the number of invoice that is being paid, we use its Business Area.

If we don't know what is being paid, but customer has only one Business Area, we should use it.

If it is not easy to identify the correct Business Area to be used, we should allocate the amount without any Business Area.

 

 

 

If company is from WP1, we should use transaction Z3F_FA_AR_FIND_BA in PI1 in order to find Business Area. Please note that in order to use this transaction we need to know the contract number or the order of the document that is being paid.

 

 

 

 

 

 

 

After selecting the needed System landcape, order needs to be inserted in the Sales Document field.

Then press the Execute button .

 

 

 

 

 

 

 

In the screen that opens, the Business Area to be used can be seen.

 

 


 

 

The search of Business Area can be done by Contract Number too. It needs to be inserted in the Contract Number field.

Then press the Execute button .

 

 

 

 

 

 

 

 

In the screen that opens, the Business Area to be used can be seen.

 




 

 

 

 

 

 

 

 

 

 

 

 

 

4.4. Payment in Advance procedure

Sometimes we receive payments made by customers before the goods are shipped and invoice sent and assigned to SOLVAY SA. Therefore, we receive the payment and the invoice isn’t yet available on customer account. 

There are three steps that should be considered when recording a payment in advance: 

  1. The customer must be identified
  2. Check whether there is an invoice open in that account, and if not, consult the various systems to determine if an advanced payment is expected
  3. If the order, customer and amount are identical of what is stated on bank statement, we are authorized to process the E5 (payment in advance). If not a dispute should be created requesting confirmation to Credit Manager.

4.4.1 Check local system

Sometimes we need to consult local system to retrieve data regarding the payment in advance. See below:

 

Searching for Sales Orders and Invoices in PF1

Example:

In the bank statement above, we can see the reference of order (4666877). Sometimes we can see the customer name too (for example, Procter and Gamble). Thus, there are two options to find the order number:

  1. by document number
  2. by customer name

 

 or

 

1. Search by document number:

Use transaction VA03 to search either by proforma (Billing document) or by order number (in the example we have the order number):

Click on 

The following screen appears:

 

The “Payment terms” field must be verified to check if it is a payment in advance or not. On the “Payment terms” field two options can occur: 

  • X InvD
  • Payment in Advance 

In this example, the invoice will be probably on customer account since the payments terms are 60 D InvD. So, to search for the invoice number related to this order, click on Environment and choose Display document flow as follows:

The following screen appears:

This gives the invoice numbers sent to the customer “6111143015” and “6111343018” which should be found on customer account in 0231 (PI1). In case the information is not enough or in case you are not sure of the correct invoices, you can try to find them by the order number that is mentioned in the assignment field in PI1.

In case of having an order with “Payment terms”: “Payment in advance”, we should check if the customer name and the amount of the order are the same as mentioned on the bank statement. If yes, we can post the payment in advance on customer account and a dispute will be automatically created informing Credit Manager. If not, we should create a dispute and ask confirmation from Credit Manager/ Credit Analyst regarding the order number.

2. Search by customer name: 

Open transaction VA03 and click on Sold-to party field

You will get the following screen:

 

The customer’s name should be inserted between asterisks. Click on   

The following screen appears:

Check both customers to see which the correct one is. Afterwards, click on

The system adds the customer’s number in “Sold to party” field automatically, and then clicks on 

The following screen appears which gives all of the pending orders for this customer. In general, the payments received involve the most recent orders, so click above the Doc. Date column to order it by date.

Then, check the last order and in case of non-conformity create a dispute.

There can be more than one proforma document mentioned in the bank statement and the numbers of the proforma documents can start with different numbers as 77… or 922… or 925... or 200... The proforma references are different depending on the company that issues the document.

If there is more than one proforma document, all of them should be checked and orders found. The sum of all orders should be equal to the total amount of the payment. If the amount is not the same always create a dispute asking for the confirmation of the orders and the amounts related to each of them. Check also if the difference is banking fees through customer masterdata.

Warning

If no useful information can be found or if there is the slightest doubt, create a dispute asking for details to the Credit Manager. 

The example described is related to PF1 system, however the same procedure should be executed for WP1.

4.4.2  Process a Payment in advance

The first thing to do is to post the payment on customer account as a “DZ” document type entry (see paragraph 4.3 of this procedure). 

Remark: If the original payment was made via check, the document type entry recorded is “DK”. It may also happen that the document type entry recorded is “AB”, as a reconciliation resulting from using transaction F-32. This procedure only mentions document type “DZ”, but it applies exactly the same way for document types “AB” and “DK”. 

Then, we should transform the  “DZ”  entry into an  “E5”  entry through  Z3F_FA_PIA transaction.

This screen has to be filled in as follows:  

  • Company code: 0231
  • Customer: Customer number in which payment was allocated
  • Processing Mode: N
  • Test mode: Not selected

Then click on . The following screen appears:   

We should select the line of the payment that needs to be transformed into payment in advance, double click on it and fill it as follows:

  • Aff.Co Co: Affiliate number
  • Sales Doc.: Sales order (we should fill this field or the Billing doc. – Only one is needed)

Warning

Please check if the order you are using wasn’t already used in customer account (ex. more than one payment for the same order). If not, you can proceed with the transaction. If it was already used, please insert a “.” in the “Assignment” field of open document with the same order, process the transaction and after the E5 creation, delete it.

  • Billing Doc.: Billing doc. (we should fill this field or the Sales doc. – Only one is needed)

Then we should choose button  and the Amount field will be filled automatically with the Sales document amount. Please note that BusA field must be filled in, otherwise payment in advance will not be processed. When there are differences between this amount and the payment, it can be for several reasons: partial payment, banking fees, etc. Thus an analysis should be performed to trace the reason of the difference.

Click on 

Choose Yes in the table and the following message appears:

After this posting, a job will run automatically and will create an E5 document on customer account. See below an example:

A dispute will be automatically created informing Credit Manager of the posting. 

When the invoice is assigned and there is no difference or the difference is on the customer master data tolerance, an automatic job runs every day and clears the E5 with the invoice (s). If there is a difference which is above the tolerance, the job will not clear and we should ask information to the responsible CSR and Credit Manager.

As soon as the invoice is cleared, the posting on customer account is as below:

Warning

Please note that after processing a Payment in advance, the related order should be released (The detailed description of how to release the order is in Chapter 4.4.3).

Payment in Advance for more than one order:

In case our payment is for more than one order, we should divide the payment on the transaction Z3F_FA_PIA as below:

This screen has to be filled in as follows:

  • Company code: 0231
  • Customer: Customer number in which payment was allocated
  • Processing Mode: N
  • Test mode: Not selected

Then click on . The following screen appears:

We should select the line of the payment that needs to be transformed into payment in advance, double click on it and fill it as follows:

  • Aff.Co Co: Affiliate number
  • Sales Doc.: Sales order (we should fill this field or the Billing doc. – Only one is needed)
  • Billing Doc.: Billing doc. (we should fill this field or the Sales doc. – Only one is needed)

To add another order for this payment, we should select   and fill with the information regarding the other order.

Then, we should click on   so that automatically the Net value field is updated (Sales order amounts) as below:

Finally, insert the correct amount on “PayAdvAmnt” field according to the orders

and press Save . In case there are banking fees, the amount inserted should be changed so that the total amount of the orders is the same as the payment amount. Please note that BusA field must be filled in, otherwise payment in advance will not be processed.

Choose Yes

and the following message appears:

After this posting, a job will run automatically and will create two E5 documents on customer account. See below:

Disputes will be automatically created informing Credit Manager of the posting.

When the invoices are assigned and there is no difference or the difference is on the customer master data tolerance, an automatic job runs every day and clears the E5 with the invoice (s). If there is a difference which is above the tolerance, the job will not clear and we should ask information to the related CSR/ Credit Manager.

As soon as the invoices are cleared, the posting on customer account is as below:

Warning

Please note that after processing a Payment in advance, the related order should be released (The detailed description of how to release the order is in Chapter 4.4.3).

4.4.3  Release the Order related to payment in advance

After processing a Payment in advance, we should click on , then go to the "Status tab" in VA02 transaction and check in the "Credit Status" line if the order wasn't released yet (The status needs to be "Not approved"):


If the "Credit Status" is "Not approved"; the payment received corresponds to the payment terms of the order and the amount of the payment and the order is the same, check if the Deliver block field in the main screen is 

. If it is the case please remove it choosing the option which is empty (see below):




Afterwards, we should go to VKM3 transaction, insert the order number and press Execute button :


Then select the line, click on button and press Save . The following message will appear:

4.5. Customer blocked for posting 

When processing cash allocation, it might happen we find a customer that is blocked. Therefore, the system will give an error message stating that the customer account is blocked for posting. Find below how this situation should be handled. 

On FEBA transaction, we insert customer number. Click on the icon “Process open items” and the following error message appears: 

In this situation, OTC AR should analyse if the customer account suggested by the system is the correct one (in transaction FBL5N confirm if there is an open invoice, if there is another customer account with the same/ similar name or if there are Freshdesk cases with the same issue) and in case of doubts contact Credit Manager before requesting the unblocking.

In case the blocked customer is the correct one, OTC AR will need to create a case and transfer it  to Data Management team (Queue “PtP D&A EMEA”) asking to unblock the customer account. When Data Management team will transfer back the case to OTC AR queue saying that the account was unblocked, we should post the payment on the account and after we should return the case to them so that they can block the customer account again. 

Warning

In order to register this payment as unallocated, we should create a case and classify it with status “Need for more information” and OTC-Subprocess “Unallocated payment”

4.6. Customer not created in Cc 0231

In case customer is not created in Cc 0231 and we are sure that is the correct customer, we should run transaction Z3F_FA_PARTN_CC_VIEW.

First of all we should select variant CIE0231 by double clicking on it:

 

 

 

 

After that we should insert customer account number and execute   

Customer is then created in 0231 with default values.

 

 

4.7. Payment to be transferred by IBA to other company

For all cases in which we receive a payment in SOLVAY SA which should be transferred to other Solvay company, we should follow the described procedure. 

Warning

  • If the payment is already allocated, you should reverse it before starting this procedure
  • For payments received in SOLVAY SA Cc 0231/ SOLVAY FINANCE AMERICA Cc 4044 for companies/ documents not assigned, we should transfer the payment by IBA (as explained below). Once the IBAs run (it can take one day or more), the clearing in local system between the G/L account (5080900000 in case of PF1 or 58999920 in case of WP1) and customer's account should be done using transaction FB05
  • When processing an IBA movement with exchange, always inform treso.cicc@solvay.com in case the payment currency is not the same as the Affiliate's main currency.

Open transaction Z3F_FA_IBA_TRANSFER2


 

Insert the sub-account concerned (in this case 50501USD16), Document Number (in this case 9002850591), remove tick from the "Test Run" and Execute.

 

The next window is open:

Then, select the line concerning the payment and insert the information regarding the IBA account to which the payment is being transferred by pressing  

 

and press

 

The IBA account is usually composed by 591 + currency of the payment + affiliate's company code 

 

 

 

In order to help the affiliate to identify the reason of the transfer, in the "Text" field, it should be mentioned the customer number and invoice number.

After all information is inserted, select the line and press .

 

 

 

The posting executed will clear the TI document in 0231: 

Warnings

  • Change the flag of the payment in Z_FLAG_CODA transaction 
  • Use transaction Z3F_FA_AFF_INFO to understand if an IBA is created and weather it is available or blocked for posting. In case the IBA doesn’t exist or it is blocked, we should search if there is a vendor account for that company and if it has a bank account. If not, please send an email to treso.cicc@solvay.com

4.8. Payment to be transferred to vendor account

We might have the need to allocate a payment received in SOLVAY SA in a vendor account. There are two possibilities in the Z3F_FA_TRANS_AR_AP transaction:

Warning

If the payment is already allocated, you should reverse before starting this procedure 

 

  • Refund to vendor  

Selecting this option, the objective is to use the payment to be transferred and paid back (ex: transfer to Solvay affiliate whenever there is not convention with CICC or to transfer to other entity that not Solvay as the case of de-migrations or companies which were sold). 

 

 

 

  • Transfer to vendor account (no payment) 

Selecting this option, the goal is to manage the payment in vendor account, meaning that no payment is to be executed. In this case, OTC AR should execute the posting and then inform PtP (create a case in Freshdesk and transfer it to “PTP HD EMEA” queue). 

 

 

Select one of the options described above and insert the sub-account concerned (in this case 50533EUR16), Document Number and unselect the tick on the "Test Run" option. 

Execute . The following screen appears:

Select the line and insert the Vendor's number by pressing  button.

Validate it by pressing .

In the text field of the line related with the payment, insert the information you find relevant for the transfer as customer, invoice or case number (please note that the text space is very limited). 

Select the line and finalize posting by pressing button.

 

 

 

 

 

 

 

A KF document will be open on vendor account as below:

  • in the 1st option with payment block B and will be paid;
  • in the 2nd option with payment block H and will remain open until further action from PtP; 

Example: 

 

 

 

 

 

On the KF document in the vendor's account in the  tab we should insert the correct vendor's "House Bank" and "Part. Bank Type".

 

 

Warning

Change the flag in Z_FLAG_CODA transaction.

The posting executed will clear TI in 0231 as you can see in the example:

4.9. Negative amount in Feba

Every time there is a return of a payment, a credit note, banking fees or a cancellation of a payment, we receive a negative amount on the CODA files. 

When a negative amount arrives in FEBA statement list, the way to proceed depends on the subaccount on which the amount is posted. This chapter describes how to handle these transfers. 

Warning

Before asking details to Credit Manager/ CICC BO, we should first analyse the bank statement and the Sub-account related looking for a document number or customer number that could lead us to the Country/ Region related. Then, we should also try to see if it is related to banking fees or to a payment to customer, which could be already executed by OTC AR

The first thing to do is to check in which Sub-accounts the movements are recorded. Therefore, the 900… doc. on FEBA transaction should be consulted 

Double click on the document:

The following screen will appear:

In this example, the posting have movements on 16 and 10 Sub-Accounts. 

There are 2 possibilities: 

  1. If related with Bank Sub-account 12, 15,16 or 17   

A)     Amount until 10€ - OTC AR is authorized to post this amount as banking fees.

Go directly to the G/L account related (you can access it on 900… doc.) in transaction F-03 (0231), choose the TO related, go to Residual items tab and post as FB, as in the example:

Warning

After this, the flag should be changed to “Posted” status in transaction Z_FLAG_CODA.

Example to change the flag of the coda:

In order to change the flag insert the first sequence of numbers in the “Short key” field and the second sequence of numbers in the “Memo record number” field. Click on the “Execute” button with “Test” field marked in order to check if the flag is related to the correct statement. If yes, go back, take off the tick from the “Test” field and press “Execute” again. 

B)     Above the limit of 10€ - We should search possible payments cancelation (ex. Direct debits/ cheques cancelation; search open items in that country by that amount). If no result is found or in case it is mentioned on bank statement “Frais bancaires” or some word that leads us to think it is banking fees related, we should then address the email to CICC BO (bo.cicc@solvay.com). In case the answer is to post as banking fees, please refer to explanation described on line A).

2.  If G/L accounts 12/15/16 and 17 are not included:  

In this case, the negative amount is not to be handled by OTC AR. We just need to change the flag to “Posted” in transaction Z_FLAG_CODA. 

Example: 

This amount will be cleared on the subaccounts when doing the subaccount reconciliation.

 

 

4.10. Unallocated payments 

For all payments that OTC AR is not able to find the correct customer account, some steps need to be followed: 

Warning

SOLVAY SA/ RHODIA bank account should be mentioned on the email as well as payment amount/ date and bank statement.

  • If the Bank is not able to give us additional information which can help us to trace the payment, we should escalate the situation to Credit Managers mailboxes (the general mailbox used for that is Europe.CreditManagement@solvay.com)

 

 Transaction ZPVK  

Therefore, open transaction ZPVK in local system as below:

On the “Credit rep. group” option insert “01” to “51” in order to have all the Credit Managers and Credit Analysts included.

Then choose the layout /UNALLOCATED

Click on it. The following screen appears:

Then, order by amount on “Net value” column and try to find a similar amount with the payment amount we have received. After go to VA03 transaction with the order number to retrieve more details and finally go to customer account and analyse payment history and  previous bank statements to confirm it is the correct one.

Afterwards, whenever the payment remains unallocated and we are waiting for information we should create a note with Freshdesk case number in SAP PI1 entry document (900…), as follows:

Double click on 900…. document of the unallocated payment.

Click on Services for Object icon  and choose Create → Create Note

 

 

Insert then the case number as below:

And click on the button.

 

 

 

The same information, stating "Unallocated; Case XXXX", after double clicking on 900... document, should be inserted on the respective subaccount 16 too as you can see in the example:

 

 

 

 

 

 

The case in Freshdesk should be classified with Status “Need for more information” and OTC-Subprocess “Unallocated payment”.

 

 

 

4.11. Payments not for Solvay 

In this case, we have mistakenly received a payment from other which is not a Solvay customer. Therefore the payment should be rejected. If we received that payment on a BNP bank account, it is possible to ask the transfer back asking it to bo.cicc@solvay.com. If not BNP, we should try to find a contact of the entity which made the payment so that we can request bank details and proceed with a manual reimbursement. 

4.12. Solvay SA (Cc 0231) closure

This section describes the main principle which must be respected concerning the monthly closing and explains how to proceed when an answer is received for a payment when the corresponding accounting period is already closed. 

Warning

For clearings on F-32 transaction we should ALWAYS use payment date (see value date of DZ document) on the “Clearing date” field. In case the period is already closed, we should use first day of the current month. 

0231 closure starts on D-1 (last working day of the month). See below the impact of the closure on OtC AR postings:

Customers clearings: The last day to perform with current month date is on D+1 (until 15h Portugal time)

IBA movements: The last day to perform with current month date is on D-1 

Posting a payment in a closed period:  

Sometimes we have to post a payment when the period is already closed. Please see below how to proceed: 

For example, an amount is on the FEBA dated 21st April 2017.  But the information needed is provided by Credit Manager only beginning of June 2017 when April period is already closed.  The amount has to be posted in June.

In FEBA transaction click on the floppy disk 

The following screen appears with document date and posting date 21st April 2017:

Then click Enter,

 

The following error message appears:

 

The posting date should be changed to the first day of the current month as well as the Period and Enter should be pressed in order to be able to proceed with the posting.

#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels