2. Process Overview

• High-level flow-chart

• High-level process

As a general rule, Credit Control is performed at order level. A few exceptions exist, where it is executed at the delivery level or good issue level.

Both at order and Delivery level

• RSIT in Shanghai (0086) (standard risk category) => there is no production activity, it is only a trading company.
• Rhodia Hong-Kong (0040) (standard risk category) => since some year ago there isn't any more commercial activity

At Delivery level only

• Brazil credit control area (0095) for Fibras business
• Ongoing request: for Rhodia Feixiang Zhangjiagang (China), which went live in RCS in January 2013, to carry out credit check at delivery level. The purpose behind that request is to be able to manage the customer that pay in advance (70% among 1800 active customers per year) 

At Good issue level only

• Brazil credit control area (0095) for Fibras business => used just for "payment in advance" in order to have the correct weight and value of the load matching with the payment received. : this is linked to the product - the credit control at the delivery enables an adjustment of the quantity to the paid amount in case of payment in advance. Before, a credit control at the order was performed and customer often didn't pay the balance.

Other exceptions

• ACETOW in the RAG (Germany) and Sertow (Russia) entities (different SAP system from Rhodia's standard)
• DACARTO (BR)

The credit check is made on the payer. If the sales order is created without payer, there is no credit control.

The credit control depends on the sales document type. For each sales document type, a customization is needed : 'no credit check', 'simple credit control' or 'automatic credit check'.

Automatic credit check was implemented and various checks are available (see credit checks).

The credit control takes place during a sales order creation, as well as at sales order changes, when the sales order is saved. If the customer data does not comply with the credit control conditions, the order is blocked.

In some cases, till conditions are met, credit check is not executed (order not complete, …).

If an order is blocked for credit, it can be automatically or manually unblocked. Once the order is released, it can follow the normal sale flow: order, delivery, billing, factoring ,…

Each night, a program runs to unblock the previously blocked orders: if the conditions are met (because a payment was received, credit line was increased, …), orders are automatically unblocked.

In the future, program will turn more often.

The ZPVK transaction is used to help the Credit Management identify the orders blocked for credit reasons. Blocked orders can be manually released via this transaction at any time.

The credit control needs data from SD and data from FI to perform the credit checks. As customer FI account data are dispatched between PI1 (factoring company accounting) and PF1 / WP1, we will use the SAP technique called "A/R summary" and an automatic running program to merge all useful FI & SD data in one table.

The credit check is made only on the "confirmed" quantity. This means that an order for which the quantity has not been confirmed is not included in the credit check and in the credit "outstanding items". It is only when the quantity is confirmed that the order undergoes this credit check, and can thus be blocked for credit.

3. Detailed Process Description

3.1 Risk Categories

3.1.1 Description

3.1.1.1 Introduction

• The Credit Control on an order is based on a Risk Category which will determine the rules that will be applied.
• The Risk Category is used to internally manage the Credit Control on the Order. It is not communicated to the business.
• For every customer, one Risk Category is assigned, with linked parameters. Those parameters will be used at credit control level to automatically block or not an order.

3.1.1.2 Determination of the Risk Category

The Risk Category results from the combination of 2 elements :

• the scoring rating;
• and the payment index.

The combination of those 2 elements give a two-entry table of risk categories (see Table of Risk category)

3.1.1.2.1 Scoring Rating

• The scoring rating is defined via the tool FSCM by the Credit Management Team, on the basis of a customer, business and financial analysis.
• It gives an assessment of the risk associated to a customer.
• The possible values for the Scoring rating are the following :
  
  

3.1.1.2.1 Payment index

• Each customer is granted automatically a payment index.

• The introduction of a payment index Good / Bad enables to ‘reward’ customers with good payment experiences and penalize customers with bad payment experiences.

• The payment experience is defined as the weighted average delay over the 6 last months. It is expressed in days.

• Limit between a good and a bad payer is set at 3 => Bad payer > 3 days

• The possible payment index values are:

  
  

 

• A NEW customer gets, by default, a value at blank, meaning a good payment experience.

'Rounding' method:

IF < 0,5 => previous unit

IF > or = to 0,5 => next unit

Example: 2,19 => 2 ; 2,65 => 3

• Exceptions :
  • Internal Customers (identified by the company consolidation method) will automatically receive a risk category S (Solvay)
  • New customers will automatically receive a risk category NEW.

3.1.1.3 Table of the Risk category

• The Risk category is the result of the combination of the Scoring Rating and the Payment Index:

  
  

How to read this table?

• If a customer :
  • gets a scoring rating 2;
  • and is a bad payer

Then a Risk Category 2B will be automatically assigned to the customer by the system.

Important remarks:

• "1G / 1B": "G" stands for 'Good' and "B" stands for 'Bad'.
• Communication with business: Only the FSCM Scoring Rating will be communicated (rating 1 -> 5) to the business. The Risk category will only be used to manage internally the credit control.

3.1.1.4 Credit Checks

5 different credit checks are performed :

• Dynamic check
• Open items check
• Next review date check
• Payment term check
• Credit status check

For each Risk Category, levels of tolerance are defined in terms of excess of credit limit, overdue, next review date and payment term.The Credit Control on an order is based on these levels of tolerance and an order will get blocked above the defined corresponding levels.

Parameters will also be defined to manage order reblockings (released documents are still unchecked) and information transfers between systems (A/R summary).

Parameters are entered at the Risk Category level. Please find here below a print screen of all the possible parameters for a Risk Category.

3.1.1.4.1 Dynamic check

a.Introduction

The dynamic check is used to check whether the engagement towards a customer exceeds the authorized credit line.

The engagement is always linked to a date, called horizon.    

The horizon, expressed in days, is the period taken into consideration to calculate the whole engagement of the group towards a customer. The engagement will then be compared to the credit line.

• If the engagement value in the defined horizon exceeds the credit limit, the order will automatically be blocked by the system (credit line is not sufficient to cover the new order).

• If the engagement is smaller than the credit line, the order won't be blocked (provided that all other credit checks are OK).

! Only orders within the credit horizon update the credit exposure.

The material availability date is taken into account to check whether an order is within or beyond horizon.

BUT:

IF the order is in the horizon, the value of engagement in this horizon increases; the order can thus be blocked though the previous ones weren't blocked.

IF the order is beyond this horizon, the value of engagement doesn't increase in this horizon; it will only be blocked if the credit limit is already reached.

All the risk categories go through the dynamic check, except S (Solvay companies).

b.Calculated exposure

Exposure will now be calculated as follows:

Total Outstanding = Receivables + Open delivery value + Open sales order value (within defined horizon)

c.Horizon

The engagement is always linked to a date, called horizon. The horizon is defined for the credit limit check.

• Engagement / credit exposure = commercial value + receivables

The Commercial Value at a given horizon date includes :

• Sales orders value not yet or only partially delivered (dynamic part)

• With confirmed quantities

• With a material availability date within the horizon

• Orders not yet delivered (Open order value)
• Orders delivered but not yet invoiced (Open delivery value)

The order gets out of the Commercial Value of the Engagement when the delivery is done and the invoice issued. It enters then in the Receivables Part of the Engagement

The horizon, expressed in days, is the period taken into consideration to calculate the whole engagement of the group towards a customer. The engagement will then be compared to the credit line.

If the engagement is greater than the credit line, the order will be blocked by the system.

If the engagement is smaller than the credit line, the order won't be blocked (provided that all other credit checks are OK).

The riskier a customer is, the more of its future orders are taken into account.

The material availability date is taken into account to check whether an order is within or beyond horizon.

Horizon is set at 1, 30 or 60 days, depending on the Risk category (see below).

d.Dynamic check parameters

Parameters were defined, per risk category, as follows:

How to read the previous table?

Let's take a concrete example:

Risk category '2G'

An order will get blocked by the system in case the credit line is exceeded by more than 10% (with a max of 250K €).

e.Tolerance

For 6 risk categories (1G, 1B, 2G, 2B, 3G, 3B), a tolerance in terms of credit line excess will be implemented via the credit limit seasonal factor, with a maximum of 100K € to 250K €.

This means that, for instance, a customer with risk category 3G can overpass its credit line by 5%, but with a maximum of 100K €.

The credit limit seasonal factor permits to specify a percentage tolerance limit up to which a customer's credit limit may be temporarily extended or reduced.

% : The first field is the percentage that a customer maximum credit limit can be temporarily increased or decreased (decreased: check box minus should be checked).

Minus : It is the indicator to control if the credit limit has to be increased or decreased. If the indicator is selected, the credit limit is reduced by the percentage rate. If it is not selected, the credit limit is increased.

From … to … : Those two fields provide the validity period of the seasonal factor.

3.1.1.4.2 Open items check

a.Introduction

This credit check works in conjunction with two values that you specify in the adjacent fields:

1. The maximum proportion of overdue items in open items. The proportion, that exceeds the specified number of days, in the total of open items should not exceed the percentage specified.
2. The number of days which open items are overdue

All the risk categories go through the open items check, except S (Solvay companies).

b.Open items check parameters

Parameters were defined, per risk category, as follows:

c.Blocking codes (dunning blocks)

1. No blocking in case of overdue if invoice is flagged for one of those reasons: dispute, proof of payment received, direct payment, CN in waiting and cheque received.
2. Creation of a blocking code Y enabling to bypass the credit check on overdues for specific reasons. Y enables to bypass the overdue check on an invoice.

d.Cash against document

Implementation of an automatic 30-day tolerance in terms of overdue if payment method is Cash Against Document.

e.Creditor amounts

• No blocking for overdue reason in case of overdue credit note
• No blocking for overdue reason if global overdue balance = 0 or shows a credit amount
• No blocking for overdue reason if global balance of the account = 0 or shows a credit amount

3.1.1.4.3 Next Review Date check

a.Introduction

This customizing point gives the opportunity to indicate whether the system carries out a credit check based on the credit limit next review date.

The next credit review date is stored in the credit data in the customer master record. When you process a document, the next credit review date must not be beyond the current date.

You can define a time buffer for this type of credit check. In the adjacent field, you can specify the number of days that are added to the next credit review date.

In case the credit limit of a customer has expired, its new orders will automatically be blocked.

b.Next Review Date Check Parameters

Next review date check will be activated for all the risk categories, except for Solvay companies (S). Tolerance varies from 0 to 60 day. Affiliates are of course not checked, as they don't get a credit line.

3.1.1.4.4 Payment term check

a.Introduction

The system can control some critical fields. The check is carried out between the critical fields in the sales document and the critical fields default value in the customer master data. If a change occurred, it blocks the document.

One of the critical fields is Payment term. It was decided to implement a payment term check for all the risk categories, except for Solvay affiliates.

b.Payment term check parameters

It was decided to implement a payment term check for all the risk categories, except for Solvay affiliates.

c.Condition to this implementation

Credit Management is responsible for payment term registering in the system.

3.1.1.4.5 Credit status check

• Activation of 'Credit status check (user 2)' at Risk Category level to systematically block all the orders of :
• Customers paying in advance - Credit status flagged at 0005 (= Payment in Advance) at Master Data level (FD 33)
• Customers paying via letter of credit - Credit status flagged at 0004 (= Letter of credit) at Master Data level (FD 33)
• Doubtful customers - Credit status flagged at 0003 (= Doubtful customers) at Master Data level (FD 33)

3.1.1.4.6 Released documents are still unchecked

a.Introduction

This function is used for checking documents that have already been released (approved for credit) by a credit representative, but that have subsequently been changed. The system does not carry out another credit check if the following conditions are met:

1. Deviation in %

You can use a deviation factor for documents that have already been approved for credit. As long as you change the document and you keep the sales document deviation in the percentage, there is no new credit check. If the change in the document causes the deviation factor that exceed the percentage, the system carries out another credit check

The new credit value may not be greater than the validated value plus the added percentage of the validated value.

2. Number of days

The field indicates the number of days after which a new credit check has to be carried out for a change document which was already approved for credit.

The date of the day must not be later than the release date plus the number of days in the field.

It concerns the documents released and not the documents with an ok result or the documents not controlled.

b.Released documents are still unchecked parameters

Parameters were defined, per risk category, as follows:

3.1.1.4.7 Checks in financial accounting/old A/R summary

a.Introduction

This functionality gives the opportunity to check if the A/R summary is still accepted for the credit control. If the existing data in the A/R summary exceeds the aging set in days and hours, the system sets the status « A/R summary obsolete ».

Payer: The ticked field « payer » specifies that credit checks against open items, oldest open item, and the highest dunning level are carried out using the open items and the dunning level of only the current payer and not with data from all payers who are assigned to the credit customer.

Permitted days… permitted hours…: You can choose the permitted aging in days/hours of the A/R summary.

b.Parameters

Parameters were set, at the request of IT department, at 3 days for all the risk categories.

3.1.2 Flowchart (parameters synthesis)

3.1.3 Activities

• Scoring rating determination
• Payment index determination
• RC parameters registering & maintenance

3.1.4 Roles and responsibilities

• CM : defines a scoring rating
• CM & 3S : put the invoice blocking codes when needed
• Only IT can enter & maintain RC parameters
• Automatic (via IT development) determination of payment index

3.1.5 Developments needs identified

• Risk category = combination of scoring rating & payment index

>< This differs from Rhodia where Risk category = Scoring rating

>< This differs from Solvay where Risk category = combination of financial (scoring) rating & country risk rating & payment index

Create payment index at Rhodia.

Define a common place to stock the info (at Solvay, payment index is stored in the field 'Customer Credit Group'. The same field is used at Rhodia to see whether the customer is insured or not).

Implement new RC calculation at Rhodia on the basis of scoring and payment index.

Adapt Solvay's RC calculation (remove the country risk rating from it)

Creation of the payment index Good / Bad on the basis of average delay at Rhodia

• We have chosen Solvay's way of calculating the average delay : Weighted average delay in days
• Period of time: 6 months.
• Limit between a good and a bad payer is set at 3.
• 'Roundings' management:

IF < 0,5 => previous unit

IF > or = to 0,5 => next unit

Example: - 2,19 => 2 ; - 2,65 => 3

Change the payment performance calculation at Solvay (6 months instead of 12)

Create the payment performance calculation at Rhodia (other method used previously)

Risk categories New, Solvay & TH

Solvay customers identified by company consolidation method automatically receive an 'S' risk category.

New customers automatically receive a NEW risk category.

Local customers invoiced by Vinythai (company 0974) manually receive a risk category TH.

• Dynamic check
  • calculated exposure at Rhodia to be aligned with Solvay's : Receivables + Open delivery value + open sales order value (within defined horizon)
  • Implement tolerance per risk category (% via credit limit seasonal factor) with a maximum amount
  • Implement parameters per risk category (yes/no, nb of days horizon)
• Overdue check
  • Suppress the oldest open item check at Rhodia
  • Implement new parameters per risk category (yes/no, nb days, max open items %)
  • Implement the bypass of overdue check for some blocking codes (dispute, proof of payment received, direct payment, CN in waiting, cheque received) at Rhodia.
  • Create a blocking code Y enabling to bypass the credit check on overdues for specific reasons (at Rhodia)
  • Implement an automatic tolerance of 30 days in terms of overdue if payment method is Cash against document (at Rhodia)
  • Implement, in both organizations, rules to avoid blockings because of overdue in case of overdue creditor amounts
    • No blocking for overdue reason in case of overdue credit note
    • No blocking for overdue reason if global overdue balance = 0 or < 0
    • No blocking for overdue reason if global balance of the account = 0 or < 0
      
      
• Document value check
  • Suppress the document value check at Rhodia.
• Next review date check
  • Implement parameters per risk category in both organizations (yes/no, number of days)
• Payment term check
  • Implement payment term check for all the risk categories (via Critical fields) in both organizations.
  • Give the hand to CM for payment term registering: this requires a lot of adaptations on Solvay side. Full description of the needed modifications will be provided by IT.
• Credit status check
  • Create customer status.
  • Activate User 2 check for customers flagged payment in advance, L/C and doubtful.
• Released documents are still unchecked
  • Implement parameters per risk category (deviation in % & number of days)
• Checks in financial accounting/old A/R summary
  • Implement parameters per risk category (3 days for each risk category)

3.1.6 Output docs

N/A

3.1.7 Reports

KPI on blocked orders3.2 Payment in advance management

3.2.1 Description

This part describes how we handle orders from customers paying in advance on a credit control point of view.

On a credit line point of view :

• Customers paying systematically in advance: 1 € (automatic if customer status is payment in advance).
• Open account customers sometimes paying in advance: Open account CL - Orders are blocked because of the use of the delivery block.

On a rating point of view :

• Customers paying systematically in advance: 5 (automatic if customer status is payment in advance).
• Open account customers sometimes paying in advance: Scoring rating.

On a next review date point of view :

• Customers paying systematically in advance : At blank
• Open account customers sometimes paying in advance : Next review date

3.2.2 Flowchart

3.2.3 Activities

At order creation :

• Corresponding payment method and payment term are introduced in the order by the CCS / CSO
• Systems automatically detects the payment term (payment in advance) and puts the corresponding delivery block code (waiting payment in advance) at order header level.

Order appears in the ZPVK transaction (list of blocked orders) :

• CM introduces a comment in the order : Awaiting funds + date

At payment reception:

• CM introduces a comment in the order : Funds received + date
• CM removes the delivery block
• Order is released

3.2.4 Roles and responsibilities

Customer : payment of the order on the basis of the proforma

CCS / CSO :

• Registers the order in the system with correct payment term & method
• Sends the proforma to the customer

CM :

• Puts the comments in the order
• Checks the arrival of the funds
• Removes the delivery block
• Releases the order

IT (automatic) : correct delivery block is put at header level

3.2.5 Developments needs identified

Need to implement an automatic delivery block set up for the orders with payment term « payment in advance ».

Remove payments in advance from routine 601 at Solvay.

Implement User 2 check.

3.2.6 Output docs

Proforma invoice sent to customer

3.2.7 Reports

N/A

3.3 Management of Letters of Credit

3.3.1 Description

Preliminary remark: at Solvin, some tasks are decentralized (outsourced to an agent). This also concerns the L/C management. For each below mentioned action, the correct actor will thus be specified (CSR or agent).

3.3.1.1 Customer creation & modifications (CSR CSR = Customer Service Representative)

At customer creation, the correct payment method is chosen: "Credit Letter".

Customer status is flagged at "Credit Letter" this will automatically generate a 1€ credit line and a scoring at 5. (se referrer à Credit Settings)

The corresponding payment guarantee procedure ("schéma de couverture") is not filled in at this stage. If Payment guarantee procedure code is filled in at master data level, it automatically falls into each order. This is not what we want.

Customer is created at master data & sales organization level.

3.3.1.2 Order template creation & modifications (CSR)

3.3.1.3 Order creation

• At order creation, following CL parameters should be entered:

Recommendations:

• Ph. Blesbois: 1 EXPERT for around 15 Export CSR.
• Muriel Rusinak (Solvin): This expert should be within each business to be able to identify the particularity of LC terms. One person is not enough; we always need a pool to be able to cover illness or holidays.

3.3.14 In ZPVK (future CM list of blocked orders)

• CM checks that all the above points are fulfilled & ask corrections if needed
• CSR sends a copy of the LC to CM and ask if confirmation is needed or not
• If the issuing bank is a first class bank or a subsidiary of an European first class bank, no need to request a confirmation, unless the bank is located in a risky country.
• If the issuing bank cannot be trusted or is unknown or is located in a risky country, we have to request a "Confirmed L/C".

• CM checks several points of the LC (issuing bank, issuing date, expiry date, latest date of shipment, amount, currency, conf/non conf)

3.3.1.5 When L/C is OK

3.3.1.6 Credit control L/C specificities

3.3.1.6.1 Routine

By-pass of credit checks

If relevant payment guarantee procedure filled in

=> ZLCC*, ZLCN* at Solvay

=> Z0001 Crédoc at Rhodia

& financial document filled in

=> If those requirement are not fulfilled the automatic credit check will be carried out and the credit status "0004" letter of credit" will block the sales order

3.3.1.6.2 Credit line

Put by CM or automatic

• Customers exclusively paying by L/C : 1 (automatic if customer status is letter of credit - enables the systematic blocking of the order)
• Open account customers sometimes paying by L/C : Open account CL - orders are blocked because of the use of the delivery block

3.3.1.6.3 Rating 

Put by CM or automatic

• Customers exclusively paying by L/C: 5 (automatic if customer status is letter of credit).
• Open account customers sometimes paying by L/C : Scoring rating

3.3.1.6.4 Next review date 

Put by CM

• Customers exclusively paying by L/C : At blank
• Open account customers sometimes paying by L/C : Next review date

3.3.1.6.5 Post delivery actions

Payment method (L/C) visible in customer account in order to allow a specific follow-up (no automatic reminders, because in case of overdue, or missing letter detailing the bank fees (cover letter) CM reverts to CSR, who contacts the bank to solve the issue).

3.3.2 Flowchart

N/A

3.3. Activities

• See description

3.3.4 Roles and responsibilities

• See description

3.3.5 Developments needs identified

• By-pass of credit checks

If relevant payment guarantee procedure filled in

=> ZLCC*, ZLCN* at Solvay

=> Z0001 Crédoc at Rhodia

& financial document filled in

• Automatic CL (1 €) & rating (5) when customer is flagged 'Credit Letter'
• Implement User 2 check.

3.3.6 Output docs

N/A

3.3.7 Reports

N/A

3.4 (Un)confirmed quantity

3.4.1 Description

CONFIRMED QUANTITY

• Orders with "confirmed" quantity are credit checked.
• When an order is confirmed at schedule line level, normal credit check applies an order can get blocked.

UNCONFIRMED QUANTITY

• In case of unconfirmed quantity, SAP standards lead to an endless loop:

• • Order with unconfirmed quantity is validated by the CM. Credit value = 0 because unconfirmed (standard SAP).
  • Logistics then confirms the quantity. But as confirmed value is > than validated value (0), the order gets blocked.
  • In standard SAP, when an order is blocked, the value of a blocked order is reset at 0 (suppression of the confirmed quantity).
  • CM validates again the order (with credit value = 0).
  • Logistics confirms the quantity, but as ….
  • And so on …

For this reason, we need to bypass the credit check: An order for which the quantity has not been confirmed is not included in the credit check and in the credit "outstanding items". It is only when the quantity is confirmed that the order undergoes this credit check, and can thus be blocked for credit. (Solvay way)

Other possible option is to implement the following: 'credit value validated' = 'order value' (not yet delivered). (Rhodia way) (and not 0 as in standard SAP)

3.4.2 Flowchart

N/A

3.4.3 Activities

• Quantity confirmation
• Order release

3.4.4 Roles and responsibilities

• IT implementation to avoid the endless loop
• Logistics confirm the quantities
• CM releases the order

3.4.5 Developments needs identified

• Suppress the credit check bypass at Solvay in case of unconfirmed quantities.
• Implement Rhodia's method: Normal credit check performed but credit value validated = order value (not yet delivered). This is different from standard SAP where credit value = 0

3.4.6 Output docs

N/A

3.4.7 Reports

N/A

3.5 Goods shortage

3.5.1 Description

Automatic credit checks are by-passed for sales order in shortage (ZPEN SD item category).

3.5.2 Flowchart

3.5.3 Activities

Relevant item inserted in the system (ZPEN SD item category).

3.5.4 Roles and responsibilities

CCS/CSO inserts the correct/relevant delivery blocks in case of shortage.

3.5.5 Developments needs identified

Maintain the credit bypass in case of shortage (type de poste ZPEN) implemented via routine 901 at Rhodia.

3.5.6 Output docs

N/A

3.5.7 Reports

N/A

3.6 Order confirmation

3.6.1 Description

• When an order is saved, if there is no blocking and that quantity is confirmed, order is confirmed to the customer.
• It sometimes happens (with the orders beyond horizon) that an order gets credit blocked though already confirmed to the customer.
• In order to protect ourselves against potential claims from the customer, a sentence should be added to the order confirmations: 'subject to credit control'.

3.6.2 Flowchart

N/A

3.6.3 Activities

Send order confirmation

3.6.4 Roles and responsibilities

CCS/CSO sends the order confirmation

3.6.5 Developments needs identified

Add a sentence in the order confirmations : 'subject to credit control'.

3.6.6 Output docs

Usual order confirmation (nothing to be changed). Just add the proposed sentence or something equivalent.

3.6.7 Reports

N/A

3.7 Incomplete orders

3.7.1 Description

Bypass the credit check in case of incomplete orders. Credit check should only be performed when order is complete.

3.7.2 Flowchart

3.7.3 Activities

• Order completion

3.7.4 Roles and responsibilities

• CCS : complete the orders (incompletion log automatically reminding if important data is missing when order is saved)
• CM : when order is complete and that it goes through credit check, validate or not the order.

3.7.5 Developments needs identified

• Already implemented at Rhodia via the routine 901
• To be implemented at Solvay

3.7.6 Output docs

N/A

3.7.7 Reports

N/A

3.8 ZPVK transaction

3.8.1 Description

• The ZPVK transaction will be used, in the frame of the credit control, to help the Credit Management identify and process orders blocked for credit reasons.
• The ZPVK transaction was specially created at Solvay to manage blocked orders. It is not an SAP standard transaction.
• It presents many advantages :
  • Possibility for the credit management to insert comments in the orders with the reasons of blocking, comments that can be seen immediately by the CCS representatives

• • Direct access to the Credit Master Sheet by clicking on a specific icon

• • Possibility for business & credit management to display new columns in ZPVD (equivalent of ZPVK for business) & ZPVK transactions, showing where the credit problem lies (credit line?, overdues?, next review date?).

• • Transportation planning date added to ZPVK to better meet the business needs in terms of order release (this is the maximum date at which orders have to be released to enable the transportation of the goods)

3.8.2 Flowchart

3.8.3 Activities

• Check on a regular basis (several times a day) the list of blocked orders.
• Release blocked orders
• Keep orders blocked & give justifications

3.8.4 Roles and responsibilities

• CM : checks the list of blocked orders, releases orders, puts comments in the order in case it is kept blocked
• ZPVK only available for CM

3.8.5 Developments needs identified

• Create ZPVK transaction at Rhodia.

3.8.6 Output docs

• N/A

3.8.7 Reports

• N/A

3.9 Automatic program to unblock orders

3.9.1 Description

• At night, a special program runs to unblock the orders previously blocked.
• If conditions are met, orders are automatically unblocked by the program (example : payment received, credit line not exceeded anymore, …)

3.9.2 Flowchart

3.9.3 Activities

• Automatic program running each night to automatically release orders when credit conditions are met.

3.9.4 Roles and responsibilities

• IT implementation of this program

3.9.5 Developments needs identified

• Create this automatic program at Rhodia.
• At Solvay, it is already implemented.
• Have the program run more often than once a night.

3.9.6 Output docs

• N/A

3.9.7 Reports

N/A

3.10 KPI on blocked orders

3.10.1 Description

• Development of KPI related to blocked orders in order to improve the order blocking process, identify existing problems and work on solutions when possible, try to decrease the number of blocked orders.

3.10.2 Flowchart

3.10.3 Activities

• KPI extraction
• KPI analysis
• KPI communicated
• KPI used as a 'tool' to improve the process

3.10.4 Roles and responsibilities

• IT : to develop KPI
• CM : KPI extraction, analysis, communication

3.10.5 Developments needs identified

• Create following KPI (in BW) in both organizations (some of them already exist) :

3.10.6 Output docs

• N/A

3.10.7 Reports

• KPI report available each month (in BW)

3.11 Automatic e-mail at order release

3.11.1 Description

• When an order is released by the credit management, the CCS / CSO / Sales managers receive an automatic e-mail.
• This will be implemented for those who want it only (some sales organizations do no want this service). So no 'default' implementation.
• Automatic e-mail to CCS / CSO with order confirmation

3.11.2 Flowchart

3.11.3 Activities

• Automatic mail sent by the system to the business
• List the sales organizations that are wanting this service
• Update the existing Solvay list

3.11.4 Roles and responsibilities

• CM releases the order
• CCS / CSO / Sales manager gets an automatic message informing him / her about the release

3.11.5 Developments needs identified

• Develop automatic e-mail at order release at Rhodia
• Already exists at Solvay (so just check and update the list of sales organizations)

3.11.6 Output docs

• Mail sent to CCS / CSO / Sales manager informing about the release

3.11.7 Reports

• N/A

3.12 LOG

3.12.1 Description

• The purpose of this log is to give information to the user on the reason why a document is blocked or not.
• It also enables a good track of the order modifications.
• IT was developed at Solvay at the request of the IT, in the frame of the Phoenix Project. It was a sine qua non condition to the change implementation.

3.12.2 Flowchart

• N/A

3.12.3 Activities

• Determine why an order was automatically released
• Determine why an order was blocked by the system
• Track order modifications

3.12.4 Roles and responsibilities

• LOG available for IT department & CM only

3.12.5 Developments needs identified

• Finish the LOG creation at Solvay & adapt it to new changes
• Create the LOG at Rhodia

3.12.6 Output docs

• N/A

3.12.7 Reports

• N/A