[b]Я немного не понял идею.[/b]
Идея в том, что если не учитывать до копейки расход по каждой категории в чеке, и не перебирать каждую строку из полторометрового чека на калькуляторе так, что сумма всех созданных категорий точно совпадёт с суммой по чеку, а важна картина вцелом, но остати на счетах, само собой, при этом должны быть точными, то при таком подходе, быстрее всего зафиксировать именно сумму чека, а дальше добавить необходимые категории, бегло пробежавшись по чеку глазами и примерно распределив по ним суммы. Там, где мне вобще приходится пользоваться этой функцией, чек содержит категории типа "продукты", "вкусности", "алкоголь", "одежда"… Долю каждой из них , имея в руках чек, достаточно быстро прикинуть в "уме" с точностью +/- 30 рублей по каждой категории, а не тратить время, забивая в транзакции цену каждого товара построчно из беспорядочного чека. Но сумма чека при этом гарантированно будет верной. Не на столько я скурпулёзный статист, чтобы вычислять с точностью до копейки сколько в этот раз в Ашане мне обошлось пиво, а сколько носки)) Указанной ранее точности вполне хватает для понимания куда и в каком количестве уходят деньги и формирования бюджета. К слову, большинство покупок обычно состоят из одной категории: "транспорт", "бензин", "квартплата", "телефон", "интернет", "ипотека", "страховка", "бытовая техника" и т.д. И для тех, кто даже в "мультикатегорийных" чеках не делит "продукты" на "мясо", "хлеб", "молоко", "сыр", "овощи", "сахар", "печенье" и не создаёт чуть ли не для каждой строки бумажного чека отдельную транзакцию, описанный подход и идея сразу фиксировать сумму чека с целью сэкономить время при детализации чека, может показаться довольно логичными. У каждого свой подход, но даже тем, кто формирует чек, создавая точную копию бумажного в программе, наличие такой логики окажется бесполезным, но мешать не должно ;)