This article aims to describe the entire flow of the integration with Netshoes so it will become clear how the integration works and what is the expected behavior in each step. The tutorial is divided into five stages:

1. Product Flow
2. Inventory
3. Prices
4. Promotions
5. Order Flow

The integration sends product, inventory and prices in separate entities. Once the products are sent successfully, you can find them at Netshoes. The integration sends the following fields:

Products	SKU
Name *	EAN
Description*	Weight*
Specifications¹	Height*
-	Width*
-	Length*
-	Images*
-	Specifications¹

Required fields are asterisked.

¹ Some specifications are required. To learn more, click here.

Specifications are sent if they conform to Netshoes' expected values. That is, when you submit a product, the integration scans its specifications. If they find any that matches the expected value of the product category in Netshoes, it sends the specification. If the specification does not have the expected value, the integration doesn't send the specification.

Ex: for a shirt that has the specification "Material", the integration will send the values used in it.

Ex: Material - Cotton

When the specifications are successfully sent for the first time, Netshoes receives the products and performs an internal cataloging process. Once they are approved by Netshoes, the integration does not update the product information because it would undo the ones that have already been registered. If you want to make any changes to the product information, you need to make them directly in Netshoes.

Ex: If the product description is changed, the integration will not update the description inside the marketplace.

Note: The product can not be deleted in the Netshoes panel, so it may be sent by the integration again.

At Netshoes, products have two possible statuses:

• Active: available for sale
• Inactive: unavailable for sale, in which case the product isn't shown in the marketplace.

There they are grouped by a product that has several variations/SKUs.

Ex: Blue shirt (product) | S, M, L (variations/SKUs)

The category is sent according to the Department filled in the mapping worksheet.

Netshoes only receives inventories for products that have already been successfully sent. Before this, stock sendings are rejected.

Once the cataloging process is finished in Netshoes, the integration automatically sends the products inventory, as long as the Approved Products API Notification is configured (learn more here.

After the products receive the first stock load, the update is made SKU by SKU whenever there's a stock change in VTEX.

Note: The inventory data sent to Netshoes is registered to our system for only 3 months.

Netshoes only receives prices for products that have already been successfully sent. Before this, price sendings are rejected.

Once the cataloging process is finished in Netshoes, the integration automatically sends the products' prices, provided that the Approved Products API Notification is configured.

Once the products receive the first price load, the update is made SKU by SKU whenever there's a price change in VTEX. However, for prices with expiration dates, when the date expires the system does not notify the affiliates. So the base price will only be sent after the next price change.

The integration sends the list prices and the final price for each SKU. The final price is sent according to the return of the fulfillment simulation. In a standard scenario, the price that is sent will always be the one determined for the sales policy linked to the integration. However, there are factors that can influence the final price, such as benefits and fixed prices.

Ex1: benefit of 10% discount for a certain category

_Ex2: SKU X is $ 10.00 in the sales policy used in Netshoes and has a fixed price of $ 15.00 for the same sales policy. The integration will send $ 15,00.

Note: since the payment method is made in the marketplace, the payment rules are determined by it. Because of this, we can't send differentiated prices depending on the payment method.
Ex: If there are interests for installment payments configured in VTEX, the price sent will still be the one returned by the fulfillment simulation.

Only benefits that can be calculated in the fulfillment simulation are applied. In this case, the following conditions can be applied:

Discount Type	Items	Conditions
Percentage	Categories	Min/Max Order Value
Nominal	Brands	Min/Max Item Value
Nominal Shipping	Collections	Price from/for
Percentage Shipping	Products	CEP
Maximum Shipping	-	Type of Shipping
Free Shipping	-	-

It is not possible to apply any condition type in benefits whose fields were filled in as -, that is, no condition will be taken into account in the integration.

When an order is made in the marketplace there are some points that influence its details, such as delivery, price and availability.

Delivery:

In this integration there are two points that will influence the delivery: Shipping Calculation and Time of Shipping Preparation. The sum of the two will be the Total Delivery Time.

Ex:
Normal Shipping = 3 days
Cost Time = 2 days
Total Delivery Time = 5 days

• Shipping

At the time of ordering, by default, Netshoes queries the shipping table registered in VTEX and we send them back the shipping options. It is worth mentioning that, in order to be able to perform the query, you must register the Shipping API in the Netshoes panel.

The store can also register a contingency table in Netshoes. Thus, if by any chance the integration is unable to query the shipping in VTEX or if the Shipping API is not registered in their panel, Netshoes uses the information in this table. In this case, Netshoes sends us the order and the integration tries to make a shipping match calculated with the carrier that best fits within VTEX (we use the carrier type as a parameter). If the integration can not find an equal carrier type, we integrate the order using the cheapest carrier available.

• Shipping preparation time

The shipping preparation time is based on the sum of the Cost Time field in the Inventory and the Cost Time at the warehouse dock. We send in bulk the same preparation time for all products.

Ex:
Inventory A
- Warehouse Dock 1: Cost Time = 3 days
Inventory B
- Warehouse Dock 1: Cost Time = 5 days

Warehouse Dock 1:
- Cost Time = 2 days

An order with Shipping Time = 3 days will have a different Total Delivery Time depending on where the product will depart from.

Leaving Inventory A:
- Preparation time = 3 + 2 (warehouse dock 1) = 5 days
- Shipping time = 3 days
- Total delivery time = 8 days
Exiting inventory B:
- Preparation time = 5 + 2 (warehouse dock 1) = 7 days
- Shipping time = 3 days
- Total delivery time = 10 days

Note: In case of using the contingency table to calculate shipping, Netshoes does not query VTEX. In this case, the only factor that will be taken into account for Total Delivery Time, will be the Shipping provided by them, ignoring the Preparation Time. You should be careful about this, as it may lead to discrepancies in the Total Delivery Time.

Price/Availability:

At the time of ordering, Netshoes does not check the price of the product or if it has stock. Only the last price/stock sent is considered.

Netshoes orders have their own statuses. Here's an explanation of these statuses compared to the ones used by VTEX. Learn more about the statuses of VTEX orders here.

Status VTEX	Status Netshoes	Netshoes Status Description
Waiting for clearance to dispatch	Created	New order with payment not yet approved
Cancellation Grace / Ready for Handling / Preparing Delivery	Approved	Payment Approved
Billed	Invoiced	Invoice issued
Billed	Shipped	Order shipped
Billed	Delivered	Order delivered
Canceled	Canceled	Order canceled

Netshoes notifies VTEX via the Order Import API (set up this API now!) every time an order is made on their platform, and then we try to integrate it.

Even if the API is not registered, VTEX reads an order feed at Netshoes to ensure there are no lost orders! But still, we suggest that the API be registered, because it guarantees a much faster integration of orders, reducing chances of a stock break.

We only integrate those which are in the Created or Approved statuses (be it a normal order or an exchange request). Any order that has already passed this status will not be integrated nor will it appear in order integration logs.

The orders are integrated with the same ID used in Netshoes. Exchange requests will have their ID supplemented with a "T" at the end.

Ex: orignial order - 6704259 | exchange request - 6704259T

If an application does not integrate on the first attempt, there is an automatic retry for errors not known by the integration or temporary errors (throttling, unavailable services 503, among others).

If it's a mapped error, such as divergence in the value of the order, SLA errors, etc., the integration does not retry. For orders with these errors to be integrated, you will need to do some action (see more about known Netshoes bugs here).

Once the order is integrated, some interactions, either in the VTEX panel or in Netshoes itself, will happen on both sides. This applies to:

• Canceling an order in Netshoes - the integration cancels the order in VTEX
• Billing an order in VTEX - the integration will invoice and update the order status in Netshoes (as explained in topic 5.4)

However, other actions taken are not reflected between platforms:

• Canceling an order in VTEX - the integration does not cancel the order in Netshoes
• Billing the order in Netshoes - the integration will not invoice it in VTEX

When you invoice the order in VTEX, the integration updates the status in Netshoes for invoiced, shipped, and finally delivered. However, for this to happen, some specific fields must be filled in according to each status. Learn more about completing these fields here.

• To change the status to invoiced you will need:   - invoiceKey, invoiceNumber and issuanceDate

• To change the status to shipped you will need:   - trackingNumber, trackingUrl and courier

• To change the status to delivered you will need:   - courierStatus: this is a field that can be automatically populated (via carrier's tracking updates) or manually (via API or the OMS interface).