Трансляция и двухвалютный склад

[EVGL]

Цитата:

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

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

Ага. Поэтому в таких случаях ты пытаешься дискредитировать автора.

[mazzy]

Брэк-брэк.

EVGL, пожалуйста, не надо начинать по новой.
Не надо цепляться к людям... Они такие, какие есть.

Пожалуйста.
Не вынуждай твои то сообщения резать...

===========
EVGL, скажи пожалуйста. На твой звгляд, зачем люди ходят на этот форум?

[Pavel]

Цитата:

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

Ага. Поэтому в таких случаях ты пытаешься дискредитировать автора.

Зачем мне это? Двувалютный склад (себестоимость запасов во второй валюте) и трансляция в аксапте от этого правильно не заработают, и тот факт, что функции были запрограммированы людьми в теме не сведущими, уже не изменить.

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

[EVGL]

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

Что касается трансляции, то в ней (без учета проблем с двухвалютным складом) за три года было найдено, кажется, только две или всего одна ошибка (что-то с ваучерами). Я следил за этим, даже уволившись из Microsoft, поскольку мне важно знать, как работает то, что я сделал. Если же люди не могут настроить функционал - не моя проблема.

Что касается корреспонденции, которую так любили обсуждать "на заре" Аксапты, то эта тема ушла из разговоров примерно три года назад. Когда я переделал "с нуля" всю систему корреспонденции. Мне не известно более ни одной ошибки, которую кто-нибудь нашел за это время в ядре корреспонденции. Впрочем, насколько я знаю, есть нарекания на объем памяти, который потребляет эта функция. Что да - то да.

Справедливости ради, да, мне стыдно за OfficialsTrans_RU. Надо только учитывать, что это была моя самая первая модификация в системе, сдаланная пять лет назад. Хотел бы я посмотреть на ваши.

[Pavel]

Цитата:

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

Что касается корреспонденции, которую так любили обсуждать "на заре" Аксапты, то эта тема ушла из разговоров примерно три года назад. Когда я переделал "с нуля" всю систему корреспонденции. Мне не известно более ни одной ошибки, которую кто-нибудь нашел за это время в ядре корреспонденции.

Смотри корреспонденцию проводок по распределениям. Полная ерунда.

[EVGL]

Цитата:

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

Смотри корреспонденцию проводок по распределениям. Полная...

Ну, значит есть. Может быть. Я могу следить за тем, что происходит, только по fixlist'ам из очередных сервис-паков.
Сорри за оффтоп. По-моему, эта переписка хорошо смотрелась бы в теме "российская функциональность".

[mazzy]

Выделено отсюда
Зачем ходят люди на этот форум?

[Pavel]

Цитата:

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

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

Стоило то «огород городить»?

В XALе 3.1&3.5 не использовалась функциональность двувалютного склада из версии 2.8. Применено элементарное решение:
- добавлены поля для себестоимости во второй валюте (в карточке фирмы, складских операциях, складских запасах, отчетности)
- заполнение выполняется автоматически, пересчетом из основной валюты баланса (т.е. по той же методике ФИФО, ЛИФО, средняя, фактическая)
- для пересчета по разным методикам в разных валютах предлагается «повторный пересчет в копии базы/компании»
Так и в правильности расчета себестоимости сомнений не возникает, и производительность системы не снижается.

[komar]

Цитата:

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

.....Программировал KURA......

Кто-то помянул страшное заклинание, которым были подписаны многие и многие баги. Не к добру это.....

[komar]

Цитата:

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

Что касается трансляции, то в ней (без учета проблем с двухвалютным складом) за три года было найдено, кажется, только две или всего одна ошибка (что-то с ваучерами). Я следил за этим, даже уволившись из Microsoft, поскольку мне важно знать, как работает то, что я сделал. Если же люди не могут настроить функционал - не моя проблема..

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

Цитата:

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

Справедливости ради, да, мне стыдно за OfficialsTrans_RU. Надо только учитывать, что это была моя самая первая модификация в системе, сдаланная пять лет назад. Хотел бы я посмотреть на ваши.

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

Извините, что ввязался в Ваш междусобойчик.

[EVGL]

Цитата:

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

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

На реальном проекте - не пробовал. Позволю себе все же усомниться, что Вы использовали все возможности инструмента. Если план счетов состоит из N сотен штук, это не означает, что вы должны настроить Nx100 комбинаций. Можно использовать шаблоны как в фильтрах (типа 40*, 62*). Из-за этого и тормозит, но только это и позволяет повторно использовать настройки для разных предприятий. Ну да вам виднее; так или иначе, я не уверен, что Вы когда-либо формулировали конкрентые предложения по развитию функции и отсылали их куда следует. От того, что вы будете абстрактно называть нечто "хламом" на неофициальном форуме, оно "конфеткой" не станет.

Что касается "чертзнаетскольких" аналитик, то Вы, наверное, это не всерьез упомянули. Нетрудно видеть, что настройки для трансляции аналитики максимально лаконичны: в идеальном случае, когда коды аналитики в компаниях совпадают, Вам нужно указать лишь три строки (по количеству аналитик) в соответствующей группе.

[EVGL]

---[самоцензура]---

Чтобы всуе не порочить гордое имя KURA: техническое задание было мое; на версию 3.0 двухвалютный склад поднимали все, кому не лень. Развивали его все, кому не лень, так что концов уже не найдешь и перекладывать ответственность на одного человека было бы несправедливо.

[EVGL]

Цитата:

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

Стоило то «огород городить»?

В XALе 3.1&3.5 не использовалась функциональность двувалютного склада из версии 2.8. Применено элементарное решение:
- добавлены поля для себестоимости во второй валюте (в карточке фирмы, складских операциях, складских запасах, отчетности)
- заполнение выполняется автоматически, пересчетом из основной валюты баланса (т.е. по той же методике ФИФО, ЛИФО, средняя, фактическая)
- для пересчета по разным методикам в разных валютах предлагается «повторный пересчет в копии базы/компании»
Так и в правильности расчета себестоимости сомнений не возникает, и производительность системы не снижается.

Хорошая идея. С учетом того, что закрытие по средней в Аксапта все равно генерит x*y проводок InventSettlement, которые связывают каждый расход с каждым приходом (как бы это не проклинали , у идеи есть право на жизнь. Но только в то случае, если методики совпадают. А если для бухгалтерского учета используют модель "средняя", а для управленческого - "ФИФО"?

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

[Pavel]

Цитата:

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

А если для бухгалтерского учета используют модель "средняя", а для управленческого - "ФИФО"?

Делаешь копию компании (в XALе копия базы), запускаешь пересчет себестоимости по ФИФО. Система как в основной так и во вторичной валюте дает стоимость запасов по ФИФО. Далее из основной компании данные применяются к бух.отчетности, а из "резервной копии" к управленческой. Дешево и сердито.

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

[EVGL]

Оба подхода имеют право на существование, но на практике вряд ли подойдут. Оба требуют того, чтобы старые "закрытия склада" были отменены до начала времен, а затем построены заново. На хорошем предприятии через пару лет это породит десятки миллионов транзакций InventSettlement/ InventTransPosting, притом Аксапта будет трахать жесткий диск неделями напролет.

Ладно, посмотрим, какие меры будут принимать Ex-Kollegen. Мне стало ясно одно: примитивная функция, которая работает на 100% корректно, для клиента все равно лучше изощренной, но работающей на 98%. Хотя тут начинают поднимать вой "сейлзы".

[Pavel]

Цитата:

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

Оба подхода имеют право на существование, но на практике вряд ли подойдут.

Это о чем? Функция в XALе и существует и работает на практике.

Цитата:

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

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

В учете "начало времен" - это отчетный период (год).

Цитата:

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

На хорошем предприятии через пару лет это породит десятки миллионов транзакций InventSettlement/ InventTransPosting, притом Аксапта будет трахать жесткий диск неделями напролет.

Проблема структуры данных аксапты и только.

Цитата:

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

Мне стало ясно одно: примитивная функция, которая работает на 100% корректно, для клиента все равно лучше изощренной, но работающей на 98%.

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

Цитата:

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

Хотя тут начинают поднимать вой "сейлзы".

Не надо все смешивать в одну кучу. Разработчик пусть делает исправно работающие функции, консультант объясняет клиенту как ими грамотно пользоваться, а сейл продает продукт труда как первого так и второго.

[komar]

Цитата:

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

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

Извините, что еще раз встреваю в разборки. Просто хотел проинформировать, что по данной функции, действительно, куда следует ничего не отсылал. Зато случалось отсылать по другим функциям. В ответ меня тоже отсылали куда следует или включали фичу в план разработки, который не выполнялся. Вследствие этого к отсыланию вкус потерял, и где-то с 2003 года в составлении каких-либо официальных предложений не участвовал. Видимо, в целесообразность затеи перестали верить и другие, а затем и сам МБС, так как примерно с 2003 года одиозные планы развития локальной функциональности плавно отплыли в небытие.
В результате некая упрощенная трансляция под конкретный проект писалась вместо попыток взывать к совести функционеров МС.

[komar]

Цитата:

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

Мне стало ясно одно: примитивная функция, которая работает на 100% корректно, для клиента все равно лучше изощренной, но работающей на 98%. Хотя тут начинают поднимать вой "сейлзы".

Вашими бы словами да планы локализации писать!

[EVGL]

Цитата:

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

В учете "начало времен" - это отчетный период (год).
Проблема структуры данных аксапты и только.

Да, но счета складских запасов в новом учетном году не обнуляют, склад не вычищают, и из старых запасов продавать не запрещают. Тем самым, если сначала закрывали по одной модели, а потом - по другой, в каждый отдельно взятый момент результат расчета будет неверным. А работаем мы с данными той системы, с которой работаем. С Dynamix AX. И структура данных уж такая, какая есть. Поэтому когда объем данных достигнет определенной величины, ваш подход становится практически неиспользуемым. Поэтому я провел бы голосование среди клиентов: нужно ли им закрытие по разным моделям? И если большинство скажет "нет" - децимировал бы функционал.

[EVGL]

Черт, название темы выбрал mazzy какое-то одиозное... Нет бы: "двухвалютный склад и профпригодность".