‎2007 Apr 10 11:58 AM
Please send me the flow of SD cycle in ABAP and linking between SD transparent tables.
‎2007 Apr 10 12:01 PM
Hi Sunny,
Check this info.
Process Summaries
Create Sales Order
1. Use Transaction Code VA01
2. Identify Sales Office
3. Enter Sold-to-party (customer) and purchase order number and date if applicable
4. Enter material, quantity and rate
5. Credit income to account (Internal Order or WBS element)
6. Enter partner (University contact details)
7. Save Sales Order
Create Billing Document
1. Directly after saving the Sales Order, follow the path Sales document> Billing.
2. Save the billing document
Other than as a follow-on function
1. Use Transaction Code VF01
2. The sales order number will default in check that it is correct
3. Save the Billing document
Print a Billing document immediately
1. Use transaction code VF03
2. Enter the Billing Document number.
3. Follow path Issue Output to > Printer
4. Click on execute twice
5. To preview, follow the path Issue Output to > Screen and click on execute twice to view
Document Flow
1. Use transaction code VA03 (Sales Order/Credit Memo or VF03 (Billing document) or
2. Follow the path Environment > Document Flow
3. Enter the document number
4. Click on the document overview icon
Common Transaction Codes
Create Sales Order VA01
Create Credit Memo VA01
Change Sales Order VA02
Display Sales Order VA03
List Sales Order VA05
Create Billing Doc VF01
Display Billing Doc VF03
Cancel Billing Doc VF11
Print Billing Doc VF03
Check out the following links for further information
http://www.sap-basis-abap.com/sapsd.htm
http://www.mhprofessional.com/product.php?isbn=0072124040&cat=&promocode=
http://www.leeds.ac.uk/infosystems/hr_finance/superusers/SDREF.DOC
http://www.sap-basis-abap.com/sd/sap-sd-processing-flow.htm
Hope this resolves your query.
Reward all the helpful answers.
Regards
‎2007 Apr 10 12:01 PM
Hi Sunny,
Check this info.
Process Summaries
Create Sales Order
1. Use Transaction Code VA01
2. Identify Sales Office
3. Enter Sold-to-party (customer) and purchase order number and date if applicable
4. Enter material, quantity and rate
5. Credit income to account (Internal Order or WBS element)
6. Enter partner (University contact details)
7. Save Sales Order
Create Billing Document
1. Directly after saving the Sales Order, follow the path Sales document> Billing.
2. Save the billing document
Other than as a follow-on function
1. Use Transaction Code VF01
2. The sales order number will default in check that it is correct
3. Save the Billing document
Print a Billing document immediately
1. Use transaction code VF03
2. Enter the Billing Document number.
3. Follow path Issue Output to > Printer
4. Click on execute twice
5. To preview, follow the path Issue Output to > Screen and click on execute twice to view
Document Flow
1. Use transaction code VA03 (Sales Order/Credit Memo or VF03 (Billing document) or
2. Follow the path Environment > Document Flow
3. Enter the document number
4. Click on the document overview icon
Common Transaction Codes
Create Sales Order VA01
Create Credit Memo VA01
Change Sales Order VA02
Display Sales Order VA03
List Sales Order VA05
Create Billing Doc VF01
Display Billing Doc VF03
Cancel Billing Doc VF11
Print Billing Doc VF03
Check out the following links for further information
http://www.sap-basis-abap.com/sapsd.htm
http://www.mhprofessional.com/product.php?isbn=0072124040&cat=&promocode=
http://www.leeds.ac.uk/infosystems/hr_finance/superusers/SDREF.DOC
http://www.sap-basis-abap.com/sd/sap-sd-processing-flow.htm
Hope this resolves your query.
Reward all the helpful answers.
Regards
‎2007 Apr 10 12:03 PM
hi,
sd cycle is:
order(va01)->delivery(vl02n)->billing(vf01)->excise(j1iin).
Links are:http://www.erpgenie.com/abap/tables_sd.htm
i think this might help u.
Regards
Santosh.
‎2007 Apr 10 12:03 PM
‎2007 Apr 10 12:03 PM
Hi,
Cycle:
EnquiryQuotationSales OrderDelivery(Picking, Packing, Post Goods
Issue and Shipment)Billing Data to FI
TABLES and Important Fields:
VBAK: Sales Document(Header Data) (VBELN)
VBAP: Sales Document(Item Data) (VBELN,POSNR,MATNR,ARKTX,CHARG)
Enquiry, Quotation, Sales Order are differentiated based on Doc.
Type(VBTYP field) in VBAK,VBAP Tables( for Enquiry VBTYP = A,
for Quotation 'B' & for Order it is 'C'.)
LIKP: Delivery Table (Header Data)(VBELN,LFART,KUNNR,WADAT,INCO1)
LIPS: Delivery Table (Item Data)(VBELN,POSNR,WERKS,LGORT,MATNR,VGBEL)
(LIPS-VGBEL = VBAK-VBELN, LIPS-VGPOS = VBAP-POSNR)
VTTK: Shipment Table (Header Data)(TKNUM)
VTTP: Shipment Table (Item Data)( TKNUM,TPNUM,VBELN)
(VTTP-VBELN = LIKP-VBELN)
VBRK: Billing Table(Header Data)(VBELN,FKART,BELNR)
VBRP: Billing Table(Item Data)(VBELN,POSNR,FKIMG,NETWR,VGBEL,VGPOS)
(VBRP-AUBEL = VBAK-VBELN, VBRP-VGBEL = LIKP-VBELN)
Apart from these tables there are lot of other tables which starts with
V, but we use the following tables frequently.
VBUK: All Sales Documents status & Admn. Data(Header)(VBELN,VBTYP)
VBTYP= C(Sales Order) VBTYP=J(Delivery) VBTYP=M(Invoice)
VBUP: Sales Documents status & Admn. Data(Item)(VBELN,POSNR)
reward points if useful
regards,
ANJI
‎2007 Apr 10 12:05 PM
hi...
Application Development Process
In this section, we will:
<u><b>Planning Phase</b></u>
Some of the most important artifacts in the planning phase are as follows:
SyncBOs required in the application are identified and verified that they can be mapped to the business objects in a backend system as well as they are sufficient to realize the client-side requirements
Client GUI design and navigation model are determined and agreed by the stakeholders
Use cases covered in each iterative cycle in the implementation phase are determined
One of the key decisions in the planning phase is to identify the business objects in the backend system and to decide how they are represented in the client application. Since one of the core functions of an Smart Sync application is that the business objects updated on a client device is successfully uploaded to a backend system and vice versa, it is very important to identify which business object in a backend system can be used and to identify the dependencies of the business objects on other objects. The identification of the business objects is typically followed by the identification of existing BAPIs. Then, it is necessary to identify the header and item structures of each object.
On the client side, the same business object identification process is required based on the requirements. It is especially important to identify whether the downsized or merged version of the business objects in a backend system can be used.
In most cases, BAPI wrappers are responsible for absorbing the differences between the client-side business objects and those in a backend system. However, if they are greatly different, it should be carefully investigated whether BAPI wrappers can really absorb the differences.
Since the GUI requirements of client applications can differ greatly from an application to another depending on the target application users, it is advisable to conduct a preliminary usability test with potential users of the application and to agree on the GUI design and navigation model used in the application as early as possible.
Finally, before moving on to the first development cycle, it is worth planning which use cases will be covered in each development cycle (For more information, refer to Iterative / Use Case Driven Development).
<u><b>Implementation Phase</b></u>
In each development cycle in the implementation phase, the client- and server-side components can be developed in parallel. However, it is important to be aware of the following dependencies:
To finalize the SyncBO access logic in the client application, the definition of SyncBOs needs to be completed, and the changes in SyncBO definition can affect the client SyncBO access logic
When SyncBOs are defined and BAPI wrappers are implemented, sample data from a backend system can be used for client application standalone testing; before that, test data must be created within the test code of the client application
For efficient parallel development, therefore, it is important to plan the activities accordingly taking these dependencies into account.
<u><b> Test / Deployment Phase</b></u>
At the end of each development cycle, it is important to conduct the integration/synchronization test, which should include the following:
Synchronization performance benchmark with various data volume
Performance benchmark of the client application on a target client device
Application deployment test
Performing the integration/synchronization test at the end of each development cycle is beneficial because it makes it possible to identify issues and risks that should be addressed in the next development cycle.
After the completion of all the development cycles and testing, SyncBOs and BAPI wrappers are moved to the production system and an installation package of the client application is put in a Mobile Infrastructure server for automatic deployment to client devices.
Iterative / Use Case Driven Development
It is rarely the case that the first plan remains unchanged throughout the entire development cycle, no matter how thoroughly the planning is conducted. Thus, as widely recommended in modern software development process, the iterative and incremental development is one of the key factors also for a successful Smart Sync application development. For an effective iteration, the following can be applied:
Cover only a couple of high-level use cases in each development cycle starting with the least dependent ones
<b>Example</b>
Suppose that it is identified that customer business object is not dependent on other main business objects although it uses country and region business objects. Suppose also that sales order business object refers to customer business object.
Then, the first cycle might cover only customer business object and related ones such as region and country objects, and not sales order business object. Furthermore, the first cycle might just concentrate on the display of customer list and detail use cases, and the creation of a customer use case might be covered in a later cycle.
Plan each development cycle to be completed in a relatively short time period, for example, in less than or equal to 3-4 weeks
Conduct integration/synchronization test at the end of each development cycle
Refine the schedule and the design based on the issues and risks identified in the previous cycle as well as the changes in the requirements (change management)
The benefits of such an iterative approach is as follows:
Makes it possible to identify and tackle issues/risks earlier in the development life cycle such as architecture risks and performance bottlenecks
Reduces the integration risks at the very end of the implementation phase
Allows continuous quality improvements and facilitates identification of reusable components
Makes it easy to keep track of the progress and to adjust the schedule
Makes it possible to demonstrate the application from an earlier phase of the application development, which makes it easy to get feedbacks from the stakeholders and incorporate them in the application
Allows the participation of technical writers and testers earlier in the implementation phase
Allows application developers to gain skills/knowledge required in various aspects of the development relatively quickly
Allows the process improvements over the iterative cycles
Server-side Application Development Process
The keys of the server-side development are as follows:
BAPI wrappers (function modules) implemented in the target backend system
SyncBOs defined in Smart Synchronization, which includes the generation of the runtime components
The table below describes the skills/knowledge and tasks required:
Target System
Skill / Knowledge Task
Web AS 6.20 Smart Sync SyncBO builder Defining SyncBOs (parameter settings)
Backend SAP system Backend application knowledge (inc. BAPIs available), ABAP BAPI wrapper (ABAP function module) development
In the planning phase, it is important to identify the business scenario and the business objects required, which is followed by the identification of appropriate BAPIs available in the target backend system. It is important to agree on how the identified business objects are represented in the client application. If the business objects used in a backend system are very different from ones in client devices, BAPI wrappers may need to absorb the differences. This can be done also on the client-side application; however, it is often the case that it is less effective to do that.
In the implementation phase, ABAP programming is required for each BAPI wrapper, and SyncBOs need to be defined using the SyncBO Builder. The SyncBO Builder will generate the runtime component (synchronizer) for each SyncBO. Then, using the SyncBO Builder, it is also necessary to generate the so-called meta-data XML, which is referenced by a client application that accesses the SyncBOs defined.
Often, it is a useful approach to define a SyncBO as soon as possible when BAPI wrapper interfaces are defined and activated for the SyncBO but before implementing the logic in BAPI wrappers. This makes it possible to generate a meta-data XML, which is often referenced during developing SyncBO access logic of a client application.
In the testing phase, the synchronization test needs to be performed. Finally, in the deployment phase, the BAPI wrappers and SyncBOs are transported to the target production systems.
The diagram below describes the simplified process of the server-side application development and where the details are covered in this cookbook:
For details of BAPI wrapper development, refer to BAPI Wrapper Development.
For details of defining SyncBO, refer to Defining Synchronization Business Object (SyncBO).
Client-side Application Development Process
The key deliverable of the client-side application development is a compiled JSP/AWT application in an archive file such as a .war/.jar file.
The skills/knowledge required for the client application development are JSP/AWT application development skills as well as the business requirements of the client application.
The client-side application development is not different from a normal JSP/AWT application development. One of the differences is, however, that the data access is performed using Smart Sync APIs.
Some of the important considerations in the client application development are as follows:
Apply Model-View-Controller design pattern, which is a popular approach of a JSP/AWT application, if the application is reasonably complex
In most cases, Smart Sync APIs should be called only within BO classes in the Model layer for reusability such as replacing the View layer with another.
Always keep in mind that PDAs are different from PCs, even if the software technology looks the same as the technology of PCs
Pay attention particularly to memory consumption and performance, and conduct the performance test on a target client device from an early phase of the development
Decide the GUI design and flows of the application as early as possible
Plan development activities taking the availability of meta-data XML, which defines the client view of the SyncBOs, into account
Develop a build script so that the standalone and integration tests are conducted frequently .
or u can visit the link
<b>plz reward pts if helpful.</b>
regards
vijay
‎2007 Apr 10 12:36 PM