Does ERPAG support dropshipping? How do I handle dropshipping in ERPAG? Can a customer return a drop shipped item?
The concept of dropshipping at first glance seems very simple, e.g. A customer places an order through my webshop and I forward his order to my drop shipper who will take care of everything from that moment on.
Is it that simple in practice?
If you answer yes, you are free to skip this blog.
For those who answer this question with a No, in this blog post, we will explain how dropshipping is managed through ERPAG. This blog is focused on practical application in ERPAG, if you need general dropshipping information you can find it on our other blog: https://blog.erpag.com/2019/02/what-is-dropshipping.html
There is a specific product type in ERPAG, which creates items on which we apply the dropshipping concept.
Creating a dropship product is quite easy – we just select “dropship product” from the drop-down menu, when creating a new product in our products and services list.
The setup is almost identical to a regular Product, but because of its specificity, “Dropship product” has the following limits:
• No on hand or quantity in stock (as the items are not received to our stock but are sent directly to the customer by the supplier)
• No stock card
• No reserved quantity
• They can not have serial or lot numbers (as we do not have access to this supplier information)
• Stock adjustment, stocktaking or set quantity with this type is not possible
• It is not possible to select such an item in the transfer document between two warehouses
• Output or input item in Work Order (except for contracting)
• Other options which include manipulation of items in stock
In practice, sometimes, a regular product (eg we had it in stock) must become a “drop ship product” (no longer in stock, delivery will be directly from the supplier) or vice versa. The change process is simple, just change the “backorder” type.
Just make sure that the quantity in stock is “0” and that all sales and purchases are completed.
For a better explanation, we will make an example – Sales Order where we will have a regular product, service and “drop ship product” (in ERPAG it is possible to have different types of items on a single Sales order).
The “icon” of a drop-ship item is different for easier visual recognition.
Since we don’t stock drop-ship items, its quantity will always be missing.
The purchase order that has the “drop ship” type has an additional section that is populated with the customer’s address to which the supplier (dropshipper) will ship the items.
Note: ERPAG will try to sum the purchase orders, if the customer’s delivery address is the same.
On the info button of Committed Quantity, we can see for which Sales Order this item is committed.
Also, in Sales Order, we can see the Purchase Order relation.
We send the Purchase Order formed like this to our supplier (dropshipper) who will send these items to our customer.
Confirmation of whether the products were sent (or delivered) to the customer, we can obtain from the supplier or from the customer that received the products. So there are two ways to complete the process, i.e. we record that our customer has become the “owner” of the goods. The method of implementation depends on the company policy itself and the logical flow.
Another approach is when the supplier (dropshipper) informs us that he has sent the items to our customer. This option can also work when the supplier accepts our order with the assumption that they will also deliver the goods.
Just like in our previous example, two documents are formed:
For the Purchase Order (type: dropshipping) we will create a Supplier Invoice and record the payment.
The document status is now “completed/paid”.
In our example, we also have another Purchase Order (for a regular item), where we will “receive” the items in order to increase the quantity in our stock, then we will create a supplier invoice and record a payment.
Now both Purchase Orders have the “completed” status.
Our Sales Order currently has the next statuses: Partially packed/Available quantity/Partially shipped/Not invoiced
We will activate it and do pack > ship > invoice > record payment.
With regular items, the return of products from the customer is not a problem for us because the items are shipped to our warehouse and that’s it. There are several logical cases when returning a drop ship product, but we will explain the most common case.
Customer returns the items directly to our supplier (dropshipper)
In our example, we will have three returning options (Products, Services, Dropship products). We will select “Dropship products” and a new form for entering items and quantity for returning will appear (in negative quantities).
A new document is formed with a “Returned” status.
You probably notice that the payment status is “overpaid”. As our customer paid us the complete amount, it’s necessary that we return him the paid amount and record that in ERPAG. We will do that through the “payment” option, and we will enter this amount as negative.
The Sales Order status now has a paid status.
Note: Customer returns and void documents have the same number as the original.
“Drop ship products” do not reach our warehouse, but the supplier sends them directly to our customers so that automatically forms a return to the supplier.
And thus, the items are returned to our supplier. _________________________________________________________________________________
JSON/XML Designer in ERPAG is a visual tool that will allow users to transform data from the ERPAG database into JSON or XML format. This can be further used for future integration with API services. This tool provides a user-friendly interface where users can define...
The biggest change we developed is Automatization and Customization. This change is a huge milestone for us, and we will publish individual instructions for using the new features in the upcoming period. This module is divided into individual wholes: JSON Designer -...
ERPAG has the ability to use Blockly Script to send or receive data via the HTTP protocol. Integration of two systems via API (Application Programming Interface) is always a complex process, especially for someone with little experience. In this blog we will explain a...
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.