So imagine a big and both structurally and geographically sprawling organization with thousands of employees, hundreds and thousands of motley suppliers, contractors, and providers of all sorts of services.

For certainty we’ll take a typical major CIS retail network with hundreds of shops in dozens of cities of a no small country, and millions of clients.

The network has contractual relations at the outlet (with buyers) and at the inlet — with suppliers of its core goods for sale and, let us say, service providers, i.e. suppliers of all the rest, including services.

In 99.9% of cases, its contractual relations with buyers (and even the purchase of a yoghurt at some X5 "Pyaterochka" discounter shop is a particular case of contractual relations, based on a public offer + a receipt), are standardized, however numerous.

At the same X5 discounter network, an unlimited number of buyers are all processed uniformly, and their relations with everyone are the same: take things off the shelf — pay the cashier — good-bye and thank you
for your purchase.

At the Metro shops that make huge efforts to create the semblance of wholesale relations with counterparties (for a degree of protection from Russian retail regulations — traditionally moronic, like any regulations imposed by officials no matter where), the customer processing business processes are a bit more diverse; the buyer (formally, always either a legal entity or a sole proprietor) may pay either in cash or by bank transfer.

At Ulmart, there are even more options; the buyer may be either a natural or a juridical person, and the latter may pay either way, and all may use balance offset, plus partial payment for purchases with accumulated
bonuses — in short, there are some ten outflow processing options (depending on how you count).

However: whatever number of options there may be (one like at Pyaterochka or ten like at Ulmart), it will be negligible as compared to the number of physical transactions using those options, that runs into millions.
To put it professionally, the customer service business processes in the above companies (and others of similar trade and scale) are fully standardized.

In respect of suppliers, all quite the contrary.

If we discard suppliers narrowly understood, meaning suppliers of the core goods-for-sale (foodstuffs for the
above-mentioned X5 shops), also handled in a highly standardized manner, albeit somewhat less so than are their customers, — there remains a variegated host of suppliers of all the rest (let’s call them SARs) required for the operation of a big and sprawling organization.

Here’s what SARs supply:

• toilet paper for the office;
• cellphone communication for personnel;
• stationery;
• lease services (shop and storage space);
• cleaning services (outsourced);
• petrol for the corporate vehicle fleet;
• transport services — rent of vehicles from external companies;
• entertainment services for holding team-building events and corporate booze sessions;
• shop and office space renovation services;
• shop equipment and
  ... really thousands of items from hundreds of SARs.

Incidentally, for each geographically detached unit the same goods mix may be (and sometimes is) supplied by different SARs.

The terms of work with each one are individual. Somewhere, one-time purchases are made on prepayment; elsewhere, regular purchases into the inventory and periodic payments in arrears (the periods may vary), or regular fixed payments but quoted in foreign currency and made at the current exchange rate; again, thousands of variants are possible.

This puts the related business processes into a heavenly order best described by the comprehensive term "thrash, haze and sodomy".

Here are some characteristic brushstrokes from Ulmart’s life (of course, the "before" picture) — relating only to their rent relations.

• "accounting" was based on hundreds of monstrous Excel spreadsheets;
• they would often forget to make payment requests on time and incur penalties;
• a rent security deposit is usually made. They would often forget about it or, if the last month of rent was incomplete, they would make a full payment and then forget to calculate the difference. That resulted in overpayment;
• the weekly plan of rent payments for the treasury was (naturally) made manually, in still another spreadsheet — of course, with a lot of errors. The treasury would either borrow too much to pay rent (and pay extra interest), or face penalties if it didn’t have enough money to pay on time;
• they would forget to reflect the rent costs in the system, which resulted in a substantially distorted P&L statement;
• budget control: when entering into a contract, they would usually do it by rule of thumb (using another separate spreadsheet). As for contracts for large amounts, they would try to monitor (with variable success due to human factors). And if the amount was not large, nobody would bother. Nuff said.

The annual losses would run into millions.
And that was about the rent alone.

The dia$par abstraction of a contract is essentially about

• a mechanism for earmarking budget funds and
• timely creation of payments.

Objects

Physically, it is a document in the system that contains a payment plan and an expenditure plan (for this specific contract).
For example, if this a year’s rent contract that provides for monthly payments, while the company reports to its shareholders on a quarterly basis, then the payment plan will consist of 12 lines, and the expenditure plan will contain four lines, accordingly.

The "Contract" document’s head will contain the following information:

• the contracting entity on our side;
• the supplier counterparty;
• the settlement account from which the payments are to be made; and
• the contract’s currency

If there are more than two parties to the contract, then the payees will be indicated in each line of the payment plan.

If the contract is concluded with a natural person, then the taxation parameter tab will be activated. By default, the system will automatically form a second payment request for the tax authority indicating the natural person’s income tax amount (this default feature can certainly be disabled :)

As the initiator creates a new "Contract" document, its signable binary (*.doc, *.jpg, etc) version will be attached.

Contract Movement

The initiator will first create a document in the "Contract Request" (draft) sub-type and move it into the "For Signature" sub-type.

The signatories are determined at this stage:

The list of approvers/signatories is formed automatically based on the approvals matrix, and documents can be signed via a mobile application — see here for more details.

The Discussion of a Contract:

If an additional agreement to a contract is concluded, the contract cannot be simply opened in the system so that its parameters can be changed.
The contract’s related document of the "Additional Agreement" type must be created and then pass the whole signing cycle like an ordinary contract. On being signed, the additional agreement will adjust the main contract automatically. Two types of adjustments are possible:

1. Individual lines in the main contract’s payment and expenditure plans can be replaced or delete altogether...
2. New lines can be added without touching the existing ones.

The system calculates the balance of the payments budget in each line of the payment plan and the balance of the expenditure budget in each line of the expenditure plan. If the budget is exceeded, the respective lines will be highlighted in red:

If at least one line’s budget in the payment or expenditure plan is exceeded, the whole document will be highlighted in red:

The budget can be controlled in two modes:

• soft: the system will just issue an excess warning and pass the contract on, and
• hard: the system will not pass the contract until the budget is adjusted.

After obtaining all the signatures, the document moves into the "Contract" sub-type — a valid and binding contract.
Robots begin working with it to create payment requests, five days before the payment date, and expense documents.

Payment request can also be created manually without a contract — we’ve already discussed it here, but the charm of the contracts mechanism is that:

• a) in this case, dia$par creates requests on its own and always on time; and
• b) a request originating from a contract is signed by just one employee, namely the comptroller. The approval process is virtually instantaneous, and the approved request moves into the treasury’s domain at once. And in the ordinary case (the contracts mechanism not used), the approvers will include the expense item owner, financial director, head of department, regional director, and accountant. This process is typical of each big company with only an average level of red tape.

Payment Processing

If the payment plan indicates the exact amounts (e.g. the fixed monthly rent), the system will automatically form payment requests to be signed following the shortcut path (for both the budget and necessity were checked as the contract itself was signed). In this case, as the user creates the contract, he checks the "Exact
Payment Schedule" box, and the system will create payment requests on its own, five business days before each payment date.

If only estimated amounts are known as the contract is created (the so-called "variables", e.g. payments for Internet ads or electricity bills), the system will notify the contract owner of the necessity to create a payment request for the exact amount. This request will also follow the short path.

There is functionality that facilitates the completion of the payment plan for typified cases:

• for rent payments: a given period’s payments (e.g. for the year ahead) are calculated automatically with all the taxes;
• loan agreement processing: the loan’s parameters and repayment schedule are indicated, and all the future payments will be calculated automatically.

In creating schedules, the system takes weekends and national holidays into account.

As each contract includes a payment plan, the system can provide the treasurer with any days", weeks", or months" summary forecast of what and when must be paid under all the contracts, broken down by entity and cash-flow item.

If using the contracts mechanism (as opposed to manually created payment requests) becomes the standard for all the company’s units, this report essentially represents the expenditure side of the cash-flow forecast.

We particularly note that this forecast is formed automatically.

Cost Processing

On the basis of the cost plan included in the contract, cost forming documents are generated automatically.

So how did the Ulmart moneymen’s daily life change after the above features were implemented?
As usual, Comrades: Glory to God in the highest, and on earth peace, good will toward men.
(Luke 2:14)

The payments are made strictly within the budget.
Negotiating payments takes minimal time; 0 unneeded signing motions, and the treasury already has money to pay as required.
Among other things, this enabled Ulmart to reduce their rent losses to zero (with hundreds of rented
facilities). A windfall of millions.
Only one person monitors all the rent payments — in addition to his main financial duties: "It works? Don’t touch it!"

This is what efficient management is about.
At least it seems so.

Our dear readers who are lucky enough to work in organizations of similar scale are kindly requested to compare their own experience with that illustrated above.

P.S. The comparison must be most impressive for the personnel of companies operating immensely prestigious "document turnover automation systems" that cost at least hundreds of thousands of dollars (in their poorest man’s versions).