Remote Inventory Management

There are different ways to manage remote inventory management with, the process is always build around the financial structure, and around the possible 3rd party applications being used.

We strongly recommend to manage a remote inventory from a secondary UNOSOF application, in where we can control and automate a lot of processes with. Let's learn more about this:

Legal Export Docs Reason

Let's start to explain the exportation process that all know, but for legal reasons very important to understand well: the purchase order needs to get invoiced on the day of exportation. As always, the commercial invoice has to match the truck invoice and the "SRI guia de remission", those papers are needed to give to a cargo agency. At the same time, the around of pieces, stems and USD's on the the commercial invoice (generated on the day of export) has to match the SRI invoice, and has to match the SANAE, its a like a closed circle.

There are two reasons from an export point of view why selling of remote inventory should not happen within the same application:

The boxes that get exported for remote inventory are tight to a PO (purchase order), and a PO is tight to an invoice, therefor the exported boxes are locked from being able to resell. Maybe its possible to rollback the invoice, but in most occasions a rollback of the invoice is no longer possible since the SRI autorizacion got processed. That would completely lock the reselling opportunity via a process such like move boxes etc.
However if the invoice has not been SRI authorized, then its possible to rollback the PO and to move boxes. While thats totally possible, this causes another issue. In order to resell those boxes, a new PO gets invoiced, in an application where only export get managed with. That causes some issues, because those PO's are actually done with boxes that are physically in Ecuador, being managed from an application that only should manage exports. The remote inventory should not get sold via an export application, because those PO's should not get an AWB coordination, Commercial Invoice, Truck Invoice, "Guia de Remission", SENAE and SRI autorizacion.

The export and legal documents being generated for the PO's that are getting exported for remote inventory stock management, should not be undone (rolled back and getting resold in different PO's) for resales within the same application

Financial structure reasons

There are two different financial structures that can applied to manage remote inventory with.

Remote inventory can owned by the farm, in where a POA (power of attorney) is been given to a third party who clears the product at the local destination where the product gets sold from.
The alternative is to setup your own company at the local destination to clear the product with, in that way the product is owned by what we call a trading company.

Either one or the other, we strongly recommend to manage to setup a secondary UNOSOF application to manage the remote inventory with, to streamline processes with and especially to separate different business units with. Let's learn more about this via these topics such as freight cost, modifier, 3rd party migrations, centralize data etc.

Freight cost

Ask yourself the following questions: Who's paying the freight, the farm or the trading company? Do you want to SRI declare the freight cost in Ecuador? If yes, we should declare the freight cost to all local, legal documents (SRI). If not, we should exclude the freight cost automatically from all the local, legal documents (SRI), and only push the freight cost into the trading company.

If you work with a POA structure, then freight can only be paid by the farm, however if you have a trading company structure the following options become available.

Modifier

Its not possible to work with a modifier if you work with a POA structure. However if you with a trading company structure, then its normal to use a modifier. A trading company buys and sells product and its a completely independent company that has its own cost (administration cost, commercialization cost, freight cost, handling cost etc). Therefor a modifier is needed to create some margin for the trading company. The modifier can be automated and can reported well to monitor how much margin has been made for cashflow management purposes.

Automate Processes

Managing a secondary UNOSOF application for financial flows and/or remote inventory management is very efficient and has a lot of good reasons, but it does requires some extra work. All data creation, such as creating SKU's, customers, etc has to get synchronized in order that the data exist in both application. learn more at:

Synch data

UNOSOF has centralized all management from one application, this makes it very efficient to create, invoice and sent invoices. Its possible to migrate any PO into another UNOSOF application, however anything that gets sold from the remote inventory, has to be managed (create PO, create invoice) only from the trading application.

Migrate PO's from 3rd party Platfoms

Its possible to sell the remote stock from a UNOSOF application and but also to migrate PO's from 3rd party applications such as Komet into UNOSOF. It can be a goal to have ALL sales together in one application, no matter if the product was sold FOB UIO, IN & OUT (CIF), FOB MIA, FOB AMS etc. It can also be possible to not migrate FOB UIO sales into the trading company, and to completely tread the businesses separated, with the consequence to have two statements for the customer which he has to pay separately.

Most ideal for the customer and for internal use is have sales reporting and customer statements being centralized.

Centralize data for Reports and Statements

The goal is to centralize all sales into 1 application where reports (sales) can be generated from, and where statements can be sent from to the customers.

PreviousHotroom Exit NextPurchases

Last updated 2 years ago