EDI Integration

I’m an EDI Implementation consultant, transitioning from the closed-source proprietary space.
I’ve spent the last 5 years working specifically with Infor SXe (ERP) & Opentext BizManager (EDI Transformation & Messaging) in the area of Distribution - the usual 850, 855, 856, 810, 832, 852 , 844, 849, etc transactions.

I’ve been evaluating the integration offerings from Odoo & ERPNext and recently found Tryton.
I’m hoping to collaborate with others on the development of open source replacements for the above tools, and generally gain expertise on OCA modules related to integration, and Tryton-specific methods for the same.

My goal, ultimately, is to deliver code and procedures that implement as many of the above transactions, in ‘customer facing’ and ‘vendor facing’ perspectives, as is possible and practical, into Tryton, Odoo or a compatible derivative.
It’s a lofty goal to say the least, seeing as ‘EDI’ covers many different areas of functionality.
I’m starting with the API for Sales Order creation (850 Inbound)
I’ve already done quite a bit with the Odoo XMLRPC interface and am now attempting to port it to Proteus for use in Tryton.

Is there any interest form my fellow community members in such a project? Would a ‘EDI Module’ be useful for those using Tryton in a EDI/B2B/EAI context?

As a specifc request - does anyone have a proteus python example for creating a Sales Order and adding multiple line-items?
I’ve already found the below for basic reading of the sale.sale model, but need the proteus version of
execute_kw(db, uid, password, 'sale.order', 'create', [order_vals])

from proteus import Model, config

# Tryton server connection settings
HOST = '192.168.0.247'
PORT = '8000'
DB = 'tryton'
USER = 'admin'
PASSWORD = 'admin'


if __name__ == '__main__':
    config.set_xmlrpc(
        url='http://{user}:{password}@{host}:{port}/{db}/'.format(
            user=USER, password=PASSWORD, host=HOST, port=PORT, db=DB))

    Sale = Model.get('sale.sale')

    domain = [] #[('state', '=', 'processing')]
    max_num_of_records = 10
    sales = Sale.find(domain, limit=max_num_of_records)
    for sale in sales:
        print("{number}: {date} {party} ({lines}) {currency}{value}".format(
            number=sale.number, date=sale.sale_date, party=sale.party.rec_name,
            lines=len(sale.lines), currency=sale.currency.symbol,
            value=sale.total_amount))

To create record with proteus, you must instantiate it, fill the fields and call save. E.g:

sale = Sale()
sale.party = party
line = sale.lines.new()
line.product = product
line.quantity = 1
sale.save()

To execute buttons, you can just use the click method with the name of the button.

If you want to see more example of proteus, you can look at any scenario (.rst files) in the tests folder of any module.

About EDI, we have already some Electronic document implemented. But I’m pretty sure the community will be happy to support more format.
It may also be useful to take a look on how we implemented the CAMT054 parser.

Thank you Cedric.
This is what I had hoped for.
An engaged user group makes it 1000% easier to jump in and develop understanding.
I’ll get started digesting what you’ve pointed me to.

A short time ago I was looking at json-rpc examples, but when attempting to use them in python 3.7 was getting errors related to xmprpclib and http libraries. They were renamed between v2 & v3
Do you suggest I go the proteus or json-rpc path? Python 3.7 or 2.7? I’d like to stick with 3.7 wherever possible but will use whatever method is ‘best practice’ from your experience.

Also, can I rule out using the Odoo style
/xmlrpc/2/common
and
/xmlrpc/2/object
API calls?

Or has the Tryton fork already diverged enough to not make that practical?

It depends on the usage and the need. Proteus or JSON-RPC are mainly the same. Proteus provides an object API on top of XML-RPC (which is equivalent to JSON-RPC, mostly the same code).
But indeed there is a third way, you can create your own dedicated API using User Application — trytond 5.3 documentation. This allows to simplify the communication and to put all the business logic in a Tryton module and also have access to more feature than the RPC.

The recent series of Tryton only support Python >=3.5

The XML-RPC has been completely reworked: Remote Procedure Call — trytond 5.3 documentation (not complete :worried:)
But basically you post on https://localhost:8000/database_name/ using the schema: <type>.<name>.<method> e.g model.sale.sale.create. The parameter of the method are configured using RPC — trytond 5.3 documentation.

This sounds interesting.
I’ve retrieved a key (without an application name) from Postman by POST to
http://192.168.0.247:8000/tryton/user/application/
I’m assuming this will be put into a ‘Authorization: Bearer’ header when calling the module URL after it gets developed and published to my server instance

If I were to ‘clone’ a simple module as a starting point, is there one you would suggest?
The ‘cookiecutter-tryton’ module looks a bit to barebones
Something simple enough to not overwhelm a Tryton Noob?

I’m looking through this now, but ‘in a nutshell’ examples can be helpful - consider me in ‘Tryton Module 101’

http://docs.tryton.org/projects/server/en/latest/topics/modules/index.html

Thanks so much for your responsiveness and dedication to this great body of work. I’m extremely impressed and grateful

It depends on the usage. If you want to create a dedicated API you can have a look at the timeshet module which creates an api for chronos (a browser extension to enter timesheet lines in offline module)

Our way implementing new ideas in Tryton starts with a blue print of the feature. In the blue print you can collect, document, teach/learn, discuss with the other community members and refine your plannings. Also the blue print is an excellent starting point for the later implementation.

A post was split to a new topic: How to setup environment to create a new module

Thank you udono.
I will collect my thoughts and use the blue print process as you’ve suggested.

Hi,

because EDI is a strategic subject for tryton, it is important that all the community feels comfortable with the way your ideas are implemented so it can successfully be integrated and supported in the official tryton framework.

I’m very glad to hear this - all the other ERP SIGs that I made acquaintances with seemed pretty indifferent to any mention of EDI. The Tryton Discussion Group has been really amazing - engaged, responsive, knowledgeable - that’s icing on the cake - the Tryton platform itself is compelling on it’s own and seems like a natural choice for what I’m picturing and the time investment to learn as much as I can about it seems like a great choice. I look forward to this process!
A Feature Request - Blue Print entry is happening shortly

3 Likes

I’m very glad you have this feeling about Tryton and it’s community. Welcome aboard! :clap::clap:

A post was split to a new topic: Implementing EDI

A post was split to a new topic: How to use timesheet custom application API