Accounting in an online store with a large product catalog: a complete guide

Torgsoft for an online store with a large catalog: server, SQL Server, orders, waybills and payments

An online store with a large catalog, several sales channels, phone confirmations, waybills and daily payment registers quickly turns into a complex operational process. This article is a step-by-step plan for setting up Torgsoft, the server and the database so that managers process orders quickly, while the owner sees the real picture of sales and money. We will separately examine what is solved by the server, what is solved by settings, and what requires contacting developers.

The material is intended for businesses that sell through their own website, Prom.ua, Rozetka and by phone, send dozens of parcels per day via Nova Poshta and Ukrposhta, and receive payments by prepayment and cash on delivery. The examples are suitable for spare parts stores, electronics, accessories, household goods, clothing, cosmetics and other businesses with a large assortment.

What result a properly configured system should deliver

The purpose of configuration is a specific working result that can be checked. A properly built accounting system for online trade looks like this:

• the product catalog is maintained in one place — in the Torgsoft database;
• prices and stock balances are automatically transferred to the website and marketplaces;
• orders enter the program without manual retyping;
• the manager has customer, order, product, delivery and comment data at hand;
• an invoice is created according to a clear rule — automatically or after confirmation;
• the waybill is generated from the order data if the required delivery fields are filled in correctly;
• payments enter financial accounting, and the responsible employee controls their connection with invoices;
• the database works faster in daily operations if technical bottlenecks have been removed;
• data is archived regularly;
• each employee has access only to the necessary functions.

If at least one element drops out, manual work appears: managers reconcile stock balances, duplicate invoices, transfer data to waybills manually, search for payments in registers. At large volumes, such work takes hours every day.

Where to start: describe your process before technical work

A new server or a new SQL Server version speeds up work when the bottleneck is really in the database, disk, memory or outdated hardware. When the cause is a chaotic process, unnecessary actions by managers or poor synchronization settings, replacing equipment will not remove the problem. Therefore, first record the real work scenario.

1. Where orders come from: website, Prom.ua, Rozetka, phone, messengers, offline point of sale.
2. How many orders are processed per day: up to 20, 20–70, 70–200, more than 200.
3. How many products are in the database: up to 5 thousand, 5–30 thousand, 30–100 thousand, more than 100 thousand.
4. How many people work in the program simultaneously.
5. Where the database is physically located: workstation, local server, terminal server, rented server.
6. Which operations are slow: product filter, “Sales with invoice issuing” form, “Remote customer orders”, synchronization, reports.
7. Which actions managers perform manually even though the data for them is already in the order.

These answers determine what exactly you need: a new server, database maintenance, changes to synchronization settings or a revision of managers’ work procedures. Without them, any technical solution will be a guess.

Online store workflow in Torgsoft

For a business with several sales channels, it is useful to think in a single chain where each link passes data to the next one.

1. Product database

A product card is created in Torgsoft: name, barcode, article number, price, stock balance, description, characteristics, photos, manufacturer, product type. This database is the main source of truth for all sales channels.

2. Synchronization with sales channels

Products, prices and stock balances are transferred to the website through the Online store synchronization option, and to marketplaces through Prom.ua integration and Rozetka.ua integration. When a product is sold offline, the stock balance is also updated for online channels.

3. Loading orders

Orders from online channels enter the “Remote customer orders” mode or immediately create an invoice — depending on the synchronization object settings, order status and payment type.

4. Order confirmation

The manager calls the customer and clarifies the order contents, delivery and payment. At this step, the employee needs stock balances, prices, product photos and the customer history at hand. Fast dialing and a customer card during a call are provided by the Customer profile and Binotel calls option.

5. Invoice and shipment

After confirmation, the manager issues an invoice in the “Sales with invoice issuing” mode, creates an outgoing delivery document, posts the payment or records cash on delivery.

6. Delivery

A waybill is generated for the parcel through Nova Poshta integration or Ukrposhta integration. With correct settings, the recipient, phone, city and branch are pulled from the order data.

7. Payment

Bank receipts are loaded into the program through the Bank statements option and linked to invoices. The owner sees what has been paid, what is awaiting payment, where there is prepayment, and where there is cash on delivery.

8. Control

The manager reviews stock balances, sales, debts, unpaid invoices, managers’ work and profitability without manually compiling spreadsheets.

Server: when an ordinary computer is no longer enough

One computer is suitable for a small store with one user and a compact catalog. For an online store with several managers, marketplaces, a large database and active synchronizations, it is worth considering a separate server or terminal mode.

Signs that it is time to review the hardware:

• the database contains tens of thousands of products and many years of document history;
• dozens or hundreds of online orders are processed every day;
• several people work in the program simultaneously;
• filters, reports and period selections open for tens of seconds;
• the database is stored on an HDD disk;
• the operating system is outdated and does not support compatible SQL Server versions;
• database archives are created irregularly or only manually.

Approximate technical parameters

The parameters below are a practical guideline. Final requirements depend on the database size, number of users, sales channels and type of activity.

The minimum requirements from the official specification are designed for the simplest scenarios. For an online store with several sales channels, daily synchronizations and payment registers, choose a configuration with a reserve: additional memory and a faster disk cost less than moving the database again in a year.

Terminal mode has separate requirements: Windows Server operating system in Standard or Datacenter editions, a static IP address, from 8 GB RAM plus approximately 150–300 MB for each user connection.

SQL Server: what it is responsible for

SQL Server stores and processes the database. When the database is large and queries are complex, the state of indexes and statistics, disk and memory really affect speed. A standard installation uses the free SQL Server Express edition, which has resource limitations. For large databases and several simultaneous users, the SQL Server edition and server configuration are selected based on diagnostic results — there is no universal answer of “install a newer version” here.

At the same time, SQL Server has clear boundaries of responsibility. It can reduce technical delays at the database level. Duplicate products, chaotic names, synchronization settings, user roles and managers’ work procedures remain on the process side. Therefore, the correct question for a technical specialist is: where exactly is it slow, what database, what server, what operations are performed and what result needs to be obtained.

Before switching to another SQL Server version, check:

• compatibility of the operating system with the required SQL Server version;
• amount of RAM on the server;
• disk type — SSD;
• availability of a full database backup;
• administrator access to the server;
• a rollback plan if the migration has to be repeated.

Where to look for the bottleneck

The symptom suggests the direction of the solution. The diagram below shows typical “symptom and solution” pairs to start diagnostics with.

The last pair in the diagram is important for correct expectations: when a specific form works slowly on any hardware, the issue concerns the program logic. Such cases are passed to developers as a task and are solved by an update, so replacing the server will not help here.

Database maintenance: indexes, statistics, optimization

A database that has been working for years accumulates documents, sales history, financial transactions and synchronization logs. This is normal for an accounting system, but the database needs to be maintained.

Torgsoft has built-in tools for this: a service operation for rebuilding and reorganizing indexes and updating statistics, as well as a database optimization mode that analyzes slow queries and creates additional indexes and statistics. Optimization can noticeably reduce the time of individual selections if the cause of the delay is related to indexes, statistics or the query execution plan.

For performance, sufficient disk space, correct server shutdown and the absence of third-party processes that consume resources during peak load hours are also important.

What to prepare before moving the database and server work

Most time during technical work is lost when a specialist connects to an unprepared server. Send this list to technical support in advance — and the question of whether the configuration is suitable will be closed before work begins.

Online store synchronization: correct exchange logic

Exchange with your own website is built according to this logic: a product is created or updated in Torgsoft, the required fields are transferred to the website, the buyer places an order, the order enters the program, the manager processes it, and after the sale, stock balances are updated for all channels.

The most common mistakes that create manual work:

• products are edited both on the website and in the program at the same time — discrepancies appear;
• there is no single rule for names, photos and characteristics;
• synchronization is started manually when many changes have already accumulated;
• no one reviews the synchronization log, so exchange errors are noticed late;
• exchange is launched immediately for the entire catalog without testing.

Before a full launch, run a test on 20–50 products: several categories, different prices, products with and without photos, an “out of stock” item, an order with payment and without payment. This way configuration errors are detected before they affect the entire catalog.

Prom.ua: what to pay attention to

For working with Prom.ua, three things are critical: catalog, stock balances and orders.

• Catalog. Check the synchronization object, the list of fields for export, product groups and characteristic matching. If the import file of a large catalog exceeds the size allowed by the marketplace, use the file compression setting before sending — this allows the file to fit within the limit.
• Stock balances. When the same product is sold offline, on the website and on Prom.ua, manual stock updating leads to discrepancies. Stock balances should be transferred through configured synchronization so that the work is not duplicated manually.
• Orders. Configure scheduled order receiving and the invoice creation rule. Check payment methods: orders with different payment types must go to the correct accounts in financial accounting.
• Statuses. Processing an order in the program changes its status on the marketplace. Perform cancellation through invoice contacts so that the status is correctly transferred to Prom.ua.

Rozetka: what to pay attention to

For Rozetka, categories, characteristics, price list and order statuses are especially important.

• check the linking of marketplace categories with product types in the program — after changing the product type, the link must be updated, otherwise items will drop out of the price list;
• create names of additional price list fields without service characters — they break the file structure;
• control the size and completeness of the exported price list: an incomplete file moves products on the marketplace to the deleted state;
• to transfer the waybill number to Rozetka, the corresponding delivery status must be set in the outgoing delivery document — check this rule in the managers’ regulations.

“Remote customer orders” mode: manager’s workplace

This is the mode where the manager sees orders from the website and marketplaces. To make the work fast, configure:

• which synchronization objects to receive orders from;
• how to identify the customer and when to create a new one automatically;
• when to create an invoice: immediately or after confirmation;
• which accounting center to write off the product from and whether to reserve it;
• if an up-to-date program version is available — display of stock balances and product photos in the order so that the manager checks availability faster during the conversation with the customer;
• the “Status” filter, which separates orders without an issued invoice from those already processed.

For a large order flow, add an internal regulation: when to call the customer back, when to create an invoice, when to cancel an order, what to do with a customer who did not answer. The regulation removes most questions of “who should have done what” between managers’ shifts.

The customer changed the order after the call: how not to lose the markup

In real work, the buyer often asks to replace a product, add an item or change delivery. For online channels, this is an important pricing point: a separate markup for the website or marketplace may be set in the synchronization object, and the order enters the program already with these prices.

When a manager manually adds a product to such an invoice, the price is taken according to the program rules, so it must be controlled. Define in the regulation:

• who has the right to change an invoice for an order;
• at what price the product is added and how the channel markup is taken into account;
• who checks the final invoice before shipment.

Also check the synchronization object setting that determines where prices for the invoice by order are taken from: from the online store or from the program. In current program versions, prices of automatic orders are protected from accidental recalculation when invoice parameters are edited, while intentional recalculation is performed by a separate “Update prices” action.

The price on the marketplace and in the program differs: verification procedure

A price discrepancy has a clear verification route. Go through it step by step before drawing conclusions.

1. Check the product price in the product card in Torgsoft.
2. Check the markup and price source in the synchronization object for this channel.
3. Check the price of this item in the exported file or price list.
4. Check the price in the order in the marketplace account.
5. Check the price in the invoice in the program and whether the invoice was edited manually.
6. If the discrepancy repeats, send technical support the order number, product name, screenshots from the marketplace account and from the program, and the synchronization time.

This set of data allows support to distinguish a settings issue from a program error in one request.

Waybills: how to remove unnecessary manual actions

Delivery is the most common source of manual work in online trade. The manager should not transfer customer data from one window to another if this data is already in the order.

• check sender data and access keys to delivery services — an expired key stops waybill creation;
• make sure that the recipient’s city, branch and phone are transferred from the order;
• use Nova Poshta waybill templates: dimensions, weight, delivery type and payment control service are saved in the template, and the manager does not enter them every time;
• for invoices with cash on delivery, the payment control service is activated by the invoice attribute — check this on a test shipment;
• configure the return of the waybill number to the marketplace order so the buyer sees tracking without manual copying.

What is automated and what remains with the manager

The program pulls from the order the data that is actually present in it: recipient, phone, city, branch, parcel contents. The template saves dimensions, weight, delivery type and payment control service. The manager remains responsible for checking non-standard cases: another parcel recipient, changing the branch after the call, non-standard weight.

The marketplace account arranges shipment within one channel. The accounting system simultaneously creates an outgoing delivery document, writes the product off from the warehouse and prepares data for financial accounting across all channels, so some steps are the recording of accounting data. The number of actions is reduced by templates, complete data in the order and a work regulation.

Payments: cash-on-delivery registers without manually entering each amount

When a store sends dozens of cash-on-delivery parcels every day, receipts come in registers. Manually entering each payment quickly turns into a separate position. To avoid this, separate payment types and set a rule for each one.

Load bank receipts into the program through the Bank statements option and link them to financial documents. Some payments can be matched by details, while unidentified, partial payments and returns are checked separately by the responsible employee according to an established rule — these most often create discrepancies between the bank and accounting.

User roles: access according to the process

When everyone works under one user with full rights, it is impossible to understand who changed a document or deleted an item. Roles must correspond to the process.

Success criteria: agree on them before work begins

The wording “it got better” cannot be checked. Agree with the contractor on a list of specific acceptance points — then both the customer and the specialist understand in the same way when the work is completed.

• the program launches on the server, users log in from their workstations;
• the database opens, documents, stock balances and history are in place;
• the equipment from the task list works: printers, fiscal devices, scanners;
• the test chain has been completed: order, invoice, waybill, payment, stock balance change;
• a database archive has been created and its restoration checked;
• the opening time of problem forms before and after the work has been recorded.

Full test scenario

1. Open the product list and measure filter speed.
2. Receive a test order from each channel.
3. Check whether the customer was identified correctly.
4. Create an invoice.
5. Add a product to the invoice manually and check the price.
6. Generate a waybill and check recipient data.
7. Link the payment to the invoice.
8. Check the stock balance change in all channels.
9. Review the synchronization log for errors.
10. Create a database archive and make sure it was recorded.

For high load, check the entire typical day: several dozen orders, several managers, simultaneous work with invoices, waybills and payments.

Service, program error or request: how to distinguish

Some misunderstandings between the user and support arise from the expectation that any request concerns a program error. In fact, requests are divided into categories, and each has its own route. Diagnostics answers the question “which category does my situation belong to”.

Service formats and conditions are described on the technical support and implementation page. If the scope or cost of work raises questions, agree on them with support before diagnostics begins.

How to write a support request so it is resolved quickly

The wording “the program is slow” gives the specialist no entry point. Describe the scale, symptoms and expected result. Example of a workable request:

Such a request contains the scale, specific forms, measurable symptoms and work boundaries. It can be assessed, planned and the result can be checked.

What targeted diagnostics provides

Diagnostics covers the server, SQL Server, database condition, speed of problem forms, synchronization, waybill and payment settings. The result is a written conclusion: what exactly limits work, what needs to be changed on the business side, what work support performs and by which criteria the result is checked. With such a conclusion, the decision about a server, database migration or process change is made based on measurements.

Areas of responsibility: what technical support does and what remains with the business

Torgsoft specialists help with program configuration, migration to another computer, local network and terminal server configuration, integration connection, performance analysis, checking errors in program operation, backup configuration and updates. Software errors are registered and fixed through updates. The list of services and support formats is described on the technical support and implementation page.

The business remains responsible for: the server and network condition, licensed operating system, data quality in the product database, access to marketplace accounts, operation of third-party service APIs, managers’ discipline and archive control. Automation produces results when hardware, database, settings and people work according to one rule.

Checklist before launch or reconfiguration

Frequently asked questions

Conclusion

For an online store with a large catalog and several sales channels, only an integrated system works: a server that matches the load, a maintained database, a compatible SQL Server version, configured synchronizations, clear rules for orders, waybills and payments, user roles and regular archives. Torgsoft covers this process as a single accounting center.

Expectations are also part of the system. Agreed result criteria, a prepared server, proper distribution of responsibility and understanding of the request route reduce the risk of misunderstandings before work begins. The best result comes from this sequence: first describe your own process, then check the technical foundation, and after that configure automation for the real daily order flow.