New Features:

• Reorganized architecture of AJAX communication to get rid of all the redundant calls to server.
  Now amount of requests the same as in core version of one page checkout, in some cases even less requests.
• Implemented indicator of submitting of data, that is shown as bg part of “Place Order” button.

Improvements:

• Separated contents of checkitout.js file into different files for not loading redundant JS files.
  In case if you modified checkitout.js file, make diff of original supplied for your versionand place your changes into separate file according to the guidelines in the following article: http://www.ecomdev.org/2012/11/29/magento-checkout-extension-ideas-architecture-revealed.html
• Added events for checkout onepage proxy
• Added events for preloaded steps json generation in js block

Bug Fixes

• Save billing address with “use_for_shipping” flag was leading to override of totals

Demo Installment

You can try our new CheckItOut! version on our demo:
demo.ecomdev.org

You can purchase our new CheckitOut extension here >

The post CheckItOut 1.5.0: Now the fastest checkout extension! appeared first on EcomDev Magento Developers.

Magento Stack Exchange vs Stackoverflow

You may ask why you need just one more Q&A for Magento, if there is a lot of questions on Stackoverflow? The answer is very simple, it will bring all the questions from technical and non technical people to the single place. I saw a lot of questions was closed as not-a-real-question on StackOverflow, mostly because it doesn’t have existing code snippet or just a question for architectural advisory.

So having a separate website on SE platform can resolve issue with non-programmer related questions for Magento topic.

Magento Answers

Official Magento Answers website is not so popular within the community because of few reasons.First of all because it is not user-friendly. It is very hard to post really nice looking questions or answer. Another reason is the moderation process of the questions & answers, it is not efficient like on Stackoverflow. Stackoverflow is much more better in this case, since it fully managed and powered by community. So why not to use a Magento specific stack-overflow version?

Why Now?

This project was started 2 years ago by Vince Pettit, but it got its commit phase only today because of  social impact of Ben Marks twitter account. Thanks to these guys for making it happen! And today is your time to make this initiative happen, support this project by signing a commit petition! Do it right now, click here!

The post Why Magento Community Needs Own Q&A Website appeared first on EcomDev Magento Developers.

Shopping Cart Processes

There are some main processes in the shopping cart that is quite good to know. The following flowcharts and their descriptions will help you.

Adding Product to Cart

Everything that starts in checkout – starts from adding product to cart. As soon as customer presses “Add to Cart” button – Magento magic begins, and today this magic secrets will be revealed. Take a lot at the following diagram to see the main processes flow. Just below the diagram see each process description. Click on diagram to view it in the full size.

Controller Loads Product

This step starts at checkout/cart/add controller action, for which Mage_Checkout_CartController class is responsible. Controller loads product by id passed via product url parameter. If the product is not loaded (not exist, not enabled, etc), then it returns customer to the previous page. Previous page is detected by referrer header or parameter.If it is not possible to detect previous page, customer just gets redirected to cart page. The loaded product with url parameters are passed to cart model method addProduct().

Cart Model Prepares Product Request

Cart model is represented by Mage_Checkout_Model_Cart. Inside of addProduct() method first product model gets checked for assignment to the current website. After the check, from url params, gets created a product request object. The request object just a Varien_Object class instance with url params as data. After creation of the object, requested quantity gets validated for matching minimal qty settings of the product. If qty is lower, it gets corrected automatically. When product and request is prepared, the quote model method addProduct()gets involved.

Quote Model Processes Product Request

Finally Magento gets to a quote model, but just to pass request to product type model. At this step, in addProduct() method of Mage_Sales_Model_Quote class invoked prepareForCartAdvanced()of product type model.

Product Type Model Validation and Processing of Request

Depends on the product type, there could be different product type models. These type models are responsible for product type specific logic. For instance simple product is just contains logic for custom options, configurable has special child product selection logic, bundle has multiple children, etc. However all product type models are extended from Mage_Catalog_Model_Product_Type_Abstract class. By the way, before 1.5, there was different method name, that were invoked during add to cart process. In 1.4.x it was prepareForCart(), and starting from 1.5.0 the method was changed to prepareForCartAdvanced() and logic were moved to a protected method _prepareProduct() with 3 parameters The reason of this change is very simple, they introduced third argument and for keeping backward compatibility, they were supposed to create another method and keep prepareForCart() as alias with two arguments. So currently all the logic of processing & validation of product request is in _prepareProduct() protected method and it is different per product type.

Simple Products (Mage_Catalog_Model_Product_Type_Simple)

The first step of the request processing for this product type is validation of custom options. They are get validated by _prepareOptions() method of type model. When options are validated and processed, then it throws an event. The event name depends on type of product processing: catalog_product_type_prepare_full_options or catalog_product_type_prepare_lite_options. Afterwards the product is checked for being added to the cart by grouped parent, in this case additional product options are added. Then _processProduct()method just returns array with a single configured instance of product and special properties set to it (qty, custom options, buy request, etc.).

Grouped Products (Mage_Catalog_Model_Product_Type_Grouped)

Grouped type process is absolutely different from simple product type, however it involves simple products process for child products. Everything starts from retrieving all assigned child products and comparing them to passed child ids in request. If no child products found in request, _prepareProduct() returns string with error message. Otherwise it just invokes _prepareProduct() method of child product type model and adds it to array of configured product instances. When all child products are processed and there is no errors returned, it adds own product instance to the array and returns it.

Configurable Product (Mage_Catalog_Model_Product_Type_Configurable)

The initial process is the same as in simple product and afterwards it checks configured options by finding a correct simple product that matches all the selected values and invokes its _prepareProduct() method. Also if configurable product has custom options, this options partially added to simple product for making it unique in the cart. If no simple product that matches selection is found, it returns string with error text, otherwise array with two items: configurable product itself and its matched child simple product.

Bundle Product (Mage_Bundle_Model_Product_Type)

The initial process as well the same as in simple product. Then all the possible options and their selections gets loaded and each options gets validated. If option is required and at least one selection was not specified in the request, then it returns an error string. Then the selections that were selected are checked for their purchase availability (i.e. isSalable() method is invoked). Later on all the selections are iterated to set selection qty from input or predefined value (if input is empty or customer cannot change it). As well prepareForCart() method gets invoked for each selection product to add its own options. In the end, bundle product model returns bundle product and all its selection products in the array of result.

Other Product Types

There are also some other product types like Virtual and Downloadable, but their process is the same as in Simple Type Model, just with some additional processes of own options.

Quote Model Adds a New Item or Changes Existing One Qty

First of all, before creating a new quote item, quote model checks for existence of the product with the same combination of options and product id. For this purpose method getItemByProduct() is used. This method walks though all quote items and calls representProduct() method of quote item model. If method returns true, quote model just updates existing item qty by calling addQty() method. Otherwise creates a new quote item and does the same for it. After qty was changed, quote item dispatches sales_quote_item_qty_set_after event, that is observer by stock module. More about this flow described in Update Items in Cart process. When item qty was set, quote model checks for possible errors in added/modified item. If error were found it throws an exception, otherwise it throws sales_quote_product_add_afterevent.

Grouping of Quote Items in Cart

I just mentioned representProduct() method, that is very interesting one and it is quite good to know, how it works. Because sometimes Magento developer needs to have some custom grouping of the items in cart. Most of developers just rewrite quote item model and override this method. However, there is a small trick you can use. Observe catalog_product_type_prepare_full_options for adding new custom option to your product. And observer code may look like the following:

public function makeMyProductUnique($observer)
{
    if ($observer->getEvent()->getBuyRequest()->getSomeFlagFromRequest()) {
        $product = $observer->getEvent()->getProduct();
        $product->addCustomOption('my_custom_unique_id', 'some_value');
    }
}

Cart Model Dispatches Add To Cart Event or Throws Exception

If everything was fine during adding product to cart, cart model dispatches an event called checkout_cart_product_add_after and sets property into checkout session object with the latest added product id. This property name is last_added_product_id.  If there were some error during product add to cart process, cart model throws an exception with error message. If error was returned as string from quote addProduct()method, then it is treated as notice. If it was a caught exception, than it will be treaded as error message. Then later on, in controller layer, the exception thrown by cart model is caught and customer redirected to product page with error or notice shown on top of the page.

 Controller Saves Cart Model

As soon as product is successfully added to cart, controller adds related products via cart model method addProductByIds(). The process of adding related products are almost the same, as all actions described above, except that only simple products without custom options can be added as related by this method. Then save() method of cart model gets invoked.

Cart Saves Quote and Collects Totals

Inside of  cart model save() method, goes total calculation process, that is invoked by  collectTotals() method of quote model. More about totals calculation, you can read in the next sections of this article. After totals are collected, save()method of quote model gets invoked. During this operation quote models saves all child entities like address, item, payment info, etc.

Controller Redirects Customer to Shopping Cart or Product Page

When item was successfully added to the shopping bag, there is also thrown an event on controller level, it is called checkout_cart_add_product_complete. You can use this event for custom redirect or building own ajax response for your super-duper ajax based add to cart functionality. It is just a small advice for all that extension makers, who would rather override method, instead of observing an event. But if you haven’t observed previous event and haven’t set the property called no_card_redirect to checkout session object, Magento uses own logic for detecting redirect url and adds a success message. Depends on configuration settings, there are two options for redirecting customer back. If config option checkout/cart/redirect_to_cart is set to true, then customer always will be redirected to the cart. Otherwise to the page from which product was added to cart (that is usually a product page).

Configure Added Item

As you might know, starting from CE 1.5.x it is possible to update configurable, bundle and simple products with custom option from the cart instead of removing old one and inserting new one. Actually Magento does almost the same for you, it removes old quote item if there is a change in options and adds a new one. You can see the difference on the following flowchart. Just click on it to view the flowchart in full size. The following flowchart do not represent the process of rendering of configure page, since it is very simple – the same as regular product page, just with set up of selected options. Also this section won’t be so massive like previous one, it describes only new steps and difference in similar actions.

Controller Finds Quote Item

Everything starts, when data gets submitted to  checkout/cart/updateItemOptions action. The first thing that controller does, it checks existence of quote item with supplied id in the current quote object. If item doesn’t exists, it adds an error message and redirects customer to shopping cart. If quote item was found, the process flow is delegated to updateItem() method of cart model.

Cart Model Prepares Product Request

Update Items In The Cart

From the name of the process it looks like, that it is also related to updating of item options. But it just changes quantity of the item in the cart. Check the following flow chart and of course descriptions of actions below it.

Controller Normalizes Localized Qty Values

Everything starts at checkout/cart/updatePost controller action. There are two action flows, but we are not looking at empty_cart one, since it is very simple. It just removes all items from cart and not so interesting like update_qty.  For update_qty action, there is invoked a protected method _updateShoppingCart(), that contains all the logic of updating quote items. First of all it retrieves an associative array of updated items and normalizes qty values according to current locale settings, because Magento supports decimal qty values and not all the countries have dot as decimal mark. So it is required to transform customer input to a correct php decimal representation in string. When qty  values are normalized, controller invokes special suggest qty functionality. It is realized by suggestItemsQty()method in the cart model.

Cart Model Updates Qty Array With Suggested Values For Each Quote Item

Inside of suggestItemsQty() method cart model walks through all items in the array. If item if the specified id exists and product is set to a quote item and product has quote item assigned, then it method passes qty to a stock item model method suggestQty(). Result returned from the method call gets set to item in array, so it will be used for updating real qty.

Stock Item Checks Qty Increments Value

When cart model calls suggestQty() method, stock item model performs a check of qty increments options. If qty increments option is specified for a stock item, it checks correctness of value specified for a stock item. It also checks if the value is between min and max values, but it doesn’t autocorrect it, it just leaves qty as is, to validate it later on by another process. Here are some test cases, to make it easier for you to get this functionality implementation right: If product has qty increments value set to 3, and min sale qty is 3 and max sale qty is 12 then:

• If specified qty equals to 2, then it won’t be autocorrected
• If specified qty equals to 3, then it won’t be autocorrected
• If specified qty equals to 4, then it will be autocorrected to 3
• If specified qty equals to 5, then it will be autocorrected to 6
• If specified qty equals to 6, then it won’t be autocorrected.
• If specified qty equals to 13, then it won’t be autocorrected

Controller Passes Qty Array to Cart Model

When suggested qty functionality process was finished, controller takes modified array and invokes updateItems() method of the cart model.

Cart Model Modify Qty Process

When cart model get array of quote items quantities to update as argument to updateItems(), first of all it dispatches checkout_cart_update_items_before event. It is pity, but you cannot modify array of qty’s by observing this event, you can only retrieve it. After dispatching of the event, cart model walks through all array rows. If row qty equals or less than 0, quote item associated to the array row gets removed from cart, otherwise it just sets quote item qty. If any item has difference between qty specified by customer and qty that was actually applied (qty increments modifications), then cart model adds notice message to session object, so customer will get notified about autocorrected values. When all items were modified or deleted, there is dispatched another event, that is called checkout_cart_update_items_after.

Quote Item Dispatches Qty Change Event

After setting of qty by cart model, quote item model dispatches sales_quote_item_qty_set_after event. This event can be observed by you to perform additional check of inventory. BTW, this event is observed by Mage_CatalogInventoy module and on this event Magento performs check of item stock availability.

Stock  Qty Change Logic

Observer Mage_CatalogInventory_Model_Observer class has specific logic qty change validation of quote item. This logic is realized in checkQuoteItemQty()method. I will not go too much in deep into check activities, just will explain it in general. If quote item qty lower than minimal qty for product or greater than maximum one, it will return an error. If specified qty is not available for item, it also will rise an error.

Controller Saves Cart Model, Cart Saves Quote and Collects Totals

Absolutely the same as in add to cart process.

Controller Redirects Customer to Shopping Cart

There is no event for updated items qty, so you cannot modify the request via specific cart controller event, but it is still possible to make a trick by adding observer to controller post dispatch event, that is called controller_action_postdispatch_checkout_cart_updatePost. This event can be used for changing redirect to ajax response, but, of course, it adds a lot of work for you to detect possible errors and updated items from session and quote objects.

Remove Item From The Cart

Quite simple process, but also have some interesting features that you should know. Just take a look at the flowchart.

Even if remove process sounds quite simple, however, there are some special features that might be new for you. Especially it is related to logic with parent-child relations. So lets take a look at every process more in detail.

Controller Passes Quote Item Id to Cart Model

It starts at checkout/cart/delete action. Controller just retrieves id url parameter and invokes cart model method removeItem().

Cart Model Removes Item from Quote

This step is really simple and straightforward. Cart model just calls removeItem() method of quote model.

Quote Item Removal Logic

When removeItem() method gets invoked, there is a check for item existence. However, if it doesn’t exists, it won’t rise an error, it just skips item removal logic.

If item exists, it marks it as deleted by invoking isDeleted() method with true value as an argument, so when save() method is invoked during quote save process, item record will be removed from the database. After quote item is marked for delete, there is a check for child quote items assigned to it. If so, it iterates over it and marks child items as deleted as well. Also if that is removed is a child item of some parent one, it will mark parent item as well. So if it has child items or is a child item itself, Magento will remove child/parent item as well.

After item was marked as removed, it dispatches an event that is called sales_quote_remove_item. You can observe it, if you have some special items, that cannot be removed from the cart. Just mark quote item in observer as un-deleted by calling isDeleted() method with first argument value that equals to false.

Controller Saves Cart Model, Cart Saves Quote and Collects Totals

Absolutely the same as in add to cart process.

Controller Redirects Customer to Shopping Cart

There is also no special event, like in update quote items qty process. Customer just gets redirected back to shopping cart.

View Shopping Cart Page

So, have you ever thought what is happing when you are viewing Shopping Cart Page? If no, then it will be a surprise for you, how many checks and processes are performed, when you land to checkout/cart/index page. Curious? Check the following flowchart. 

Controller Checks Number of Quote Items

When you are viewing the shopping cart page, controller checks number of items in your shopping cart. If you have at least one item, it starts initialization of shopping cart model, otherwise just renders shopping cart page (empty cart template). Shopping cart model is initialized by its init() method invokation.

Cart Model Resets Checkout Data

When cart model gets initialized, first of all it resets checkout method for Onepage checkout flow. It is done by setting up property checkout_method to empty value for a quote model. Also if there were any steps performed for multiple shipping checkout, e.g. checkout_state property of checkout session object is not equal to Mage_Checkout_Model_Session::CHECKOUT_STATE_BEGIN constant value. In this case all the addresses added to a quote will be removed, also cart model removes payment info instance, since it may affect another checkout type.

As well, if apparently during initialization process all the items were removed from the quote, cart model will remove all the shipping rates.

Controller Saves Cart Model, Cart Saves Quote and Collects Totals

Absolutely the same as in add to cart process.

Quote Model Validates Minimum Amount

When all the totals are recalculated, controller calls quote model method, that is called validateMinimumAmount(). In this method quote model walks though all addresses and invokes method with the same name on them. If any of those methods return false, quote method will return false as well.

On address model level validateMinimumAmount() method compares configuration value from sales/minimum_order/amount path with amount from address base_subtotal_with_discount property. This property contains subtotal with all discounts.

If minimum amount is not valid, controller adds notice message to checkout session with minimum required amount for purchase.

Controller Adds Quote Messages to Checkout Session

When all the initialization and validation are performed, there might by some messages stored in quote model. So controller just retrieves that messages and adds it to checkout session object.

Controller Sets Cart Updated Flag

You might be curious, why controller sets updated flag, if nothing was updated? There reason is quite simple, as soon as customer came back to shopping cart page from any checkout page and if in another browser tab he has a checkout page, the data on that checkout page gets invalidated, so customer needs to start over the checkout process. So for this purpose this property changed, since with every ajax or regular request every checkout flow checks it and if it equals true, redirects customer to cart.

Controllers Renders Shopping Cart Page

There is no hidden actions at this step, it is quite straight forward. Controller just loads layout and renders it.

What’s Next?

So when you know how main processes work in shopping cart, it is time to dig more into advanced part like totals and addresses. So don’t forget to check our blog in few weeks! Next time you will get aquatinted with Quote Address, Totals and Price Calculation! Also I am going to reveal some secrets of tax applying process.

The post Magento Checkout: Shopping Cart Flow appeared first on EcomDev Magento Developers.

How Magento Checkout Extension Was Built

I saw enormous amount checkout extensions on the market, while I was working on different project and my main concern about them is, that they all are realizing absolutely own logic for checkout. 90% of them even don’t follow MVC design and have mess in the code. Most of them do not use existent Magento models and just copy-paste the logic of data processing in Magento core.

So one of the main ideas in this extension architecture was to keep logic close to Magento core as it is possible, and luckily the result was achieved. The initial send of extension for code review to other developers made us proud of the work done.

How It Works

The extension functionality is realized by controller, proxy of checkout model and wrapper blocks for checkout steps in own built layout structure that is easy to modify. Extension can be enabled or disabled for each store view, you can choose different layouts and color schemes. It is very easy to add own steps or hide existent ones. The extension architecture improved flexibility of checkout process customizations itself, some of developers developers even call it Magento checkout framework. So how it become possible?

JavaScript Classes

First of all idea of using the same JavaScript class names and make them compatible with core OnePage Magento Checkout. All the classes use PrototypeJS OOP implementation, that provides awesome way for overriding existing functionality and building inheritance between classes. It helped me to unify logic between all checkout steps and make them more independent form each other, than in OnePage.

The base class for all steps is represented by EcomDev.CheckItOut.Step prototype, that is later on used for Payment, ShippingMethod classes. As well Billing and Shipping address steps having also abstract based on this one, it is called EcomDev.CheckItOut.Step.Address.

So EcomDev.CheckItOut.Step has methods and properties that can be useful for your custom steps or customizations as well:

• Methods
  • initialize(container, saveUrl) - a constructor, should receive a container html element and url for saving of the data. If you want to add additional parements for your custom step, you just can use inheritance implementation in PrototypeJS:

    var YourCustomStep = Class.create(EcomDev.CheckItOut.Step, {
        initialize: function ($super, container) {
           $super(container, 'http://my-save-url.com');
        }
    });
    

    As you see in the example above, the saveUrl argument is removed and new $super argument is introduced. $super in this case is automatic argument for prototype to identify the argument in which to pass a super class method, e.g. parent method.

    Constructor contains logic for binding event listeners to form elements and registering step in checkout object.

  • isValid() – this method invoked each time before auto-submitting data to save url. If it returns false, of course data is not going to be submitted.
  • submit() - it performs validation and send ajax request for saving of the data.
  • submitComplete(response) - receives response on ajax call from submit() method and processes it.
  • isLoading(flag),  isLoading()- sets or returns is loading flag for step. It is used to notify checkout object about ajax activity at step.
  • addCallback(closure) - adds callback to submit and submitComplete actions. Every callback receives a step as an argument, so you can check is submit completed or not by calling isLoaded() method.
  • showMask(), hideMask() – methods used for showing/hiding loading mask over the method container. The mask div with class name .step-loading should be specified in your step template.
  • addRelation(stepCodeOrStepCodes), isRelated(stepObject) - these methods are used to realize relation between particular checkout steps. For instance payment method is related to shipping method and billing address step changes. So by specifying addRelation() on it, extension will automatically update the payment methods. However, this functionality for payment method is used in conjunction with step hashes, that will be described a bit later in the article.
  • getValues() – returns all step form element values with element name as object key.
• Properties
  • code – property specifies the step code, that is unique for within checkout. E.g. shipping_method or review.
  • changeInterval – interval since keyup or change events for form fields, after which data get’s validated and submitted. Also data can be only validated or only submitted depends on other properties configuration. Default value is 1200 ms.
  • autoSubmit - used for indicating that checkout step can be automatically submitted. E.g. if equals to false, you will need to call submit() method from your code to invoke step data saving. Default value is true.
  • autoSubmitInvalid - indicates allowance of submission of not valid data in the form. In CheckItOut is used for address forms to keep data in quote and update shipping rates as soon as possible. Default value is false. 
  • ignoreValidationResult - this property is used to indicate that step isValid method shouldn’t affect overall checkout process. For instance if coupon code is not entered correctly and has error, it shouldn’t block customer from proceeding to purchase. Default value is false.
  • loadedHash – this property contains hash of the currently loaded step content. Checkout object checks it when related step is saved. If loadedHash property value is NOT the same as in AJAX response, then step is reloaded. If step doesn’t support this property (i.e. AJAX response doesn’t have hash info), step will be reloaded with each related step change.
  • checkout - this property contains an instance of EcomDev.CheckItOut class to access its methods from step.

• getStep(stepCode) – returns step object by step code.
• isLoading() – returns true if at least one step isLoading() method returns true.
• notifyLoading() – checks all step objects isLoaded() method and  marks submit buttons as disabled if there any loading process.
• getSubmitButtons() – returns array of all buttons on the page that have .btn-checkout class name.
• reloadSteps(stepsArray) – reload steps by steps, that are changed. E.g. walks though all the step objects and checks that it is related to passed one in array, then reloads.
• isValid()  - returns true only if all step objects isValid() method returns true, otherwise false.
• getParameters() – returns all form element values for all step objects. Ready to be used in Ajax.Request.
• submit() – validates all steps, places order via AJAX request to save order action of one page controller.
• forcedSubmit() - submits data without checking steps validity,
• submitComplete(response) – processes response of save order action.
• showMask(), hideMask() – hides shows order place mask (e.g. text “Submitting your order information”)
• showOverlay(frontElement), hideOverlay() – very helpful for showing your custom popups. Creates transparent overlay under your popup and centers your popup in viewport. Variable frontElement should be an HTMLElement, that has absolute position and defined z-index. Z-Index is mandatory to locate the best position for overlay. Z-Index and absolute position can be defined even in CSS file, since Scritaculous getStyle() modification supports retrieving final applied styles.

Also don’t forget, that by using of PrototypeJS you can override classes definition all the time. For instance you want to customize ShippingMethod step class behavior, then this construction will help you:

ShippingMethod = Class.create(ShippingMethod, {
       isValid: function ($super) {
              if (someSpecialCondition) { // Some custom logic
                   return false;
              }
              return $super(); // Calling parent isValid method
       }
});

The example above customizes ShippingMethod validation for some special custom condition. The process, that happens there is actually a small trick, that you can do even with customizations of standard OnePage checkout.

So this PrototypeJS feature gives an awesome way of JS customization without modifying original file. I always recommend to developers including own JS file after checkitout.js and do performing own customizations via Class.create(). So when you receive a new version of CheckItOut! you don’t need to diff files and re-apply your the customizations, you just update main codebase and your customizations just automatically applied.

Here a list of current checkout step classes that you can customize:

• LoginStep – PopUp with login form
• Billing – Billing Address Information
• Shipping – Shipping Address Information
• ShippingMethod – Shipping Method with possible Gift Options selection
• Payment – Selection of payment method and entering of payment details if required
• Review – Order items, checkout agreements, special actions on order item level
• ConfirmPopUp - special step for compatibility with some EU regulations
• CouponCode – step, that allows entering coupon code right on the checkout page

Layout Structure

Since CheckItOut! 1.3.0 version, there was introduced a new layout scheme, that allows an easy way to modify step placement or add own ones without rewriting checkout models. As well this layout implementation allows to apply absolutely different CSS color schemes and provides very easy way of its style customization. Now it is the same as with JS files, you don’t need to modify CSS, you just can include own one and apply your custom styles.

But before we will go in deep to CSS color schemes, first I will describe layout structure and how it is built.

Step Blocks

The extension is not rewriting any block, it is even sets only one custom template for review step, all the others are retrieved from core OnePage checkout. This was achieved by detaching original blocks from layout rendering tree and creating own structure of blocks that just retrieves original blocks html.

All step blocks implement EcomDev_CheckItOut_Block_Layout_Step_Interface interface that is used to provide information to its container about the block and how to render it. It has such methods:

• getStepName() – returns name of the checkout, that is visible to a customer
• getStepNumber() – returns a step number in sequence of all steps presented in layout tree
• getStepContent() – returns rendered associated onepage step content
• addClassName($className) – adds a CSS class to a block html container
• removeClassName($className) – removes a CSS class
• getClassName() – returns a list of css classes assigned to a block rendered as a string and separated by space
• isVisible() – this method returns information about visibility of the step, can be used to hide some steps in checkout, if they are not required. For instance in EcomDev_CheckItOut_Block_Layout_Step_Login, EcomDev_CheckItOut_Block_Layout_Step_Payment and EcomDev_CheckItOut_Block_Layout_Step_Shipping_Method using it to hide itself if customer is logged in, there is no reason to show payment method and shipping method selection accordingly.

That’s quite simple interface and you need to implement it if you have a block that can’t be extended from EcomDev_CheckItOut_Block_Layout_Step_Abstract one. This abstract already have all of the them implemented and even more, it can retrieve data from onepage checkout by step code. For instance you can use EcomDev_CheckItOut_Block_Layout_Step_Address block retrieves data from onepage checkout blocks.

Take a look at the following layout XML:

<block name="checkout.layout.billing"
       type="ecomdev_checkitout/layout_step_address"
       template="ecomdev/checkitout/layout/step/default.phtml">
    <action method="setStepCode"><code>billing</code></action>
    <action method="setStepNumber"><number>0</number></action>
    <action method="initAddress" />
</block>

It creates a billing address step in default layout scheme. Method setStepCode is called to specify with step content retrieve from onepage checkout. Method setStepNumber removes numbering from this step, e.g. it won’t be counted and the step number won’t be shown. Method initAddress does some secret logic that you can check yourself if you bought an extension :).

Now let’s take a look at ecomdev/checkitout/layout/step/default.phtml, so you can see how it works:

<?php if ($this->isVisible()): ?>
<div class="<?php echo $this->escapeHtml($this->getClassName());?> <?php if ($this->getPositionCode()): ?><?php echo $this->escapeHtml($this->getPositionCode());?><?php endif;?>" id="checkout-step-<?php echo $this->getStepCode();?>">
    <?php if ($this->getStepName()): ?>
    <div class="step-header" id="checkout-step-<?php echo $this->getStepCode();?>-header">
        <?php if($this->getStepNumber() != 0): ?><span class="number"><?php echo $this->escapeHtml($this->getStepNumber()); ?></span><?php endif;?>
        <?php echo $this->escapeHtml($this->getStepName()); ?>
    </div>
    <?php endif; ?>
    <div class="step-content" id="checkout-step-<?php echo $this->getStepCode();?>-content"><?php echo $this->getStepContent(); ?></div>
    <?php if ($this->hasLoadingOverlay()):?>
    <div class="step-loading" style="display:none;"><span><img src="<?php echo $this->getSkinUrl('images/opc-ajax-loader.gif') ?>" alt="<?php echo $this->__('Loading step data...') ?>" title="<?php echo $this->__('Loading step data...') ?>" class="v-middle" /> <?php echo $this->__('Loading step data...') ?></span></div>
    <?php endif;?>
</div>
<?php endif;?>

As you see, there is no billing address form. Instead of rending form in extension, it renders checkout/onepage_billing block and outputs it via getStepContent method. So standard Magento checkout step HTML is used.

Container Blocks

Additionally to standard step blocks, there are container ones. All of them are using EcomDev_CheckItOut_Block_Layout_Step_Container class, that has some nice methods:

• addClassNameForStepCount($className, $stepCount) – conditional addClassName method implementation. Adds CSS class only if amount of child blocks, that visible and implement EcomDev_CheckItOut_Block_Layout_Step_Interface interface, is equal to $stepCount.
• removeClassNameForStepCount($className, $stepCount) – conditional removeClassName method implementation. Has similar logic to the previous method.
• getStepCount() – returns number of child blocks, that implement EcomDev_CheckItOut_Block_Layout_Step_Interface and are visible
• getStepContent() – returns all sorted child blocks HTML, that are visible.
• isVisible() – indicates container visibility, determined by number returned by getStepCount() method.

Both these types of blocks building the layout system of CheckItOut! extension. However it is not all layout benefits. There also very flexible system of layout handles.

Layout Handles

As you know, it is possible to choose in Magento checkout extension configuration the page layout. For instance you can make it two column or just default single step style. This functionality is build in a very easy way. We added a special configuration node where you can specify as many layout handle names, as you wish. The node where you can add custom layout types is the following: ecomdev/checkitout/layout. Please take a look at the following XML of two_column layout type:

<two_columns translate="label" module="ecomdev_checkitout">
    <label>Two Column Layout</label>
    <handles>
        <default>ecomdev_checkitout_layout_default</default>
        <custom>ecomdev_checkitout_layout_two_column</custom>
    </handles>
</two_columns>

Node name is an unique code for layout type. Label is for showing name of the layout type to the admin user. Handles node contains layout handles that will be added in the same order as they are specified.

As you see for two columns design it uses default handle as a base and own custom one as modifier. You are not limited to only two layout handles, you can add as many of them you wish, so you can build layout structures very easily.

What You Can Do With It

Most of our customers who buy the extension, just telling us that it is awesome checkout platform for their stores and very easy to customize it for skilled developer. I’ve seen at least 5 websites with customized version of CheckItOut!, that have really amazing flow implementation. It is very easy to customize from layout XMl as well as on CSS level.

Hope you will like it as well, as most of our customers!

P.S. Just forgot to give you a link for it: CheckItOut! – Magento Checkout Extension

The post Our Magento Checkout Extension Ideas & Architecture Revealed appeared first on EcomDev Magento Developers.

Reason #1. Knowledge

This course will help you in learning the main concepts of test drived development with Magento. Also it gives awesome opportunity for getting familiar with best practices in usage of our EcomDev_PHPUnit extension. BTW, just few weeks before the course, a new version of extension going to be released. This version will contain a lot of code refactoring and optimization, that of course will benefit you in your day to day development.

Reason #2. Attendees

This training course is a great opportunity to meet with other developers who is also addicted to test driven development. Together with them, you can learn much more, than doing it yourself.

Reason #3. Magento-Hackathon

As you know from 11th till 13th of January, there is another awesome event planned in Berlin! I cannot imagine better opportunity to apply your knowledge on practice, right after the training! Check it out: http://www.magento-hackathon.de/

Reason #4. Location

The training center is located in the city centre of Berlin. It is in average a 20 minute walk from the most popular touristic sights. Check the location on the map: http://goo.gl/maps/qn7o0

Reason #5. Cookies

Every Magento developer likes cookies, so there will be enough amount of them to meet the demand.

Not yet interested? Check out the training agenda!

Training Facility

The FastLane Institute of Knowledge provides a fully equipped training room with PC that have all the required preinstalled software. So you don’t need to bring own laptop, install development environment and Magento. Everything will be already prepared for you!

Do You Want to Register?

Just do it right now at the following page.

The post 5 Great Reasons for Visiting Test Driven Development Training in January appeared first on EcomDev Magento Developers.

Idea

So as all of you know, the identifier of the home page is stored in configuration and retrieved via Mage::getStoreConfig() method. But not everyone knows, that you can easily change any configuration value on the fly without changing the actual values in the database or file system. And we decided to use this smart trick to substitute the value of in configuration before the page renders.

Realization

First of all we need to create module that will contain our observer. I won’t describe how to do it, since I believe you can do it yourself.

So let’s just start from creating an observer that will make this substitution on the fly:

class Your_ModuleName_Model_Observer
{
    // Configuration path for our custom cms homepage
    const XML_PATH_FOR_CONFIG_TO_CUSTOM_HOMEPAGE = 'somemodule_section/home/page';
    /**
     * Substitutes homepage during by replacing
     * configuration value for the current store
     *
     */
    public function substituteHomePage()
    {
        $customHomePageForLoggedIn = Mage::getStoreConfig(self::XML_PATH_FOR_CONFIG_TO_CUSTOM_HOMEPAGE);
        if (Mage::helper('customer')->isLoggedIn()
            && $customHomePageForLoggedIn) {
            // Substitute only if page is defined
            Mage::app()->getStore()->setConfig(
                Mage_Cms_Helper_Page::XML_PATH_HOME_PAGE,
                $customHomePageForLoggedIn
            );
        }
    }
}

As you noticed in the code, the page that is gets set for logged in customers defined somewhere in configuration. It is because we don’t like hardcode values in our modules ;). If you’d like to know how to define this configurations, please refer to our article about it.

Then the next step is to attach our observer to a particular controller preDispatch. In our case it is cms_index_index action, so event name will be controller_action_predispatch_cms_index_index. You need to specify the following in config.xml of your module, to make it happen:

<?xml version="1.0"?>
<config>
   <frontend>
       <events>
          <controller_action_predispatch_cms_index_index>
              <observers>
                  <your_modulename>
                      <model>your_modulename/observer</model>
                      <method>substituteHomePage</method>
                  </your_modulename>
              </observers>
          </controller_action_predispatch_cms_index_index>
       </events>
   </frontend>
</config>

Where To Use

The trick above can be used not only for this functionality. It is just a particular use case we have met on one of our projects, you have more ways to implement it based on different conditions. For instance, if you are developing a project based on enterprise edition, you can make conditions for pages based on a particular customer segment. But in this case you should consider, that full page cache is not taking care of the current segment when caching data, so some magic with cache processor should be done.

Have fun developing with Magento!

The post Magento Smart Trick of The Day: Dynamic Home Page appeared first on EcomDev Magento Developers.

Realization has varying difficulty for online business card and for huge CMS like Magento.
Is it possible to make it pixel to pixel with the design for Magento template? Certainly yes, but just if you know all render content.

If you want to create general-purpose style for all themes for Magento you will stumble upon many obstacles.

First step – browser support in terms of reference

The first step for beginning creating custom fields, is a condition in the terms of reference must be the paragraph about browser suppor like this:

Browser Support
The custom fields of form will be developed as in design for browsers with support CSS3. In old browsers like IE7,8, Firefox2 will be displayed default fields.

• You have a lot of arguments in favor of this.
• The less code in HTML layout – better for SEO.
• Faster upload and render page.
• Less JavaScript – the chipper support the project in future.
• Those people who use old browsers will not appreciate efforts.
• It’s modernly.

HTML5 and CSS3 Rescue Rangers

For a simple web-site it is possible to write general stylesheet on CSS3. The common idea of realization custom elements like radio or checkbox on CSS3 is to hide input and set background to label with sprite.

input[type="checkbox"] {
    opacity: 0;
    position: absolute;
}
input[type="checkbox"] + label::before {
    background: url('custom_checkbox.png') no-repeat 0 -15px;
}

This method needs to be accurate and sticks the same layout for elements all over the project.

Problematic situations in the Magento

In different blocks we see different layout.

In related product you can see checkbox with no label.
In checkout radio which sometimes wrapped in span, sometimes not.
In rating block we can see label wrapped in span.
In account page we can find checkbox wrapped in div and with js event on it.

So, if you have the goal to solve this problem just with CSS3 you need to refactor all template files and structure them the same as it possible.

Some advices:

• Try don’t change existing class names.
• Be careful with js events in tags.
• Always test form validation after customization.

Be very careful with checkout in Magento (v 1.7):
HTML render different structured HTML layout, so you must check every step and all options.

Ready to use CSS3 stylesheets

Check the solution for checkbox elements, radio-buttons and drop-down lists created by our company for you:

Custom checkbox

• Code on GitHub
• Demo & Documentation

Custom radio-button

• Code on GitHub
• Demo & Documentation

Custom dropdown list

• Code on GitHub
• Demo & Documentation

Soon we will produce you custom buttons and inputs stylesheet.

Implement stylesheets to Magento Project

You can mention, that custom checkbox and custom radio-button is almost identical – it’s really true but it was divided for this article deliberately because for the reason of different layout all over the Magento project it’s better to style blocks one by on.

If you are sure in your skills and adequacy your project you can use common method to checkbox and radio.

Custom radio-buttons in poll (radio-button)

You can see a video-guide about implementing custom radio-buttons to poll block on Magento 1.7 Community Edition.

Instruction

1. Include CSS file in project
2. Insert CSS file within Magento XML layouts
3. Adjust your styles within situation and fix bugs if you have.
4. Test in browsers.
5. Try to submit form.

Result:

Custom checkboxes in related product (checkbox)

In related product we have checkboxes with lo label. Technically we can solve it in two ways:

1. Editing template file
2. Hack in JS without editing template file

With editing template file

Step 1
Insert line with label in file “catalog/product/list/related.phtml“. It must looks like this:

<input class="checkbox related-checkbox" type="checkbox" id="related-checkbox<?php echo $_item->getId() ?>"
name="related_products[]" value="<?php echo $_item->getId() ?>" />
<label for="related-checkbox<?php echo $_item->getId() ?>"></label>

Step 2
Implement stylesheet CSS the same way as in the previos example about radio-button.

Step 3
Make some adjustments in CSS to display checkbox in right way

#block-related label {
    float:left;
}

Hack in JS without editing template file

The same as in the previos solution but in first step instead changes in templates include in project JS based on prototype.

$('block-related').select("input[type=checkbox]").each(function(el){
   new Insertion.After(el,
   '<label for="' + el.identify() + '"></label>');
});

Result:

Conclusion

As conclusion we can say, that there are no universal method of integration custom elements form to all project. But we can derive a formula of successful front-end development at this part.

The post Magento and style custom elements of the form appeared first on EcomDev Magento Developers.

Main Magento Checkout Modules

Checkout functionality is spread over different modules. There are 4 modules, that represent the base functionality of it. Of course there are more modules, involved in the process, but most of them (like shipping, payment method) just extend existing functionality of base ones. So let’s take a look at these base modules for checkout process.

Mage_Checkout module

Talking about this module, it considers to be the main module in checkout process. It contains controllers, blocks and models, that realize the logic of checkout flow. It has currently two on-site Magento checkout flows and, I suppose, you know them: Onepage and Multishipping. Both of them have similar structure, but realized via different controllers, blocks and models.

Onepage checkout flow

Onepage checkout flow is the most feature-rich and default one. Also all the payment and shipping methods, that are developed for Magento has been supporting this checkout flow more often, than other ones. It splits up into 6 steps:

• Checkout Type Selection Step
  This is an entry point of the checkout flow, where customer has a choice how to proceed with checkout. There are few options available for him/her, depending on configuration: login as a customer, create a customer account during checkout or just make an order without registration (i.e. guest checkout). If a customer has already logged in, this step wouldn’t show up at all.
• Billing Address Step
  At this step customer enters his billing address, based on wich the available payment methods will be retrieved. Also against this information, the payment gateway usually performs a fraud check. If a customer is logged in, then he will just need to select one of addresses stored in his address book. If customer chose to use this address as his shipping one, then it will be just copied into it. Also based on billing address, taxes can be calculated, but it depends on configuration.
• Shipping Address Step
  This step is used for calculation of delivery costs and available shipping methods. Also by default Magento calculates taxes based on shipping address, if it stays the same in configuration. If there are no products, that must be shipped (e.g. digital/virtual products), this step is omitted.
• Shipping Method Step
  This step contains information about available shipping methods and costs. The chosen shipping method may affect available payment methods in the next step, because of order total being changed. The information for this step is retrieved from Mage_Shipping module and all the other ones, that extends it (e.g. some specific shipping carrier modules). In such a way, when there are no products in order, that must be shipped, this block is not visible as in previous step.
• Payment Method Step
  This step allows customer to choose preferred payment method and, of course, supply payment details (depends on payment method). The data for this step is supplied by  Mage_Payment and all modules, that provide particular payment provider integration and extend this module functionality.
• Review Step
  This step is the last one in Onepage checkout, before an order thank-you page. It shows order summary and some specific blocks, that may be added for receiving customer consent on terms and conditions of purchase, 3D secure authorization, etc.

The functionality of these steps are represented by such classes:

• Mage_Checkout_Block_Onepage and Mage_Checkout_Block_Onepage_* classes represent view blocks of each step.
• Mage_Checkout_OnepageController class realizes controller logic for saving data from checkout and redirecting customer to a proper page.
• Mage_Checkout_Model_Onepage class is a model of checkout flow and takes care about validation and saving of the data in a proper way.

Multiple shipping addresses checkout flow

Multi-shipping flow allows customer to choose different shipping address on item level, but has some architectural limitations, that doesn’t allow you to use it with all payment methods. It is splited up into such steps:

• Login or Create an Account Step
  This step is required for checkout functionality, because of limitations related to address selection (it is required for Magento to have address for multiple shipping, being selected from customer address book)
• Select Addresses Step
  At this step customer selects a shipping address from address book for particular quote item. As well, by logic of this checkout flow, a separate address can be selected even for the same shopping cart item, having qty greater than 1.
• Shipping Information Step
  This step is used to choose delivery method per shipping address. The information about delivery costs retrieved via Mage_Shipping module, like in Onepage checkout flow.
• Billing Information Step
  At this step customer can change his billing address from address book (default billing address is used usually). Also customer can choose the payment method, he would like to pay with.Information about payment methods are also retrieved  from Mage_Payment module, but not all the enabled payment methods can be used for multiple shipping. Magento cannot use payment method with redirect to payment gateway page, because it is related to architectural limitation of multiple shipping (it is creating a separate order for each shipping address).
• Place Order Step
  This step is similar to Review step in one-page checkout. It shows order summary and some specific blocks, that may be added for receiving customer consent on terms and conditions of purchase, 3D secure authorization, etc.

The functionality of this checkout flow is realized by the following classes:

• Mage_Checkout_Block_Multishipping_* classes represent view blocks for each step.
• Mage_Checkout_MultishippingController class realizes controller logic for saving data from checkout and redirecting customer to a proper page.
• Mage_Checkout_Model_Type_Multishipping class is a model of checkout flow and takes care about validation and saving of the data in a proper way.

Generic classes

Also checkout has some generic classes, that are used at shopping cart and by both checkout flows.

• Mage_Checkout_Model_Session class is a session object, that stores information about current quote object and available checkout steps (depends on checkout flow).
• Mage_Checkout_Model_Cart class realizes simplified way of modification of the quote object at shopping cart page. Used in the system to add/update/remove products from quote.
• Mage_Checkout_Model_Agreement and Mage_Checkout_Block_Agreements classes are used for showing up terms and conditions checkboxes and text at the checkout page.

Mage_Sales module

The next module is not less important than Mage_Checkout. This module provides models that represent small units of checkout and sales functionality. These units can be generally separated in two groups: quote entities (pre sale process) and order entities (after sale process).

Quote Entities

These entities are used for collecting order information before customer pressed “Place Order” button. They also only temporary ones, if you’ve set up cron jobs properly in Magento you will notice that with some period of time old quote objects are getting deleted from the database. There are such quote entities available:

Quote

This is the main entity, from which later on the order is created. It contains general information about order, currency and its rate, customer information and some general total values. It is also an entry point for access to all the other entities, like addresses, items, payment, shipping rates. The functionality of this entity is realized by Mage_Sales_Model_Quote class.

Quote Item

The next one, is an entity of a single product line in the order. It contains information about product, its relations and data for price calculations (prices, row totals, discounts, taxes, etc). It is represented by Mage_Sales_Model_Quote_Item class.

Quote Address

This entity contains billing or shipping information depending on it type. Also this entity is used for all the total calculations, because Magento can properly calculate taxes via using this information. There are some specific logic in calculation of the totals, depending on the type of order:

• Virtual Order – if all the items in the quote are not applicable for shipping (e.g. downloadable products, digital gift cards), then billing address is used for calculation of all the totals of the order, since items will be assigned to billing address.
• Normal Order – if any item in the quote is applicable for shipping, then shipping address is used for calculation of all the totals. If there is more then one shipping address with assigned quote items to it, then the totals will be merged and summary will be used for quote object.

More about totals and addresses you will learn from the next articles.

Quote Address Item

This entity is used only if Multishipping flow. It extends functionality of quote items by linking total calculation per shipping address. The functionality of this entity is realized by Mage_Sales_Model_Quote_Address_Item class.

Quote Address Shipping Rate

This entity is used for storing result of the last shipping rate collection process, this one is used only for temporary purpose and not exported into order. The functionality is realized by Mage_Sales_Model_Quote_Address_Rate  class.

Quote Payment

The entity is used for storing and validation of payment data entered by customer, and using it later on during order placement process, by another entity. This entity is not doing any payment transactions, since all transactions are done based on created order. The functionality is realized by Mage_Sales_Model_Quote_Payment class.

Order Entities

When customer pressed “Place Order” button in the admin panel, these entities will take the control over checkout process. The entities data are retrieved from quote by using service models and fieldset maps defined in configuration (see global/fieldsets in this article). There are such entities available:

Order

This is the general entity of the post sale process. It contains values of totals calculated during checkout process, sale state and general information about customer. As well this entity can be used as an entry point to access all the other entities related to it (items, addresses, shipments, invoices, etc).

The data for this entity gets imported from quote and quote address.

Unlike a quote address entity, this one does not calculate totals all the time. There are only few cases of totals being updated:

• Creation of invoice leads to updated order paid total amounts.
• Creation of creditmemo leads to updated  order refund total amounts.
• In case of cancelled order appropriate total amounts will be updated as well.

The functionality of this entity is realized by Mage_Sales_Model_Order class.

Order Item

This is an entity of a single product line in the order with information about ordered, paid, canceled and refunded amounts. As well this entity contains some general information about product and options selected during checkout process.

Depending on the checkout flow the data for this entity is supplied from quote item (onepage) or quote item + address item (multi-shipping).

The special qty properties of this entity realizing system logic of possibility to create invoice, creditmemo, shipment, RMA or cancel an order. More details about their usage you will learn from the next article about customizations of quote and order entities.

The functionality of this entity is realized by Mage_Sales_Model_Order_Item class.

Order Address

This entity contains address information for specific address type. If order is not virtual, there order will have two addresses: billing and shipping. The entity data is transfered from quote address, but unlike quote address, it doesn’t have total amounts, only address and selected shipping method info.

The functionality of the entity is realized by Mage_Sales_Model_Order_Address class.

Order Payment

The entity represent itself a realization of unified way of all payment interaction with order. It contains data about payment method and some transaction details (depends on payment method realization). This entity using a payment method model that is provided from Mage_Payment or module that extends its functionality. So basically the entity itself is just a facade, that uses appropriate object to register payment transactions for an order.

The functionality of the entity is realized by Mage_Sales_Model_Order_Payment class.

Order Payment Transaction

This entity first time were introduced in Community Edition 1.4 to make possible storing of multiple transactions within one order. It was not possible before 1.4 to have multiple refunds working correctly, because of overridden transaction id for payment entity after first refund.

Basically transactions is a hierarchical structure of the payment method data, you can manage them within your payment method implementation in any way. For instance your payment module can create two partial credit card authorizations. In this case you need to track capture process for each authorization operation separately. This entity will help you to achieve correctly working solution.

The entity itself doesn’t have some specific payment functionality, it just stores data that were set by payment method instance. It is realized via Mage_Sales_Model_Order_Payment_Transaction class.

Order Status History

This one is very simple unit. It just used for tracking changes in order status with possibility to track some system message. The functionality is realized by Mage_Sales_Model_Order_Status_History.

Invoice

This entity is used to track actual payment capture operation for the order. Invoice has own items that are used for tracking payment state per every item qty in the order. As soon as invoice changes status to paid and a referencing order item sate and paid amount with qty will be updated.

There are two kind of invoices:

• Online This kind of invoice is not available if payment method haven’t supplied transaction identifier during authorization process. When you create an online invoice, it will interact with payment method model for capturing money via payment gateway.
• Offline This kind of invoice is always available in Magento. Mostly used with non-online payment method, like “Check/Money Order”. If you create such an invoice, it won’t charge real customer’s money, it will just register that order items were paid.

The functionality of invoice and its sub-entities is realized by the following classes:

• Mage_Sales_Model_Order_Invoice an invoice itself
• Mage_Sales_Model_Order_Invoice_Item an invoice item, that is linked to order item.
• Mage_Sales_Model_Order_Invoice_Comment an invoice comment for some system or custom messages of admin user.
• Mage_Sales_Model_Order_Invoice_Total_* all of this classes are realizing total collectors logic to calculate proper amount of invoice amounts, that need to be paid.

Shipment

This entity is used to track shipping status of the items in the order. When order state is changed to “processing”, it will be possible to create a shipment for particular order items or the whole order. The shipment is similar to invoice, except, that it has no total collectors and just registers qty that on item level for shipped items. As soon as all order items were shipped, the order will change its state to “complete”.

The functionality of the shipment and its sub-entities is realized by the following classes:

• Mage_Sales_Model_Order_Shipment a shipment itself
• Mage_Sales_Model_Order_Shipment_Item a shipment item, that is linked to order item.
• Mage_Sales_Model_Order_Shipment_Comment a shipment comment for some system or custom messages of admin user.
• Mage_Sales_Model_Order_Shipment_Track a tracking number record, that is used for tracking delivery by API of some delivery method (FedEx, DHL, UPS, etc).

Creditmemo

This entity is used for tracking refund process of the payment to customer for invoiced order items. Non-invoiced order items cannot be refunded, since no actual capture operation were registered for them.

There are two kind of creditmemos:

• Online This kind of creditmemo is not available if payment method haven’t supplied transaction identifier during capture process. When such a creditmemo is created it will refund money back to customer via payment method model.
• Offline Like an offline invoice, this kind of creditmemo will be used only to register refund in Magento.

The functionality of creditmemo and its sub-entities is realized by the following classes:

• Mage_Sales_Model_Order_Creditmemo a creditmemo itself
• Mage_Sales_Model_Order_Creditmemo_Item a creditmemo item, that is linked to order item.
• Mage_Sales_Model_Order_Creditmemo_Comment a creditmemo comment for some system or custom messages of admin user.
• Mage_Sales_Model_Order_Creditmemo_Total_* all of this classes are realizing total collectors logic to calculate proper amount for refunding only money that was paid for items specified in creditmemo.

All of these entities and other entities, that are defined in this module, will be described more in detail in the next articles with useful code snippets and customization guidelines.

Mage_Shipping module

This module is used for retrieving shipping costs and shipment tracking info for post sale process. It has a single model (Mage_Shipping_Model_Shipping), that reads configuration for gathering all the shipping carrier models and sends rate requests for calculation of shipping costs. All the carrier models are extended from Mage_Shipping_Model_Carrier_Abstract class, that is defined in this module.

Some carriers that are implemented by this module:

• Mage_Shipping_Model_Carrier_Tablerate Fixed carrier implementation, that calculates shipping prices based on data stored in the database table. The rate is calculated based on destination and one of order totals (weight, amount, qty, etc).
• Mage_Shipping_Model_Carrier_Flatrate Fixed carrier implementation, that calculates shipping prices based on fixed price specified in the admin panel. Calculation formula depends on configuration.
• Mage_Shipping_Model_Carrier_Freeshipping Fixed carrier implementation, that always gives zero shipping price. The availability of this shipping method depends on minimum order subtotal specified in configuration.

Mage_Payment module

This module is used during checkout process for retrieving of available payment methods and processing order payment later on. The payment methods are retrieved from configuration like shipping carriers in Mage_Shipping module.

All the payment method models are extended from an abstract class that is defined in this module (Mage_Payment_Model_Method_Abstract). Also this module has some generic payment methods that store owner already can use:

• Mage_Payment_Model_Method_Checkmo Offline payment method, that allows customer to pay in cash or by check. When customer choose this payment method, the information about check beneficiary will be shown (if admin user specified it).
• Mage_Payment_Model_Method_Ccsave Offline payment method, that stores creditcard number for further processing by admin user.
• Mage_Payment_Model_Method_Purchaseorder Offline payment method, that stores PO number for further processing by admin user.
• Mage_Payment_Model_Method_Free Offline payment method, that is used only when grand total of the order is equal to zero. In Enterprise version of Magento it is used to track order that are fully paid by customer balance, reward points or giftcards.

Of course there are more payment methods available in core, but they are implemented as standalone modules and can be disabled at any time. Mage_Payment module is always available.

Summary

This article itself cannot describe all the functionality of checkout, it is just a short overview. Anyway, I hope you got something valuable for yourself from it.
This article is only the first one in the series, so don’t forget to follow updates of our blog. There are more than ten topic drafts already, that are waiting to be shared with Magento community.

The post Magento Checkout: Functionality Concept appeared first on EcomDev Magento Developers.

The post Your project appeared first on EcomDev Magento Developers.

Frontend

• Full theme development from PSD
• Custom styled components for widgets (banners, featured, etc)
• Quick view feature
• Custom layered navigation with sliders

Backend:

• Shop migration
• Flight reservation system integration
• Complex delivery rules per products
• Integration with airline loyalty system
• Strict admin user restrictions
• Special PDF packing slips
• Special reports
• Special customer recognition system
• Customized checkout flow
• Special price appearance on the frontend

Our extensions:

• Multiple filters
• ExIm

The post KLM appeared first on EcomDev Magento Developers.