Закрытие и коррекция

[AlexUnik]

Доброго времени суток!
Сегодня столкнулся со следующей проблемой:
- необходимо выполнить закрытие склада, себестоимость считается по средней;
- переливаю все данные с рабочей компании в тестовую (SQL Server и AOS тестовой компании расположены на отдельном сервере с более слабой конфигурацией, чем рабочий);
- на всякий случай делаю синхронизацию и реиндексацию таблиц на тестовом сервере;
- выполняю закрытие в тестовой компании;
- выполняю закрытие в рабочей компании;
- условия закрытия одни и те же: минимальная пропускная способность - 100, минимальная коррекция пропускной способности - 1; минимальный процент сопоставляемого количества - 10; минимальная сумма сопоставления - 5; минимальное среднее количество при закрытии - 0,1.
- после выполнения закрытия обнаруживаю внушительную разницу по рассчитанной себестоимости в тестовой и рабочей компаниях (сумма на 90 счете) - примерно 0,02%;
- в ходе выяснения обнаруживаю, что возникает разница из-за того, что суммы коррекции в тестовой и рабочей компании отличаются по некоторым проводкам примерно на 5-10 рублей вне зависимости от суммы проводки;
- после это еще раз проверил исходные данные - вся информация перекачалась в тестовую компанию нормально, обороты полностью совпадают.

У кого какие предположения могут быть по этому поводу?

[Hezl]

Может приложения различаются?

[bucken]

Может расхождение в рабочей и тестовой логике приложения появились? Попробуйте с рабочей логику на тестовую тоже копировать, помимо данных. Но это так предположение...

[bucken]

Цитата:

Изначально опубликовано Hezl
Может приложения различаются?

вот человек уже про это и сказал.

[AlexUnik]

Цитата:

Может расхождение в рабочей и тестовой логике приложения появились? Попробуйте с рабочей логику на тестовую тоже копировать, помимо данных. Но это так предположение...

Расхождения в логике по механизму закрытия склада исключены, так как изменения не вносились. К тому же математика тестовой компании просто копировалась с математики рабочей.
Повторная заливка данных и пересчет ничего не дал - те же результаты.
Быть может, на расчет себестооимости влияют ресурсы? В одно случая считается с одной точностью, в других - сдругой?
А как у Вас обстоят дела с закрытием идентичных компаний на разных серверах? Неужели все закрывают склад сразу в рабочей компании?

[xonix]

Вот было бы здорово, чтоб Аксапта была такой умной, чтоб в зависимости от оборудования меняла бы логику работы!
Надо в МБС идейку подкинуть

[AlexUnik]

Цитата:

Вот было бы здорово, чтоб Аксапта была такой умной, чтоб в зависимости от оборудования меняла бы логику работы!

Вы, наверное, забыли то время, когда программы, написанные на Clipper, рабоатли на одних компьютерах и не работали на других :^) Причина была в процессорах...

[xonix]

Было дело... наверно... я клиппер в то время обошёл стороной.
Так ведь "не работали"!
Припомните случай, чтоб "работали, но по другому"

Может, просто дело в алгоритме закрытия? Может, результат неустойчив относительно порядка обработки? Т.е. при перезаливке данных меняется порядок следования данных, а где-то в алгоритме нет принудительной сортировки какой-нить таблицы - и данные выгребаются в другом порядке?

Для "спокойствия" забэкапьте и поднимите всю базу средствами MSSQL и убедитесь в идентичности результата...


Ээхх.. Килппер... Были времена....

[AlexUnik]

2 xonix

Цитата:

Для "спокойствия" забэкапьте и поднимите всю базу средствами MSSQL и
убедитесь в идентичности результата...

Спасибо. Да, наверное, только это осталось. Все остальное не помогло. Мы тоже пришли к выводу, что причина в сортировке. Подниму бэкап - расскажу

[AlexUnik]

Продолжение истории.
Создал вторую компанию на рабочем сервере. Залил в нее архив, сделанный до пересчета. Закрыл склад. Проверил с данными рабочей компании на этом же сервере. Все сходится. Ладно, значит, данные не корректировались после того как был сделан архив.
Теперь снова заливаю архив в ту же компанию на рабочем сервере. Делаю бэкап рабочей базы данных средствами SQL Server. Поднимаю его на тестовом сервере. Переливаю математику с рабочего сервера. Закрываю склад. Проверяю с данными рабочей компании - опять та же самая разница! Мистика какая-то..

[Андре]

1. Проверьте все-таки идентичность приложений. Хотя бы путем копирования приложения с одного сервера на другой.
2. Если приложения одинаковые, а погрешность небольшая - наверное, можно попробовать списиать это на особенности "интерпретатора" Аксапты и архитектуру процессора. В моей практике было несколько случаев, когда одна и таже программа выдавала различный результат на разных машинах - в частности, на foxpro-шных програмах. Кроме того, довольно известная "ошибка" - любая программа на Pascal скомпилированная на Pentium и запущенная на Pentium2 вылетает с runtime ошибкой. Если же, эту же программу перекомпилировать на Pentium2 (тем же самым компилятором) - то она корректно работает на обеих машинах.

То есть, я готов предположить, что на различных машинах, с различными процессорами, а тем более архитектурами Аксапта порождает различный машинных код из одного и того же X++ кода. Например, рассовывает переменные по разным регистрам, принимает различные решения о распределение переменных в стеке/регистрах/памяти и т.д., что теоритически может привести к некоторым погрешностям.

[xonix]

2 Andre
Вы это серъёзно, или прикалываетесь?

[Андре]

Про что именно ? Процитируйте, пожалуйста.

[xonix]

Про то, что есть связь между размером погрешности и архитектурой процессора?
Разный результат, который выдавала программка - это не пример к данному случаю. Что за программка и какой результат был неустойчив? Мож там программка специально мерила производительность системы и меняла алгоритм (я и говорю, мож и аксапта такая продвинутая?)
Я Не верю, что на разных архитектурах результат может даваться с разной точностью на одном и том-же алгоритме. Либо работает - либо нет (это случай с Runtime).

[Андре]

Цитата:

Про то, что есть связь между размером погрешности и архитектурой процессора?

Я этого не утверждал. Про связь РАЗМЕРА погрешности и архитектуры. А вот про факт НАЛИЧИЯ погрешности (и ее отсутсвия) я высказывал ПРЕДПОЛОЖЕНИЕ. Которое может быть истинным, а может и нет - у меня нет доступа к ядру Аксапты.

Цитата:

Мож там программка специально мерила производительность системы и меняла алгоритм

Нет.

Цитата:

я и говорю, мож и аксапта такая продвинутая?

Нет.

Цитата:

Я Не верю, что на разных архитектурах результат может даваться с разной точностью на одном и том-же алгоритме.

Я тоже.

[Андре]

Перечитал еще раз свое сообщение. Прошу прощения, похоже я вот здесь неточно выразился и сбил всех с толку:

Цитата:

Если приложения одинаковые, а погрешность небольшая

Нет, я не считаю, что есть связь между размером погрешности и архитектурой процессора. Я имел в виду то, что иногда (очень и очень редко) архитектура влияет на результат выполенния программы.
Более того, я на 99,99% уверен в том, что в данном случае высказанное мною предположение не имеет отношения к описанной выше проблеме.
На те же самые 99,99% я уверен, что у человека отличаются либо приложения, либо данные, либо настройки. Но если он с этим не соглашается, и убеждает что все идентично, то в рамках оставшихся 0,01% я могу высказать любую гиппотезу, которая может иметь отношения к данному случаю. Вот только не надо забывать про вероятность того, что дело именно в этом

[AlexUnik]

2 Андре и Xonix
Спасибо за поддержку :-)

Для очистки совести запустил сейчас глобальную компиляцию на тестовом сервере. После чего перелью данные из архива рабочего сервера и закрою склад еще раз.
Этим, я надеюсь, смогу окончательно развеять сомнения в идентичности математики приложений.

Во всем остальном никаких различий не должно быть, поскольку:
1. Данные не изменялись после создания архива, т.к. закрытие склада во второй компании на рабочем сервере дало теже результаты, что и первое закурытие на этом сервере.
2. Серверные базы данные тождественны, т.к. получены путем серверного Backup и Restore.
3. Математика не должна различаться, т.к. была просто скопирована с рабочего AOS на тестовый.

Продолжение следует...

[AlexUnik]

Глобальная перекомпиляция не изменила ситуацию. Различие то же самое, что и первоначально, - где-то в районе 0,02%. Для больших оборотов это выглядит внушительно, но только для тех, кто знает о различии в расчетах :-)

[fed]

Есть еще такая гипотеза:

При загрузке проводок по inventTrans при закрытии склада, система сортирует их по индексу openItemIdx (там valueOpen и itemId) (то есть скорее всего соритрует - там в запросе стоит фраза index hint, а не index .
В принципе - если при переливке данных с сервера на сервер изменился порядок ключей в индексе (уж не знаю как там MS SQL индексные страницы сортирует при переброске бэкапа) то и порядок обработки проводок мог изменится.
Ну а порядок этот на довольно много всяких вещей влияет. (Мне несколько лениво тут все возможные случаи расписывать)

В общем - попробуй в этот индекс в конец добавить поле recId и в методе load класса inventCostItemDim поменять фразу
index hint OpenItemIdx
На фразу
index OpenItemIdx

Если после всего этого у тебя склад все равно будет по разному закрываться - останется только списывать все на гремлинов живущих в сервере

[AlexUnik]

2 Fed
Спасибо. Я так понял, большинство склоняется к этому варианту. Сейчас попробую проверить. Единственное, что могу сказать сразу - даже когда открываешь таблицу InventTrans через репозитарий в рабочей и тестовой компании - порядок записей различен. Ну это и понятно, т.к. индекса по полям ValueOpen + ItemID явно недостаточно для создания жесткой последовательности.