SPEC-India

 Advantages

1.  Clean application code— Application code that is replete with data access details is difficult to read and maintain. Application logic tends to become obscured by the many calls necessary to do even simple database calls. When an application uses a well-designed data accessor abstraction that exposes logical database operations, its code can focus more on its own business logic.
2.  Incorporation of optimization strategies— Data access code usually is a primary analysis focal point when tuning an application’s performance. Data access code is a common bottleneck source and simple optimizations often have significant effects. When data access code is spread across a system, it requires much more effort to apply and measure optimizations because you must repeat their implementations multiple times. When you encapsulate all physical data access code within a data accessor implementation, you can incorporate an optimization strategy once and it immediately applies across the entire system.
3.  Adoption of new database features or platforms— When physical data access code is spread throughout a system, it is hard to add support for new features or platforms because it involves searching the entire code base and replacing or adding new calls where necessary. This process is tedious and error-prone. When a data accessor implementation encapsulates physical data access code, you only have one isolated component to enhance.
4.  Swappable physical data access implementations— You can swap among multiple data accessor implementations without changing application code. This enables you to conveniently support multiple, diverse database platforms and technologies.

 Disadvantages

1.  Limits application control of data access— Application code is limited to the logical operations defined by a data accessor abstraction. When a data accessor abstraction is not well-designed or versatile enough for an application’s data access requirements, the application code may resort to unnatural or awkward workarounds that ultimately lead to unexpected results.

 Complete:  SRS defines precisely all the go-live situations that will be encountered and the system’s capability to successfully address them.

 Consistent: SRS capability functions and performance levels are compatible, and the required quality features (security, reliability, etc.) do not negate those capability functions. For example, the only electric hedge trimmer that is safe is one that is stored in a box and not connected to any electrical cords or outlets.

 Accurate:  SRS precisely defines the system’s capability in a real-world environment, as well as how it interfaces and interacts with it. This aspect of requirements is a significant problem area for many SRSs.

 Modifiable:  The logical, hierarchical structure of the SRS should facilitate any necessary modifications (grouping related issues together and separating them from unrelated issues makes the SRS easier to modify).

 Ranked: Individual requirements of an SRS are hierarchically arranged according to stability, security, perceived ease/difficulty of implementation, or other parameter that helps in the design of that and subsequent documents.

 Testable:  An SRS must be stated in such a manner that unambiguous assessment criteria (pass/fail or some quantitative measure) can be derived from the SRS itself.

 Traceable:  Each requirement in an SRS must be uniquely identified to a source (use case, government requirement, industry standard, etc.)

 Unambiguous:  SRS must contain requirements statements that can be interpreted in one way only. This is another area that creates significant problems for SRS development because of the use of natural language.

 Valid:  A valid SRS is one in which all parties and project participants can understand, analyze, accept, or approve it. This is one of the main reasons SRSs are written using natural language.

 Verifiable:  A verifiable SRS is consistent from one level of abstraction to another. Most attributes of a specification are subjective and a conclusive assessment of quality requires a technical review by domain experts. Using indicators of strength and weakness provide some evidence that preferred attributes are or are not present.

1 Your software system is professionally designed and documented before it is coded.   You will know exactly what you are getting, in advance. 
2 Since system design comes first, reusable code is easily spotted and coded with the highest efficiency.  You will have lower development costs. 
3 Logic ‘holes’ can be spotted in the design drawings.  Your software will behave as you expect it to.  There are fewer surprises. 
4 The overall system design will dictate the way the software is developed.  The right decisions are made before you are married to poorly written code.  Again, your overall costs will be less. 
5 UML lets us see the big picture.  We can develop more memory and processor efficient systems.  
6 When we come back to make modifications to your system, it is much easier to work on a system that has UML documentation.  Much less ‘relearning’ takes place.  Your system maintenance costs will be lower. 
7 If you should find the need to work with another developer, the UML diagrams will allow them to get up to speed quickly in your custom system.  Think of it as a schematic to a radio.  How could a tech fix it without it? 
8 If we need to communicate with outside contractors or even your own programmers, it is much more efficient. 

SAP Sales and Distribution allows the user to execute different business transactions based on sales documents defined in the system.

SAP differentiates sales documents into four major groups as below:
o Customer Inquiries and Quotations
o Sales Orders
o Outline Agreements, such as contracts and scheduling agreements
o Complaints, such as free of charge deliveries, credit and debit memo requests and returns

SAP Sales and Distribution Processing Document Flow

The sales documents are individual documents,  but they can also form part of a chain of inter-related documents. For example, a customer’s telephone inquiry may be recorded in the system. The customer next requests a quotation, which can be  created by referring to the inquiry. The customer later places an order on the basis of the quotation can be  created as a sales order with reference to the quotation. The goods would then be shipped and billed to the customer. After delivery of the goods, the customer claims credit for some damaged goods and a free-of-charge delivery with reference to the sales order is created. The entire chain of documents – the inquiry, the quotation, the sales order, the delivery, the invoice, and the subsequent delivery free of charge – creates a document flow or history. The flow of data from one document into another reduces manual activity and makes problem resolution easier. Inquiry and quotation management in the Sales Information System helps in planning  and control of  sales.
Each of these sales documents are explained in brief in the following sections.

Customer Inquiry / Quotation

Customer Inquiry is a customer’s request to a company to provide a quotation or sales information without obligation. An inquiry can relate to materials or services, conditions and if necessary delivery dates. The sales area that accepts the inquiry becomes responsible for further processing.

A quotation presents the customer with a legally binding offer for delivering a product or services within certain fixed conditions. This offer is legally binding for the company within a specified time period. A sales area can reply to a customer inquiry with a customer quotation or use it to refer to a business partner contact.

SAP supports pre-sales business processes in the system using the inquiries and quotations functions. Customer inquiries and quotations to the customer can be entered and monitored is the system.

Sales Order

Sales Order is a request from a customer to a company to deliver a defined quantity of products or services at a certain time. The sales area that accepts the inquiry is responsible for completing the agreement. The sales order is a contractual agreement between a sales organization and a sold-to party about delivering products or providing a service for defined prices, quantities and times.

In the sales order, functions such as pricing and printouts are available. The system checks whether the material is available for the requested delivery date and if necessary, transfers the requirements to materials planning. Shipping deadlines and shipping points are determined in delivery scheduling.  Credit limit checking is also performed.

Scheduling Agreements

Scheduling agreements are outline agreements with the customer specifying delivery quantities and dates. These are then entered as schedule lines in the delivery schedule. The user can either create schedule lines when the scheduling agreement is created or can create them later to an existing scheduling agreement.

Scheduling agreements are fulfilled by creating the deliveries as per the delivery schedule. Deliveries are processed a scheduling agreement in exactly the same way as normal delivery is processed. After the delivery, the system updates the delivered quantity field in the scheduling agreement item with the delivery quantity.

Processing scheduling agreements has the same functions as sales order processing, including pricing and availability checks.
 

Customer Contracts

Customer contracts are outline customer agreements that display when sales materials or services to be sold within a certain time period. Customer contracts are of various types:

o Master Contracts
Master contract is a document that allows the user to group contracts together as lower level contracts. Thus, all the data that refers to other documents remains consistent. The master contract contains the general terms which apply for all lower level contracts.

o Quantity Contracts
Quantity contract is an agreement that the customer will order a certain quantity of a product during a specified period. The contract contains basic quantity and price information, but does not specify delivery dates or quantities.

o Value Contracts
Value contract is a contractual agreement with a customer that contains the materials and/or services that they may receive within a time period and up to a specified target value. Value contract can contain certain materials or a group of materials (product hierarchy or assortment module).

o Service Contracts
Service contract is an agreement that contains the conditions for offering a certain service to the customer e.g. rental and maintenance contracts. A service contract contains validity dates, cancellation conditions, price agreements, and information on possible follow-up actions.

Complaints

Complaints can be of the following types :

o Free of Charge Deliveries.
Although these are not complaints, they are offered as part of this component. A free-of-charge delivery is used to send a customer a free sample of products. As the system cannot create a delivery without a sales document, so the user has to create sales document type for free of charge delivery.

o Free-of-Charge Subsequent Deliveries
If the customer complains (for example, that they received the wrong quantity) the user can send them the extra material later free of charge. This free-of-charge subsequent delivery always refers to a sales order.

o Returns
If the customer complains, for instance, that the goods were faulty, and organization takes the goods back to check them. Once the goods are checked, the user can implement one of the following activities:
o Send the customer a credit memo
o Make a subsequent delivery of the goods, free of charge
o A return is a sales document used in complaints processing for when a customer sends good back.
o Enter a return in the system if the customer returns damaged goods, or goods that had been delivered for sale on approval.
o The return causes the system to:
o Register the receipt of goods using a returns delivery, and post the goods to stock (for example, blocked stock).
o Create a credit memo, once the user has checked the goods and approved the complaint.

o Credit Memo Requests
If the customer complains that the price was miscalculated (for example, too high) then a credit memo for the appropriate sum can be issued instead of taking the goods back.  A credit memo request is a sales document used in complaints processing to request credit for a customer. The credit memo request can be automatically blocked for checking. Once it has been approved, the user can remove the block.

o Debit Memo Requests
If prices were calculated as too low, the user requests a debit memo. A debit memo request is a sales document used in complaints processing to request debit for a customer. The debit memo request can be automatically blocked for checking. Once it has been approved, the user can remove the block.

The user can enter a credit or debit memo request in one of the following ways:
o Without reference to a preceding document
o With reference to a preceding document, such as:
* Sales orders
* Contracts
* Contract release orders
* Billing documents

o Invoice Correction Requests
The invoice correction request works in the same way as credit and debit memo requests, but here the user enters the price or quantity that should have been calculated. The system then calculates the difference and creates either a debit or a credit memo, depending on whether the difference is negative or positive.

When the user creates an invoice correction request, reference must be made to an available billing document (invoice).

All complaints can be approved or rejected. Once a complaint has been approved, the user can create either a credit or debit memo, depending on the type of complaint. If the user rejects a complaint, a reason can be specified for the rejection and this can be used as selection criteria for listing complaints.

The ability to deliver the right product to the right place at the right time is the core of your business.  Inventory is one of the largest investments that any company makes.  Ensuring, that you have enough of the right product in stock, while avoiding stock-outs and over stocks is a daily challenge.  You are responsible for reducing investment in inventory and increasing inventory turns. An automated Inventory Management System, helps you in managing this challenge.
Inventory Management system allows you to manage stocks on a quantity and value basis in order to plan, enter, check goods movements and carry out physical inventories. They provide inventory management with dimensions and provide complete visibility on the quantity, location, and status of inventory flowing in and out of a location or multiple warehouses.
Inventory Management systems are tightly integrated with Financial Accounting systems for the pricing of each inventory transaction voucher, with the order management system for the customer and internal orders, shipment notes etc. and with other sales and demand forecasting systems for item planning.  Bar Coding and RFID interfacing is also a highly desired feature.
Features of the Inventory Management System :
* Forecasting :  Create Inventory forecasts by  matching supply with customer demand. 
* Auto create purchase orders for reorder point items
* Maintain Item Dimension : 
 o Characterize items by using multiple dimensions like  configuration, size,  color etc.
 o Maintain business logic based on  valid combinations of dimensions
* Maintain Storage Dimension : 
 o Describe storage by using warehouse, pallets and locations
 o Track items using the serial and batch number dimensions
* Placement and Storage policy definition at warehouse and Item level with a provision for multi level storage specification e.g. warehouse, aisle, rack, shelf and bin
* On-hand Inventory Tracking
 o Warehouse-wise on-hand inventory
 o Drill down using Item dimension / storage dimension
* Quarantine management
 o Set aside items in quarantine and look-up on quarantine inventory
* Inventory Analysis based on user defined limits on revenue, cost value,  margin, carrying cost etc.
 o ABC Analysis
 o HML Analysis
 o PQR Analysis

An Order Management System (OMS) is a software used by many industries to enter and manage the order processing. The OMS normally would be an integrated system supporting the order entry, order management and order delivery.  Preferably this should be a centralized system with on-line updates, so that customers, sales representative, delivery agents are all accessing and updating a single system and up-to-date information is available to all
The orders could come from multiple sources, viz. customer call, fax, e-mail, EDI,  mobile device (salesmen carrying a mobile device),  internet etc.
Order Management would involve : Order search, customer search,  order modification, approval, cancellation, order copy, product search, product substitutes etc.
There could be multiple delivery mechanism viz. Door to Sales, 3PL,  External Carrier,  Customer Pick-up etc.

Another common use of order management software is by eCommerce and Catalog companies. This software facilitates entering of an order, whether via a web-site shopping cart or a data entry system (for orders received via phone and mail). It typically captures Customer Proprietary Information and Account Level information. Credit Verification or Payment processing is done to check for validity and/or availability of funds. Once entered, valid orders are processed for warehouse fulfillment, such  as picking / packing / shipping.
Typical Features of an Order Management System
1. Marketing Information (Catalogs, promotions, pricing)
2. Prospects
3. Vendors (Purchasing and Receiving)
4. Customer Information & Search (Names, addresses, order history, preferences, product catalog, pricing, taxing, credits, promotions, customer bill-to, ship-to, alternate ship-to, support for customer hierarchy etc.)
5. Product Information & Search ( description, attributes detail, inventory information (local warehouse /  remote warehouse locations, quantities, product substitutions, complimentary items, product kits/ groupings)
6. Pricing (rules based: list, cost-up, list-down, specific and general contract, discount, promotion, best price comparison and item/group column/volume)
7. Taxing (Order level or line level jurisdictional sales tax)
8. Billing Terms
9. Credit limit management
10. Order Entry (Sales Order, Quotes, Credit Memos, Special Orders, through EDI)
11. Customer Order History
12. Customer Order Rules and Preferences
13. Order Processing (Selection, Printing, Picking, Packing)
14. Order Delivery ( Multiple shipping methods : external carrier,  customer pick up, 3PL etc.)
15.  Customer Service (Returns & Refunds)
16. Ability to mass update, duplicate orders etc.
17. Data Analysis and Reporting
18. Integration with other required systems like Finance Systems for GL / AP / AR, Warehouse systems for inventory, Logistics Systems for Delivery, Sales Force Automation systems etc.
19. Integration with mobile devices / internet
Typical  Non-Functional Features of an Order Management System
1. User friendly interfaces
2. Adequate security features
3. Adequate Help and documentation

Patterns are usually

• Recurring solutions to common problems of design
• Practical/concrete solutions to real world problems
• Context specific
• “Best-fits” for the given set of concerns/trade-offs
• An effective means of (re)using, sharing, and building upon existing wisdom/experience/expertise

Patterns are not

• Restricted to software design or Object-Oriented design
• Untested ideas/theories or new inventions
• Solutions that have worked only once
• Abstract principles or heuristics
• A “silver bullet” or panacea

Different types of patterns include

• Design Patterns (software design; often object-oriented):

• Architecture (systems design)

• Design (component interactions)

• Analysis Patterns (recurring & reusable analysis models)
• Organization Patterns (structure of organizations/projects)
• Process Patterns (software process design)
• Domain-specific patterns

A design pattern is a proven solution for a general design problem. It consists of communicating classes and objects that are customised to solve the problem in a particular context. . it captures design experience of experienced programmers.

A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them. Thus design patterns make it easier to reuse successful designs and architectures.

Design patterns help us choose design alternatives that make a system reusable and avoid alternatives that compromise reusability. Design patterns can even improve the documentation and maintenance of existing systems by furnishing an explicit specification of class and objects interactions and their underlying ‘intent’.

In short design patterns help a designer to reuse the existing patterns the way we use the source code library.

• A class may inherit several interfaces but only one abstract class.

• An interface cannot provide any code, just the signature. An abstract class can provide complete, default code and/or the details that have to be overridden.

• An interface cannot have access modifiers for the attributes and operations (all are public). An abstract class can contain access modifiers for the attributes and operations

• No fields can be defined in interfaces. An abstract class can have fields and constrants defined

• If various implementations only share method signatures then it is better to use Interfaces. If various implementations are of the same kind and use common behaviour or status then abstract class is better.

• If various implementations only share method signatures then it is better to use Interfaces.  If various implementations are of the same kind and use common behaviour or status then abstract class is better to use.

A model that describes a system’s functional requirement in terms of use cases.  The use case model seves as a contract between the customer and the developer

Use case model gives a static view of the system functions and their static relationships both with external entities and with one another.

It is a functional model which provide description of a system’s behaviour from users standpoint by answering the following questions.

• What functions does the system offer?
• What external agents interact with the system?
• In what functions are those external agents involved?

Use case diagrams illustrate the relationship between actors and use cases

Use Case model is very useful for capturing the functional requirements.