Mono Marketplace Setup Configurations
Last updated
Was this helpful?
Last updated
Was this helpful?
The Marketplace Dashboard application needs to be installed on ACC. To do this, log in with your username and password at .
From the menu, navigate to the App Store, select the Mono application where sales will be made, then choose the relevant project and proceed with the installation.
After the installation, navigate to My Applications from the left menu, select the relevant application, and enter its application page. Once the necessary build and deployment processes are completed, the Mono Marketplace Dashboard application will appear in the left menu of Omnitron, ready for use.
After the installation, the menu will appear as shown in the screenshot.
After the deployment of the application is completed in ACC, a sales channel will be automatically created in Omnitron. The required fields within this sales channel must be filled in.
You can access the sales channel via Omnitron > Settings > Sales Channels.
Field Name
Description
Example
Information
Required
Channel Name
The name of the sales channel
Mono
Automatically created
Required (should not be changed)
Catalog Name
Catalog Name for Mono
*May vary from brand to brand
Mono_Catalog
Automatically created
Required (should not be changed)
Channel Type
Channel Type
*All sales channel types appear as a dropdown in Omnitron
Sales Channel
Automatically created
Required (should not be changed)
Status
The sales channel will not function unless it is activated.
Inactive
By default, it is set to inactive. (It needs to be activated)
Required
Schema Type
This is the section where the information to be stored in the sales channel settings is defined. The information specified here is presented as a form in Omnitron to provide the necessary data for the operation of this sales channel. A schema containing the minimum requirements needed for the sales channel to function is automatically generated. Additionally, you can add any extra information you want to store here (for example, data needed for the ERP integration of the sales channel). The key-value pairs that will be included in the Channel Config are defined here.
The dictionary in the value section includes the following: key, label, required, and data_type.
key → The key used to access the information within the channel config.
label → How the field will appear in the form within the Omnitron Sales Channel Settings interface.
required → Indicates whether the value is mandatory (true/false).
data_type → The data type of the value (list, text, integer, bool, json).
{
"base_url": {
"key": "base_url",
"label": "Base Url",
"required": true,
"data_type": "text"
},
"access_token": {
"key": "access_token",
"label": "Access Token",
"required": true,
"data_type": "text"
},
"buffer_stock": {
"key": "buffer_stock",
"label": "Buffer Stock",
"required": false,
"data_type": "integer"
},
"category_ids": {
"key": "category_ids",
"label": "Category Ids",
"required": true,
"data_type": "list"
},
}
Default information has been entered automatically.
Required (You may add new fields, but existing fields must not be modified)
Base Url
API URL belonging to Mono
https://b5b8134d541c4eaab7e92fe2eaa9fe06.lb.akinoncloud.com
Pre-filled with the default value: https://example.com/
Required
Access Token
default
Pre-filled with the default value default (This information is obtained from Mono).
Required
Category Ids
The main category IDs available on the Mono side should be reviewed and added here. [
{
"id": "f8aeb10e-f0f9-4f17-9687-60e542bdaefc",
"name": "Giyim"
},
{
"id": "ea832a4f-1a1a-432c-a318-abe69254f1d1",
"name": "Çanta, Aksesuar"
},
{
"id": "ffcc74a6-6b46-4820-91fd-d30501037aa0",
"name": "Ayakkabı"
},
{
"id": "16a74479-df58-4a37-8cc6-120f7d899554",
"name": "Elektronik"
},
{
"id": "4ce62b9d-3909-4ffe-8e79-b002499359ce",
"name": "Ev, Mobilya"
},
{
"id": "a9857570-940b-4b1e-94be-dd7ca5508660",
"name": "Kozmetik Kişisel Bakım"
},
{
"id": "a0685d19-5666-435c-98e0-f12304fafd8d",
"name": "Anne, Bebek, Çocuk"
},
{
"id": "1c5bfc9e-1d56-4aab-ac51-7f4d0afbe87c",
"name": "Yapı Market, Bahçe"
},
{
"id": "fa2ebb5a-d4f0-4830-8c64-588ae46472cc",
"name": "Spor, Outdoor"
},
{
"id": "bbeaa64d-b9e5-4efd-8c97-25a8e6025cca",
"name": "Ofis Ürünleri"
},
{
"id": "31a01933-749c-4234-8ad0-7863f69015a5",
"name": "Pet Shop"
},
{
"id": "5e34833e-fd9a-4ebc-ae92-331d7a307056",
"name": "Kitap, Kırtasiye, Hobi, Oyun"
}
]
f8aeb10e-f0f9-4f17-9687-60e542bdaefc
ffcc74a6-6b46-4820-91fd-d30501037aa0
Pre-filled as empty (The category IDs to be used, as provided in the table, should be entered in this field).
Required
Feature Flags
Allows enabling or disabling active processes. An important point to note here is that even if a specific process will not be active, it must still be added here with the value set to false.
(For more detailed information on feature flags, please refer to Section 9 titled Feature Flags below.)
{
"get_orders": false,
"get_cancel_orders": false,
"get_refund_orders": false,
"send_update_orders": false,
"get_updated_orders": false,
"delete_product": false,
"product": false,
"price": false,
"stock": false,
"send_refund_order_status": false,
"split_packages": false
}
All flags are pre-set to false by default.
Required
Cargo Company Mapping
When an order is fetched, this setting ensures that the order is written to Omnitron with a default cargo (shipping) company. Additionally, if the brand does not manage the shipping processes (i.e., send_shipping_info is not active), and if the cargo information slug received from Mono is mapped here, the shipping company will be assigned accordingly during order retrieval.
{ "default": "3",
“yurtici”: “2”
}
Pre-filled with the default key default.
Required
Use Cargo Label
If the brand does not manage the shipping processes (i.e., send_shipping_info is not active) and you want to generate a shipping label when fetching the order from Mono, this setting must be enabled.
Note: The shipping label is always in PDF format.
Inactive
Pre-filled as empty.
Optional
Use Neighborhood
This setting determines whether the neighborhood (mahalle) information in the address data will be used when creating an order. If enabled, the neighborhood information in the shipping and billing addresses of the order will be processed during the address creation step for the related order in Omnitron. If disabled, the neighborhood information will not be used when the order is fetched into Omnitron.
Inactive
By default, this setting is left disabled. If the company’s ERP requires neighborhood information, this field should be enabled so that the neighborhood data can be used from Omnitron.
Optional
Order Number Format
When pulling order data from Mono to Omnitron, the order number is formatted according to this setting. If this value is left empty, the default format "{orderNumber}-{id}" will be used to write the order number into Omnitron. Here, "orderNumber" corresponds to the order_number field on the Mono side, and "id" corresponds to the number field.
MONO-{orderNumber}-{id}
Pre-filled as empty.
Optional
Default Reason Id
If the reason ID included in the return data fetched from Mono is not found in the Refund Reason Mapping, the refund data will be retrieved using the Omnitron refund reason ID entered here and written to Omnitron.
(The ID information can be obtained via:
{omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=refund&is_active=true)
5
Optional
Required
Refund Reason Mapping
{
“f3909f53-a535-40cc-8d50-de0cd047aedd”:”7” ,
“f488f79f-503f-4787-a8ef-6a37b085b5e1”:”5”
}
Pre-filled as empty. (If left empty, when refund information is fetched from Mono, the refund reasons will be recorded using the “Default Reason Id” specified in the previous step.)
Optional
Refund Start Date
This is the initial start date from which refunds will begin to be fetched. The format should be "yyyy-MM-ddTHH:mm:ssZ".
2023-07-01T00:00:00Z
Pre-filled as empty.
Optional
Failed Integration
Records that encounter errors during the integration process are temporarily delayed with a penalty period. (Detailed information is provided below in Section 3, titled Failed Integration Settings.)
{
"order": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 3
},
"DEFAULT": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"product": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"productprice": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"productstock": {
"RETRY_INTERVAL": 28800,
"EXPIRATION_DATE": 57601,
"MAX_RETRY_COUNT": 2
},
"sent_to_remote": {
"EXPIRATION_HOUR": 6
}
}
Pre-filled with a default value.
Required
Send Shipping Info
This setting determines whether the shipping process will be managed by Mono or by the brand.
Inactive
By default, this setting is left disabled. (If disabled or not selected, the shipping process is managed by Mono. If enabled, the brand manages the shipping process itself.)
Optional
Cancellation Reason Id
This specifies the reason ID that will be used when canceled orders are fetched from Mono and recorded in Omnitron.
(The ID information can be obtained from the endpoint:
{omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=cancel&is_active=true)
4
Pre-filled as empty.
Required
Cancel Reason Mapping
{
“f3909f53-a535-40cc-8d50-de0cd047aedd”:”1” ,
“f488f79f-503f-4787-a8ef-6a37b085b5e1”:”3”
}
Pre-filled as empty. (If left empty, when cancellation information is fetched from Mono, the cancellation reasons will be recorded using the “Cancellation Reason Id” specified in the previous step.)
Optional
Reject Item Reason
This is the reject (refund rejection reason) information to be used during the approval or rejection process of the refund data retrieved through the refund order flow in the order.
Damaged
Pre-filled as empty.
Optional
Attribute Set Strategy
This is the strategy setting that determines which attribute set the products belong to.
CategoryNode
Pre-filled with a default value.
Required (Should not be changed)
Use Channel ID In Address Mapping
If the brand wishes, it can enable this field to perform address mapping on a per-channel basis. When enabled, the mapping process prefixes the address data with the channel ID and queries using the channelId_address information with a sales channel filter during searches.
Inactive
Pre-filled as empty.
Optional
Buffer Stock
This value represents the quantity to be deducted from the product's current stock when feeding stock to Mono. If no value is entered, the product's full current stock is sent to Mono.
3
Pre-filled as empty.
Optional
Waybill Option
During order updates sent to Mono, if the order status is "Shipped" or "Delivered" and the enabled field in this setting is set to true, the waybill_number field will be updated with the order’s invoice number if it exists; otherwise, it will be updated with the value entered in the default field.
{
"enabled": true, "default": "999"
}
{
"enabled": false, "default": ""
}
Optional
Send Cancel Reason ID
This is the ID from Omnitron used when sending cancellation information created in Omnitron (and not coming from Mono) back to Mono.
(The ID information can be obtained via:
{omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=cancel&is_active=true)
Note: This ID must be different from the Cancellation Reason Id and the IDs in Cancel Reason Mapping, as cancellations coming from Mono are differentiated based on the reason.
10
Pre-filled as empty.
Optional
Records that encounter errors during the integration process are temporarily held with a penalty period. The values for RETRY_INTERVAL and EXPIRATION_DATE are given in seconds.
RETRY_INTERVAL: The time in seconds to wait before retrying after an error occurs.
EXPIRATION_DATE: The duration in seconds after which failed integrations expire.
MAX_RETRY_COUNT: The number of additional retry attempts after an error occurs. The retries do not happen sooner than the RETRY_INTERVAL period.
sent_to_remote: The maximum amount of time to wait for a response from the marketplace for batch requests. For example, a value like { "EXPIRATION_HOUR": 360 } can be set here.
Any updates to these values will take effect in subsequent operations. For example, if a SKU’s stock update previously fell into the penalty queue with a retry interval of 3 hours, and this interval is later updated to 2 hours, the system will retry after the original 3-hour penalty. If it fails again, it will then use the updated 2-hour retry interval for subsequent penalties.
When there is any error in requests sent from Omnitron to Mono, we use the failed integration settings to put the sent data into a penalty state for a certain period. For example, if an attribute value is missing during product submission, these settings allow the error to be corrected within a specified time frame.
The category tree is fetched according to the added Category Ids within the sales channel.
After the category tree is pulled into Omnitron, it can be viewed under the Category Management section when the relevant Mono is selected in Sales Channels.
After this process is successfully completed (which can be monitored via logs), the flow responsible for fetching attributes will run. Once the attribute-related operations are finished (i.e., the Default Attributes flow has run and completed successfully), you can proceed to the next steps.
After completing the category tree fetching step, users need to perform category mappings through the Mapper.The Akinon Mapper function within Omnitron enables users to configure and manage the attribute values of products they want to sell on marketplace sales channels according to each marketplace’s requirements. Additionally, it provides the ability to verify whether the attributes and attribute values are correct before the products go live for sale.
You can find detailed documentation about the Mapper and the necessary configurations to be done within the Mapper in Appendix 1 here.
Examples of custom mappings you can create for Mono are available in Appendix 2.
Products need to be added to the relevant category tree on the Mono side. Each product should be assigned to only one category; otherwise, an error will occur during submission.
When the Mono marketplace application is installed on the relevant brand’s Omnitron, it appears as Mono in the left-side menu.
Dashboard data related to the Mono marketplace application is displayed on this screen.
TOTAL SKUs IN THE CATALOG The number of SKUs with simple product type and active status added to the relevant catalog.
NUMBER OF SKUs ON SALE The number of SKUs that have been sent to the marketplace and are currently on sale.
TOTAL SKU DIFFERENCE The number of SKUs added to the catalog but not on sale in the marketplace. This section compares the sellable products in Omnitron with the products on sale in the marketplace. It considers products in Omnitron that have a price, stock greater than zero, a category, a product image, and are included in the catalog.
NUMBER OF SKUs WITH PRICE DIFFERENCES THAT HAVE BEEN CORRECTED The number of SKUs with price differences between Omnitron and the marketplace. If there is a difference, a task has been run to correct these discrepancies, and the differences have been resolved.
TOTAL STOCK COUNT IN THE CATALOG The total stock count of all products in the marketplace catalog.
TOTAL STOCK COUNT The total stock count of products currently on sale in the marketplace.
TOTAL STOCK DIFFERENCE The stock count of products that are in the catalog but not on sale in the marketplace.
NUMBER OF SKUs WITH STOCK DIFFERENCES The number of SKUs with stock differences between Omnitron and the marketplace. If there is a difference, a task has been run to correct these discrepancies, and the differences have been resolved.
This screen displays logs and reports.
The logs of the flows are displayed on this screen.
Category Node The flow that pulls the entire tree structure of main categories entered in the channel settings into Omnitron.
Category Attribute and Values The flow that pulls the category attributes entered in the channel settings into Omnitron.
Default Attributes The flow that prepares predefined fields (like remote_id, title, etc.) for the mapping process during product sending.
Product The flow that sends products entered in Omnitron to the marketplace.
Product Delete The flow that removes products taken out from the catalog in Omnitron from sale on the marketplace.
Stock The flow that sends updated stock information of products updated in Omnitron to the marketplace.
Price The flow that sends updated price information of products updated in Omnitron to the marketplace.
Order Create The flow that pulls orders from the marketplace into Omnitron.
Order Update The flow that updates orders on the marketplace when their status, invoice, or shipping tracking number is updated in Omnitron.
Order Cancel The flow that updates the status of canceled orders on Omnitron when they are canceled on the marketplace.
Order Refund The flow that updates the status of refunded orders on Omnitron when they are refunded on the marketplace.
Updated Orders The flow that updates order statuses on Omnitron when order statuses change on the marketplace.
Approve / Reject Refund Order The flow that sends the approval/rejection status of refunds approved/rejected in Omnitron to the marketplace.
Split Packages The flow that transmits order splitting requests coming from Omnitron or another OMS system to the marketplace.
Compare Attributes The flow that updates the statuses of category attributes changed on the marketplace in Omnitron.
Send Cancel Order Items The flow that updates the status of canceled orders on the marketplace when they are canceled in Omnitron.
This screen provides reports on products that are added to the catalog in Omnitron but are not listed for sale on Mono. It highlights discrepancies between the price and stock information in Mono and the corresponding data in Omnitron.
Creating Alarms and Notifications The Marketplace Dashboard is an advanced automation platform designed to facilitate e-commerce integrations. Alarms and notifications play a vital role in informing users about critical events such as integration errors, data delays, and successful completions. Thanks to real-time alerts, users can quickly detect and resolve integration issues, ensuring smooth operation of e-commerce processes. This contributes to providing the best shopping experience to end customers.
Benefits of Alarms and Notifications
Real-Time Issue Detection: Alarms instantly detect integration errors, ensuring accurate data flow between systems.
Proactive Problem Resolution: Alarms enable timely intervention for integration issues, minimizing downtime and operational impact.
Increased Data Integrity: Alarms prevent data delays or interruptions, supporting consistent and accurate data processing.
Optimized Customer Experience: Quick resolution of integration problems keeps order, stock, and product information always up to date, providing customers with a seamless shopping experience.
Improved Operational Efficiency: Users are informed about critical events and can focus on strategic tasks thanks to alarms.
Data-Driven Decision Making: Alarms offer valuable insights to optimize integration processes.
Reduced Downtime: Early detection of issues minimizes system outages and prevents revenue loss.
Customizable Alerts: Akinon Marketplace Dashboard allows flexible alarm customization based on business needs.
Seamless Cross-Platform Communication: Alarms facilitate communication and synchronization between different e-commerce systems.
By leveraging alarms in the Akinon Marketplace Dashboard, users can effectively monitor and manage e-commerce integrations, enabling a reliable, efficient, and customer-centric shopping experience.
Step 1: Access Alarm and Notification Settings The Marketplace Dashboard is not a standalone product opened via a separate URL. To access it, first go to the Sales Channels menu on the left side of Omnitron, click on the relevant marketplace, and then select Marketplace Operations from the dropdown menu.
Step 2: Create a New Alarm and Notification Rule Click the + New Alarm button located at the top right corner of the “Alarms” screen.
On the opened settings page, select a Flow Name from the dropdown list.
Set the alarm conditions based on specific criteria such as error rate, flow duration, time interval, and metric value.
Select a notification channel and add the email addresses of the individuals or teams who will receive the notifications. (There is no limit on the number of email addresses.)
Step 3: Saving the Alarm and Notification Rule After successfully configuring the alarm rule, click the “Save” button to save the alarm.
Thanks to the power of alarms and notifications in Akinon Marketplace Dashboard, e-commerce integrations become more efficient. Real-time monitoring enables immediate intervention in issues, maintaining data accuracy and ensuring a flawless customer experience. Customizable alerts allow teams to stay informed and make data-driven decisions.
Error Rate: If the number of errors within the specified time interval exceeds the defined limit, the alarm is triggered.
Average Flow Time: If the average processing time of the flow within the specified time interval exceeds the set duration, the alarm is triggered.
This screen is used for triggering flows.
The following steps should be followed for errors encountered in the logs:
“Stock data not found” error indicates that the product stock data is missing. Stock data must be added for the related product.
“Price data not found” error indicates that the product price data is missing. Price data must be added for the related product.
“... attribute is required” error indicates missing mapping for the related attribute. Mapping should be done as described in Section 5 (Marketplace Mapping).
“Unreported order of ERP can not be canceled” error means the order has not yet been sent to the ERP. The order must be transmitted to the ERP before cancellation can proceed.
“Address is not valid. channel: 137 code: 137_Merkez model: Township city id: .., city name: …” error indicates that the Township in the order address needs to be mapped.
Product triggering from the dashboard only triggers create operations. To trigger product updates, use the “Update Bulk Product Version Date” option in the channel settings at the top right and upload a CSV file via the “Update by file upload” section.
For triggering flows, refer to this document: Flow Trigger Document.
Stopping the shipment of faulty products or resending products that failed to be sent;
Faulty products are retried for a certain period according to the rules defined in the Failed Integration settings in the channel configuration. Products for which retry attempts have stopped according to this rule require manual triggering.
To remove products that have fallen into this state from the penalty queue, go to Omnitron’s right menu, select Settings > Sales Channels, then select the relevant channel. On the resulting page, use the Update by Uploading Files button located to the left of “Delete Bulk Failed Integration” at the top right to upload a CSV file.
If too many faulty products accumulate in the queue, since processing is done in batches of 50, the queue may not proceed to the next products. There are two solutions for this:
Promptly fix errors related to mapping, catalog, stock, price, etc., and then trigger the process again by uploading a CSV file.
Properly configure the Failed Integration settings in the channel configuration with appropriate time intervals.
For the error "Failed to suggest product to catalog," if the issue is related to attribute values, the Category Attributes flow should be run to fetch the updated attribute values. If needed, the Compare Attributes flow should also be executed.
Errors encountered after CSV upload:
sku cannot identify please check your csv file. Header value should be set this: sku This error occurs when the first row of the CSV file is not set as "sku". The CSV file must be created according to the template provided on the trigger screen.
The relevant SKU not exists in Omnitron. Request URL: {url} This error occurs if the relevant SKU does not exist in Omnitron.
The relevant record is processing in another queue, LocalBatchId: {local_batch_id} This error appears when a product that is already in the sending process is triggered again. It is necessary to check the product logs and wait for the flow with "Waiting" status to finish. After the process completes, the relevant log can be filtered by SKU to check the final status.
The relevant record is not in queue. The item may have been penalized or check if the product is saleable This error occurs if the product is inactive or not in the catalog.
For the Order Update (send_update_orders) flow and unresolved orders on the MPD side, the following applies:
If there is an ongoing or opened return process for the order, it will not be updated.
The shipping number value will only be sent if “Send Shipping Info” is actively checked. For details, refer to the “Feature Flags” section.
The order status cannot be updated retroactively. Therefore, manual intervention in the flows should be avoided.
The default frequency values for operation are as shown in the table below. These values can be modified by the Marketplace team.
Flag
Description
Frequency
get_orders
This ensures that orders with the "Preparing" status on the Mono side are pulled into Omnitron, going 12 hours back from the flow's runtime. Before activating this flag, the settings mentioned in the 2nd section (Sales Channel Definition) — Use Neighborhood, Use Channel Id In Address Mapping, Use Cargo Label, Cargo Company Mapping, Send Shipping Info, Order Number Format — should be properly configured.
It runs every 5 minutes.
get_cancel_orders
The flow fetches claims marked as "cancel completed" from the Mono side going back 12 hours from the flow's execution time and processes cancellations in Omnitron, ensuring that the maximum number of cancellation plans is 6. Before activating this flag, the Cancellation Reason Id and Cancel Reason Mapping settings under the second heading (Sales Channel Definition) above must be properly configured.
It runs every 5 minutes.
get_refund_orders
The flow retrieves claims with refund status that are in “open” or “waiting” states from the Mono side, processes the claim lines, and creates refund requests in Omnitron. Before activating this flag, the Default Reason Id, Refund Reason Mapping, and Refund Start Date settings under the second heading (Sales Channel Definition) above must be properly configured.
It runs every 5 minutes.
send_update_orders
It enables sending the order statuses (“Preparing”, “Shipped”, “Delivered”), invoice information (invoice_number, invoice_date, e_archive_url), and tracking details (tracking_number, tracking_url, shipped_date) to Mono. Before activating this flag, the Send Shipping Info and Waybill Option settings under the second heading (Sales Channel Definition) above must be properly configured.
With this flow, the invoice and order status are updated. The tracking number is sent only if Send Shipping Info is enabled.
It runs every 5 minutes.
send_split_packages
Necessary details can be found in the document at the link: Requirements and settings needed for the order splitting flow.
It works through the trigger sent from the OMS externally via outbound.
product
It enables the sending of products that have been added or updated in the catalog, along with their price and stock information, to Mono. Before activating this flag, the Buffer Stock setting in the section above (Sales Channel Definition) must be properly configured.
It runs every 5 minutes.
delete_product
It ensures that the stock of products removed from the catalog is set to zero on the Mono side.
It runs every 5 minutes.
price
It ensures that the prices of products that need to be updated are sent to Mono.
It runs every 5 minutes.
stock
It ensures that the stock quantities of products that need to be updated are sent to Mono. Before activating this flag, the Buffer Stock setting in the section 2 (Sales Channel Configuration) above must be properly configured.
It runs every minute.
get_updated_orders
When shipping processes are managed by Mono, this flow retrieves orders that have changed to “Shipped” or “Delivered” status on the Mono side, going back 24 hours from the flow’s run time, and updates the status and tracking_number (for “Shipped” status) on an item basis in Omnitron. Before activating this flag, the Send Shipping Info setting under the second main heading (Sales Channel Definition) above must be configured properly.
It runs every morning at 06:00.
send_refund_order_status
It allows the approval or rejection of the generated refund request on the Mono side.
It runs every 5 minutes.
send_cancel_order_items
It enables the cancellation information created in Omnitron for an order to be sent to Mono. Before activating this flag, the settings under the second section above (Sales Channel Configuration)—Send Cancel Reason Id, Cancellation Reason Id, and Cancel Reason Mapping—must be configured appropriately.
Important Note:
It is crucial to differentiate between the cancellation reasons used in the Order Cancel flow and the reasons used in this flow. In other words, when performing the cancellation here, do not select a cancellation reason that corresponds to the IDs defined in the Cancellation Reason Id and Cancel Reason Mapping fields in the channel configuration. If such a reason is selected, the cancellation will not be sent to Mono.
It runs every 5 minutes.
This is the static token information to be used in requests sent to Mono. You can refer to the following link to learn how to obtain the token:
The refund reason information from Mono is mapped to the refund reason information in Omnitron for the refund process. Here, the key is the ID from Mono (specifically, those with type refund as shown at ), and the value is the corresponding reason ID in Omnitron.
(The Omnitron reason IDs can be obtained via:
{omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=refund&is_active=true)
The cancellation reason information from Mono is mapped to the cancellation reason information in Omnitron for the cancellation process. Here, the key is the ID from Mono (specifically, those with type cancel as shown at ), and the value is the corresponding reason ID in Omnitron.
(The Omnitron reason IDs can be obtained via:
{omnitron_url}/api/v1/channel/{channel_id}/cancellation_reasons/?cancellation_type=cancel&is_active=true)
