1C:UNF Customization Built Around How You Work

Who UNF suits and where it hits its limits

A configuration for small and mid-sized companies that want all their accounting in one place.

1C:Small Business Management is chosen by trading companies, service businesses and small manufacturers. One database holds customer orders, warehouse, purchasing, cash, payroll and simple production. That is enough to start, and many companies work on standard UNF for years.

The limits appear as the company grows. A second warehouse, contract-based wholesale prices, delivery, order picking and reports for the owner come along. Standard UNF provides the basic mechanisms but does not know your rules. Then staff start keeping spreadsheets on the side, and the data in 1C stops matching reality.

Customizing UNF brings these processes back into the database. We do not rewrite the configuration; we add what is missing precisely and carefully.

A typical example: a company sells wholesale and retail, has a warehouse and a showroom, some orders go out by delivery and some are collected by customers. Standard UNF can record all of this with documents, but the key picture is missing: what has been picked, what has left, what is paid and what is outstanding. The owner learns about it from conversations with managers, not from the system.

Another example: a service company keeps work orders in UNF, but technicians work on site and cannot see their jobs on a phone. Data is entered after the fact, and the manager cannot tell how much each technician actually earned.

Warehouse and bin locations in UNF

Standard UNF bins plus what the warehouse is missing.

UNF has warehouse bins, but without location import, locations on documents and convenient printing they are hardly used. We import locations from Excel, show the bin on invoice lines and build a pick list sorted by route. More on the bin location management in 1C page.

Our case study shows this work: a trading company on UNF, locations for 209 of 209 article numbers, a pick list, reports and a mobile scanner. See the case study (in Russian).

Besides locations, issue control is often customized in UNF. An invoice can be posted while the goods have not yet been handed to the customer, especially when part of the order is collected right away and part is sent by delivery. We add an issue status and a report on posted but not issued documents, so the warehouse and managers see the same picture.

For stock counts we build bin-by-bin recounts with a scanner: the storekeeper walks a rack, scans items, and the system immediately shows differences from the books.

Integrations: website, Kaspi, apps

UNF becomes the data source for every sales channel.

Stock and prices from UNF go to the website and Kaspi, and orders come back into the database. For mobile apps and bots we build an HTTP service in an extension that serves data in real time. None of this requires taking the configuration off vendor support.

Kaspi and other platforms have a separate page about 1C integration with marketplaces.

Another common task is importing bank statements from Kazakhstan banks and automatically matching payments to orders. The accountant stops matching payments by hand, and the sales manager immediately sees that the customer has paid.

When UNF should be replaced rather than customized

We say so honestly if customization would cost more than a migration.

Sometimes a company's needs go beyond UNF: complex production with routings, many legal entities with intercompany sales, deep warehouse accounting with an order-based scheme. This can be customized too, but maintaining such a database will be expensive. In those cases we suggest comparing customization with a move to 1C:Trade Management or 1C:Integrated Automation and estimate both options.

In many cases the line is drawn not by features but by load. If more than twenty or thirty users work in the database at once and documents run into thousands a day, it is worth assessing performance in advance and possibly moving the database to a client-server setup. That is part of our work too.

UNF customization price and timeline

We give an exact price after reviewing the database.

We recommend starting with the area that hurts most, such as the warehouse or payment reports. The company sees results quickly and understands better what to customize next. Later stages usually go faster because we already know the database.

All work is fixed in writing: what we do, the timeline and the price. If new requests come up along the way, we estimate them separately instead of stretching the original task.

Common UNF customization mistakes we fix

What we find in databases that were customized before us.

Edits to the standard configuration. The most common problem. Changes were made directly in the configuration, the database is off vendor support and has not been updated for a year or two. Kazakhstan reporting is outdated, and the accountant works around errors by hand. We assess what can be moved into an extension and bring the database back onto vendor support.

Undocumented customizations. The previous developer left, and nobody knows what was changed and why. We compile a short register of customizations: what each one does, who uses it, whether it is still needed. Some turn out to be unnecessary and can be removed.

Slow performance. Heavy queries in posting handlers, reports that take minutes, unnecessary event subscriptions. We analyze performance measurements and rewrite the bottlenecks.

External data processors instead of customizations. Dozens of external files sit in the accountant's folder, and some stopped working after an update. What is needed goes into the extension; the rest is removed.

Unmonitored integrations. Exports to the website or Kaspi sometimes stop, and you find out from customers. We add an exchange log and error notifications.

After such a review the database becomes predictable: it is clear what has been changed, updates install normally, and new customizations do not break old ones.