1С:Drive modifications for the system’s sale at the USA market
Developing a mechanism of calculation of the US taxes and functional features for exchange of documents and accepting payments from counterparties
Customer
IT-company occupied with 1C implementation and support outside Russia.
Customer’s request
To extend 1С:Drive to sell the system in the United States.
Result
We developed a mechanism of calculation of the US taxes. We implemented functionality for exchange of documents and accepting payments from counterparties. Our extensions let the customer start successful sales of 1C:Drive in the United States.

Situation

In 2019 IT company, occupied with 1C implementation and support, came to us. The Customer wanted to introduce 1C:Drive to the US market, but the program configuration lacked functionality, needed by local users. For example, 1C:Drive did not support the US taxation system, neither was it integrated with banks and operators of electronic workflow.
The Customer asked us to extend the system so that the mass consumer solution suited the needs of user from the USA.

Development of the block for calculation of taxes

Project date: spring of 2019
Task: to develop within 1С:Drive a mechanism of calculation of taxes taking into consideration the specific features of the US taxation system
Determining tax rates in the United States is quite a challenging task. While in Russia or in Europe we have a fixed tax rate, in the States a Sales Tax is applied, which is calculated based on the region, the city, the state and other factors. One can learn about current tax rates on an official website of a certain district, in specialized magazines or via online services.

Solution

To customize integration between the existing service and 1C:Drive is cheaper and quicker than to start developing a mechanism for calculation of tax rates from scratch. The Customer pointed two online resources that provide tax calculations: TaxJar and Avalara. We analyzed both of them and chose TaxJar, since it is more convenient and it’s easier to work with.

While integrating TaxJar into 1C it came to light that there was no classifier of addresses for the United States in 1C:Drive. So there was a high risk that a user entered the wrong data and so TaxJar could not calculate the rates correctly. We started to look for a suitable classifier that could transfer the address to TaxJar in a unified format. We chose the cheapest and the most easy-to-use among various options — OpenStreetMap — and connected it to 1C through an API. Thus, we eliminated the risk of invalid input of address: the user entered the address in the way he knew it, and the service either corrected it automatically or suggested possible alternatives.

Result

We spent two months to customize integration between TaxJar and 1С. After that time we had a turnkey solution that let automatically calculate the newest tax rate in 1C. The Customer presented this functionality in 1C:International. We discussed with him the problems that appeared during implementation of our mechanisms, and 1C:Drive developers modified the system it terms of Sales Tax accounting.
Developing the mechanism of electronic workflow

Project date: summer of 2020
Task: to customize integration between 1С:Drive and the United States accounting system QuickBooks, so that the 1C users could exchange documents with their counterparties as well as execute and accept payments.
The Customer asked to implement within 1C:Drive the functionality that would allow 1C users from the United States to exchange documents with their counterparties, as well as execute and accept payments. The task was complicated by the fact that in the US, in contrast to Russia, there is neither single integrated operator of electronic workflow, nor a unique format of exchange with a client-bank that were quickly connectable to 1C:Drive. There is a broad range of electronic workflow providers and banks in the USA, and it would be very long and complicated to develop integration with their systems from scratch.

Solution

We realized that it would be much quicker to customize data exchange between 1C and the service that was already integrated with all required systems and exploit its potential for sending documents and invoices. We picked out QuickBooks – the US accounting system – as a middleware. It is a bit more private analog of Russian “1C:Accounting” that is very popular in the US and is used by many companies for accounting and exchange of documents.
The difficulty was that there were no tools for quick integration of 1C with QuickBooks. Moreover, to connect to external services of QuickBooks one should pass an OAuth 2.0 authorization, which means that one had to get, being inside 1C, a code for token generation and a token itself from QuickBooks. For QuickBooks could provide such data, a global IP-address is required. But not every customer with a locally installed 1C-system can afford a static IP and a web-service maintenance. To find a universal solution we developed a mediate service that collects necessary authorization data from QuickBooks and then transfers them to 1C. We located a web-server and the service itself on a separate workstation.

There exist two options of further functionality implementation:
  • in case the end user has no IP-address of his own and no possibility to deploy additional infrastructure, we use the address of our workstation;
  • if the end user has such desire and ability, we can locate a mediate service on his resources.
Then we proceeded with integration of QuickBook services into 1C. We wrote exchange rules for the following documents: SalesOrder (customer order), SalesInvoice (delivery note), PaymentReceipt (receipt of payment), PaymentExpence (invoice), PurchaseOrder (order to supplier).

Result

We implemented an option of electronic workflow in 1C and got the opportunity to send accounting documents for mutual payments with counterparties to QuickBooks and to upload them to 1C. We are still customizing this solution and help implementing it to our end customers.