What is the optimal algorithm for uniquely determining the terms in the sum?

Question

Mathematics

Business has a problem. Customer orders are sent by mail by cash on delivery (this is when payment is received), they are being processed (sending, receiving, processing payment) for a couple of weeks. In the current situation, we can have 20-50 orders at a time in different shipment statuses.
After paying for orders every few days, we receive a payment from the post office. One amount. And it is important for us to know the specific orders that were paid for. This information is not included in the bill.
There was an idea to regulate this with the help of order amounts. We are ready to go to certain costs, providing a small discount, so that later we can understand by the amount which orders were paid.
From my student days, I remember that there are some mathematical theories that will help encrypt data in this way. so that later on by the sum it was possible to unambiguously decipher them.
What should the algorithm be able to do?
1) Suppose we have already sent, but not yet closed deals with amounts S1, S2, S3..., Sn. We receive an order with order amount Z0. We need to change its price in such a way that its final price is Z1 such that there is no set of indices i, j, ..., k, and a, b, ..., c such that Si + Sj + .. .+ Sk = Z1 + Sa + Sb + ... + Sc, while from all possible options Z1 must be chosen such that the difference |Z0-Z1| was minimal.
2) We receive a payment from the Post with the amount P. The algorithm must uniquely determine i, j, .. , k, such that Si + Sj + Sk = P

Answer 1

If we represent the cost of a separate order (in kopecks) in a 2-ary number system (a set of bits) and each order must set only its own bit (take the least significant bits, setting the rest to 0), then the sum of these numbers in the least significant digits will be similar to the bitwise OR operation , i.e. by the total amount, it will be possible to clearly understand which order was included in it.
After receiving the payment, we will receive in total in the least significant bits those orders that have been paid, and for subsequent orders we take these vacated bit positions.

Example, we take the lower 4
bits for the address (the ability to simultaneously be processed by 4 orders) orders, for example 1 + 2 + 4, then this will give the amount of 299r - 10010 1011 , look at the least significant bits, 1,2 and 4 are set

The disadvantage is that 20 orders are 2 ^ 20 kopecks - this is a price difference of 10t.r. (i.e. the 20th order may differ in price from the initial one by this amount), it also imposes a restriction on the minimum order price (you can select lower bits for cheap orders and older bits for more expensive ones.
It is logical that this will only work if there are few orders, for example, 2 ^ 10 is only 10.24r
Unfortunately, if you do not add some other knowledge about the possibilities of grouping orders, then this will not be optimized in any way

Answer 2

The simplest thing is to encrypt the last 2 digits of the order number as a penny in the payment amount. Or 3 digits - as the last digit of the ruble amount + kopecks. There will be no uniqueness, but reducing the number of candidates by 100-1000 times may be quite enough for your task.
But this is such a decision. In general, cash on delivery (and the form of cash on delivery, in theory, you prepare as the sending party) has a "destination" field. And the post office is obliged to give it to you along with the payment. What prevents you from entering the order number in the appointment in your system? "Order payment #XXX-YYY-ZZZZ" or something like that.

Answer 3

Here they suggest installing bits, this is a working solution, but it introduces a large error. Often you can do much better. You need to ensure that no amount can be made up by different subsets of active orders, right?
First, by exhaustive search, find the sums of all subsets. If there are matches, take the minimum amount that can be scored more than 1 time. Subtract 1 kopeck from the random order. Repeat the process. If the prices are plausible, well over 100 kopecks and the prices vary, then even for 20 orders you will only have to subtract a few kopecks.
True, if there are a lot of orders with the same price, then the lower bits will also have to be changed.