Scala

[komar]

Цитата:

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

komar, если есть время и не жалко, то есть такой вопрос в рамках темы.

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

Боюсь, времени таки жалко - хорошо, если успею функциональность в обших чертах сравнить. Кроме того, баги - это больше специализация отделов поддержки и разработки.
Что касается того, как они ищутся - все как раз очень понятно - если есть функция, она не работает - вот и баг. Какой же еще способ???

[mazzy]

Цитата:

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

Что касается того, как они ищутся - все как раз очень понятно - если есть функция, она не работает - вот и баг.

А если функция работает, но не так, как ожидает заказчик?

Например, с точки зрения Скалы, является ли это багом?
Существуют ли недостатки у Axapta

[komar]

Цитата:

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

А если функция работает, но не так, как ожидает заказчик?

Например, с точки зрения Скалы, является ли это багом?
Существуют ли недостатки у Axapta

ссылка была на закрытие склада? С точки зрения Скала корректная стоимость на 41 счете расчитывается в момент проводки. То есть проводку сделали, и вот уже оно ФИФО, ЛИФО, Средняя (причем нормальная средняя, а не полученная странным итерационным алгоритмом Акзапты) - расчитана. Процедуры же аналогичные пересчету используются только в случае, если необходимо исправлять данные (т.е. наколбашение проводок задним числом как стиль работы) - процедурка есть, но скорее ее использование является при нормальной работе склада редко возникающей необходимостью.
Аналогично устроены (если ошибаюсь, пусть меня поправят) и некоторые другие системы - например, Baan, да вроде и тот же 1С.

Так что приведенная ситуация в Скале не возникает, равно как и растущие из нее конфликты.

[mazzy]

Цитата:

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

С точки зрения Скала корректная стоимость на 41 счете расчитывается в момент проводки. То есть проводку сделали, и вот уже оно ФИФО, ЛИФО, Средняя (причем нормальная средняя, а не полученная странным итерационным алгоритмом Акзапты) - расчитана. Процедуры же аналогичные пересчету используются только в случае, если необходимо исправлять данные (т.е. наколбашение проводок задним числом как стиль работы) - процедурка есть, но скорее ее использование является при нормальной работе склада редко возникающей необходимостью.
Аналогично устроены (если ошибаюсь, пусть меня поправят) и некоторые другие системы - например, Baan, да вроде и тот же 1С.

Так что приведенная ситуация в Скале не возникает, равно как и растущие из нее конфликты.

?!?!?!


А какже, накладные расходы, сходящие в себестоимость, которые могут появиться гораздо позже?
А какже, неотфактурованные товары? Товары, которые физически оприходованы, но их себестоимость мы еще не знаем, поскольку докУментов на них нет... Но продвать/использовать их уже надо... Разве такого нет?

Про 1С я знаю - там нет такого понятия - неотфактурованные товары. Там накладные расходы могут вводиться только в том же приходном документе... А если накладной расход появляется позже, то уже проведенный документ правится и перепроводится. А затем перепроводятся все расходы, чтобы исправить себестоимость (в 1С это штатный механизм такой)

А как же Скала?
Что происходит с накладными, неотфактурованными товарами, калькуляцией фактической себестоимости в производстве (если отклонения от плана зафиксированы ПОСЛЕ того, как выполнена физическая приемка готовой продукции)?

[twilight]

Цитата:

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

ссылка была на закрытие склада? С точки зрения Скала корректная стоимость на 41 счете расчитывается в момент проводки. То есть проводку сделали, и вот уже оно ФИФО, ЛИФО, Средняя (причем нормальная средняя, а не полученная странным итерационным алгоритмом Акзапты) - расчитана. Процедуры же аналогичные пересчету используются только в случае, если необходимо исправлять данные (т.е. наколбашение проводок задним числом как стиль работы) - процедурка есть, но скорее ее использование является при нормальной работе склада редко возникающей необходимостью.
Аналогично устроены (если ошибаюсь, пусть меня поправят) и некоторые другие системы - например, Baan, да вроде и тот же 1С.

Так что приведенная ситуация в Скале не возникает, равно как и растущие из нее конфликты.

Насколько я выяснил, 1C в смысле пересчета себестоимости сделан продвинутее Аксапты, так как там пересчитывается себестоимость только в тех документах, на которые влияет изменение ранее сделанного прихода.

[mazzy]

Цитата:

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

Насколько я выяснил, 1C в смысле пересчета себестоимости сделан продвинутее Аксапты, так как там пересчитывается себестоимость только в тех документах, на которые влияет изменение ранее сделанного прихода.

Давайте в отдельной ветке...
С удовольствием поучаствую в обсуждении.