Synchronization pitfalls in PDP Mobile with 1C:ERP for accounting and meters

“One electricity meter ended up with three readings for the same date.”

In PDP Mobile, we added synchronization with 1C:ERP: personal accounts, charges, meter readings, and receipts. On paper, it looks like a standard exchange with an accounting system. In practice, the places where you can’t cut corners show up quickly: meter identifiers, time series of readings, and tariff zones.

Below are three pitfalls we avoided in this integration.

Pitfall 1. Link readings only to the personal account

A personal account is a convenient entity for the user: they see the property, charges, and receipts. But for accounting, a reading belongs not to an abstract “account”, but to a specific meter in 1C:ERP.

That’s why each meter in PDP Mobile stores the identifier from the accounting system. Not a local number from the mobile app, not an address, not a resource type, but the meter’s id in 1C:ERP. This field becomes the anchor point when transmitting readings.

If you send only the personal account and a set of values, there are too many guesses left on the 1C side: which device to accept, where to attach the history, what to do when the meter is replaced. We removed that ambiguity at the model level: first we identify the meter as an accounting object, then we send its readings.

A practical detail: the most discussion was not about PDF receipts, but about where the boundary lies between “data for the screen” and “data for accounting”. On screen, you can present things compactly. In an integration, compactness quickly turns into loss of meaning.

Pitfall 2. Treat a reading as a single number

For a single-tariff meter, this is tempting: date and value. But the project includes a three-tariff electricity meter, which means that for a single date we receive separate values for zones T1, T2, and T3.

We did not collapse them into one field and did not send an “overall total”. Readings are sent as time series: date plus values by tariff zone. For a three-tariff electricity meter, T1/T2/T3 are transmitted separately.

This format matters not just for a clean structure. Charges in 1C:ERP are tied to tariff zones. If the zone is lost on input, accounting ends up with data that can no longer be correctly broken down again.

The minimal record format looks like this:

{
  "meterAccountingId": "id-in-1C",
  "date": "2024-..-..",
  "zones": {
    "T1": "...",
    "T2": "...",
    "T3": "..."
  }
}

What matters here is not the JSON itself, but the contract: the date is not separated from the values, and the zones are not mixed together. For meters with one zone, the structure is logically the same, just with a shorter set of zones.

Pitfall 3. Generate the receipt separately from the 1C data

A PDF receipt is the visible part for the user, so it is easy to start assembling it in the app: take the charges, personal account, and period, then render a template. But then you end up with two versions of the same financial entity: the data in 1C:ERP and the PDF assembled by the app itself.

We went the accounting-system route. PDF receipts are generated from 1C data. PDP Mobile receives the result that matches what accounting considers the source of truth for calculations.

This is especially important alongside charges and readings. The user submits readings, 1C processes the data, generates charges, and then a receipt is produced from that data. If you break the chain and render the PDF separately, discrepancies will look like an app bug, even though the root cause may be a mismatch between sources.

What we fixed in the exchange contract

In this integration, we kept a few rules in place:

• the personal account is synchronized as an accounting entity, not just as a card in the app;
• each meter is linked to an identifier in 1C:ERP;
• readings are transmitted as a time series with a date;
• tariff zones T1/T2/T3 are not merged;
• the PDF receipt is built from 1C data.

The worst place for a bug is not the transport or the PDF file. It usually appears earlier, in the data model: one meter is treated as a single number, and a personal account is treated as a sufficient identifier for the device. For an electricity meter, the contract must contain the date, the meter id from 1C:ERP, and separate T1/T2/T3 values.