SAP SD tables

Here is the list of important tables used in SAP sales and distribution component.

Tables for Sales documents

VBUK: Table contains Header Status and Administrative Data of sales documents

VBAK: Table contains Sales Document’s Header Data

VBKD: Table contains Sales Document’s Business Data

VBUP: Table contains SD order item Status

VBAP: This contains SD order item Data

VBEP: Sales Document Schedule Line data

VBEH: Sales Document Schedule Line history

VBBE: Sales Requirements: Individual Records

VBEX: SD document – export control

KANZ: Assignment of Sales Order Items – Costing Objects

VBFCL: Sales Document Flow Cluster

VBLB: Sales Document: Release Order Data

VEDA: Contract Data

Sales activities

NAST: Message status

SADR: Company address management

VBFA: SD Document Flow

VBKA: Sales Activities

VBPA: Sales documents Partners

VBUK: Sales Document: Header Status and Administrative Data

VBUV: Sales Document: Incompletion Log

Tables for billing documents

EIKP: table for Foreign Trade: Export/Import Header Data

EIPO: Foreign Trade: Export/Import: Item Data

FPLA: Billing Plan

FPLT: Billing Plan: Dates

FPLTC: Payment Cards: Transaction Data – SD

KOCLU: Cluster for Conditions in Purchasing and Sales

NAST: Message Status

SADR: Address Management: Company Data

VBFCL: Sales Document Flow Cluster

VBPA: Sales Document: Partners

VBRK: Billing Document: Header Data

VBRL: SD Document: Invoice List

VBRP: Billing: Item Data

VBUK: Sales Document: Header Status and Administrative Data

Shipments

VTTK: Table contains Shipment document’s Header data

VTTP: Table contains Shipment document’s Item data

VTTS: Shipment document: Stages

VTPA: Partner for shipment

VTFA: Shipment document flow

VEKP: SD document: Shipping unit header

VEPO: SD document: Shipping unit item (contents)

Deliveries

LIKP: SD document: Delivery: Header data

LIPS: SD document: Delivery: Item data

SAP ALE Tutorial The full form of ALE is Application Link Enabling. ALE is the fundamental component of SAP for

exchanging data between SAP system and non-SAP systems for business integration purpose. ALE

is using Synchronous/asynchronous communication for reading data and asynchronous

communication for writing data. The major advantages of ALE are

Application data can be distributed between different SAP releases

Data can continue to be exchanged after a release upgrade without requiring special

maintenance

Customers can add their own enhancements

Communication interfaces enable connections to non-SAP systems

IDOCs (Intermediate Documents) are used to transfer the data in ALE. These IDocs are created and

dispatched in distributed systems using message types and BAPIs.So ALE distribution can be

Distribution using BAPI or Distribution using message types.

Basic process flow of ALE

In Outbound system the IDOC containing data will be created and prepared for dispatch.

Then this IDOC will send to the target system

In target system inbound processing will start on IDOC and the data will be posted in

application.

ALE System structure

Application layer

ALE layer

Communication Layer

Outbound and inbound processing is occurring at Application layer and ALE layer. Communication

layer is responsible for transferring the data between system using trfc or EDI file interface.

ALE provides various tools for Monitoring data transmission, Error Handling, Synchronization,

Consistency checks etc for the communication between distributed application systems.

Transaction code SALE can be used to view the basic ALE settings and description. To access the

ALE tools choose the path Tools -> Business Framework -> ALE

SAP IDOC structure tutorial What is SAP IDOC

The full form of IDoc is Intermediate Document. It’s a SAP standard document format for exchanging

data between different application servers. The Idoc interface will contain the data structure and

processing logic. The data structure is known as IDoc.Using IDoc different application servers can

be connection via a message based interface. It has an extensive exception handling before the

data is stored in the application server. Electronic Data Interchange (EDI) and Application Link

Enabling (ALE) are the main techniques using IDoc to exchange data between systems.

Segments are the basic building blocks of Idoc and store the actual data. SAP supplies some IDocs

by default and they are known as basic types of idoc. We can add additional data to the existing

basic types using reference segments. We can define our own IDoc types if the basic types won’t fit

for our requirements.

Structure of an IDOC

Every IDoc consist 3 records they are

Control Record: It contains the general information about that IDoc. It stores the sender

identification, receiver identification and IDoc type.Cotrol Records are stored in the data dictionary

table EDIDC and it can be views by transaction code SE11.Idoc type is the key information for IDoc

processor to interpret the data containing in that IDoc.

Important Fields containing in Control records are

Mestyp: (Logical message type)

Idoctp: (Idoc type -Basic structure of the IDoc)

Cimtyp: (Structure of customer extension)

Rcvprt: (Partner type of the receiver)

Rcvprn: (Partner number of the receiver)

Rcvpfc: (Partner function of the receiver)

Data Records: It contains the actual data to process.Data records are stored in the data dictionary

table EDIDD.Data records consists with two parts segment name and segment data. For each

segment type of the IDoc structure, there is a DDIC structure with the same name. A field string with

this structure is used for creating a data record. The application data is mapped to the field string.

The segment type is written to the field SEGNAM, and the field string is written to the field SDATA.

This data record is then included in the internal table with the structure edidd.

The fields in data records are

Segnam: (Segment type)

Sdata: (Actual data with maximum 1000 byte-long character)

Status Record: It stores the status of IDOC. The status records are stored in the data dictionary

table EDIDS.

The important fields in these records are

DOCNUM

STATUS

STATXT

SEGNUM

Steps to create a basic type Idoc

Creation of a new basic type of IDOC consists of several steps. Here is the detail explanation and

steps to do for that.

Step 1: Creation of Segments

Here are the steps to define segments

Enter Transaction code WE31

Select Utilities -> Requests (Organizer)

Specify segment type and choose create

Enter a short description of the segment and enter the corresponding field names and data

elements associated with that segment.

Goto -> Documentation and describe the segment type

Come back to segment editor

Save and Enter the segment in a transport request

Step 2: Define a basic Idoc Type

Enter transaction code WE30

Enter a name for the basic IDoc type and mark basic type as the development object. And

choose create

Enter a description for the basic Idoc type and choose tick mark button.

Position the mouse on header and choose create button

Enter the segments.

Save

Step 3: Assigning Message types

We need to create new message types only if the existing message not matching with our

requirements.

Steps to create a new message type

Enter Transaction WE81

Choose edit button and then new entries

Enter the message type with description

Save

Steps to assign basic Idoc type to message type

Enter transaction WE82

Choose edit button and then new entries

Enter the message type, basic type and SAP release in their corresponding columns.

Save data

Step 4: Create function Module for outbound processing

The steps for creating a function module have been described in our earlier posts. Here is a brief

about the steps.

Open the function builder to create our new function module

Create the segments as global data and code the function module to pass the application

data to the corresponding segments.

Activate the function module

Step 5: Maintaining the Attributes of a Function Module

Use transaction code BD51 to maintaining the Attributes of a Function Module (Like the settings for

dialog possible etc)

Step 6: Assign function module to the basic Idoc

Use Transaction code WE57 and then assign the function module to various objects as per our

requirements. This step is the ALE registration for the function module.

Step 7: Assigning a Process Code

This step is used to assign a new process code to the new function module. This enables the

function module to be identified from the partner profiles defined in the IDoc Interface when an IDoc

of the new message type is received.

Enter transaction code WE42

Enter process code and a description. Choose the Processing with ALE and Processing by

function module options and save your entries. In the maintenance screen assign the

inbound function module to the process code.

Choose new entries

In the detail screen enter Process code, Module fame, Idoc fame, Application Object fame

etc

Save

Enter transaction code WE42 again

Go back to maintain the inbound process codes and choose the Logical message navigation.

Choose change mode and select new entries

Enter the message type and process code

Save

Step 8: Defining a partner

The new basic type must be entered in the partner profiles before being used. Use transaction code

WE20 to create partner profile. Partner number, partner type, Partner function, message type,

permitted agent and process code are the important fields to maintain in inbound partner profiles.

These are the common steps involved in creating a new basic type Idoc. The other steps you need

to do after this may be

Create Logical System

Create RFC destination

Using of test tool for IDOC

You will get more details about these in our other tutorials.

IDOC status codes

After the process of inbound function module and outbound function module the state of status will

be recorded in the status record of IDOC.We can view the status by using transaction codes WE02,

WE05 and WE07.Here is the list of main IDOC stats codes for Outbound and Inbound IDOC.

Outbound IDOC status codes with status description.

01: IDoc generated

02: Error passing data to port (It’s an error status)

03: Data passed to port OK

04: Error within control information of EDI subsystem

05: Error in translation

06: Translation successful.

07: Error on syntax check (It’s an error status)

08: Syntax check successful

09: Error on interchange handling (It’s an error status)

10: Interchange handling successful

11: Error on dispatch (It’s an error status)

12: IDOC Dispatch successful

13: Retransmission successful

14: Interchange Acknowledgement positive

15: Interchange Acknowledgement negative (It’s an error status)

16: Functional Acknowledgement positive

17: Functional Acknowledgement negative (It’s a warning error status)

18: Triggering EDI subsystem successful

19: Data transfer for test successful

20: Error on triggering EDI subsystem (It’s an error status)

21: Error on passing data for test (It’s an error status)

22: Dispatch successful, acknowledgement still due

23: Error on retransmission (It’s an error status)

24: Control information of EDI subsystem successful

25: Processing despite syntax error (It’s a warning error)

26: Error during syntax check of IDoc (It’s an error status)

27: Error in ALE dispatch level (It’s an error status)

29: Error in ALE service (It’s an error status)

30: IDoc is ready for dispatch in ALE service

31: IDOC is marked for deletion.

32: IDoc was edited

33: Original of an IDoc which was edited

34: Error in control record of IDoc (It’s an error status)

35: IDoc reloaded from archive

36: Timeout error on Electronic signature not performed (It’s an error status)

37: IDoc added incorrectly (It’s an error status)

38: IDoc archived

39: Arrival of IDOC in target system confirmed

40: Application document not created in target system (It’s an error status)

41: Application document created in target system

Inbound IDOC status codes with status description.

42: IDoc was created by test transaction

50: IDoc added

51: Application document not posted (It’s an error status)

52: Application document partially posted (It’s an error status)

53: Application document posted successfully.

54: Error during formal application check (It’s an error status)

55: Formal application check successful

56: IDoc with errors added (It’s an error status)

57: Test IDoc: Error during application check (It’s an error status)

60: Syntax error on IDOC (It’s an error status)

61: Processing despite syntax error (It’s a warning error status)

62: IDoc passed to application

63: Error passing IDoc to application (It’s an error status)

64: IDoc ready to be transferred to application

65: Error in ALE service (It’s an error status)

66: IDoc is waiting for predecessor IDoc in serialization process

68: IDOC is marked for deletion.

69: IDoc was edited

70: Original of an IDoc which was edited

71: IDoc reloaded from archive

73: IDoc archived

74: IDoc was created by test transaction

Using the standard report RC1_IDOC_SET_STATUS we can change the status of an IDOC if we

require for that. We can reprocess IDoc if we are getting errors.

ALE IDOC Transaction codes

Here is the list of important ALE IDOC transaction codes and its purposes for a quick reference.

1. SALE – This transaction code is used for access IMG ALE Configuration root

2. WE05 – IDoc overview

3. WE07 – IDoc statistics

4. WE20 – This transaction code is used for manually maintain partner profiles

5. WE21 – This transaction code is used for Ports in Idoc processing

6. WE47 – This transaction code is used for edit IDOC status values. (Real path: SALE -> Set-

Up System Monitoring -> IDoc Status Display -> Edit IDoc Status Values)

7. WE60 – This transaction code is used for create IDoc documentation (IDOC header file)

8. SM59 – This transaction code is used for Create RFC Destinations

9. SM58 – Schedule RFC Failures

10. BD21 – Create IDocs from change pointers

11. BD50 – This transaction code is used for Activate Change Pointer for Message Type

12. BD52 – This transaction code is used for Activate change pointer per change.doc object

13. BD53 – This transaction code is used for Reduction of Message Types

14. BD55 – This transaction code is used for Defining settings for IDoc conversion

15. BD56 – This transaction code is used for Maintain IDOC Segment Filters

16. BD59 – This transaction code is used for Allocation object type -> IDOC type

17. BD61 – This transaction code is used for Activate Change Pointers – Globally

18. BD62 – This transaction code is used for Define rules

19. BD64 – This transaction code is used for Maintain customer distribution model

20. BD71 – This transaction code is used for Distribute customer distribution model

21. BD79 – This transaction code is used for Maintain rules

22. BD82 – This transaction code is used for Generate Partner Profiles

23. BD87 – This transaction code is used for Status Monitor for ALE Messages (Real access

path is Tools -> IDoc Interface/ALE -> Administration ->Monitoring -> IDoc Display ->Status

Monitor )

24. BD88 – Outbound IDoc reprocessing

25. BDM2 – IDoc Trace

26. BDM5 – This transaction code is used for Consistency check

27. BDM7 – IDoc Audit Analysis

28. WEDI – This transaction code is used for ALE IDoc Administration

29. SARA – This transaction code is used for IDoc archive administration

30. BALE – ALE Distribution Administration

IDOC Reprocess reports

We can reprocess IDoc if we are getting errors. Several standard reports are available for this

reprocessing. Here are some standard reports for reprocessing of IDOC.

Report RBDMANI2

We can execute this program for manual reprocess of IDOC.It can be used when we get the status

51 or status 63 errors for an inbound IDOC.

Report RBDMANIN

It used for Posting of inbound IDocs with Status 51.

Report RBDMOIND

It checks whether the communication with tRFC was successfully completed. If successfully

completed, the status of the IDoc is changed. This reprocess program can be used for outbound

IDOC with status codes from 03 to 12.

Report RSEOUT00

For reprocessing outbound IDOC with status 30

Report RBDAPP01

For reprocessing inbound IDOC with status 64

Report RBDAGAIN

It for reprocessing of incorrect outbound IDOC with statuses 02, 04, 05, 25 and 29

Report RBDAGAI2

It for reprocessing of IDOCs after ALE input error with statuses 56, 61, 63 and 65

Report RBDAGAIE

It for reprocessing of Edited IDOCs with status 32 and 69

IDOC STATUS CODES:

After the process of inbound function module and outbound function module the state of status will

be recorded in the status record of IDOC.We can view the status by using transaction codes WE02,

WE05 and WE07.Here is the list of main IDOC stats codes for Outbound and Inbound IDOC.

Outbound IDOC status codes with status [...]

SAP LSMW Tutorial with Steps to create

The full form of LSMW is Legacy System Migration Workbench. As the name specifies it’s a tool in

SAP for migrating the legacy data to SAP system.LSMW is the transaction code used to start.

Commonly used importing technology in LSMW are

Direct Input method

Batch Input Recording

BAPI Method

IDOC method

In this tutorial we describes about the steps involved in creating an LSMW project for migrating the

legacy data.

In LSMW we are doing the things in a step by step procedure and the next step screen will be

automatically displayed after very step. Here are the steps involved in LSMW.

Here is the screen shot of LSMW initial screen

Step 1: Maintaining Object Attributes

Here we are specifying about the project, subproject, object and importing technology (like batch

input, IDOC etc.)

Choose maintain object attribute from the LSMW steps screen

Choose Change

Specify the Object

Specify the nature of data transfer that one time or periodic.

Select the object type and import technique.

Step 2: Maintaining the source structures

Here we define the structure of source.

Choose maintain the source structure from the LSMW steps screen

Choose Change

Point your mouse on Source Structures

Choose Create Structure

Enter the name and description for the structure

Choose Continue

Step 3: Maintaining Source Fields

After the creation of structure in step 2, in this step we are going to define each field in that structure.

Choose maintain source fields from the LSMW steps screen

Choose Change

Point your mouse on the Source Structure where we are going to add fields.

Choose Create Field.

Enter the field name, text, length and type

Choose Continue

Step 4: Maintaining Structure Relationship

Here we specify the relationship between the SAP structures and the source structures created in

step 2.

Choose maintain structure relationship from the LSMW steps screen

Choose Change

Point your mouse on the SAP structure ID.

Choose Relationship.

Point your mouse on the corresponding source structure.

Choose Continue

Choose check for finding any errors in relationship.

Step 5: Maintaining Field mapping and Conversion Rules

The mapping between SAP structure fields and source structure fields, and conversion rule is

specifying in this step. Instead of manual mapping, auto field mapping option is also available.

Choose maintain field mapping and conversion rule from the LSMW steps screen

Choose Change

Choose extras -> auto field mapping

Choose the appropriate options

Step 6: Maintaining Fixed Values, Conversions and User-Defined Routines

Specifying the conversion rules for processing data. Here we specify the fixed values etc.

Choose maintain field mapping and conversion rule from the LSMW steps screen

Point the mouse on the field where we want to add rule

Choose insert rule

The rules list will display. Select the rule.

Set the indicator

Choose Continue

The normal available rules are

1. Initial

2. Constant

3. Transfer (MOVE)

4. Fixed Value (Reusable)

5. Translation (reusable)

6. Prefix

7. Suffix

8. Concatenation

9. Left trim

10. ABAP coding

11. User-defined routine

Step 7: Specifying files

In this step we will specify the files used for the migration.

Choose Specifying the files from the LSMW steps screen

Enter file name, description and other settings

Step 8: Assigning files

Here we assign the specified files to the corresponding source structure.

Choose Assign files from the LSMW steps screen

Choose change

Point the mouse on a structure

Choose Assign file

Select the corresponding file

Press Continue

Step 9: Importing Data

In this step press execute to read the data from source.

Step 10: Displaying Imported Data

In this step choose continue to display the data that has been read.

Step 11: Converting Data

In this step choose execute to transfer the read to the file of converted data.

Step 12: Display Converted Data

In this step choose execute to display the converted data.

Depending on the importing technology specifies in step 1. The next steps may have.

Step 13: Create batch input session

Step 14: Run batch Input Session.

OR

Step 13: Starting IDOC generation

Step 14: Starting IDOC processing

Step 15: Create an IDOC overview

Step 16: Start IDOC post processing

You will get more details about batch Input Session and IDOC in our other tutorials.

SAP BDC Tutorial The full form of BDC is Batch Data Communication. It’s a technique in SAP used for mass input of

data or uploading data into SAP system (If particular BAPI is not available).BDC also known as

Batch Input. There are two types of BDC are there

Call Transaction Using (using CALL TRANSACTION statement)

Batch Input Session (using BDC_OPEN_GROUP, BDC_INSERT and

BDC_CLOSE_GROUP function modules)

ABAP programming is requires for any BDC methods. First we need to record a transaction and then

embed this recording in our ABAP program. Then we will run this using Call Transaction using or BI

session method.

CALL TRANSACTION USING:

This is the fastest method to transfer data.

Syntax:

CALL TRANSACTION <tcode>

USING <bdc_tab>

MODE <mode>

UPDATE <update>

Main Display Modes used

A: Display all

E: Display Errors only

N : No Display

Main Updates modes

S: Synchronous

A: Asynchronous

L : Local Update

While we doing CALL TRANSACTION USING method, first we will create a structure BDCDATA for

the transaction. This structure is used in the USING addition of the CALL TRANSACTION statement.

Batch Input Session

In this method data is stored in a batch input session and later run this session. Here is the process

flow of BI session method.

Use BDC_OPEN_GROUP function module to create a BI session.

BDCDATA structure, enter the value for all screens and fields that must be processed in the

transaction

Use BDC INSERT function module to transfer the transaction and the BDCDATA structure to

the session

Use BDC_CLOSE_GROUP function module to close the batch input session.

Now this session will be in a batch input queue and we need to process it. The session processing

can be two types

Manually using the batch input menu options (SM35 transaction).

Use RSBDCSUB program to run the session in background.

http://www.freesaptutorial.com/category/smartforms/

What is Smartforms and its advantages

SAP Smartform is a replacement solution for using SAPScripts. Smart Forms requires only half of

the time for creating or maintaining the forms. We can create the forms without any programming

skills. A good graphical interface is provided to create the forms. It supports fax, email, printer and

internet as output Medias. When activating a smart form system creates a function module for this

and this function module will process at run time. The program for data retrieval will pass the data to

this function module. The smart form contains the entire form logic. Migrations from SAPscripts to

Smart forms are also supported. A form painter tool and table painter tool are used for designing the

page and table layout respectively. We can do drag and drop, cut and paste while creating the

forms. We can insert static and dynamic tables in forms. It also supports the usage of images.

Structure of a Form

A form contains pages, output areas (called windows), address, graphics and text data etc. In pages

we specify the page layout and other general settings for the page. Windows are the output areas in

a page. There are several types of windows used in a form page.

Main Window: Contains the main continuous data and supports page break.

Secondary window: Output the data in a fixed size area.

Final Window: A special type of secondary window used for output the data available only at

the end of form processing

Copies Windows: A special type of secondary window used for marking the pages as copy

or original.

We can use only one window as a main window in a form. It will have the same width in all pages. Its

height can differ.

To call the Smart forms initial screen we can use the transaction code SMARTFORMS.

It contains a SAP Form builder to maintain a smart form, style builder to maintain form styles (can

use the transaction code SMARTSTYLES) and text module maintenance (to create or modify

reusable text).Sap form builder contains.

Form painter

PC editor

Navigation Tree

Table painter

Form Check

The supported Output formats for Smartforms are

OTF: It’s the commonly used format for printing the forms.

XSF: XML scheme contains the form contents without layout information

HTML: It’s containing the XSF with layout information ( for mainly interactive web forms).

XDF: XML scheme containing only the application passed data.

SAP is a German Enterprise Application Software development company founded in 1972.The name

SAP stands for “Systems, Applications and Productions in Data Processing”. The company has

spread over 50 countries and has more than 109000 customers.

SAP software Products

SAP ERP is the main product of the company which focused on Enterprise Resource Planning. SAP

ERP coming with SAP Business Suite enterprise software.

SAP Business Suite contains the following five major applications.

1. SAP CRM (Customer Relationship Management)

2. SAP ERP

3. SAP PLM (Product Lifecycle Management)

4. SAP SCM (Supply Chain Management)

5. SAP SRM (Supply Relationship Management)

Other major Enterprise Solutions are

SAP Manufacturing

SAP Service and Asset Management

Alloy

Duet ( It’s joint offering with Microsoft)

Duet Enterprise

Mobility solutions

SAP BusinessObjects analytic solutions

SAP BusinessObjects business intelligence solutions

SAP BusinessObjects GRC solutions (Governance, Risk and Compliance)

SAP BusinessObjects EPM solutions

SAP Crystal solutions

SAP solutions for auto-ID and item serialization

SAP solutions for enterprise information management

SAP solutions for sustainability

Solution extensions

SAP Business One and Crystal solutions are some of the products for small size and mid size

companies. The company also provides on demand and other rapid deployment solution products.

SOA (Service-oriented architecture), SAP NetWeaver technology platform, In-Memory Computing

technology and SAP BusinessObjects portfolio are the technologies and platforms provided by SAP

for making the companies to implement and running the solutions faster and cost effective way.

SAP is having a three tier architecture congaing Presentation Server, Application Serve and

Database Server. The more details about this architecture cam be found in our later posts.ABAP and

Java are the programming languages used in SAP for customization ad other modification works as

per the user requirement. You will get more details about that in our tutorials.

There are several companies for implementing SAP for the companies planning to use their

products. Trained SAP professionals are required for doing this job. The company also provides

certification based on exams for the professionals.

Transaction codes

VS00: Tcode for Master data

VC00: Tcode for Sales Support

VA00: Tcode for Sales

VL00: Tcode for Shipping

VT00: Tcode for Transportation

VF00: Tcode for Billing

See the other transaction codes

VA01, VA02 and VA03: Create , change and display order respectively.

VA05: List of sales orders

VA21, VA22 and VA23: Create, change and display quotations

VD01, VD02 and VD03: Create , change and display customer respectively.

XD01, XD02 and XD03: Create, Change and display customer respectively.

VA11, VA12 and VA13: Create , Change and display inquiry respectively.

VL01: Create outbound delivery with ref sales order

VL04: Collective processing of delivery

VF02: Change billing document

VF11: Cancel Billing document

VF04: Billing due list

VL02N: Change delivery document

VL04: Delivery due list

VKM5: List of deliveries

VL06G: List of outbound deliveries for goods issue

VL06P: List of outbound deliveries for picking

VL09: Cancel goods issue

VT02N: Change shipment

VT70: Output for shipments

FBL5N: Display Customer invoices by line

FBL1N: Display Vendor invoices by line

VKM3, VKM4: List of sales documents

VKM1: List of blocked SD documents

VD52: Material Determination

VOV8: Define Sales documents type (header)

OVLK: Define delivery types

V/06: Pricing

CREDIT CHECK CONFIG REPORTS:

Using a test environment that is due for a refresh I run into credit limits when entering sales

orders more than often. Manipulating the credit check for a customer in FD32 is not always

sufficient. The following reports also are useful (if not essential):

RVKRED06 - Background jobs for checking blocked credit management.

If an order is no longer outside the horizon as defined in the dynamic credit check, (i.e. it is

INSIDE the horizon) it can cause existing “good” orders to block. If you run this job every night,

if you have your horizon set for 1 month it can cause a lot of blocks at beginning of month. Try

to use „W‟ for weekly horizon status.

RFDKLI10 – Customers With Missing Credit Data

RFDKLI20 – Reset Credit Limit for Customers

RVKRED77 – Reorganize SD credit data

When updating errors occur, it enables you to reorganize the open credit, delivery and billing

document values.

RVKRED08 – Checking sales documents which reach the credit horizon

You should runs this report periodically, usually at the start of a period. The report checks all the

sales documents, which reach the dynamic credit check horizon. The period for the „date of the

next credit check‟ is proposed from the current date, with the help of the period split for open

sales order values