Skip to main content

Other Channel Types

Marketplace​

For integration with the marketplace from Omnitron, there are certain operations that must take place such as reconciliation processes, mapping of attributes, etc. As in every marketplace, there are two different roles. One is the marketplace, and the other is the supplier;

Marketplace can sell its own products through any channel, as well as the products of all suppliers in reconciliation, through this platform.

Supplier can sell their own products through any channel, as well as through the marketplaces, in reconciliation and as channels. In other words, a company providing the marketplace system through the Omnitron does not prevent the sale of its own products and does not cause any problems for the supplier either.

Model Structure​

We can discuss this section under two items; marketplace and supplier. For the marketplace, an order is created using a model derived from Order, called Vendor Order. This allows us to distinguish orders. (omnitron.orders.models.VendorOrder)

Figure 1: VendorOrder Model Fields and Inheritance

For the supplier, an order is created using the Order model without any differences from normal order. (omnitron.orders.models.Order)

Data Source is the model name of the digital contract. Contains name, stock_list, price_list, is_active, commission_rate, maturity_rate, token, conf and supplier_code.

Figure 2: DataSource Model it’s Relations

Reconciliation is the model name of the reconciliation previously referred to. Contains data_source, channel, start_date, end_date, status, creation_type(automatic or manuel), item_selection_type(orderitem or orderitem and cancellation),number, name, total_income, total_expanse, total_commission, commission, maturity and conf. When the necessary contexts are provided through the frontend, the relevant record is created.

Figure 3: Reconciliation Model it’s Relations

VendorOrder; An Order model unlike the normal Order is created and linked with this model inherited from the Order with a foreignkey (order). data_source and sent_date are also in this model.

Figure 4: Fields only in VendorOrder

VendorOrderItem; Inherited from OrderItem. And the order foreign key is linked directly as VendorOrder. As in VendorOrder, the OrderItem model is created and linked with the model with a foreignkey (base).

Figure 5: VendorOrderItem Model Fields and Inheritance

Script​

After providing the attribute mapping that needs to be entered for the supplier from the marketplace Omnitron, the contract must be created from the Unified Digital Contract screen of the Unified Network menu from the marketplace Omnitron.


{
   "reconciliation_conf":{
      "data_source_name":"AD",
      "item_selection_strategy":{
         "days_later":6,
         "strategy_type":"delivered_date"
      },
      "commission":"10.00000",
      "maturity":90,
      "creation_strategy":{
         "day_of_week":2,
         "strategy_type":"weekly"
      },
      "creation_strategy_change_date":"2020-02-10 16:06:19.979257+00:00"
   }
}

If the supplier is from Omnitron, the channel type must be created by selecting Unified on the Sales Channels screen accessed from the Settings menu. When unified is selected, the input field will open for entering the unified digital contract key. The API key value provided when creating the digital contract from the Marketplace Omnitron must be entered in this input field.

Conf. example of the relevant channel,

{
  "token": "<marketplace token>",
  "server": "http://<marketplace_url>",
  "shipping_company": "ups"
}

The user must wait for 10-15 minutes after these operations. Meanwhile, the digital contract process begins. The process is completed with the execution of the relevant tasks.

Service​

VendorOrderService​

(omnitron.orders.service.VendorOrderService)

  • create_order: The method used to create vendor orders. number, channel and data_source perform existence checks and create the vendor order.

  • update_order: sends the old_status, old_cancel_status and old_external_status values to audit context for recording the statuses. If the status update has been sent to the relevant method, it is sent to the order items with update_order_item in VendorOrderItemService, and then to update_order_item in OrderItemService. Finally, what needs to be updated in order is updated and saved.

  • order_status_update: After controlling whether there are active items of order, if there is none, is_refund is controlled and the order status value is updated as refunded if is_refund True, and as cancelled if not. If there are active items, we advance the process by adding the status value of the active OrderItem.

  • reject_order_cancel: As in update_order, it is sent to the audit context for recording the statuses. Then we send the order linked to the vendor order to reject_order_cancel in OrderService. We follow this with order_status_update.

  • approved_order_cancel: As in update_order, it is sent to the audit context for recording the statuses. Cancellation_info control is made; if there is none, cancellation_info is added, if there is any, the approving party is entered. If this party is data_source, operations such as adding invoice_number are carried out. If ERP, it is sent to approved_order_cancel in OrderService. It is then sent to order_status_update.

  • cancel_order: Here, we first collect the reasons in the order that is linked to the vendor order; then, we send the order linked to the vendor order to cancel_order in OrderService.

Figure 6: VendorOrderService Methods

VendorOrderItemService​

(omnitron.orders.service.VendorOrderItemService)

  • create_order_item: A method that allows to create vendor order items.

  • update_order_item: Sends the order item linked to the vendor order item to update_order_item in OrderItemService.

  • bulk_update_order_item: Puts through serializer for update and sends to update_order_item_with_base.

  • update_order_item_with_base: First, it sends the order item linked to the vendor order item to update_order_item in OrderItemService. It then checks that retail_store in shipping_address and the order.status value are delivered, and sends to update_base_order_item.

  • update_base_order_item: Collects certain data and sends the order item linked to the vendor order item to update_order_item in OrderItemService.

  • update_order_item_send_stock: Sends the product_stock value in stock_list linked to order_item to update_sold_quantity_reported method in ProductStockService.

  • send_shipping_info: Sends the order item linked to the vendor order item to send_shipping_info in OrderItemService.

Figure 7: VendorOrderItemService Methods

Channel Tasks​

All tasks are in omnitron.channels.integrations.akinon.tasks. As in other channels, there is data that the supplier needs to send. Tasks such as providing price & stock information, sending products, picking orders, etc. are located here.

Commands are located on serializer_class in omnitron.channels.integrations.akinon.integration.Integration.

These are:

  • InsertProduct: Throws a post to omnitron.products.resources.views.DistributedProductViewSet and inserts the product.

  • UpdateProduct: Inherited from InsertProduct. The product is updated by throwing a PUT request to the same location.

  • CreateProductIntegrationObject: Throws a GET request to omnitron.products.resources.views.DistributedProductViewSet and picks the products. Defined as the failed action of InsertProduct.

  • UpdateOrderIsSend: Throws a PATH request to omnitron.orders.resources.views.VendorOrderViewSet and updates the send status.

  • UpdateSendStock: Throws a POST request to omnitron.orders.resources.views.VendorOrderItemViewSet and updates stock.

  • InsertImage: Throws a POST to omnitron.products.resources.views.DistributedDownloadableImageViewSet and allows to insert images for the relevant product.

  • CreateDownloadableImageIntegrationObject: Defined as the failed action of InsertImage. Throws a GET request to omnitron.products.resources.views.DistributedDownloadableImageViewSet.

  • DeleteProduct: Throws a DELETE request to omnitron.products.resources.views.DistributedProductViewSet with the remote id information of the product to be deleted.

  • GetAttributeValues: Throws a GET request to omnitron.products.resources.views.DistributedAttributeValueViewSet and gets the attribute values.

  • GetAttributeSets: Throws a GET request to omnitron.products.resources.views.DistributedAttributeSetViewSet and gets the attributesets.

  • UpsertStock: Throws a POST request to omnitron.catalogs.resources.views.DistributedProductStockViewSet and carries out bulk update if there is stock, or bulk addition if there is no stock.

  • UpsertPrice: Carries out price update and addition actions such as UpsertStock. Destination of the thrown request is; omnitron.catalogs.resources.views.DistributedProductPriceViewSet

  • GetOrders: Request is thrown with GET request from omnitron.orders.resources.views.VendorOrderViewSet and in line with certain conditions. For instance; in case of start_date, end_date and order_number and get_url conditions, it is added to the filter, the query is completed and the request is thrown.

  • CancelOrders: Request is sent to the omnitron.orders.resources.views.VendorOrderViewSet.cancel endpoint. The integration action of the sending party is added based on the response to this request.

  • UpdateOrderItems: When there is an update requirement for order items, a patch request is sent to omnitron.orders.resources.views.VendorOrderItemViewSet.

  • BulkUpdateOrderItems: Does the same thing as UpdateOrderItems, but in bulk.

  • GetCancellationPlans: A request is thrown to omnitron.orders.resources.views.VendorCancellationPlanViewSet. It collects all created cancellation plans and creates those not available.

  • ApproveCancellationPlan: Throws a POST request to omnitron.orders.resources.views.VendorOrderViewSet.cancellation_approved_order endpoint for the approval of the cancellation of the relevant order.

  • RejectCancellationPlan: Throws a POST request to omnitron.orders.resources.views.VendorOrderViewSet.cancellation_reject_order endpoint for the rejection of the cancellation of the relevant order.

  • RejectOrderCancel: Does the same things as RejectCancellationPlan.

  • GetReconciliations: Throws a GET request to omnitron.orders.resources.views.VendorReconciliationViewSet and gets reconciliations. Suspends or proceeds with orders according to the reconciliation status.

  • UpdateReconciliationStatus: Throws a POST request to omnitron.orders.resources.views.VendorReconciliationViewSet and notifies the other party of the update in the reconciliation.

  • CreateOrderIntegrationObject: Throws a GET request to omnitron.orders.resources.views.VendorOrderViewSet with order number filter and creates integration actions for order and order items in the supplier.

  • CreateOrderItemIntegrationObject: Throws a GET request to omnitron.orders.resources.views.VendorOrderViewSet and creates integration actions for order items in the supplier.

  • DeleteImage: Throws a DELETE request to omnitron.products.resources.views.DistributedDownloadableImageViewSet and updates downloadable image in seller.

  • UpdateImage: Throws a PUT request to omnitron.products.resources.views.DistributedDownloadableImageViewSet with order number filter and creates integration actions for order and order items in the supplier.

Views​

omnitron.orders.resources.views.VendorOrderViewSet Inherited from OrderViewSet. There are two more methods different from OrderViewSet; these are on get_queryset and cancel. For get_queryset, the data source has been filtered and returned through the orders with the token in the request and the token in the datasource. For cancel, such a course of action has been taken for data source control.

Figure 8: VendorOrderViewSet Structure

omnitron.orders.resources.views.VendorOrderItemViewSet

In this class, it has been inherited from OrderItemViewSet.

  • get_queryset: The data source has been filtered and returned through the orders with the token in the request and the token in the datasource

  • perform_update: Overridden so that the serialized data is sent to omnitron.orders.service.VendorOrderItemService.update_order_item_with_base method.

  • bulk_update: Overridden so that the request data is sent to omnitron.orders.service.VendorOrderItemService.bulk_update_order_item method.

Figure 9: VendorOrderItemViewSet Structure

Serializers​

omnitron.orders.resources.serializers.VendorOrderSerializer

Inherited from OrderSerializer.

omnitron.orders.resources.serializers.VendorOrderCreateSerializer

Inherited from OrderSerializer, with validate method overridden. Here, discount_amount, amount and installment_interest_amount’s orderitems linked to the vendor order were fetched as and filled in as attrs.

omnitron.orders.resources.serializers.VendorOrderItemSerializer

Inherited from BaseOrderItemSerializer.