Electronic Data Interchange {EDI}
Company
Levva
Design Team
Letícia Braga
Carol Aggio
This Backoffice EDI was made for the client Grupo NC - biggest pharmaceutical group in Brasil - while I was working at Levva.
With this interface, the user now has more autonomy to end user to set and manage EDI layouts with less technical knowledge, less dependency on Mercanet FTP/API and more velocity and agility in their tasks.
.png)
Context
Need
Grupo NC deals with thousands of pharmacies, propagandists, sales orders, invoices and more. They were using Mercanet (a very outdated-windows-95-like software) to manage orders layouts and requirements. It takes a lot of technical knowledge to do it, making it hard to teach new employees how to use it.
Process
It was a big learning curve for me, and it was the most technical product I've ever worked on, even being "small". The whole process took 2 months, among understanding the flow, gathering references, building the wireframe and finally the whole final product.
Outcome
More autonomy to end user to set and manage EDI layouts with less technical knowledge, less dependency on Mercanet and more velocity and agility in their tasks.
Flows
.png)
This is a brief explanation of where the EDI fits within the FTP and Mercanet API.
The EDI is an intermediator and data colector among sales orders, invoices, stocks, layout requirements and overview.
You may also navigate in the
Miro flow below:
The old process
Register Distributor

Format they received the order encrypted

How they read the order after decrypt

Define FTP/API/EDI order layout

Codes explanations

Layout settings to send the order

Layout for invoice

References I used










Final Screens
A home with relevant data for end user to track and overview: Before, the user had to manually identify inconsistencies, pendencies and manage it all. Because of the amount of workload, I decided to put filters and important data to keep an eye on, in a very simple and friendly interface.

Clear way to see and register distributors: Before, there was no compilation of distributors. The best practice for this would be a table, easy to consult, filter and take actions according to what the user needs.

Clear way to see and manage orders: to follow a pattern, I also put a table in this page. Because the user would be able to make more actions, a multiple selection of checkboxes would be more appropriate for a couple or mass actions.

Order details: there is no more need to decrypt information to see details. The operation still exists on the backend, but nor for the final user anymore. Details should be easy to overview with only the information needed. In this case, there is a table for the items inside an order but no actions are allowed except sorting.

New format to set and manage layouts for orders and invoices: this is the most important task for this user. Before, there were a lot of rules to remember, but now the system itself blocks actions that the user cannot make. Now, this task could be made with more agility and someone with no technical knowlege could be easily taught on how to fill the information.
