Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Pricing
Partner Processing
Text Processing
Action Processing
You make Customizing settings for the first three of these services in the section entitled Customer Relationship Management -> Basic
Functions. You can define the settings for actions in CRM Billing directly in this section.
Here, you can find information on the pricing service for billing in SAP CRM. This service is used to determine and calculate prices,
taxes, surcharges, discounts, and other pricing conditions for individual items or for ranges of items.
Pricing can occur both in the pricing and the billing components of SAP CRM. Items might, for example, need to be re-priced in billing if
particular pricing conditions are not to be determined until billing takes place.
Requirements
You have set up pricing in Customizing for Customer Relationship Management under Basic Functions -> Pricing -> Define Settings for
Pricing. To ensure that you can make full use of the pricing service in SAP CRM billing, you need to have completed the following
activities:
In the field catalog, specify which fields can be used for creating condition tables.
You use condition tables to define combinations of allowed fields for which condition records (condition master data) can be
created in the system.
You use access sequences to define search strategies that enable the system to search for condition records in the condition
tables.
You use condition types to define the effect of a condition in a business transaction (whether it is a price, a
surcharge/discount or tax, for example).
In the pricing procedure, you define which condition types are valid within a specific business transaction, the sequence in
which they are calculated, whether and how subtotals are calculated, and other control information.
You use a condition exclusion to define rules stipulating how a selection should be made if several condition records are
determined during pricing.
You use copy types to specify system responses when pricing document data is copied from one business transaction to
another. You only need to define the copy types relevant to Billing in this activity - you do not need to assign them here.
Activities
In order to make full use of the pricing service in SAP CRM billing, complete the following activities in Customizing for Customer
Relationship Management under Billing:
In the activity Define Billing Item Categories, select a pricing procedure to be used for generating pricing documents in the
billing due list.
In the same activity, select a predefined pricing type and copying type to be used for transferring pricing conditions to the
billing due list and to billing documents.
In the activity Define Billing Types, select a pricing procedure to be used in billing documents.
The pricing procedures used for generating the pricing documents of billing due list items and billing documents must at least contain
the condition types that are to be transferred from business transactions to billing.
In SAP CRM billing, you can only use billing due list item fields and billing document fields that might need to be re-priced during input
processing. This excludes data that is relevant to tax determination - the system determines this on the basis of the following
information:
Product
If you want to add fields from SAP CRM and/or create customer-specific fields and use them for pricing in SAP CRM billing, you need to
complete the following activities:
1. Add the fields to the field catalog in Customizing for Customer Relationship Management under Basic Functions -> Define
Settings for Pricing -> Maintain Field Catalog.
2. Include the new fields for the billing due list item, billing document header, or billing document item in the Billing Engine
Navigator (transaction BEFN).
3. Define appropriate mapping information for the pricing service in the Billing Engine Navigator.
If these settings do not suffice or if you require additional functions, you can use the following Business Add-Ins (BAdIs) to define
customer-specific enhancements:
You can find these BAdIs in Customizing for Customer Relationship Management under Billing -> System Enhancements -> Business
Add-Ins.
Further notes
SAP CRM billing uses the same Customizing and condition master data for billing as the relevant business transactions do.
During input processing, the system transfers pricing conditions item by item to a new pricing document, taking into account
the pricing type and copying type that are defined for the billing item category. Only pricing conditions that exist both in the
pricing procedure of the business transaction and in the pricing procedure of the item category are accepted.
If the entire quantity of the business transaction (an order item, for example) cannot be invoiced, but only a partial quantity (as
might be the case for a partial delivery), the system makes a quantity-based adjustment to the pricing conditions during input
processing. You can use the copying type to specify how this should be achieved.
When the billing process is triggered, the pricing conditions of the billing due list items are copied to the pricing document of
the billing documents. The system does this using the pricing type and copying type that you defined in the billing item
category.
If you do not specify a pricing procedure for a billing item category or a billing type, pricing conditions are not processed at
all.
Define Billing Relevance of Item Categories
You determine the billing scenario for each item category that requires billing
Generation of Billing Due List
Prerequisites:
*-Data
DATA: l_header_guid TYPE crmt_object_guid,
lt_guid_tab TYPE crmt_object_guid_tab,
lt_orderadm_i TYPE crmt_orderadm_i_wrkt,
lt_billing_items TYPE crmt_billplan_billing_it_tab,
ls_billplan_wrk TYPE crmt_billplan_com,
l_header_invoiced TYPE boolean.
*-Field symbols
FIELD-SYMBOLS: <fs_orderadm_i> TYPE crmt_orderadm_i_wrk.
*-mkae sure this is on the create only
CHECK i_mode = gc_mode-create.
*-get the header guid
CALL FUNCTION 'CRM_INTLAY_GET_HEADER_GUID'
IMPORTING
ev_header_guid = l_header_guid.
*-pass the header
INSERT l_header_guid INTO TABLE lt_guid_tab.
*-read the items
CALL FUNCTION 'CRM_ORDER_READ'
EXPORTING
it_header_guid = lt_guid_tab
IMPORTING
et_orderadm_i = lt_orderadm_i
EXCEPTIONS
document_not_found = 1
error_occurred = 2
document_locked = 3
no_change_authority = 4
no_display_authority = 5
no_change_allowed = 6
OTHERS = 7.
*-items found
IF sy-subrc = 0.
*---go over the items
LOOP AT lt_orderadm_i ASSIGNING <fs_orderadm_i>
WHERE itm_usage NE gc_item_usage-billing_request.
*-----get the billing plans
CALL FUNCTION 'CRM_BILLPLAN_READ_SUBITEMS_SI'
EXPORTING
iv_guid = <fs_orderadm_i>-guid
CHANGING
ct_billing_items = lt_billing_items
EXCEPTIONS
error_occurred = 1
OTHERS = 2.
*-----look for inoviced billing plans
READ TABLE lt_billing_items WITH KEY invoiced = true
TRANSPORTING NO FIELDS.
IF sy-subrc = 0.
*-------something has been invoiced
l_header_invoiced = true.
EXIT.
ENDIF.
ENDLOOP.
*---if something has been invoiced
IF l_header_invoiced = true.
CLEAR c_ref_possible.
ENDIF.
ENDIF.
ENDFUNCTION.
-----------------------------------------------------------------------------------------
FUNCTION zcrm_unlink_collect_change.
*"----------------------------------------------------------------------
*"*"Local interface:
*" IMPORTING
*" REFERENCE(IS_BILLPLAN_BADI) TYPE CRMT_BILLPLAN_BADI
*"----------------------------------------------------------------------
*-include
INCLUDE crm_direct.
*-DATA
DATA: ls_input_fields TYPE crmt_input_field,
ls_billplan TYPE crmt_billplan_com,
ls_orderadm_i TYPE crmt_orderadm_i_com.
*_______________________________________________________*
* input fields *
*_______________________________________________________*
*-pass the fields
CALL FUNCTION 'CRM_BILLPLAN_CREA_INPUT_FIELDS'
EXPORTING
iv_structure_name = gc_2000_billplan_ui
IMPORTING
es_input_fields = ls_input_fields.
*-fill logical key
CALL FUNCTION 'CRM_BILLPLAN_FIND_LOGICAL_KEY'
EXPORTING
iv_guid = is_billplan_badi-guid
iv_handle = is_billplan_badi-handle
iv_object = gc_logical_object-billplan
IMPORTING
ev_logical_key = ls_input_fields-logical_key.
*-pass the object name
ls_input_fields-objectname = gc_object_name-billplan.
*-pass the ref guid
ls_input_fields-ref_guid = is_billplan_badi-ref_guid.
*-pass the ref kind
ls_input_fields-ref_kind = is_billplan_badi-ref_kind.
*_______________________________________________________*
* billplan dta *
*_______________________________________________________*
MOVE-CORRESPONDING is_billplan_badi TO ls_billplan.
CLEAR ls_billplan-ref_to_header.
*_______________________________________________________*
* Pass changes to globals *
*_______________________________________________________*
INSERT ls_input_fields INTO TABLE gt_input_fields.
INSERT ls_billplan INTO TABLE gt_billplan.
ENDFUNCTION.
Taxation Settings:
View_Tax.pdf
Also check
Defines the sequence in which the system accesses tax condition records when more than one tax applies in a particular country.
Use
In CRM, this tax classification (in conjunction with a country and optionally a region) is assigned to a tax group.
Taxes >> Basic Settings >> Tax Jurisdictions >> Using SAP Software > Technical Settings > Define Indicator
When this destination is maintained, all transactional RFC (tRFC) calls which update the external tax system (function modules
RFC_UPDATE_TAXES_DOC and RFC_FORCE_TAXES_DOC) will be send via this destination. The RFC calls for tax calculation
(function module RFC_CALCULATE_TAXES_DOC) in the external system are still sent via the destination that is defined in the 'TTXD-
RFCDEST' field.
If this destination is not maintained, all calls in the external tax system are sent via the destination that is defined in the 'TTXD-
RFCDEST' field.
If an external tax system is used, that system determines a tax jurisdiction code or checks its validity during address data maintenance
for an American or for a Canadian address (customer, vendor, plant and so on).
o If the tax jurisdiction code field is empty, the R/3 System will attempt to determine a tax jurisdiction code.
o If the tax jurisdiction code field contains a value, the R/3 System checks this tax jurisdiction code against the
respective address.
o If the tax jurisdiction code field is empty, the R/3 System will attempt to determine a tax jurisdiction code.
o If the tax jurisdiction code field contains a value, the R/3 System checks this tax jurisdiction code against the
respective address.
o If this check fails, the tax jurisdiction code for the respective address will be determined
Transactions -- Integration with TTE -- Assign Item Object types to TTE Business Processes
Use
In addition to the activities in the Implementation Guide (IMG) for the Transaction Tax Engine (TTE), check that the following
requirements have been met:
IPC Administrator settings for the TTE are complete. All required RFC destinations are maintained in the IPC.
Tax configuration is complete in the IMG for CRM: Basic Functions -> Taxes including the following activities for master data
replication:
Condition Types 0TTE and 1TTE that call the TTE have been defined in the IMG for CRM : Basic Functions ->
Pricing -> Define Settings for Pricing -> Pricing Procedure
The condition types must have the following attributes:
- Mandatory
- Statistical
For CRM 3.x customers who want to continue to use CRM3.x tax event determination, execute
Replicate R/3 BP tax categories and tax classification to CRM Transaction PITM
The Customizing load object DNL_CUST_TAX has been initiated to ensure that changes to master date in R/3 are
automatically replicated in CRM by a delta download.*
In the SAP menu, choose Architecture and Technology -> Middleware -> Data Exchange -> Initial Load -> Start
To transfer tax results to R/3, complete the following activity in the IMG for CRM: Basic Functions -> Billing -> Intergration ->
Transferring Billing Documents to Accounting*
EDI tax type codes are required for exchanging standardized messages with non-SAP systems
Tax Type ID
Tax type IDs must be unique within a tax category. The combination of tax category and tax type ID uniquely identifies a tax type. This
combined ID is used to define on a technical level how the system finds condition records for tax rates and exemptions.
Procedure
Enter consecutive numbers 1, 2, 3, 4, for each defined tax type. The tax type IDs defined in this table must be unique within a tax
category.
Examples
The system uses standard condition technique and provides a field catalog that consists of parameters that are relevant for tax rate and
exemption finding. This field catalog has a set of product tax group fields "PRTXGRP_mmnn," where mm is the tax category code and
nn the tax type ID.
Tax type "VAT" for VAT taxes is by default assigned tax category "Sales tax" (internal code "01") and tax type ID "01". As a
consequence, parameter "PRTXGRP_0101" represents the product tax group for tax category "01" (sales tax) and tax type id "01" (tax
type "VAT"). Similarly, "PRTXGRP_0102" is related to tax type ID "02".
Dependencies
If the tax type IDs are not unique, the system cannot process conditions and pricing properly
Condition Type for Tax Rates
This condition type is used by the system to store and retrieve tax rates for a particular tax type.
Specifically, this condition type applies to taxes that are calculated as a percentage of a base amount (as opposed to quantity-based
excise taxes).
For incoming VAT-like taxes the tax amount may have to be split into a deductible and a non-deductible part. To this end a condition
type for non-deductibility can be assigned. This condition type finds the rate of non-deductibility. As a result, the system returns both the
deductible and non-deductible part of the tax amount.
Notes
The default condition type for non-deductibility is 3001. The access sequence for this condition type includes a table where a
default rate can be maintained (usually 0 %, if by default a transaction is fully deductible).
This condition type is used by the system to store and retrieve tax rates for a particular tax type.
Specifically, this condition type applies to quantity based taxes (excise taxes).
Condition Type for Exemptions
This condition type is used by the system to store and retrieve exemption records for a particular tax type.
Exemption Type
Freedom from tax obligation. General exemption and specific exemptions are exemption types.
Legal Text ID
The legal text ID is used in Brazil and refers to the tax law for ICMS and IPI tax. This text is stored in the Nota Fiscal and every
transaction that leads to an ICMS or IPI calculation requires a tax law.
Legal Language
A legal language can optionally be assigned to a legal text ID.
If such a language has been assigned, the legal text can only be maintained in this language. For technical reasons you must logon in
the legal language in order to maintain the legal text. TTE always returns the legal text in the assigned legal language, irrespective of
the logon language.
If no legal language has been assigned, legal texts can be maintained in any logon language. TTE returns the legal text in the logon
language, or returns a warning if there is no version of the legal text available for the logon language.
Tax Event
The system determines the tax event based on the tax-relevant attributes of the business transaction and the participating partners and
products.
The tax event determines which taxes are due (tax types) and how the taxes are calculated (tax calculation procedure). Tax events can
also serve as a key for maintaining tax rates, e.g. to assign a zero tax rate to exports.
Non-Taxable Indicator
Direction Indicator
Examples
A typical set of tax events for a member state of the EU may look like this:
Dependencies
Non-Taxable Indicator
Indicates that a transaction is not taxable meaning that the TTE does not determine nor calculate tax, nor is any tax data returned.
It is important to distinguish a non-taxable transaction from a zero-rated transaction. In the latter tax is formally due, but at a rate of
zero. In this case, the system completes the tax determination and calculation steps, and returns a complete set of tax data, including
tax types, tax rates, tax amounts and any other tax elements. The system has to be configured correctly so that non-taxable
transactions and zero-rated transactions are clearly defined.
Direction Indicator
Outgoing
Incoming
Internal
Examples
Sales transaction
In this case:
If company A initiates the tax calculation, the direction indicator is "Outgoing" as it is supplying a product.
If company B initiates the tax calculation, the direction indicator is "Incoming" as it is acquiring the product.
Tax Calculation Procedure
Defines the permitted condition types and access sequence of calculation steps per transaction. These steps are condition types
which either find a condition record, such as a tax rate, or a condition type such as tax base value.
Procedure
To view the valid tax calculation procedures, choose Maintain Tax Calculation Procedure
(Cross-Application Components -> Transaction Tax Engine -> Condition Technique -> Maintain Tax Calculation Procedure)
Product Usage Indicator
Example
In some countries, petrol purchased for powering a private vehicle is subject to different taxation rates than petrol used for powering
factory machines (production).
0 - Resale
1 - Production
2 - Consumption