HubSpot + TeamSystem integration

TeamSystem is an Italian software group based in Pesaro, serving small and mid-sized companies and professional firms, and more than 500 million electronic invoices pass through its platforms each year. Its organization page names Denmark, Spain and Albania as its markets outside Italy. So a North American group is most likely to meet TeamSystem through an Italian subsidiary or parent that runs its accounts and electronic invoicing on it, while the group’s sales and marketing run on HubSpot.

The ask follows from that split. The group wants the Italian customers, orders and invoices visible in the same HubSpot portal as everyone else’s. It wants a deal won in HubSpot to become an order the Italian office can invoice, without anyone retyping it into a system whose screens and documentation are in Italian.

TeamSystem is a family of products, and the route depends on which one the Italian entity runs. TeamSystem Enterprise is the modular ERP, and TeamSystem’s old Alyante address now opens its page. Danea Easyfatt is invoicing, stock and sales software used by more than 100,000 Italian businesses, published under TeamSystem’s Danea brand. The documentation differs as sharply as the products. Easyfatt publishes its exchange formats openly, in Italian. TeamSystem’s development portal asks for a sign-in before it shows anything.

For Easyfatt, four records carry the value, and the table uses Easyfatt’s own document names. Products move into HubSpot from Easyfatt’s product file. Invoices move into HubSpot on a custom object associated to the company. Customers and orders move the other way: a closed won deal becomes an Easyfatt customer order, and the customer fields on that order are how Easyfatt finds or creates the customer record.

That makes the customer key Easyfatt’s rules rather than ours. Easyfatt matches an incoming order on its customer code or, when the order carries no code, on the customer’s web login, a field Easyfatt uses for e-commerce customers that has no counterpart in HubSpot. When neither is sent, or neither finds a record, it tries the fiscal code, VAT number and email, plus the PEC address when a code or login was sent, and creates a new customer only when nothing matches. So we store the Easyfatt customer code on the HubSpot company once it exists, send a checked VAT number every time, and carry the HubSpot deal id in one of the order’s custom note fields so every order traces back.

TeamSystem Enterprise holds the same kinds of record, customers, orders, items and electronic invoices, under names and access terms we confirm with the partner in discovery.

For Easyfatt, the shape is a small exchange service that Easyfatt calls, not the other way round. Easyfatt posts its product file to an address we give it, as a multipart upload of XML, either complete or incremental, and treats any reply other than OK as an error. Its order download calls a second address with an HTTP GET, optionally with a date range and an order number range, and reads back an Easyfatt-Xml file of documents. Both calls authenticate with the web server’s Basic, NTLM or Digest login, or with a header carrying the same credentials.

The service stores each product file, hashes it so a repeat changes nothing, and batch upserts HubSpot products on the product code. For orders, it writes won deals as customer orders, logs which numbers Easyfatt has taken, and serves only new ones. Invoices come back as Easyfatt-Xml exports from the documents section and load onto the custom object. For TeamSystem Enterprise the same service reads whatever access the partner grants, with the same keys, replay log and reconciliation.

The deciding factor is which TeamSystem product the Italian entity runs, and in which edition. On Easyfatt, the documented exchange is the route, and Danea offers it in the Enterprise One and Enterprise editions, the ones it says can integrate with e-commerce solutions. The specifications are public, if only in Italian. Both transfers start from Easyfatt’s own functions, so freshness follows how often the office runs them.

On TeamSystem Enterprise, nothing is public enough to scope from, so the route waits on the partner, and the build then follows the usual keyed ERP pattern. An iPaaS is a poor fit for either, because Easyfatt expects to call a web service that answers in its own XML, and there is no marketplace app to fall back on.

1. Scope. We establish which TeamSystem product and edition the Italian entity runs, who administers it, and what the partner will grant for TeamSystem Enterprise.
2. Architect. We fix the exchange endpoints or the Enterprise access, the customer and order keys, the VAT and payment code table and the replay log, and write them down in English and Italian.
3. Build. The service is written against sample files from Easyfatt, which Danea says even its demo version can export, and a HubSpot sandbox, with a portal allowlist from the first commit.
4. Validate. We send a catalogue, download a week of won deals as orders, and reconcile products, orders and invoices with the Italian office.
5. Operate. We watch every transfer, replay what failed, and retest after each Easyfatt or TeamSystem release.