Import Reports for Projects.

Sometimes we try to use reports of Module Cost Object Controlling (CO-PC-OBJ) but we get error saying “Transaction XXXX does not exist”.

Here we can say transaction 7KVD for Actual Costs.

Report 7KVD is missing here.

However these reports are available in the system but in client ‘000’, to import these reports use Transaction Code OKSR.

You can also follow the below path to access this transaction code:

SAP Ref. IMG -> Project System -> Information System -> Costs/Revenues Information System -> Cost Element Analysis -> Standard Reports -> Import Reports.

Once you execute the transaction, you will get list of all available reports, It is only relevant to click on the missing reports which you need to import from the repository.

Select Actual Cost Report (Techn. Name 7KVD).

As a result the report has been imported from client 000 to client 100

In order to create a transport order, switch to the report writer maintenance. Or   it would be also possible to download and upload the reports, but prefer to Create transport orders. 

SAP Ref. IMG -> Project System -> Information System -> Costs/Revenues Information System -> Cost Element Analysis -> Custom Reports -> Maintain Libraries.

You can also use it using transaction code GR22. Select Change Library Option.

Now follow the steps shown in the screen shots.

The report group with dependent objects has to be transferred.

Then execute it and add it in a Transport Request.

So, Now you have transaction code 7KVD Actual Cost Report available in your client.

Regards,

Sujeet Mishra

Hi All ,

Reconciliation between SD & COPA and thereafter COPA & FI is a time consuming and hectic job in every organization . Before starting this , we need to ensure the correctness of COPA . I tried to explain how COPA data and report can be corrected without interfering into SD module .

                    COPA correction of selected billing docs (record type “F”)

When costing based COPA is active, billing docs from SD flows directly to COPA. For this every condition type in SD is mapped to a value field in COPA. But sometimes one or more condition types are found missing in COPA, which result in SD-FI-COPA mismatch. Again on some occassions the condition type is found to have flown to some other value field for which it’s not customized. The main reasons behind this missing value fields are: 

Ø      the customization , mapping SD condition type to value field, is changed during a period

Ø      change in the condition type in SD itself

Ø      Multiple condition type mapping to single value field.

SAP recommends the reversing of billing doc and releasing of the same to FI/COPA again; in certain circumstances it’s not possible in SD.

In such cases, in COPA the reposting option is available without affecting SD or FI. The related program is RKERV002and t code is KE4S. The inherent problem is it creates 2 more docs, viz. the reversed doc and the reposted correct doc. So it ends up with 3 docs in the COPA tables. After that we can delete the original and reversed doc through t code KE4S00. As physical deletion from database is not possible, cancellation of these 2 docs again create two more cancelled docs. At the end we are left with five COPA docs against one billing document.

To overcome the multiple doc scenarios we need to delete the faulty COPA doc from database and post the same billing doc to COPA without any check. This involves 3 activities viz. deletion, posting, reconstructing. 

The procedure is as follows:

1. Open the CE1xxxx table and check the billing docs finally before deletion (xxxx=operating concern):

2. Run SE38 and input for program RKEDELE1

Remove the “test run” and execute

3. For confirmation check the billing docs in CE1xxxx table again: on execution we should get a msg like

4. Now we need to post the billing docs to COPA again without any check. For this we will run KE4S:

5. Now the deletion and posting is completed, but this only updates the CE1xxxx table. We need to update the main profitability segment table which is CE3xxxx; otherwise the COPA report will not reflect the changes. This is known as reconstruction of CE3xxxx table.

Before doing this we need to create a blank file viz. “ABC.txt” on the desktop. SAP stores the intermediate data in this file during the phase of reconstruction.

Run program RKEREO31:

We see the result in test mode:

As test result is successful we will run the program in real mode :

Now both CE1xxxx and CE3xxxx tables are updated. All changes we wanted to carry out will be reflected in COPA report.

===============================================================

Regards

Indranil

Learn how to drive financial performance excellence with ERP CO and BPC and technology enablers like HANA, Mobile and Analytics.

Don't miss our 2013 the Financial Excellence Forum (SAP customers only)

• October 8-9, 2013, SAP America, Executive Briefing Center, Newtown Square, PA

During the event, SAP, along with our partners and customers, will share best practices and solutions to put you in control of financial performance. Topics will include:

• How to streamline top-down and bottom-up financial and operational planning processes
• Understanding what drives cost and profitability across any business dimension
• SAP solutions for business planning (BPC), cost management (CO-CCA), product costing (CO-PC), and profitability analysis (CO-PA)
  
  

In addition to valuable presentations from SAP customers, the two-day agenda will include peer-networking and roundtable sessions, best practices presentations, and more.

You’ll also have the chance to preregister for jumpstart sessions on topics including business planning, product costing, and indirect cost allocations

Come and see how our latest innovations can help tap into real-time financial insights – anytime, anywhere.

This SAP customer value network event is free to attend, but space is limited, so reserveyour spot today. For more information (agenda, hotels, directions) please visit the our event landing page

The purpose of the document is to understand the basics of accounting in relation to revenue recognition. The idea of having a document came to me when I came across many of my colleagues and many of new entrants could not distinguish between Accrued system of accounting and Deferred system of accounting.

==================================================================================================================

What is Revenue Recognition?

To understand what is Revenue Recognition, we need to understand what are the basic accounting principles which guide all the accounting standards across the world. There are two basic accounting principles

1. Accrued System
2. Cash System

In Accrued system of accounting principle, as far as revenues are concerned, revenue is recognized with, when it is either realized or realizable no matter when the cash is received.

• Accrued system of accounting

The below points make it clear to understand the accrual system of accounting

1. The Accrual Method of Accounting matches revenues when they are earned against expenses associated with those revenues.
2. Under accrual accounting, if your business receives a bill, that bill is counted as an expense, even though you have not yet paid the bill.
3. In the same way, if you bill a customer, that bill is counted as income, even though you have not yet received payment.

• Cash system of accounting, or, Deferred system of accounting

The cash method of accounting reports transactions only when

1. When cash is received or
2. When a payment is made.

Need for Revenue Recognition?

The need for Revenue recognition arises because of growing size of business houses globally and various accounting standards followed across the globe. The major are listed below

1. Generally Accepted Accounting Principles (US-GAAP),
2. International Accounting Standards (IAS),
3. Financial Reporting Standards (IFRS), as well as,
4. Sarbanes-Oxley Act.

Classification of Revenue Recognition.

Revenue Recognition can be classified based on time frame and on the basis of occurring event. Below are the three classification.

• Standard revenue recognition

means that the billing document posts directly to a revenue account. This posting is made without involving the Accrual Engine, i.e. without a revenue recognition process.

• Periodic (time-related) revenue recognition

means that the revenue from a sale is distributed and posted equally across the entire contract validity period. Billing posts to an accruals account here and revenues are first transfer posted to the revenue accounts in a second step.

• Service-related revenue recognition

means that the revenue is recognized as the result of an event such as a confirmation or a delivery. Billing also posts to an accruals account here and revenues are first transfer posted to the revenue accounts in a second step.

How Service related revenue recognition is different?

Service related revenue recognition can be best understood as contracts made for maintenance of equipment after the guaranteed period. Wherein, unless for the monthly maintenance, either in terms of general maintenance or replacement of part, of equipment is identified; revenue is not noted in the books of accounts.

Business Scenario

Contract for certain period of time.

• A contract is created in the system for certain period of time. The contract is either Time Based or Event Based.
• In time based contracts, irrespective of the services rendered, either on site or offshore to the product, revenue is raised at periodic intervals. The intervals can be monthly, bi-monthly or any other period frame. But the entire contract revenue is collected in the book of accounts as Accrued revenue.

• In event based system of Revenue Recognition the accrual revenue is noted in the as the result of an event such as a confirmation or a delivery. On such an event billing also posts to accruals account in the first step and revenues are transferred the revenue accounts in a second step.

Accounting follow

• Standard Revenue recognition

• Time related Revenue recognition

• Service related revenue recognition - On happening of an event.

My recommendation and suggestions would be based on normal manufacturing industries which has a turnaround of 1000 crores INR.

To make end user job easier or simpler, this has to be done in the implementation, I will explain in detail.

Controlling

Cost Element Accounting

I have seen some customers those who use manual creation of cost elements, User’s sometime choose a wrong cost element category. So my suggestion would be to use controlling integration as automatic creation of cost elements. By doing this, if users creates a General ledger a/c for expenses or revenue, the system automatically create a cost elements with the particular cost element category. Below is the sample default setting, one can set as many accounts and cost element category.

For secondary cost elements , always use the series of 900000+

Cost Center Accounting,

Cost center – my suggestion would be to create cost center for 4 or 5 digits. Eg., 1001 as ACCOUNTS & FINANCE.

Activity Types – Create activity type by mentioning AT**, for example, create AT01 as CUTTING & BENDING, AT02 as MACHINE HOURS

Internal Order Accounting,

Order types - create internal order types starting with 0100 , after that 0200 and go on. Refer the below screen shot.

Internal order – Have more than 7 digit number ranges for internal order. Internal orders are very important in controlling module as it also used for process order or production order.

Introduction :
This blog describes shortly our experiences of increasing the performance of CO-PA by using HANA. To do so we implemented first a HANA side- by – side scenario. Later on we switched to ERP on HANA.

The way from CO-PA on classical DB over a HANA side – by - side scenario to ERP on HANA:
Because of high data volume that increased more and more in the last years, reporting for CO-PA at SAP AG was only possible on BW system. Furthermore management accounting reallocations that were done for costing based CO-PA could only be done in BW due to poor performance caused by the high data volume.
Therefore SAP AG decided to implement a side – by - side scenario for costing based CO-PA. The reason was to gain experience with the HANA DB and to get an insight how much the performance will be increased by HANA. For the side – by –side scenario the CO-PA accelerator was used.
The following picture shows roughly how the side – by – side scenario looked like.

The CO-PA table CE1XXXX which holds the transactional data of CO-PA was replicated to a HANA box. If CO-PA reads data from this table, the data were selected from the table CE1XXXX of the HANA Box. The rest of CO-PA was not changed or affected, only selects of the standard CO-PA coding were done on the HANA Box to speed up the performance of CO-PA.
The administration of this behavior in detail was customized with transaction KEHC that is part of the CO-PA accelerator.
Every system in the system landscape, development system, quality system and productive system had a HANA box beside. The data replication to the HANA box was done at first by a program that runs in batch, later on it was replicated with SAP LT replication server.
The BW reporting remained unchanged to minimize risk that means the CO-PA data were uploaded to BW as before and the users did their CO-PA reporting in BW.
Some power users in ERP benefited from the fact that transactions KE24 and SE16H increased significantly from a performance point of view.
In addition there was another positive effect too, regarding custom developed programs of CO – PA. At SAP there are management wise postings for some SAP specific processes. These  specific processes that are done to enhance reporting capabilities of CO-PA and to fulfill some specific requirements of the Controlling department. The postings for that processes depend on the standard postings of CO-PA and are a kind of follow up – postings. Because of the high data volume it was not possible before HANA to do these postings in CO-PA. Due to that reason the postings were done in BW. The disadvantage of this was that the postings were not available real-time. The controller had to wait until the data was uploaded and calculated in BW.
With the HANA side-by-side scenario it was possible to bring these processes back to ERP and to realize them as an online scenario. To do so ABAP programs were developed for these scenarios that select the CO-PA data with standard function modules RKE_DATA_READ_CALLBACK. This standard function module makes use of the CO-PA HANA accelerator and selects the data automatically from the HANA database depending on the customizing entries done with transaction KEHC. Because the performance increased rapidly, it was possible to implement the scenarios as online scenarios. That means, every time after a CO-PA document has been created, an asynchronous event is triggered and an event – handler function module reads the newly created document together with some other necessary documents from the HANA database, calculates the values for the follow – up document and saves it immediately to the database.
Now that CO-PA was such fast with the HANA box, it was even possible to post the documents for the last 8 years afterwards too in CO-PA to get also historical data for the scenarios on the ERP side.

Conclusion :
• The experience with the HANA side – by –side scenario was very positive because performance increased rapidly.
• It was possible to bring follow – up postings from BW back to ERP by developing custom programs that are able to read CO-PA data such fast from HANA that the follow-up postings are done real-time now.
• For the custom developed programs it was beneficial to use the standard function modules for selecting and saving CO-PA data so that the standard cares about selecting CO-PA data in an appropriate way.
• In the meantime the side - by – side scenario at SAP has been switched off because SAP switched the whole ERP system to the HANA database.
• Another positive effect was, that the custom developed programs for the follow – up scenario didn’t have to be changed for the switch from HANA side – by – side scenario to ERP on HANA because they use CO-PA standard function modules to read and save data. These function modules now reads the data from the underlying HANA DB of the SAP ERP system. Because of that the switch from the HANA side - by - side scenario to ERP on HANA was relatively uncomplicated for these programs. The performance is at least as good as for the side – by – side scenario, but of course data replication is no longer necessary.

By Joerg Mueller & Dominik Fliess.

Tight deadlines often rule the workday of a controller and numerous similar information workers. In particular during month and quarter end closing actvities speed matters - while, for sure, expectations towards precision and reliability of the results remain. Balancing the tension between those two targets, obviously, can be a challenge.

In our role as solution architects for controlling applications, we were onboarded as team members for the SAP internal ERP on HANA adoption project. A project, which lead to an exchange of the existing ERP database by our new HANA platform. An important milestone, and a solid foundation for a closer integration of our CRM and BW systems, which were already upgraded to HANA.

The ERP on HANA adoption was part of the SAP runs SAP initiative, which aims to showcase SAPs solution portfolio. It positions SAP itself as an early adopter of its own solutions. Prior to any customer, solid business process and system setup scenarios can be developed, and products can be guided up the crucial steps on the learning curve. An additional and important proofpoint before the rollout to our customers.

Graphic: Controlling Profitability Analysis (CO-PA), Acceleration by ERP on HANA / Integrated Platform

In the following list we would like to share in brief some remarkable results, we were able to achieve in the CO-PA area, after the upgrade to ERP on HANA:

• CO-PA experiences an impressive general acceleration. In particular reporting and mass data based analytical transformation processes gained an immense boost in performance.
• CO-PA reports can be build on line item basis - no need for summarizations and aggregations anymore.
• We were able to set up virtual infoproviders for realtime reporting in BW, which enable us to directly access ERP line items as they occur. i.e. time consuming extractions can be substituted - a blessing during closing activities.
• No index-definitions or adjustments are necessary anymore to set up new  processes. i.e. free development, less impact on competing processes in the modul environment.
• The use of the new enhanced table selection possibilities allows complex and detailed adhoc content analysis.
• HANA as a platform provides almost unrestricted opportunities for additional, customer specific process implementations and optimizations.

It's obvious, that similar to the graphic above, those results emphasize on integration, process design and execution and on the analytical reporting aspects of the ERP on HANA implementation - from a controlling perspective. A homogeneous platform, as drafted in the graphic, is a big advantage for any kind of "end to end" optimization and growth strategy. The technological boundaries actually disapear and you can set your primary focus on process implementation, integration and reporting - as you normally do as an application consultant.

We think, those results show also, that, as a consequence of the HANA platform usage, the company as a whole benefits - business and IT environment. The technology impacts everybody involved in running, analyzing, designing and modelling of the existing system and process landscape. It provides flexibility and accelerates the business transformation process.

Hello Friends

Today when I sit in my hotel room in Bangalore (after attending Tech Ed), my memories took back me to my consulting days when I lived all those fun days, which I could not during my college days, for the want of making a career.

Whenever any of our colleagues had a baby boy or girl delivered in their family, the 1st comment from me was "Many Happy Returns" and the obvious answer was a scary face... The 2nd thing that would come out is a Question "Which SAP module you are planning for Kid" and during one such instance the conversation went further. I proposed we teach the kids alphabets as below.. Ofcourse we could not find for all, so please help in closing the loop

A - Activity Type

B -Business Area

C- Controlling Area

D- Dunning

E- Evaluation group (asset accounting)

F- ??

G- Goods Receipt

H- ??

I - Inspection plan

J - ??

K - ??

L - Long Term Planning

M - Movement Type

N - ??

O-??

P - Plant

Q - Quality stock

R - Restricted Stock

S - Stock Transport Order

T - Transaction type

U - Unrestricted stock

V- ??

W- ??

X - ??

Y/Z - Custom developments

Br, Ajay M

If we want to valuate inhouse product through costing run in a way which is not provided by SAP standards (all the priorities / strategies provided),

we need to use the user exit EXIT_SAPLCK21_002.

A product costing of such nature is detailed here; We tried to gather and finalize the requirements and how it could be achieved :  

Following parameters need to be achieved when costing run takes place:

1. A. For any bought out item indigenous ,

ØSystem should look into all PO s containing that material.

ØSuch PO s should be restricted to whose delivery date falls within last 365 days of costing run date.

ØSystem will consider only PO s released and line item is not deleted.

ØSystem will then pick the highest price from the PO s; the price is net effective price.

ØIf the purchasing unit of material is different from BOM unit, the price needs to be converted to BOM unit.  

ØThis net effective price will be compared to MAP of the material and higher of two will be taken into valuation.

ØIncase system could not find any such PO for the abovementioned period then the MAP will be picked up for cost estimate.  

          B. For any bought out item imported,

ØTo encounter the High Seas sale issue, which contain only the basic price, system will find the basic price of all import PO s;

    then the highest basic price will be picked up.

ØAll modvatable items will be deducted from the effective price to arrive at the basic price .  

2. For exchange rate ,

ØFor all imported bought out items, the above mentioned price will be multiplied by exchange rate as on most recent date the costing run date

ØTo achieve this, a separate exchange rate type will be maintained in the exchange rate table ; which must be different from classical "M" or "P"

To achieve point no 1 A:

We need to join EKKO & EKPO table to get the PO s relevant for the material & plant.

Standard SAP join table WB2_V_EKKO_EKPO will be used.

Delivery Date we will get from EKET-EINDT, this should be restricted to last 365 days of costing run date. This can be achieved by calling a FM.

Effective Price we will get from EKPO-EFFWR; this to be divided by EKPO-MENGE (quantity); currency we will get from EKKO-WAERS.

So with the material no (EKPO-MATNR) PO s will be sorted first; then the highest price will be picked up.

To convert the price from purchasing UOM to BOM UOM, a FM will be called.

This will be compared with (MBEW-VERPR) field of the MM.

The MAP is set as 2^nd priority, in case system fails to find any PO in the above period. 

To achieve point no 1 B:

System will recognize the high seas sale with a unique purchasing group “XXX”.

For all import PO s from net effective price the landing charge, CVD modvatable, additional duty of customs will be deducted to arrive at basic price.

This basic price will be inflated by say 1.1205 times to arrive at net effective price. ( this 1.1205 factor is applicable for India)

To achieve point no 2:

As mentioned, system will check the currency and will multiply with the unique exchange rate type maintained.

A new exchange rate type Y1 is configured for quotation costing; only this exchange rate type and corresponding exchange rates will be called in the user exit.

Relevant field is TCURR-GDATU (most recent date to costing runs date) & TCURR-UKURS (exchange rate as on that date).

The details of ABAP code written

FUNCTION EXIT_SAPLCK21_002.

INCLUDE ZXCKAU08

TYPES: BEGIN OF lty_ekpo,
        ebeln    TYPE ebeln,
        ebelp    TYPE ebelp,
        bukrs    TYPE bukrs,
        waers    TYPE waers,
        matnr    TYPE matnr,
        menge    TYPE bstmg,
        effwr    TYPE effwr,
        bprme    TYPE bprme,
        knumv    type knumv,
        ekgrp    type ekgrp,
        mengec   TYPE bstmg,
        eindt    TYPE eindt,

       END OF lty_ekpo.

TYPES: BEGIN OF lty_eket,
        ebeln    TYPE ebeln,
        ebelp    TYPE ebelp,
        eindt    TYPE eindt,
       END OF lty_eket.

TYPES: BEGIN OF lty_ins,
        menge    TYPE bstmg,
       END OF lty_ins.
DATA: lt_ekpo TYPE STANDARD TABLE OF lty_ekpo,
      lw_ekpo TYPE lty_ekpo.
DATA: lt_eket TYPE STANDARD TABLE OF lty_eket,
      lw_eket TYPE lty_eket.
DATA: lw_ins  TYPE lty_ins.

DATA: lv_date  TYPE p0001-begda,
      lv_verpr TYPE verpr,
      lv_vprsv TYPE vprsv,
      lv_value TYPE ukurs_curr,
      lv_meins TYPE meins,
      tmeins   LIKE t006-msehi,
      tbprme   LIKE t006-msehi,
      tmgvgw   LIKE plfh-mgvgw,

               tkwert   like konv-kwert,
      tkschl   like konv-kschl.

REFRESH: lt_eket,lt_ekpo.CLEAR:   lv_date,lv_verpr,lv_vprsv,lv_value.SELECT SINGLE meins
  INTO lv_meins
  FROM mara
WHERE matnr = f_matbw-matnr.SELECT SINGLE verpr vprsv
  INTO (lv_verpr,lv_vprsv)
  FROM mbew
WHERE matnr = f_matbw-matnr
   AND bwkey = f_matbw-werks.

IF lt_ekpo IS NOT INITIAL.
    SELECT ebeln ebelp eindt FROM eket INTO TABLE lt_eket
    FOR ALL ENTRIES IN lt_ekpo
    WHERE ebeln = lt_ekpo-ebeln
    AND   ebelp = lt_ekpo-ebelp
    AND   etenr = '0001'.
    IF sy-subrc = 0.
      SORT lt_eket BY ebeln ebelp.
    ENDIF.

IF lt_eket IS NOT INITIAL.
      LOOP AT lt_ekpo INTO lw_ekpo.
        if lw_ekpo-ekgrp = '946'.(the purchasing group for high seas sale = 946)
           lw_ekpo-effwr = lw_ekpo-effwr * 11205 / 10000.
        endif.
        if lw_ekpo-waers ne 'INR'.
           select kwert kschl
             into (tkwert, tkschl)
             from konv
            where knumv = lw_ekpo-knumv

            and kposn = lw_ekpo-ebelp.
           if sy-subrc eq 0.
              if     tkschl = 'ZLC1'.
                     lw_ekpo-effwr = lw_ekpo-effwr - tkwert.
              elseif tkschl = 'ZCV1'.
                     lw_ekpo-effwr = lw_ekpo-effwr - tkwert.
              elseif tkschl = 'JADC'.
                     lw_ekpo-effwr = lw_ekpo-effwr - tkwert.
              endif. (the condition types to be deducted are identified as ZLC1 / ZCV1 / JADC)
           endif.
           clear : tkwert, tkschl.
           endselect.
        endif.
        READ TABLE lt_eket INTO lw_eket WITH KEY ebeln = lw_ekpo-ebeln
                                                 ebelp = lw_ekpo-ebelp BINARY SEARCH.

          IF sy-subrc = 0.
          CALL FUNCTION 'CF_UT_UNIT_CONVERSION'
            EXPORTING
              matnr_imp     = f_matbw-matnr
              meins_imp     = lv_meins
              unit_new_imp  = lv_meins
              unit_old_imp  = lw_ekpo-bprme
              value_old_imp = 1000
            IMPORTING
              value_new_exp = tmgvgw.*          ENDIF.
          lw_ekpo-menge = tmgvgw * lw_ekpo-menge / 1000.
          CLEAR : tmgvgw.
          lw_ekpo-eindt  = lw_eket-eindt.
          IF lw_ekpo-menge > 0.
            lw_ekpo-mengec = ( lw_ekpo-effwr / lw_ekpo-menge ).
          ELSE.
            lw_ekpo-mengec = lw_ekpo-effwr.
          ENDIF.

IF lw_ekpo-waers NE 'INR'.
            CALL FUNCTION 'READ_EXCHANGE_RATE'
              EXPORTING
                client           = sy-mandt
                date             = sy-datum
                foreign_currency = lw_ekpo-waers
                local_currency   = 'INR'
                type_of_rate     = 'Y1'
              IMPORTING
                exchange_rate    = lv_value
              EXCEPTIONS
                no_rate_found    = 1
                no_factors_found = 2
                no_spread_found  = 3
                derived_2_times  = 4
                overflow         = 5
                zero_rate        = 6
                OTHERS           = 7.
            IF sy-subrc <> 0.
              MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
                      WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
            ENDIF.
            lw_ekpo-mengec = lw_ekpo-mengec * lv_value.
          ENDIF.
          MODIFY lt_ekpo FROM lw_ekpo.
          CLEAR: lw_ekpo,lw_eket.
        ENDIF.
      ENDLOOP.

      CALL FUNCTION 'RP_CALC_DATE_IN_INTERVAL'
        EXPORTING
          date      = sy-datum
          days      = '00'
          months    = '00'
          signum    = '-'
          years     = '01'
        IMPORTING
          calc_date = lv_date.

      IF lv_date IS NOT INITIAL.
        DELETE lt_ekpo WHERE eindt LT lv_date.
      ENDIF.
      SORT lt_ekpo BY mengec DESCENDING.
      DELETE ADJACENT DUPLICATES FROM lt_ekpo COMPARING matnr.

      READ TABLE lt_ekpo INTO lw_ekpo INDEX 1.
      IF sy-subrc = 0.
        IF lv_verpr IS NOT INITIAL.
          IF lv_verpr GE lw_ekpo-mengec.
            lw_ins-menge = lv_verpr.
          ELSEIF lv_verpr LE lw_ekpo-mengec.
            lw_ins-menge = lw_ekpo-mengec.
          ENDIF.
          exp_preis = lw_ins-menge.
        ENDIF.*      else.   "IF PO Not Found*         exp_preis = lv_verpr.
      ENDIF.
      clear lv_verpr.
    ENDIF.
  ENDIF.

ENDIF.

Business scenario is as follows.

  1. Semi-finished product  S1 have a Raw material  R1 as BOM item.

2. When you procured R1, procurement price difference 1000 was occurred.

  3. When you processed good receipt for S1, Production price differences 80 was occurred.

  4. A half of S1’s good receipt qty  was used for Finished goods F1.

  5. The remaining qty of S1 was  in ending inventory.

  6.  All of Finished goods was in ending inventory.

FI posting logic is below.

  1. FI posting logic for Procurement price difference and Production price differences

  2. FI posting logic for material ledger closing

Even if your organization has not yet made the move to the SAP HANA platform, your organization can still become a benefactor from the intellectual renewal that is on-going at SAP that is being driven by the HANA in-memory database technology.  This is because with SAP's effort to optimize the SAP Business Suite running on SAP HANA it creates the opportunity to reinvent everything, and if done correctly, to simplify it as well.

To give you some background into further what I mean, consider the following customer success story which demonstrates not only the power of SAP HANA, but also the spirit of reinvention.  A large SAP customer in the consumer packaged goods industry was eager to see how the Profitability Analysis (CO-PA) accelerator with SAP HANA could help reduce the run time of their very complex schedule of top-down distribution jobs which they execute each period end.  While working with this customer, SAP not only demonstrated the power of SAP HANA by cutting hours from the run times of their top-down distribution jobs, the developer also created the next generation of CO-PA top-down distribution tools which greatly improve the usability of the application.  The enhancements to the CO-PA top-down distribution are announced in SAP Note 1695850 with effect from ERP release 6.0 enhancement package 5 (6.05) with support package 7 (SAPKH60507) and all equivalent SPs in later EHPs.  Note that SAP HANA is not required to take advantage of the usability improvements in the enhancements to top-down distribution.  However, running SAP HANA as a financial accelerator or as the primary database underneath the ERP system will certainly improve the speed of the top-down distribution, along with many other transactions.

I have been working with these enhanced top-down distribution transactions and have shared some knowledge about them in the SCN Wiki for ERP Financials.  To help gain visibility to this information, I have written this weblog to share the following links:

Top-Down Distribution of Actual Data

KE28 (Configure and) Execute Top-Down Distribution of Actual Data

KE28A - Variant Start of CO-PA Top-Down Distribution

KE28T - Technical Settings for CO-PA Top-Down Distibution

KE28L - History Log

KE28R - Mass Reversal

I hope you find these Wiki pages useful and that your organization achieves a similar success as to that gained by the CPG customer mentioned above.

I am writing my first blog on SDN keeping in view the requirement of Clients.  There are some different tools to create short cuts for the COPA (Ke30) reports, but how to assign t. code to each report is not available. In following steps which shows the how to create T. Code for COPA reports.

(Ke30 View)

Transaction Code SE93

Type Transaction Code starts with “Z” or “Y” and click on Create button.

Assign text to transaction Code and select the last option “Transaction with Parameters (Parameter Transaction)”

In Default Values Tab

Transaction = “START_REPORT”

Check on “Skip initial Screen”

Classification Tab

Check on “Inherit GUI attribute”

In the Default Values tab, click on Add Icon.

Please note

XXXX is the Operating Concern

The technical thing in it is the spaces after 01CE1XXXX and the report name must be equal to 23 (Spaces)

REPORT2 is the name of report assigned in KE30,

Special Note

If the report in KE30 not exist in current server (development Server) than that is not a problem, write name of the report from the Production Server, after transport it works in that Server. 

Save and assigned Package

Transport it to PRD Server and execute the assigned report directly without entering in KE30.

Lots of folks out there must be wondering how to join BSEG with BKPF in infoset and query reports. Normally, system just give you an error which does not allow you to join. Let me show you how to do this in another way.

Step 1: Create Infoset SQ02

- Create a infoset with just Direct read table BSEG

Step 2: Declare additional variables in the code section and DATA area.

   DATA: X_BUDAT LIKE BKPF-BUDAT,
      X_MONAT LIKE BKPF-MONAT,
      X_BELNR LIKE BSEG-BELNR,
      I_WRBTR LIKE wmto_s-amount,
      lv_amount1 LIKE wmto_s-amount.

data: begin of I_BKPF occurs 0,
        bukrs  like bkpf-bukrs,
        belnr  like bkpf-belnr,
        gjahr  like bkpf-gjahr,
      end of I_BKPF.

Step 3: Create Additional Selection Field "S_BUKRS" as Mandatory and as a Single Field.

Step 4: Create Additional Selection Field "S_BUDAT" as Mandatory.

Step 5: Create Additional Selection Field "S_MONAT". (Optional)

Step 6: Create Additional Selection Field "S_BELNR" as a hidden field". This is the document no to be linked to BSEG.

Step 7: Put your cursor on the 1st selection field "S_BUKRS" and click on the code icon as shown below.

Step 8: Paste below code in as part of your authorization checks. Save the code.

   AUTHORITY-CHECK OBJECT 'S_TCODE'
            ID 'TCD' FIELD 'FB03'.
if sy-subrc ne 0.
   MESSAGE 'You are not authorized to FB03.' Type 'E'.
endif.

AUTHORITY-CHECK OBJECT 'F_BKPF_BUK'
            ID 'BUKRS' FIELD S_BUKRS-LOW
            ID 'ACTVT' FIELD '03'.
if sy-subrc ne 0.
   MESSAGE 'You are not authorized to Company Code.' Type 'E'.
endif.

Step 9: Now put cursor on the selection field "S_BELNR" and click on the Code Icon like step 7, Paste below code in and save.

   CLEAR: I_BKPF, S_BELNR.
REFRESH: I_BKPF, S_BELNR.
SELECT BUKRS BELNR GJAHR
       INTO TABLE I_BKPF
       FROM BKPF
       WHERE BUKRS IN S_BUKRS
        AND   BUDAT IN S_BUDAT
        AND   MONAT IN S_MONAT.
if sy-subrc = 0.
  LOOP AT I_BKPF.
    S_BELNR-SIGN = 'I'.
    S_BELNR-OPTION = 'EQ'.
    S_BELNR-LOW = I_BKPF-BELNR.
    APPEND S_BELNR.
    ENDLOOP.
ELSE.
  MESSAGE 'No Data Exists...' Type 'E'.
ENDIF.

Step 10: Go back to Extras tab, and click on create icon. Create additional field "BUDAT" to show Posting date field from BKPF.

Step 11: Add an extra field like above step. Field is "WAERS" and Like reference is  BKPF-WAERS. Sequence of Code = 2

Step 12: Add other extra fields like Posting Period (BKPF-MONAT), etc.

Step 13: In the same Extra Tab, create Code. Once inside, you might want to give a sequence number 29 to field "Sequence of Code Section".

Step 13: Paste below code inside and Save. if you have other extra fields from BKPF, be sure to modify the Clear and select statement from BKPF table.

CLEAR:  BUDAT, WAERS.
SELECT SINGLE BUDAT WAERS
  INTO (BUDAT, WAERS) FROM BKPF
  WHERE BELNR = bseg-belnr
  AND   BUKRS = bseg-bukrs
  AND   GJAHR = bseg-gjahr.
*Modify signs.
  IF BSEG-SHKZG = 'H'.
    BSEG-DMBTR = 0 - BSEG-DMBTR.
    BSEG-WRBTR = 0 - BSEG-WRBTR.
  ENDIF.
*Make sure amount is in correct decimal.
  CLEAR: lv_amount1, I_WRBTR.
  MOVE BSEG-WRBTR TO lv_amount1.
    CALL FUNCTION 'CURRENCY_AMOUNT_SAP_TO_DISPLAY'
    EXPORTING
      currency        = WAERS
      amount_internal = lv_amount1
    IMPORTING
      amount_display  = I_WRBTR
    EXCEPTIONS
      internal_error  = 1
      OTHERS          = 2.
MOVE I_WRBTR TO BSEG-WRBTR .

Step 14: Once done, you should have something like below:

Step 15: Now you can pull all the relevant fields you want to show in report to field groups.

Step 16: Save and Generate your infoset when you are done. Assign it to a User group.

Step 17: Create your query with SQ01 and you just need to select the List field.

Step 18: Execute your report and Good Luck.

Hi All,

I am writing here My Next blog which is related to Automatic account Assignment OKB9 does not work. In My previous Blog there was Mention that in OKB9 set Acc assignment 1 As valuation area is mandatory, Now here in case if  you have set Acc assignment 3 Profit Center is mandatory.

All steps will remain same as mention in Previous blog Please refer the Link Automatic account assignment OKB9 does not work.

Now question is here, if you have set Account assignment In OKB9 "3 Profit Center is mandatory"

The System not able to get Cost center from OKB9 for  Auto-generated line item or for Eg. You have Created COGS Account as cost element and assigned it on GBB-VAX.

Make Some Addition changes in Program "ZRGGBS000_1"

IF COBL-PRCTR IS INITIAL .
       COBL-PRCTR = COBL-PPRCTR.

and

   I_PRCTR   = COBL-PRCTR

Hi..

To create t-code for report writer, co-pa drill-down report and ABAP Query report,  You input transaction code as below picture after you execute t-code SE93.

You input short text for transaction code and select “Transaction with parameters” radio button as start object in create transaction screen as below picture.

You input the data for creating transaction code as below picture except for default Values.

In case of Report writer, you input the data for default Values as below.

    D_SREPOVARI-REPORTTYPE    RW

    D_SREPOVARI-REPORT              Report group name

    D_SREPOVARI-EXTDREPORT

    D_SREPOVARI-VARIANT

    D_SREPOVARI-NOSELSCRN

In case of CO-PA Drill-down repot, you input the data for default Values as below.

      D_SREPOVARI-REPORTTYPE         RE

      D_SREPOVARI-REPORT   

      D_SREPOVARI-EXTDREPORT         KE 01CE1XXXX                  Report name    * XXXX means Operation concern name.

      D_SREPOVARI-VARIANT

      D_SREPOVARI-NOSELSCRN

In case of ABAP Query report, you input the data for default Values as below.  

    D_SREPOVARI-REPORTTYPE         AQ

     D_SREPOVARI-REPORT                  User Group name

     D_SREPOVARI-EXTDREPORT        ABAP Query name

     D_SREPOVARI-VARIANT

     D_SREPOVARI-NOSELSCRN

In case of CO-PC Drill-down repot, you input the data for default Values as below.

     D_SREPOVARI-REPORTTYPE        RE

      D_SREPOVARI-REPORT    

      D_SREPOVARI-EXTDREPORT        KK  01KKROBJ                        Report name

      D_SREPOVARI-VARIANT

      D_SREPOVARI-NOSELSCRN

After you finish inputting the parameter value, you click “save” button and input the package name in which you want to save the transaction code in

next screen.

Dear Colleagues,

I'd like to propose a little "game" (excuse me if it was already done before).

Let's try to create a list/ranking of most "annoying" system limitations/shortcomings.
I'm pretty sure many of us have some favourites.

We can also share how we go around them.

Here's my list:

1. No Costing Views for split valuated materials at valuation type level.
    I really don't understand why there is such a limitation (if someone knows please shed the light).
    Without costing view we can't create cost estimates at valuation type level. We can't assign Profit Centers either.

2. Accounting for tax in cross-company cost allocations.
    Wouldn't it be nice if transaction KALC could generate additional lines for GST?

3. Fully integrated inter-company code subcontracting process.
    Quite a few times I came across this requirement when subcontracting vendor is another company code in the system.
    It would be really great if we could automatically trace stock quantities provided to internal subcontracting vendor.

Regards,

Szymon

When for the first time I was asked to work on transfer pricing, it took me a few moments to recollect what it was and what I know about the topic. Then the reading, searching started before I could design, build, test and deliver the custom module to my customer. So, I thought it would be useful to share with others the information I had gathered on transfer pricing.

Disclaimer: Please note that the below content is just what I could recollect from my readings and does not contain any thing specific to SAP. It is more on a general note. Also, the transfer pricing methods are not limited to the number I have described below and the terminology used to describe them may be different. I have tried describing only the base methods on which others are built.

Transfer Pricing

Transfer pricing involves a range of activities from setting, analysis, documentation to adjustment of charges made between related parties for goods, services, or use of property (including intangible property). Inter company transactions across borders are growing rapidly and are becoming much more complex. This has led to the rise of transfer pricing regulations as governments seek to stem the flow of taxation revenue overseas, making the issue of great importance for multinational corporations.

Companies often use transfer prices as substitutes for market prices - maybe market prices do not exist for the scenario or they do not facilitate internal trading or factor in the synergies created. Thus, a transfer price imposition helps benefit from these synergies. However, the complication might be that synergistic benefits’ sharing between responsibility centers is often arbitrary, so the "correct" transfer price cannot exist. Transfer prices affect the profit reported in each responsibility center, and, more importantly, they are used to influence decision making, especially in a decentralized environment.

The extensive use of transfer pricing has management, financial as well as tax implications. For instance, low transfer pricing can make a division's financial performance look better than it might be if it would have paid open market prices for its inputs. On the other hand, unusually high transfer pricing can cause the division's taxable income to be lower than it might ordinarily be, while the selling division will have inflated profits.

The "arm's length" principle is used as a standard to calculate transfer prices. Under this approach, the price that an independent buyer would pay an independent seller for an identical item under identical terms and conditions, where neither is under any compulsion to act is taken into account.

There are practical difficulties in implementing this approach. For items other than goods, there are rarely identical items. Terms of sale may vary from transaction to transaction. Market and other conditions may vary geographically or over time. Also, most systems recognize that an arm's length price may not be a particular price point but rather a range of prices.

Some of the common Transfer Pricing methods are:

• Comparable Uncontrolled Price method (CUP)
• Resale Price method
• Cost Plus method
• Profit Split method
• Transactional Net Margin method (TNNM)

Some methods are more appropriate and indicative for an arm’s length result for certain transactions than others. For example, a cost‐based method is usually considered more useful for determining price for services and manufacturing, while a resale price‐based method is usually considered more useful for determining price for distribution/selling functions.

Comparable Uncontrolled Price method (CUP)

The method compares the price charged for property or services transferred in a controlled transaction to the price charged for property or services transferred in a comparable uncontrolled transaction in comparable circumstances or after reasonable adjustments are made to account for the differences. This method is widely used in practice with respect to royalties. If reasonable adjustments cannot be made, the reliability of the CUP method is decreased. In such cases, another transfer pricing method should be used in combination with the CUP method or considered instead of the CUP method.

CUP method is not a one sided analysis, as price is arrived at between two parties to the transaction and also a detailed transactional comparison is involved.  In addition, unlike the other methods, it avoids the issue as to which of the related parties should be the tested parties for transfer pricing purposes. However, often it is hard to find closely comparable uncontrolled transactions as strict comparability standard is required particularly with respect to product comparability. What adds to the complexity is the fact that internal comparable transactions frequently don’t exist while external comparable transactions are difficult to find in practice.

Resale Price method

This method is one of the traditional transaction methods and focuses on the selling company as the tested party in the transfer pricing analysis. The mechanism of the resale price method reduces the price of a product that the selling company charges to an unrelated customer by an arm’s length gross margin, which it uses to cover its selling, general and administrative (SG&A) expenses, and still make an appropriate profit, taking into account its functions performed and risks incurred. The financial ratio used here is the gross profit margin, which is defined as the gross profit to net sales ratio of the selling company.

The resale price method is a demand driven method as the base price is the market price and it can be used to without forcing distributors to make unrealistic profits. However, unlike the CUP method, it is a one sided analysis focusing on the selling company and the data on gross margin may not be comparable in uncontrolled transactions due to accounting inconsistencies.

Cost Plus method

This method focuses on the manufacturing company as the tested party in the transfer pricing analysis. It begins with the costs incurred by the supplier in a controlled transaction for property transferred or services provided to a related purchaser. An appropriate cost plus markup is then added to this cost, to make an appropriate profit in light of the functions performed, risks assumed, assets used and market conditions. It compares the gross profit markup earned by the manufacturing company or service provider to the gross profit markups earned by comparable companies. The financial ratio used here is the gross profit mark‐up, which is defined as the gross profit to cost of goods sold ratio of a manufacturing company.

Third parties can be easily found that are using cost plus method to set prices. Also, since the basis is internal costs, the data is readily available. However, there may be no link between the level of market prices and the costs. It is also a one sided analysis and accounting consistency with the comparable uncontrolled transactions may be a problem. In addition, since the calculation is based on actual costs, there may be no incentive for cost control to the manufacturer or service provider.

Profit Split method

This method seeks to eliminate the effect of special conditions made or imposed in a controlled transaction on profits by determining the division of profits that the involved parties would have expected to realize from engaging in it. The first step is to identify the profits to be divided between the parties from the controlled transactions. Then, these profits are divided between them based on the relative value of their contribution, which should reflect the functions performed, risks incurred and assets used in the transactions.

The split can be decided through contribution analysis or residual analysis. In contribution analysis, the combined profits are allocated on the basis of the relative value of functions performed. In the residual analysis, first, a basic profit for the routine contribution is allocated and then, the residual profit is allocated based on the circumstances.

This method is used where comparable transactions could not be found.  It results in avoiding extreme result for one of the involved parties due to its two sided approach and also is best to deal with the returns which occur as a result of synergies. However, there may be certain measurement problems in applying this method. For instance, due to different accounting practices, the costs and revenues of each party may be difficult to compare.

Transactional Net Margin method (TNNM)

The method examines the net profit margin relative to an appropriate base (say, costs, sales, assets) that a taxpayer realizes from a controlled transaction and compares it with net profit margins earned by the tested party in comparable uncontrolled transactions. This method is a more indirect method compared to others as net profit margin is compared and there may be many factors which affect it but have nothing to do with transfer pricing.

It may be better to choose the TNMM if, for example, there is different reporting of the cost of goods sold and operating expenses for the tested party and the comparable parties, so that the gross profit margins reported are not comparable and reliable adjustments cannot be made, the resale price method may be relatively unreliable. However, this type of accounting inconsistency will not affect the reliability of the TNMM, as this method examines net profit margins instead of gross profit margins.

This method can be applied to the less complex party in the transaction and hence less complex analysis is needed. Also, it can be applied to both sides of the transaction and gives the same results as a modified resale price or cost plus method. However, several countries do not recognize the use of this method. In addition, it may be difficult to calculate back the transfer price from a determination of arm’s length net margin.

Recreating it as it was accidentally deleted by one of the moderators (apparently he's not able to reinstate it).

Link to the original blog post:

http://scn.sap.com/community/erp/financials/controlling/blog/2014/03/14/the-most-annoying-system-limitationsshortcomings

Dear Colleagues,

I'd like to propose a little "game" (excuse me if it was already done before).

Let's try to create a list/ranking of most "annoying" system limitations/shortcomings.
I'm pretty sure many of us have some favourites.

We can also share how we go around them.

Here's my list:

1. No Costing Views for split valuated materials at valuation type level.
    I really don't understand why there is such a limitation (if someone knows please shed the light).
    Without costing view we can't create cost estimates at valuation type level. We can't assign Profit Centers either.

2. Accounting for tax in cross-company cost allocations.
    Wouldn't it be nice if transaction KALC could generate additional lines for GST?

3. Fully integrated inter-company code subcontracting process.
    Quite a few times I came across this requirement when subcontracting vendor is another company code in the system.
    It would be really great if we could automatically trace stock quantities provided to internal subcontracting vendor.

Regards,

Szymon

L'environnement économique de l'Afrique francophone diffère de celui du reste de l'Afrique. Toutefois, les entreprises peuvent faire face aux défis uniques présentés par cette région en sélectionnant des solutions ERM adaptées.

Les investisseurs se tournent de plus en plus vers l'Afrique, qu'ils considèrent comme une destination attrayante pour placer leurs capitaux. Cependant, toutes les nations africaines ne sont pas sur un pied d'égalité. La gestion de l'activité peut varier de manière significative d'une région à l'autre.

Tout investisseur potentiel en Afrique francophone devrait se tenir informé des défis spécifiques que représente l'environnement économique de ces nations. Lors de la mise en place d'infrastructures de réseau commercial, il est nécessaire d'adopter une approche adaptée à l'Afrique francophone. Voici cinq clés pour surmonter les défis propres aux pays de l'Afrique francophone.

Gestion des risques

Le cadre légal et réglementaire qui s'applique aux nombreux pays constituant l'Afrique francophone peut être source de difficultés particulières, y compris pour les investisseurs expérimentés. L'environnement juridique est très différent d'un pays à l'autre, ce qui pose un problème majeur de conformité. De plus, ces pays présentent souvent des risques d'investissement significatifs relatifs aux enjeux d'infrastructure et de stabilité.

Grâce à des logiciels spécialisés ciblant la gouvernance, le risque et la conformité, les entreprises peuvent éliminer le facteur lié à l'insécurité d'exploitation au sein de nouveaux marchés inconnus. Les activités liées aux risques et à la conformité peuvent être intégrées à la stratégie, la planification et l'exécution, tout en réduisant les coûts et en protégeant les sources de revenus et l'image de la marque.

Collaboration

De nombreuses entreprises sous-estiment souvent les obstacles constitués par les différences linguistiques et culturelles qui se posent lorsqu'ils tentent de s'établir en Afrique francophone. Faire venir des employés parlant le français dans ces pays n'est pas la méthode adéquate. Les investisseurs doivent se familiariser avec les diverses cultures commerciales et les subtilités qui pourraient échapper aux étrangers. De plus, les accords juridiques et les concessions doivent être établies en français car elle l'emportent, en termes juridiques, sur leurs équivalents en anglais.

Des partenariats locaux sont indispensables au sein d'un tel environnement. Les entreprises doivent faire preuve d'une volonté profonde de coopération avec les acteurs et les experts locaux. Les technologies de cloud permettent la création d'environnements collaboratifs à un degré inégalé, rendant ainsi les chocs de cultures obsolètes.

Ressources humaines

Il n'est possible de surmonter les barrières linguistiques et culturelles qu'avec l'aide de personnes talentueuses. Toutefois, la plupart des meilleurs talents africains quittent souvent le continent afin de poursuivre leurs études ou de travailler à l'étranger, ce qui ne facilite pas la tâche.

Grâce aux logiciels de gestion des ressources humaines, le processus qui vise à trouver, attirer et garder les personnes les plus à même de comprendre l'idiosyncrasie des différents environnements économiques est simplifié. Ces solutions permettent de créer un environnement de travail axé sur les employés, qui contribue à la productivité et à l'automatisation des processus administratifs, et facilite la formation. Les employés sont dans les conditions idéales pour toujours donner le meilleur d'eux-mêmes. 

Service client

Les principales sources de revenus en Afrique francophone proviennent traditionnellement de l'exploitation minière et des compagnies pétrolières. Une tendance notable se dessine dans les pays d'Afrique dépendant de ces ressources : l'accent est de plus en plus mis sur les secteurs clients parallèlement aux activités économiques basées sur les ressources.

Il serait judicieux pour les investisseurs intéressés par l'Afrique francophone de tirer le meilleur parti de ces marchés relativement sous-développés et de s'imposer le plus tôt possible comme leader du secteur. Mettre en œuvre des stratégies axées sur le client grâce à des logiciels CRM est l'une des manières d'y parvenir. Les outils tels que les outils d'analyse de données permettent d'obtenir une visibilité clients qui favorise une meilleure réactivité des entreprises. Dès lors, elles sont en mesure de développer et de renforcer la fidélité des clients.

Croissance

La croissance dans les pays d'Afrique francophone a pris du retard par rapport aux nations anglophones ou lusophones du continent. Les pays francophones ne contribuent qu'à hauteur de 19 % au PIB moyen de l'Afrique subsaharienne et enregistrent un taux de croissance moyen de 3,4 %, soit quelques points de moins que les pays principalement anglophones d'Afrique de l'Est.

Grâce à la rapidité et à l'adaptabilité prodiguées par les solutions ERP super-puissantes actuelles, les entreprises peuvent suffisamment rationaliser leurs opérations pour se concentrer pleinement sur la croissance. Les solutions de gestion permettent de faciliter la croissance grâce à l'introduction de nouvelles sources de revenus, entre autres. Les niveaux de collaboration, de flexibilité et de productivité dont bénéficient les entreprises dotées de solutions ERP permettent d'optimiser les échanges avec le client. De ce
fait, la mise en œuvre de nouveaux produits et services est simplifiée.

Voilà quelques-unes des nombreux applications pour lesquelles les solutions de gestion d'entreprise peuvent jouer un rôle clé au sein de l'environnement économique de
l'Afrique francophone. Les entreprises doivent étudier de près les pays où elles comptent s'implanter et choisir les solutions technologiques complémentaires en conséquence.