Занятные замечания по программам семейства УС Лэнд от реальных пользователей : КИС Lack & УС Land

Зачастую пользователи обращаются с нестандартными вопросами или запросами, а иногда замечают ошибки в программах, исправления которые приводят к обнаружению "нежданчиков" и глобальной переделки системы... Вот, например недавно присланный скрин с вопросом - как такое могло произойти?





… и одна из глобальных проблем, выявленных при анализе скрина. Выявлено, т.к. обычно использую данные от пользователей просто для отладки нюансов программы, а "вне" этих нюансов данные не анализирую, а посему иногда получаются такие неожиданности.

Последний код документа == ZVMU, т.е за время работы фирмы с программой было создано более 1.7млн безналичных операций и счетчик документов - уникальных кодов уже очень близко к пределу == ZZZZ (36-ричное число). Удивительно, т.к. голова забита другими задачами, но вспомнил, что уже предполагал у них такую ситуацию и в версии 2112 системы продумал и сделал перекодировку счетчика по данным типам документов в программа hLv... Ну а дальше, когда все ушли с работы автоматом преобразовал коды и получилось:





… но это была лишь одна прблемища выявленная на скрине => продолжение следует

Продолжение - окончание:

Изначально, где видны все проблемы было в письме со скрином:





Проблема была сложной для понимания, т.к. задающий вопрос не помнил, как это сделала? Следовательно нужно было найти способ, как её повторить. В программе есть много способов привязать оплаты к накладным, что даёт возможности для многих аналитик, хотя с позиции "аналитики" привязки не обязательны. Перепробовал все способы, например, когда задаём сумму платежа, а программа сама автоматом подбирает накладные для привязки:





Всё работало чётко, пока не "нащупал"... В списке накладных для оплаты (привязки) можно для самоконтроля задать общую сумму платежа и ручками подобрать под неё накладные, а программа просто контролирует, что бы сумма по отобранным ТТН не превысила заданную.





Хвост оплаты создаёт отдельный непривязанный к ТТН платеж. Так вот, если указать сумму точно равную подобранным ТТН, программа создавала липовый документ с нулевой суммой. Осталась "последняя" загадка - почему привязан нулевой платеж к накладной?

Оказалось, что программа честно и тупо отражала список накладных с непривязанным хвостом меньше или равным нулевой сумме финансового документа, т.е. полностью оплаченных и к ним можно было привязать нулевую сумму в режиме «^ -> Связать с товарно-транспортной накладной»... Исправил эту некритичную ситуацию заблокировав привязку нулевых сумм и отбор полностью оплаченных накладных.