A Telegram bot for 1C:
accounting data for staff away from a desk

Let's run the numbers for a fit-out company working on 14 sites at once: restaurants, showrooms, offices. The accounts are kept in 1C:UNF on the company's own server, and each site has a foreman and two to four crews. Each foreman calls the office 6–8 times a day: “when is the tile arriving?”, “has the subcontractor been paid?”, “what's left in the budget?”.

Fourteen foremen make about a hundred calls a day. If each call takes 2.5–3 minutes, including looking up the answer in 1C, the office manager spends 4–5 hours a day on the phone and fits their own work in between. That's 0.5–0.6 of a full-time position. On a ₽80k salary, the company pays up to ₽48k a month for someone to read numbers aloud off a 1C screen.

There's also a vicious circle. Incoming materials get posted in 1C when someone gets round to it, sometimes 1–3 days later. Until then, the other foremen can't see the real stock and call again. More calls mean later postings, and later postings mean more calls.

The first suggestion in this situation is to buy more licences and hand out logins. On paper that makes sense. But there's no laptop on site, and the foreman's hands are busy with tools. The password gets forgotten within a week or two, and a forgotten password turns into the same call to the office.

The second suggestion is to open the 1C web client to the internet. This is where the head of IT immediately has questions. The company's accounting database becomes reachable from the internet at an address that someone will find sooner or later. And permissions inside the configuration still have to be set up so that each foreman sees their own site and nobody else's. That's a separate piece of work inside 1C.

Three parts, each with its own job.

• · 1C publishes its own HTTP services. An HTTP service is a built-in way for 1C to hand data to another program on request. The services are added as an extension and published on a web server, and the standard configuration stays unchanged. A few such methods return exactly what's needed: the employee's list of sites, the remaining budget, an order status.
• · An intermediate service sits between Telegram and 1C on a rented server in Russia. It handles login, permissions, a cache for frequent requests, a queue and retries. If 1C is busy with a scheduled task, the request waits in the queue, and the person doesn't see an error.
• · The rented server and the company's 1C server are joined by an encrypted WireGuard tunnel. 1C has no public address. Only the bot is exposed to the internet.

That's the answer to the main question from the head of IT: staff can reach the data from anywhere, and there is no way into 1C from the internet. The full setup, with the estimate for the company from the first chapter, is on the page for the ready-made 1C:UNF solution for foremen.

Parts of this setup already run in my own projects. The knowledge-base assistant is a Telegram bot with three access levels. And the selective traffic routing I run through my rented server is built on a WireGuard tunnel.

Login is by phone number from a pre-approved list. The person taps “share phone number”, and the system checks it against the list and links it to the employee's record in 1C. There is no password at all. That's a deliberate decision: a forgotten password turns straight back into a call to the office.

Permissions are set in the intermediate service, outside the bot's interface. A foreman sees only their own sites: a request about someone else's site never reaches 1C. A button hidden in the interface can be worked around, so the permission check runs on the server.

The whole interface is buttons. Main menu: “My sites” → site → “Orders / Payments / Budget / Confirm delivery”. It takes at most two taps to get a result, and there's almost nothing to type. If a tool is awkward to use in gloves, people won't use it. They'll go back to phoning, because phoning always works.

One button puts data into 1C. A truck arrives, the foreman photographs the delivery note and taps “Confirm delivery” in the order card. The photo goes to storage linked to the 1C document, and the materials are posted to the site within the same minute. That breaks the vicious circle from the first chapter: the other foremen see the real stock and no longer need to call to check it.

A large share of the calls are just checks: “has it left yet?”, “has it been paid yet?”. Messages the bot sends on its own take care of them: “the truck with the tiles has left the warehouse”, “the subcontractor has been paid, the completion certificate can be signed”, “budget overrun on this site: +3% over plan”. They are triggered by events in 1C and by scheduled checks.

There is a side effect too. As long as the remaining budget is a number the office manager reads out, it's an abstraction. Once it's on screen and updates itself, the foreman can count the money before making a decision.

The estimate assumes the bot answers 19 out of 20 questions from foremen: the ones about stock, payments, the budget and delivery times. That leaves each foreman with about 0.4 calls a day, roughly two a week, all of them about unusual situations.

“We've set up the permissions” means nothing until someone has measured it. Before launch I take an ordinary employee's account and look at what can be pulled through the bot with it: their own sites, other people's sites, contract amounts, salaries. The answer should be a number: how many records belonging to others are visible.

What a full measurement looks like, and what it showed the first time, is described in the article on personal data and AI models. There the same technique is applied to an internal knowledge-base assistant.

Four situations in which I talk clients out of it.

• 1. No access to the 1C server. The whole approach depends on being able to publish HTTP services and set up a tunnel. If your database is rented and you don't have admin access, start with a conversation with whoever runs the server.
• 2. Few people in the field, and few calls. For the company from the first chapter, the numbers are ₽480k one-off, ₽12k a month for support, and ₽40–48k a month saved. Leave support out, and the investment pays back in 10–12 months. With it, the net saving is ₽28–36k a month, and payback takes 13–17 months. Plan around the longer timeline. If you have one foreman who calls twice a day, the saving is several times smaller, and the investment may never pay off.
• 3. You need full document entry. A bot works well where the job is to “look up” and “confirm”. If someone has to create a document with twenty fields and pick items from a catalogue, buttons won't be enough. The honest answer here is a 1C workstation.
• 4. The process itself is broken. If materials go unposted because nobody is responsible for posting them, a bot will only speed up the mess. In that case I first suggest a process audit: over two weeks I work out where staff time goes and draw up a list of tasks, each with a payback estimate. The quickest wins go first.

Nowhere, and it isn't needed here.

Everything described above is careful data exchange: methods in 1C, permissions, a queue, retries, buttons. A language model would add unpredictability exactly where you need accuracy: the remaining budget must be exactly the remaining budget.

The same principle applies to a related task: loading Federal Treasury statements into 1C. A program reads the file and converts it into the format 1C needs, without a single call to a model. Two to three hours of manual work became 5 seconds (the Treasury statements case).

A model is added later and separately, where there's free text and a decision to make about it: first-line answers to customers, search across internal documents with a link to the source. That's a different service with a different budget.

A simple rule for checking a vendor: if the task can be described as “take field A and show it to person B”, it doesn't need artificial intelligence.

For the company from the first chapter I plan for about 7 weeks from kick-off to launch and budget ₽480k one-off plus ₽12k a month for support. The exact timeline depends on whether your 1C already has HTTP services published. The same approach works for logistics (a driver marks “cargo accepted” and “shipped”), manufacturing (a shop supervisor checks the shift plan and logs defects with a photo), field service, sales reps and retail. The common thread is always the same: the person works away from a computer and needs figures from the accounting system.

Before you call a contractor, answer four questions. They determine both the timeline and the price:

• a. Which 1C configuration you use: UNF, UT, ERP or KA. Any of them will do, as long as it already has HTTP services or they can be published.
• b. Whether your 1C can hand data to another program. Ask your 1C specialist exactly this: “Do we have HTTP services published, and if not, how long will it take to publish them?” If they aren't published, that's the first task of the project.
• c. Who looks after the 1C server: your own employee, a contractor or the company you rent it from. That decides how many days it takes to set up the tunnel.
• d. Whether employee records include phone numbers. Login and permissions are tied to them: no records, no separation by site.

If all four questions have answers, the sensible first step is a pilot from ₽60,000 for 1–2 weeks: one scenario, one site, five people. After two weeks you can see whether people use the bot and how many calls it has really removed. Then I'll redo the payback estimate with your own figures, and it will be clear whether the full setup is worth building.

Connections with 1C, Bitrix24 and amoCRM are described in the services catalogue, and the price range for this area is on the pricing page.

If we carry on working together, the audit fee counts toward the first project.