...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
- DT: Digital Technology
Scope
ERP
References
| Expand | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||
|
Attachments
...
In PI1:
Open FEBA transaction and choose the following criteria's:
Company code: WARP
Statement date: Statement date of the payments
Statement status: 7
Execute 
Afterwards, click on each unallocated (red entries), click on the 900… document, choose 
and go to the "Attachment list" to check the case number. Then, go to Salesforce and check if the case was correctly created and sent to the correct entity (Credit Manager, cash collector or to banks).
...
Use FBL3N transaction in PI1 system to check the unallocated payments as below:
Select only the document type "TI" (transfers IN) and then search by "unallocated" in the text field. Example below:
Afterwards, for all the open payments we should do the follow-up by verifying if the item can be cleared, sending reminder or escalating to AR Process Expert if it is blocked for resolution.
For PF1 and WP1, the payments are posted on customer accounts by
...
Finance team (automatic postings during the bank statements upload). Therefore
...
Finance team should
...
create a
...
ticket to
...
Credit Management in case of unallocated payment in which they are sure it is customer related.
...
Then the report "Unallocated" should be retrieved from Salesforce report as below:
...
| Warning |
|---|
|
...
|
On a daily basis the following file is updated:
| Warning | ||
|---|---|---|
|
...
|
Example:
...
3.1.1 Escalation procedure
For unallocated cases for more than three months and if no answer received or if is not enough to allocate the payment, the team member doing the controls should send an email to Accounts Receivables
...
Service Owner, explaining the reason why it is being escalated (mention if no answer received, doubts, proposal). In case it is interco related or any technical constraint, a reminder should be sent to the company related or to
...
DT.
3.2 Weekly review of Unmatched payments
The objective of this control is to assure that all non-matched payments equal or above 50.000,00 EUR have been analyzed and escalated. Therefore a list with all those items has to be justified
...
.
This weekly control must be done on Thursdays.
...
Open FBL5N transaction and chose the following variant:
...
Execute 
The following screen
...
appears
...
...
...
the companies according to this file:
| Embedded Google Drive File | ||
|---|---|---|
|
For each of the unmatched amounts,
...
...
...
...
...
...
| Warning |
|---|
|
...
|
...
3.
...
3 Monthly review of receivables not assigned to
...
Factoring company
The principle
...
is to have all customers/receivables from a company with convention with
...
Solvay SA/Essential FA assigned to
...
the Factoring company (Cc 0231/6440). Therefore, the objective of this control is to show evidence that customers not assigned
...
have a valid reason in the "Long text" field for not assigning its receivables.
This control should be
...
done once per month on the D+2 in the
...
two local systems assigning to
...
Solvay SA/Essential FA: PF1
...
and WP1
...
.
...
...
transaction in local systems and choose the following variants in all systems:
...
Execute 
...
...
...
- Public institutions
- Legal purposes
- Phisicall persons
- Legal reasons (Ex. Italian law)
- Contract decision to local bank account
- Private persons
- Old doubtful accounts (not new cases)
- Local specificities (it should be detailed the reason)
Other reasons from these ones should be analysed and escalated to Aurelie Mazerot and Hugues Frisque.
This result should be extracted to excel as below:
Click
...
on 
...
Execute 
Save the file in your desktop
Finally, add this excel file to the email with the remaining controls.
Example of the file:
3.
...
The objective of this control is to check if the open receivables in WARP are the same as the ones in local systems: PF1, WP1 and RHO.
Due to various reasons, a clearing done in WARP can be blocked in the affiliate interface and originate a difference in the balance. Running the transaction mentioned below, all the entries which show different balances between WARP and local system customers will appear in the transaction result. All open entries should have a clear justification and to whom it was escalated.
Open transaction Z3F_AP_AR_BALANCE in PI1 system and Execute 
Remark: This transaction can take some minutes to open
The following result appears:
Then, limit the search to customers by selecting "C" in the "Partner Type" as below:
After, the limit should be done in "CM region mgmt" by excluding "Lat" and "NAF" as below:
...
Remark: The ones without Region in "CM Region mgmt" are the ones which the mapping correspondence was removed, however they should be checked to assess if EMEA and ASIA related and under the scope.
Each line shows a discrepancy of the balance between WARP and local system customer account. The field "Delta" shows the amount of the discrepancy.
Example:
In order to have a detailed view of the discrepancy select the line and click in 
.
In the image above we can see that the difference of 325.606,12 is related to contract 1000827683.
The control of this report is focused in the "Responsible" and "Issue" fields in which we should find the reason of the discrepancy and the entity to whom it was escalated. See examples below:
Click in 
and save the file in your desktop.
The report should be extracted to excel and send it in the email.
3.5 Daily Review of Factoring Monitoring
All the assigned Receivables to CICC that do not have all the information or aren't correct can originate errors when are assigned and are displayed in Z3F_FA_OI_MONITOR transaction.
All the contracts assigned to WARP are verified automatically by the system through 24 checkings, described below:
| 101 | OPEN: Check downpayment not yet paid |
| 102 | MD: Check vendor master data payment block (Factoring) |
| 103 | DOC: Document currency not accepted |
| 104 | INTRA: Document belongs to a chained vendor |
| 105 | DOC: Posting date is higher then current date |
| 106 | PAYM: payment method of document is not accepted for this vendor |
| 107 | MD: Partner doesn't exist in the factoring company (general) |
| 108 | MD: Partner doesn't exist in the factoring company (company code) |
| 109 | MD: Partner is blocked for posting in the factoring company |
| 110 | MD: Partner is flagged for deletion in the factoring company |
| 111 | DOC: Document date is higher then current date |
| 112 | DOC: The amount is bigger than the reference amount |
113 | DDEBIT: Vendor with direct debit / Doc with other payment meth. |
| 114 | DDEBIT: Amount over the direct debit limit |
| 115 | DDEBIT: Payment method in doc.(5) different from the one in the vendor |
| 116 | MD: Bank country with embargo |
| 117 | DOC: Document type is not valid for agents |
| 118 | COMPANY: Item belong to invalid company code |
| 119 | PAYM: payment method of document is not accepted for this customer |
| 120 | DOC: Document with factoring but master data in manual exception |
| 121 | DOC: Document with factoring but no factoring in master data |
| 122 | MD: Check vendor master data payment block (Affiliate) |
| 123 | DOC: Amount is bigger than max amount (Incoming cash) |
| 124 | DOC: Amount is bigger than max amount (Outgoing cash) |
The objective of this control is to check that all open entries are already handled and escalated to the proper entity.
Run Z3F_FA_OI_MONITOR in the three local systems transaction:
Select Customers and Execute 
Remark: the US, CA, MX and BR customers should be excluded.
The status of the entries should be yellow and the payment block X, meaning that the situation was already escalated through email. If it is red, it means that is open and it wasn't analysed.
It should be done a print screen of the entries and added to the email.
Warning: The controller should check all cases pending for more than 15 days and do the follow up, checking if it can be solved and if not, to send a reminder.
...
4 Records of doubtful receivables and losses based only on a supporting document communicated by CM
For bad debt customers, we should provide the request in which
...
AR team received the request to post a customer into doubtful status only if requested by Audit company. In this case, we should search in
...
BMC the request case and send it to the requester.
4. Reporting controls
The email should be send to the following addresses:
...
Service Owner Accounts |
...
Receivable |
...
...
...
OTC BO Manager
...
Accounts Receivable team leader:
...
Cash Collection team leader:
...
Regional Team Leaders | nuno.mendes@syensqo.com; caio.alves@syensqo.com and laddawan.wiboolworakul@syensqo.com |
Accounts Receivable Mailbox | receivables@syensqo.com |
...
Accounts Receivables team mailbox
...