Vnecoms extentions

Perspective team has been working on a fashion marketplace on the VnEcoms extensions for a long time. The project covers all stages of development, from UI/UX design to QA and testing. Today it is already in pre-deployment condition. So we have a lot to talk about and are happy to share.

Often, the Magento platform is associated with the development of online stores only. However, it allows businesses to scale up to the multi-vendor marketplace. The following components of the marketplace system are Merchant Administration System, Product Information Management, Order Management System, Billings, Reporting&Analytics.

During the development of the fashion marketplace, we applied a group of extensions from VnEcoms. However, the extensions only cover some customer needs, which is a usual practice. After all, every business has its peculiarities. The customization has been subject to many processes, and we would like to tell you more about them.

  1. Firstly, we have simplified the process of seller registration. We built the logic of the seller filling in a form on the page of the marketplace: the data from the form gets into the administrative panel. The main admin receives notifications to the e-mail address and on the admin panel about a new request and confirms it.
  2. Registration of the order was automatized. How it looks: the seller presses the eccept button when receiving the order and automatically creates an invoice, shipment, and the delivery of waybills. Also added an opportunity to edit the order.
  3. The management of orders was modified. Below you can see the view of the personal account before and after modification. Orders are distributed according to the status: new, processing, combined or canceled. For a seller, it is way more convenient to track the order.
  4. The Vendor RMA from VnEcoms was modified to meet the client’s needs. Previously, its function allowed a return from only one seller at a time. We have created a logic so that you can choose products from any seller when returning. It became more accessible for the buyer to manage the registration and return process.
  5. Another case is the development of the delivery function. It’s a separate story. Since it was an international multi-vendor marketplace, the owner chose DHL as the logistics operator for order delivery. The Magento platform has a module for the DHL delivery method but not for the marketplace. VnEcoms also has it. However, it is designed to work for one seller, so that is one DHL account. Both options did not solve the technical task. As a result, we have redesigned the module provided by VnEcoms to work with one account. During the process, there was a problem with the correctness of ratings (UK presence). As it turned out, DHL API did not consider the Brexit fee then. After that, we finalized the functionality. Also, a function was developed for reserving the address ban of shipments. The seller gets a new order and clicks accept, then automatically creates an invoice, shipment with the generation of packages and receiving shipping labels, and a tracking number from DHL. The order status changes to processing. Once the invoice is created, the DHL Address Ban button is available. Additionally, a feature has been developed that sends requests to the DHL API twice daily on cron and checks the post statuses. If it’s delivered, then the order is considered final, and only after that can the seller make a return. The buyer can also monitor the order’s status through the tracking number in his account. This mechanism has been used to ensure that the tracking number is automatically displayed on the DHL page.
  6. In this case, we had to realize a highly complex pricing logic. We have developed a price-setting module specifically for the client’s technical task. It was essential to keep the primary function of Magento. The first thing that complicates the pricing mechanism is the marketplace’s geography. It has different stores depending on the buyer’s region: UK, USA, EU, GLOBAL. Accordingly, for other buyers, there are various taxes, additional costs of delivery, and so on. In general, the charge is calculated taking into account six indicators. That is why the same goods in different stores can be fundamentally different in meaning of price. We have created the function so that the seller in his office displays the cost of the goods. The final cost considers all the indicators and is calculated automatically for each store. On the site, the buyer sees the final cost of the product, formed according to the pricing logic. The seller has retained all basic marketing logic (special price, group price, and tier price) at the level of the page, and the store owner can manage the catalog price.
  7. For transactions on the site, use the payment service Stripe. It is customized accordingly to business needs. When creating or supporting regular online stores, meeting such a function as the division of payment between several participants was not necessary. In this case, we met a task that says the full payment does not fall on account of the market’s owner but only the commission.
    VnEcoms has a module for Stripe, but it did not cover our needs. Thanks to the modification, the module removes funds from the bank card and assigns the accounts to the owner of the business and the seller of goods. The market owner is given a сommission, the spent parts, and the delivery cost. The seller receives at the expense of the product sum, which was made at its creation, with the deduction of the basic commission.

In addition to VnEcoms modules, more than a dozen other vendor modules were used to cover the customer’s needs. Some of them we’ve installed without changes, and others are customized:

Amasty_Magento 2 layered Navigation – for filtering products.

Additionally, we have extended the functionality of the module as follows:

  • if you get on the category page, all filters are available
  • in the process of filtering, filters that were previously “disappeared” are now visible, although they are inactive.

BSSCommerce_Magento Multiple Store View Pricing.

A group of modules was used to install price points at the page level.

FME_Magento 2 Product Image Zoom. Photo Gallery & Product Image Gallery.

The modules are installed for the product image zoom and gallery in general.

Age Array_Form Builder

The module allowed the client to create forms conveniently and place them on the site pages.

Mageplaza_Blog

They used extensions to create a blog for sellers.

Mageplaza_StoreSwitcher

Enabled us to redirect our clients from different countries to the right side and switch to the correct currency.

Mageplaza_SocialLogin

The module provides client login through social networks.

Ebizmarts_MailChimp

The module that manages mail.

Modules from Mirasvit

Magento 2 Improved Asynchronous Re-indexing Mirasvit, Magento 2 Full Page Cache Warmer Extension for warming the cache and re-indexing from the admin, Knowledge Base Extension for creating a seller and customer knowledge base.

Source: https://www.fintechnews.org/marketplace-development-based-on-vnecoms-extensions/