Manufacturers and wholesalers that need to digitize their sales process can be confused by the options. Just because something is called a “solution” doesn’t mean it will solve your problem. We’ve previously looked at eProcurement and punchout catalog solutions to see how they differ from eCommerce systems for B2B companies. Today, we conclude with a comparison of EDI and B2B eCommerce systems.

What is EDI?

Electronic Data Interchange (EDI) is a way for computers to transfer documents by using predetermined formats and digital rules. It is a direct data transfer between the sending and receiving company. No translators or extra processing is needed.

EDI arose as a way of solving the problem of transferring documents between businesses. If the Company A wants to buy or offer their customer widgets from Blue Widget Express, both companies are going to create documents that must be shared. Company A will prepare a Purchase Order (PO) to send to Blue Widget Express; Blue Widget Express must then create a Sales Order and Invoice. When humans create documents, errors are bound to occur; if computer programs create the document, the chances for error are dramatically decreased. Besides, computer-to-computer information exchange is much more cost-effective than handling paper documents. There’ve been studies that showed manual processing of paper-based order costs can go as high as $70 while computer processing costs are less than $1.
But, computers can only talk to each other when they have an agreeable format. This is where EDI comes into play.

How Does It Work?

Businesses that want to share documents using EDI must first agree on one of several EDI standards. These include ANSI, EDIFACT, TRADACOMS and ebXML to name a few. These standards provide a predetermined format for the information in the document. The larger business usually sets the standards and is unwilling to modify their EDI terms. This means the smaller business has to conform to these standards in order to do business. However, there are times when an EDI relationship can be highly custom with different pricing, fulfillment terms, and protocols.

So, let us provide a sample use case. From the example above, a Company A employee would prepare a PO using the agreed-upon standard and then electronically send it to Blue Widget Express. Blue Widget Express would receive the PO and it would be automatically entered as an order. Because Blue Widget Express isn’t manually entering the order, order entry and other human errors are eliminated. The order can be filled – with the sales order and invoice generated – and these documents are sent back electronically to Company A using the same predetermined format. Company A and Blue Widget Express no longer need to use the same software, as long as they agree on an EDI standard for sharing documents.

Is EDI Different from eCommerce?

EDI is a way of conducting commerce and it is electronic, so technically it is eCommerce. But it is more about transmitting documents and less about what actually goes into the buying and selling process. EDI is a means of placing orders, eCommerce is a way of not only accepting orders but providing buyers with a complete shopping experience including a front-end store. For example, if a buyer at Company A knows they need to buy 600 Tiny Aqua Widget SKU 148439 from Blue Widget Express, EDI is a perfect way to place the order. However, if the buyer isn’t sure what widget they need, or if they need specs on the Tiny Aqua Widget, or if they need to compare the Widget to another widget, EDI won’t be of much help. Let’s look at EDI and B2B eCommerce side-by-side.

Main benefits
EDI	eCommerce
Electronic ordering	Electronic ordering
Eliminates manual order entry	Eliminates manual order entry
Perfect for repeat orders	Perfect for researching products and brand promotion (although it supports repeat orders as well)
Doesn’t include product information	Contains complete product information
Excellent for automating orders based on inventory levels	Provides cross-selling & upselling opportunities
Use Cases
EDI	eCommerce
Manufacturer ordering/reordering raw materials	Manufacturer ordering supplies
Wholesaler ordering regular inventory	Wholesaler selling to distributors
Distributor ordering regular inventory	Distributors selling to retailers
Automated ordering based on inventory levels	Manufacturers/wholesalers selling direct

EDI and B2B eCommerce: Which Option is Better?

As a B2B seller, EDI is simply another way to accept orders from your existing customers. A sales rep doesn’t need to be available by phone to take the order, customers can order at any hour, it streamlines getting an order into your system and you don’t need to invest in the technological integration necessary for punchout catalogs. EDI is highly-efficient for the customer that knows what they want. eCommerce is built for reaching new markets and expanding sales with existing customers. With eCommerce you can easily upsell and cross-sell to existing customers. You can provide detailed product information for an improved buyer experience. In addition, product catalogs can be indexed by popular search engines where new buyers can be made aware of your offerings. eCommerce can process new RFQs when EDI works with already established agreements. While EDI and eCommerce both streamline the ordering process, only eCommerce has the ability to expand your customer base, penetrate new markets, and showcase your brand.

What Strategy is Right for You?

The right strategy is usually a blend of digital solutions, like EDI and B2B eCommerce. If your existing customers rely heavily on their e-procurement systems, it’s possible that EDI or punchout catalogs could simplify the ordering and approval process. But you can’t simply rely on those solutions alone.

To build new business and expand an existing business, eCommerce gives B2B buyers the online shopping experience that customers want. And to support the back-office, the right sales portal does more than handle sales orders. It can be used for support, marketing, and customer service.

For more information about finding the right digital solution to grow your business, talk to Oro.

blog-hero

In the rapidly changing eCommerce world, multiple payment options put every buyer just a few clicks from the purchase. Out of the box, OroCommerce supports the most popular and trusted payment methods:

PayPal Payments Pro.
Payflow gateway.
Invoices with configurable payment terms.
Check/Money Order.

You can hardly predict the next most popular online and offline payment company in your customer’s area or the next high-tech payment method to emerge, but you can be prepared to the change. With flexible and customizable open-source OroCommerce application, you can adjust quickly and support it the next day (well, maybe the next week).

This topic will guide you through adding a custom payment method for your OroCommerce-based B2B store. For this example. we’ve chosen collect-on-delivery payment, as it comes in many flavors (cash, credit card, and online wallet) and many people still consider it the most credible and risk-free option for online purchases.

Adding a new payment method

Step 1. Create and enable a bundle

Note: See Symfony best practices for naming and placing your bundle.

Create a new bundle that extends the PaymentBundle and enable it using the steps explained here. Briefly, they are:

Run a Symfony generate:bundle: command.
Note: Kernel and routing updates are not necessary, as OroPlatform automated these steps.

Create a bundles.yml file in Resources/config/oro/ folder with the following content:

    bundles:
        { name: OroBundleCollectOnDeliveryCollectOnDeliveryBundle, 
          priority: 100 }

Regenerate application cache using the cache:clear: command.
Note: In a production environment, add –env=prod parameter to the command.

Step 2. Implement payment method configuration

To define custom configurable options and manage visibility and availability of the payment method, bind it to the Configuration Settings using the following steps:

Update Configuration.php class in OroBundleCollectOnDeliveryDependencyInjection namespace with the configuration options, like in this example:

class Configuration implements ConfigurationInterface
    {
        const COLLECT_ON_DELIVERY_ENABLED_KEY = 'collect_on_delivery_enabled';
        const COLLECT_ON_DELIVERY_LABEL_KEY = 'collect_on_delivery_label';
        const COLLECT_ON_DELIVERY_SHORT_LABEL_KEY = 'collect_on_delivery_short_label';
        const COLLECT_ON_DELIVERY_SORT_ORDER_KEY = 'collect_on_delivery_sort_order';
        const COLLECT_ON_DELIVERY_ALLOWED_COUNTRIES_KEY = 'collect_on_delivery_allowed_countries';
        const COLLECT_ON_DELIVERY_SELECTED_COUNTRIES_KEY = 'collect_on_delivery_selected_countries';
        const COLLECT_ON_DELIVERY_ALLOWED_CURRENCIES = 'collect_on_delivery_allowed_currencies';
        /**
         * {@inheritdoc}
         */
        public function getConfigTreeBuilder()
        {
            $treeBuilder = new TreeBuilder();
            $rootNode = $treeBuilder->root('collect_on_delivery');
            SettingsBuilder::append(
                $rootNode,
                [
                    self::COLLECT_ON_DELIVERY_ENABLED_KEY => [
                        'type' => 'boolean',
                        'value' => false,
                    ],
                    self::COLLECT_ON_DELIVERY_LABEL_KEY => [
                        'type' => 'text',
                        'value' => 'Collect On Delivery',
                    ],
                    self::COLLECT_ON_DELIVERY_SHORT_LABEL_KEY => [
                        'type' => 'text',
                        'value' => 'Collect On Delivery',
                    ],
                    self::COLLECT_ON_DELIVERY_SORT_ORDER_KEY => [
                        'type' => 'string',
                        'value' => 60,
                    ],
                    self::COLLECT_ON_DELIVERY_ALLOWED_COUNTRIES_KEY => [
                        'type' => 'text',
                        'value' => PaymentConfiguration::ALLOWED_COUNTRIES_ALL,
                    ],
                    self::COLLECT_ON_DELIVERY_SELECTED_COUNTRIES_KEY => [
                        'type' => 'array',
                        'value' => [],
                    ],
                    self::COLLECT_ON_DELIVERY_ALLOWED_CURRENCIES => [
                        'type' => 'array',
                        'value' => CurrencyConfiguration::$defaultCurrencies,
                    ],
                ]
            );
            return $treeBuilder;
        }
    }

Next, define the custom configuration options in the system_configuration.yml in the Oro/Bundle/CollectOnDeliveryBundle/Resources/config/ folder. See the system configuration sample:

    oro_system_configuration:
    groups:
        collect_on_delivery:
            title: oro.collect_on_delivery.system_configuration.groups.collect_on_delivery.title
        collect_on_delivery_display:
            title: oro.collect_on_delivery.system_configuration.groups.display_options.title
    fields:
        collect_on_delivery.collect_on_delivery_enabled:
            data_type: boolean
            type: oro_config_checkbox
            priority: 100
            options:
                label: oro.collect_on_delivery.system_configuration.fields.enabled.label

        collect_on_delivery.collect_on_delivery_label:
            data_type: string
            type: text
            priority: 90
            options:
                label: orob2b.payment.system_configuration.fields.label.label
                tooltip: orob2b.payment.system_configuration.fields.label.tooltip
                constraints:
                    - NotBlank: ~

        collect_on_delivery.collect_on_delivery_short_label:
            data_type: string
            type: text
            priority: 90
            options:
                label: orob2b.payment.system_configuration.fields.short_label.label
                tooltip: orob2b.payment.system_configuration.fields.short_label.tooltip
                constraints:
                    - NotBlank: ~

        collect_on_delivery.collect_on_delivery_sort_order:
            data_type: string
            type: text
            priority: 80
            options:
                label: oro.collect_on_delivery.system_configuration.fields.sort_order.label
                constraints:
                    - OroB2BBundleValidationBundleValidatorConstraintsInteger: ~

        collect_on_delivery.collect_on_delivery_allowed_countries:
            data_type: string
            type: choice
            priority: 70
            options:
                label: orob2b.payment.system_configuration.fields.allowed_countries.label
                required: true
                constraints:
                    - NotBlank: ~
                choice_translation_domain: messages
                choices:
                    all: orob2b.payment.system_configuration.fields.allowed_countries.all
                    selected: orob2b.payment.system_configuration.fields.allowed_countries.selected
                attr:
                    'data-page-component-module': 'orob2bpayment/js/app/components/config-hide-fields-component'
                    'data-dependency-id': 'collect_on_delivery_allowed_countries'

        collect_on_delivery.collect_on_delivery_selected_countries:
            data_type: string
            type: oro_locale_country
            priority: 60
            options:
                label: orob2b.payment.system_configuration.fields.selected_countries.label
                multiple: true
                attr:
                    'data-depends-on-field': 'collect_on_delivery_allowed_countries'
                    'data-depends-on-field-value': 'selected'

        collect_on_delivery.collect_on_delivery_allowed_currencies:
            data_type: array
            type: oro_currency_selection
            priority: 60
            options:
                label: orob2b.pricing.system_configuration.fields.enabled_currencies.label
                required: true
                multiple: true
                constraints:
                    - NotBlank: ~

    tree:
        system_configuration:
            commerce:
                children:
                    payment:
                        priority: 400
                        children:
                            collect_on_delivery:
                                priority: 70
                                children:
                                    collect_on_delivery_display:
                                        priority: 100
                                        children:
                                            - collect_on_delivery.collect_on_delivery_enabled
                                            - collect_on_delivery.collect_on_delivery_label
                                            - collect_on_delivery.collect_on_delivery_short_label
                                            - collect_on_delivery.collect_on_delivery_sort_order
                                            - collect_on_delivery.collect_on_delivery_allowed_countries
                                            - collect_on_delivery.collect_on_delivery_selected_countries
                                            - collect_on_delivery.collect_on_delivery_allowed_currencies

Note: ConfigBundle guarantees that configuration from the system_configuration.yml is applied. Administrator can still manage the same settings in OroCommerce UI.

After that, in Oro/Bundle/CollectOnDelivery/Method/Config/CollectOnDeliveryConfigInterface.php, declare the configuration interface:

<?php

    namespace OroBundleCollectOnDeliveryMethodConfig;

    use OroB2BBundlePaymentBundleMethodConfigPaymentConfigInterface;
    use OroB2BBundlePaymentBundleMethodConfigCountryConfigAwareInterface;
    use OroB2BBundlePaymentBundleMethodConfigCurrencyConfigAwareInterface;

    interface CollectOnDeliveryConfigInterface extends
        PaymentConfigInterface,
        CountryConfigAwareInterface,
        CurrencyConfigAwareInterface
    {
    }

Next, implement a class with the methods that read configuration option values:

<?php

        namespace OroBundleCollectOnDeliveryMethodConfig;

        use OroBundleCollectOnDeliveryDependencyInjectionConfiguration;
        use OroBundleCollectOnDeliveryMethodCollectOnDelivery;
        use OroB2BBundlePaymentBundleDependencyInjectionConfiguration as PaymentConfiguration;
        use OroB2BBundlePaymentBundleMethodConfigAbstractPaymentConfig;
        use OroB2BBundlePaymentBundleMethodConfigCountryAwarePaymentConfigTrait;
        use OroB2BBundlePaymentBundleMethodConfigCurrencyAwarePaymentConfigTrait;

        class CollectOnDeliveryConfig extends AbstractPaymentConfig implements CollectOnDeliveryConfigInterface
        {
            use CountryAwarePaymentConfigTrait, CurrencyAwarePaymentConfigTrait;

            /** {@inheritdoc} */
            protected function getPaymentExtensionAlias()
            {
                return CollectOnDelivery::TYPE;
            }

            /** {@inheritdoc} */
            public function isEnabled()
            {
                return (bool)$this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_ENABLED_KEY);
            }

            /** {@inheritdoc} */
            public function getOrder()
            {
                return (int)$this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_SORT_ORDER_KEY);
            }

            /** {@inheritdoc} */
            public function getLabel()
            {
                return (string)$this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_LABEL_KEY);
            }

            /** {@inheritdoc} */
            public function getShortLabel()
            {
                return (string)$this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_SHORT_LABEL_KEY);
            }

            /** {@inheritdoc} */
            public function isAllCountriesAllowed()
            {
                return $this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_ALLOWED_COUNTRIES_KEY)
                    === PaymentConfiguration::ALLOWED_COUNTRIES_ALL;
            }

            /**
             * @inheritDoc
             */
            public function getAllowedCountries()
            {
                return (array)$this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_SELECTED_COUNTRIES_KEY);
            }

            /**
             * @inheritDoc
             */
            public function getAllowedCurrencies()
            {
                return (array)$this->getConfigValue(Configuration::COLLECT_ON_DELIVERY_ALLOWED_CURRENCIES);
            }
        }

Step 3. Define a configuration service

In Resources/config/services.yml, add service definition for the implementation above, like in the following example:

    oro_collect_on_delivery.method.config:
        class: 'OroBundleCollectOnDeliveryMethodConfigCollectOnDeliveryConfig'
        public: false
        arguments:
            - '@oro_config.manager'

Step 4. Implement a payment method

Note: Sources are normally grouped under the Method namespace. In our example, the CollectOnDelivery.php has OroBundlePaymentBundleMethod namespace.

As we are extending the PaymentBundle that has dedicated PaymentMethodInterface, we are to implement the following methods:

execute method that is responsible for payment transaction processing (including requests to external payment gateways and updating transaction status upon their response).
For collect on delivery, we need two actions: payment that marks payment transaction as authorized, active and successful, and capture that finalizes payment transaction and changes payment status to ‘Paid in full’.
getType method that returns a unique payment method id. In our sample, getType returns collect_on_delivery value.
isEnabled allows verifying that the payment method is enabled. Usually, this information is based on the configuration settings.
isApplicable allows limiting payment availability based on specific conditions (e.g. currency filter and country filter are supported in the latest version of OroCommerce).
supports method defines the actions supported by payment method. For the collect on delivery, supported methods are PURCHASE (an alias for AUTHORIZE) to start payment process and CAPTURE to confirm payment.

Here is the sample implementation for the collect on delivery payment method (in Oro/Bundle/CollectOnDelivery/Method/CollectOnDelivery.php):

<?php

    namespace OroBundleCollectOnDeliveryMethod;

    use OroBundleCollectOnDeliveryMethodConfigCollectOnDeliveryConfigInterface;
    use OroB2BBundlePaymentBundleEntityPaymentTransaction;
    use OroB2BBundlePaymentBundleMethodPaymentMethodInterface;

    class CollectOnDelivery implements PaymentMethodInterface
    {
        const TYPE = 'collect_on_delivery';

        /** @var CollectOnDeliveryConfigInterface */
        private $config;

        /**
         * @param CollectOnDeliveryConfigInterface $config
         */
        public function __construct(CollectOnDeliveryConfigInterface $config)
        {
            $this->config = $config;
        }

        /** {@inheritdoc} */
        public function execute($action, PaymentTransaction $paymentTransaction)
        {
            switch ($action) {
                case self::PURCHASE: // on order review step create authorization transaction
                    $paymentTransaction
                        ->setAction(self::AUTHORIZE)
                        ->setActive(true)
                        ->setSuccessful(true);
                    break;
                case self::CAPTURE: // on order view page allow to mark order paid in full
                    $paymentTransaction
                        ->setActive(false)
                        ->setSuccessful(true);

                    // for CAPTURE transaction sourcePaymentTransaction is  AUTHORIZE one, so lets mark it inactive after capure
                    $sourcePaymentTransaction = $paymentTransaction->getSourcePaymentTransaction();
                    if ($sourcePaymentTransaction) {
                        $sourcePaymentTransaction->setActive(false);
                    }
                    break;
                default:
                    throw new InvalidArgumentException(sprintf('Action %s not supported', $action));
            }

            return [];
        }

        /** {@inheritdoc} */
        public function getType()
        {
            return self::TYPE;
        }

        /** {@inheritdoc} */
        public function isEnabled()
        {
            return $this->config->isEnabled();
        }

        /** {@inheritdoc} */
        public function isApplicable(array $context = [])
        {
            return $this->config->isCountryApplicable($context)
                && $this->config->isCurrencyApplicable($context);
        }

        /** {@inheritdoc} */
        public function supports($actionName)
        {
            return in_array((string)$actionName, [self::PURCHASE, self::CAPTURE], true);
        }
    }

Step 5. Define a payment method service

In Resources/config/services.yml, for the implementation above, add service definition with orob2b_payment.payment_method tag, like in the following example:

    oro_collect_on_delivery.method:
        class: 'OroBundleCollectOnDeliveryMethodCollectOnDelivery'
        public: false
        arguments:
            - '@oro_collect_on_delivery.method.config'
        tags:
            - { name: orob2b_payment.payment_method }

Step 6. Implement a view layer

A PaymentBundle has a dedicated PaymentMethodViewInterface that call for the following methods implementation:

getOptions should return available configuration options. You can filter the options using context.
getBlock should return the block name (template) for payment method.
getOrder helps manage payment method order on checkout.
getLabel and getShortLabel should return the label or shortLabel from the configuration.
getPaymentMethodType returns payment method type (in our example it is ‘collect_on_delivery’).

Here is the sample implementation for the view layer for collect on delivery payment method (in Oro/Bundle/CollectOnDelivery/Method/View/CollectOnDeliveryView.php):

    <?php

    namespace OroBundleCollectOnDeliveryMethodView;

    use OroBundleCollectOnDeliveryMethodCollectOnDelivery;
    use OroBundleCollectOnDeliveryMethodConfigCollectOnDeliveryConfigInterface;
    use OroB2BBundlePaymentBundleMethodViewPaymentMethodViewInterface;

    class CollectOnDeliveryView implements PaymentMethodViewInterface
    {
        /** @var CollectOnDeliveryConfigInterface */
        private $config;

        /**
         * @param CollectOnDeliveryConfigInterface $config
         */
        public function __construct(CollectOnDeliveryConfigInterface $config)
        {
            $this->config = $config;
        }

        /** {@inheritdoc} */
        public function getOptions(array $context = [])
        {
            return [];
        }

        /** {@inheritdoc} */
        public function getBlock()
        {
            return '_payment_methods_collect_on_delivery_widget';
        }

        /** {@inheritdoc} */
        public function getOrder()
        {
            return $this->config->getOrder();
        }

        /** {@inheritdoc} */
        public function getLabel()
        {
            return $this->config->getLabel();
        }

        /** {@inheritdoc} */
        public function getShortLabel()
        {
            return $this->config->getShortLabel();
        }

        /** {@inheritdoc} */
        public function getPaymentMethodType()
        {
            return CollectOnDelivery::TYPE;
        }
    }

Step 7. Add a template / layout

Finally, to enable compatibility with the new OroPlatform
Layout feature available in the Layout Component, add a bundle-specific template and block layout in CollectOnDelivery/Resources/views/layouts/default/ folder. Create the following files:

A new_payment_method_block.html.twig file with the similar contents:

    {% block _payment_methods_collect_on_delivery_widget %}
    <div>
    </div>
    {% endblock %}

A layout.yml file with the content similar to the following:
```
    layout:
        actions:
            - @setBlockTheme:
                themes: 'CollectOnDeliveryBundle:layouts:default/collect_on_delivery_block.html.twig'
```
Note: JS component is necessary for redirecting a user from the Order review step to the Finish Checkout step.
Preview
Once you build OroCommerce with the new payment method and enable it in OroCommerce configuration, it becomes visible in the Open Order process on the Payment step:
When a customer submits an order, payment status changes to “Payment authorized”:
Upon delivery and payment collection, the administrator uses Capture action that is available on the top right of the Order details screen.
Once payment is captured, the order status changes to Paid if full.
Source files
Source files of the collect on delivery bundle that was used as a sample for new payment method creation are available on github.

While it’s still quite early in the year and the operational loads are not as high as during the insanity of Christmas sales, January is just about the best time of the year to review your systems and infrastructure against the best practices, your projected (and budgeted) needs and potentially new legal requirements.

To help you with this we have prepared and are now releasing this Reliable and Secure Infrastructure for OroCommerce guide to cover the basics to look out for.

The main valuables you will find in the guide are:

How to estimate workload and data size, which parameters need to be taken into consideration, which aspects the workload is going to depend on and how to plan the capacities accordingly;
Basics of making your systems reliable and scalable, which platforms and components have proven to work well with OroCommerce, what are the best ways to secure both scalability and availability and more;
Monitoring your operations, the scope of monitoring that is an industry must (spoiler: it will range from performance to security incidents), tools and platforms to build an adequate monitoring system and things to look out for when monitoring;
How to make your deployments secure from the start: although Oro closely follows the Open Web Application Security Project (OWASP) recommendations at all stages of the deployment and the standard deployment is designed to work with the payment gateways riding our customers from having to store any cardholder data, we would still like to make a few recommendations you will find useful.

Additionally, as the cherry on the cake, especially valuable for those planning or auditing the eCommerce deployments, we’ve thrown in Sample Deployment Configurations. In this section, you will find three sample deployments you could use as a baseline if you are just planning your infrastructure, or match against if you are auditing or looking to improve.

The three Sample Deployment Configurations are:

Minimum Deployment Configuration – a basic config which can be used for planning and budgeting your infrastructure at the earliest stages of your eCommerce project, when you have relatively low traffic or you are just testing the concept).
Scalable Deployment Configuration – this option is recommended for scalability from the start if you require support for huge catalogs or you plan to quickly expand to multiple localizations and sub-brands.
Secure Deployment Configuration is similar to the Scalable Configuration, with one difference: every component of the system is moved to a dedicated subnet, which will mitigate the possible intrusions by isolating tiers from one another.

We hope you will find this guide useful. Should you wish to share your own best practices, or discuss other infrastructure variations, please drop us a line in the comments below or at our forums.

As we constantly revise Oro’s products for improvements, we do our best to update the Oro community on the newest application upgrades in the most informative way. From now on, we’ll be moving to a different format for our regular OroCRM and OroCommerce maintenance releases announcements. What’s new about it?

In our blog, we’ll be summarizing the new releases once per month. Along with that, we’ll be providing a recap of the enhancements and bug fixes made within the long-term support (LTS) maintenance releases and offer quick links to the minor versions’ of the maintenance releases.

To be instantly alerted of the new maintenance releases, follow our OroCRM EE, OroCRM CE, OroCommerce EE and OroCommerce CE GitHub repositories and check out our release schedule to get an idea of when new versions will be available.

And now, let’s finally give our new announcement format a try and see what improvements the latest maintenance releases include.

New LTS Maintenance Releases for OroCRM and OroCommerce

OroCRM Enterprise Edition 2.0.35

In OroCRM Enterprise Edition 2.0.35, the following items have been improved:

The text of the system notification that appears when creating a new event in the calendar has been changed to be more user-friendly.
Users can now make all necessary changes when editing workflows.
Image resizer now functions properly.
The work of the security facade service decorator has been improved.

For the complete list of enhancements, check out the respective * GitHub repository and the OroCRM Enterprise 2.0.35 release notes.

* Note that all of our GitHub repos for the Oro products’ Enterprise Editions are only available to the logged in Enterprise users.

OroCRM Enterprise Edition 1.12.35

The maintaining release of version 1.12.35 for OroCRM Enterprise Edition provides general performance improvements and the following bug fixes:

The “Create E-Mail Template” works properly when being opened.
Search by tags added to the cases converted from emails works as intended.

To learn more about OroCRM Enterprise Edition 1.12.35, visit the respective GitHub repository and view the OroCRM Enterprise 1.12.35 release notes.

OroCRM Enterprise Edition 2.3.19

The major improvements OroCRM Enterprise Edition 2.3.19 introduces include the following:

OroPlatform 2.x LTS dependency on Symfony 2.8 has been upgraded to the latest patch version.
Import via message queue has been improved to properly initialize file reader and writer.
The global view issue and ownership issues have been resolved.
Export jobs have been improved to exclude temp folder overflow
The amount of unexpected queue messages for user’s success login tracking has been decreased.

For the complete list of enhancements, check out the respective GitHub repository and the OroCRM Enterprise 2.3.19 release notes.

OroCommerce Enterprise Edition 1.3.19

OroCommerce Enterprise Edition 1.3.19 provides the application enhancements as follows:

The WYSIWYG Editor has been enabled for the content blocks.
Applying filters and deleting products using the management console is resolved.
Applying sorter filters and merging Account or Contact using the management console is error free.
The process of creating promotions and adding products to them has been improved to ensure no errors occur.
The validation of the product’s localizedfallbackvalues field on /product/view now works as intended.

OroCommerce Enterprise Edition 1.3.19 GitHub rep will provide you with more technical details. Make sure to read the release notes, too.

Minor Maintenance Releases for OroCRM and OroCommerce

OroCRM Enterprise Edition 2.4.9

Visit the GitHub repository and read the OroCRM Enterprise Edition 2.4.9 release notes.

OroCommerce Enterprise Edition 1.4.9

This maintenance release introduces a few minor fixes to ensure a smooth user experience and an increased security level. Here you can view all of the changes to the application and look through the release notes for OroCommerce Enterprise Edition 1.4.9.

OroCRM Enterprise Edition 2.5.2

The maintenance release of version 2.5.2 for OroCRM Enterprise Edition is dedicated mostly to insignificant bug fixes you can learn about more by visiting this GitHub repository and viewing the release notes.

OroCommerce Enterprise Edition 1.5.2

The OroCommerce EE 1.5.2 maintenance release provides several performance optimizations. To find out what they are, follow this link that will take you to the repository. Here you can also find the accompanying release notes.

Stay tuned for the next batch of the Oro maintenance releases we’ll blog about in a couple of weeks.

Do let us know what you think about our new format in the comments section below. Every feedback counts and will help us best deliver the best offering to our Community.

We’d like to inform our Community of the immediate availability of the maintenance release of version 1.0.34 for OroCommerce Enterprise Edition (EE).

The release provides application bug fixes and delivers general performance improvements.

For the complete list of enhancements, visit our GitHub repositories or simply follow the links below (please first log into GitHub):

OroCommerce EE 1.0.34 Application * (click here to view the release notes)

* The links lead to the private GitHub repository only available to the OroCommerce EE users.

To upgrade OroCommerce to the latest version, please follow the steps provided in the OroCRM upgrade and clone instructions as the upgrade process is similar (ensure you are using the orocommerce.git repository or files from http://oroinc.com/b2b-ecommerce/download page).