О сломанных шестеренках в большом моторе

[AlexSD]

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

Загрузка курсов в пакетном режиме не более чем бантик. Если предприятию так сильно нужен курс на завтра, я не думаю, что утомительно запускать эту процедуру в нужное время.

ЗЫ. Я был тогда и остаюсь в курсе, в какое время появляются курсы на сайте ЦБ.

[sukhanchik]

Цитата:

Сообщение от EVGL

Еще один кошмарный образчик неудавшейся функциональности - это т.н. "трехсторонее сопоставление":

Ага, а еще это "многостороннее сопоставление" убило возможность корректировки входящего НДС. Ведь исходящий НДС мы должны посчитать по ставке 18% (ну или по той ставке, которой надо) - а входящий по большому счету - мы не считать должны, а должны забить таким, каким он к нам пришел в счет-фактуре, даже если он отличается от расчетного.
Возможно, конечно - что виновато в этом не это сопоставление - но, учитывая схему его работы - ручная корректировка входящего НДС совершенно не вписывается в идеологию сопоставления. А проанализировав код, который лишил возможности корректировать НДС - я все-таки пришел к выводу - что отключили эту функциональность исключительно ради функциональности трехстороннего сопоставления.

Речь идет о форме Настройка-Налог из заказов на покупку. Вкладка Корректировка появляется только для исходящего налога (форма TaxTmpWorkTrans).

Вот что на форме прописано в методе init (особенно порадовало - КАК это написано - formstr и название формы с апострофами):

......     
        switch (callerForm.name())
        {
            case formstr('PurchTable') :

                regulationTab.visible(false);
                tmpTaxRegulation_ds.allowCreate(false);
                tmpTaxRegulation_ds.allowDelete(false);
                break;
......

Здесь - relulationTab - как раз та самая закладка Коррекция

Метод setAllowEdit той же формы:

    if (callerForm)
    {
        if (callerForm.name() == formstr('PurchTable'))
        {
            purchaseOrderForm = true;
        }
    }

    if (sourceSingleLine || (!taxRegulation.taxLinesExist() && !invoiceRegister)
        || purchaseOrderForm == true)
    {
        tmpTaxRegulation_ds.allowEdit(false);
        taxRegulationField.allowEdit(false);

Что любопытно:
1. "Врезки" с упоминанием PurchTable сделаны аккуратно. Если их также аккуратно убрать - то функционал корректировки входящего НДС появляется. Правда в этом случае начинает (как и ожидалось) крышу сносить у трехстороннего сопоставления - НДС-то уже "не тот" . Я имею в виду конечно вариант, когда цена включает НДС.
2. Код формы TaxTmpWorkTrans в 4.0 SP2 отличается от кода формы в 2009 RU6 исключительно этими вставками
3. То, КАК было написано название формы в коде позволяет сделать вывод о гхм... сравнительно небольшом опыте работы в АХ разработчика, писавшего этот код. Неудивительно - что он "поломал" функциональность корректировки - он просто мог не знать для чего она нужна....

А теперь самое интересное. В официальных тренингах от МС корректировка входящего НДС описана как работающая функциональность, которую нужно показывать слушателям (ну, само собой, трехстороннее сопоставление тоже должно показываться). Правда, налоги рассказываются в курсе по финансам (Финансы 1, глава 6; Корректировка на стр. 6-62), а сопоставление - в курсе по логистике (Логистика 1, глава 3 на стр. 3-64) .

[Logger]

sukhanchik, а как вы в итоге для себя эту проблему решили ?
Включили обратно возможность корректировки НДС, пожертвовав остальным ?

[sukhanchik]

Цитата:

Сообщение от Logger

sukhanchik, а как вы в итоге для себя эту проблему решили ?
Включили обратно возможность корректировки НДС, пожертвовав остальным ?

На проекте - естественно - выкинули нафиг трехстороннее сопоставление и вернули "взад" функциональность корректировки входящего НДС.
На курсах - корректировку приходится показывать на исходящем НДС (благо там работает), говорить - что на входящем НДС как бы аналогично, но "есть нюанс"

[mnt_dx]

Плохо даже не то, что функции а-ля ГАК не работают, а то что они не дают жить нормально - справочники по-новому качать. Может они специально, чтобы разработчикам было не скучно?

[EVGL]

Корректировку входящего НДС можно делать непосредственно в форме разноски накладной.

[sukhanchik]

Цитата:

Сообщение от EVGL

Корректировку входящего НДС можно делать непосредственно в форме разноски накладной.

Да, это верно. Но, кто ж в РФ чего-то правит в форме разноски заказа? (Шутка).
Опять-таки - а почему в форме разноски можно корректировать, а в форме заказа нельзя?. И документацию не обновили.
Но в целом - согласен - выйти из положения конечно можно

[Bega]

Цитата:

Сообщение от Ivanhoe

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

Коллеги, поделитесь, как в результате решали на проектах проблему с "подвисшими" накладными?

[mazzy]

Цитата:

Сообщение от Bega

Коллеги, поделитесь, как в результате решали на проектах проблему с "подвисшими" накладными?

не-не-не!
ребяты, пожалуйста, не засирайте потенциально интересную и достаточно общую тему. Задайте вопрос в соседней ветке. не бойтесь, и соседнюю тоже прочитают, и ответят.

Здесь же тема задана EVGL: О сломанных шестеренках в большом моторе

Цитата:

Сообщение от EVGL

С высоты 12 лет работы с AX и с чувством внутреннего превосходства практика над теоретиками хочется пофилософствовать о том, как мельчайшая недоделка делает невнедряемыми целые модули.

[EVGL]

Цитата:

Сообщение от AlexSD

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

Загрузка курсов в пакетном режиме не более чем бантик. Если предприятию так сильно нужен курс на завтра, я не думаю, что утомительно запускать эту процедуру в нужное время.

ЗЫ. Я был тогда и остаюсь в курсе, в какое время появляются курсы на сайте ЦБ.

Честно говоря, я на вашем месте не оправдывался, а налил бы себе водки, выпил с горя и задумался бы над философской составляющей темы. Ибо любой бантик в реальном мире реальных денег и людей должен работать на 100%. Или "бантика" просто не должно быть. "Бантик", работающий на 98% исключительно опасен, и я сейчас это продемонстрирую.

Этот чудо-класс не делает ExchRate::flush(). Т.е. в результате импорта, не важно какого - ручного или автоматического - курсы появляются, но на непрерывно работающем AOS курсы для отгрузок берутся все равно старые из кэша. Я благодарю Бога, что я заметил это сейчас, перед вводом в эксплуатацию, а не после.

[Logger]

Цитата:

Сообщение от EVGL

Этот чудо-класс не делает ExchRate::flush(). Т.е. в результате импорта, не важно какого - ручного или автоматического - курсы появляются, но на непрерывно работающем AOS курсы для отгрузок берутся все равно старые из кэша.

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

Чтобы все четко было надо этот инструмент переделывать, например вводить какую-нить рассылку сообщений всем активным клиентам, по приемке которой они бы сбрасывали свои кеши.

[Pustik]

Цитата:

Сообщение от EVGL

Этот чудо-класс не делает ExchRate::flush(). Т.е. в результате импорта, не важно какого - ручного или автоматического - курсы появляются, но на непрерывно работающем AOS курсы для отгрузок берутся все равно старые из кэша. Я благодарю Бога, что я заметил это сейчас, перед вводом в эксплуатацию, а не после.

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

Цитата:

Сообщение от Logger

Чтобы все четко было надо этот инструмент переделывать, например вводить какую-нить рассылку сообщений всем активным клиентам, по приемке которой они бы сбрасывали свои кеши.

Согласен с решением.Как быть, если человек занимается отгрузкой ежеминутно.Настроить ему ежеминутную поставку сообщений - это понятно.Этого будет достаточно?
У меня буквально недавно был вопрос от человека, который этим занимается.Почему у меня отгрузилось по другому курсу?Ответить не смог. Предложил сделать сторнирование и перепровести отгрузку.

[Logger]

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

[Pustik]

Цитата:

Сообщение от Logger

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

На вскидку, в общих словах, что-бы вы посоветовали?

[Logger]

Здесь на форуме выкладывалась утилита при помощи которой можно было рассылать сообщения пользователям из формы активных пользователей, сбрасывать auc файлы и делать много других полезных вещей. Можно было бы её движок приспособить для сброса кешей.

[Pustik]

Эта утилита уже скачена и работает у нас (еще раз спасибо автору за нее).Спасибо EVGL и Logger за полезную информацию. Все остальное дело техники.

[raz]

А что делать с пакетниками, кторые разносят документы? Они вроде как не пользователи. Такую мину подложили.

[Logger]

Цитата:

Сообщение от raz

А что делать с пакетниками, кторые разносят документы? Они вроде как не пользователи. Такую мину подложили.

Ага. Это точно. Чтобы все правильно было - надо наверно от такого кеширования отказываться и предоставлять его ядру, то есть вернуться к стандартному кешированию таблиц.

Только в ядре на RU7 у нас аосы не всегда своевременно кеши синхронизируют. Похоже там тоже не все гладко.

[Wamr]

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

[CDR]

На самом деле курсы не так страшны, как их малюют.

На Х++ кешируются загруженные курсы для определенной даты. Соответственно если в компании не увлекаются постоянным редактированием уже загруженных курсов, все работает стабильно. При загрузке курса на новую дату, он автоматом добавляется в кеш при разноске первой валютной операции на эту дату.

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

Алгоритм был приблизительно такой:
Если транзакции нет - кеширование не работает. Если транзакция есть - выбирается запись из кеша. Если кеша нет, чтение из базы и сохранение в кеш. Если кеш есть - свяряются идентификаторы текущей транзакции и записи в кеше. Если совпадают - используется закешированный курс. Если не совпадают - кеш обновляется и сохраняется с идентификатором текущей транзакции. На производительность системы при разноске документов доработка практически не повлияла. И глюки с кешем пропали.