Anashka

Добрый день
Разработчикам на подумать: Бывает иногда стоит задача разобраться почему вроде бы одинаково заполненные документы ведут себя при проведении по разному. Или при настройке обменов вручную создается документ, а потом аналогичный загружается некоторыми правилами и необходимо сравнить его с эталонным.
Было бы супер если бы была такая фича как сравнение двух объектов у ИТК.
По сути она есть, но нужно выполнять некоторые манипуляции.
1. Открыть объект1 в редакторе объекта и сохранить в xml
2. Повторить только для объекта 2.
3. Сравнить их как текстовый файл средствами платформы или сторонними программами.

Но было бы отлично если в списке выделяешь два элемента справочника на форме списка (или документа) и ИТК сам бы выполнял пункты 1 и 2 и открывал их сравнение какими либо средствами.

Отличная подборка, спасибо автору.
Можно добавить следующие инструменты в раздел интеграций:
SoapUI - отладка веб. сервисов.
Fiddler - отладка REST сервисов
Liquid XML - просмотр и редактирование XDTO

Небольшая рекомендация:
Т.к. поиск осуществляется по реквизиту ПолеА, то стоит существующий реквизит переименовать в СтароеЗначение_ПолеА и добавить новый реквизит ПолеА. Это позволит сохранить старые значения для возможной повторной обработки данных.

(3) Константин С.,
Из решения системы видно, что оно ни как не зависит от выбранного вами способа расчета стоимости при движении ТМЗ. Эти стоимости как раз в уравнениях являются неизвестными, а в качестве свободных членов уравнения принимается стоимость начального остатка и стоимость внешнего прихода.
На счет кривизны учета тут можно долго спорить и рассуждать, в жизни допустимо (особенно для больших торговых сетях) наличие отрицательных остатков, т.к. возникают ошибки в пересортицах и до момента инвентаризации они не могут быть исправлены, а инвентаризацию делать ежемесячно перед закрытием не каждый может.

Цитата

Из-за того, что документы вносятся в произвольном порядке в пределах дня (порядок документов не играет роли) на счетах и в регистрах может складываться не совсем красивая картина, с наличием огромных сумм, которых в принципе быть не должно. Данная проблема может быть устранена расположением документов в нужной хронологии, но тогда теряется основной смысл РАУЗ - возможность произвольного расположения документов в течение месяца

думаю что нашел причину данной проблемы, описал ее тут http://infostart.ru/public/550292/
Проблема не том что документы в какой-то не такой последовательности, проблема именно в особенностях решения СЛАУ, или так скажем в правилах сходимости метода решения.

(1) script,
Я, опытным путем, пробовал разные варианты для данного условия и в некоторых случаях решение было найдено, в некоторых нет. Однозначно сказать могу только что решение 100% будет найдено если норма меньше единицы. Если же она больше единицы, то есть вероятность что решение не будет найдено.
Надеюсь что с помощью данной статьи кто-то из сообщества или общими усилиями поможет однозначно разобраться и понять данную ситуацию и конкретизировать правило при котором решения СЛАУ не будет.

В статье на примерах рассматривается, как в УПП при включенном РАУЗ решается система линейных алгебраических уравнений.