Слов нет

[Falcon]

Вы знаете, уважаемый г-н Егоров, иногда полезно оказаться "вдали от Родины", дабы понять, как оно на самом деле должно быть. В частности, вы не поверите - приходят и говорят. И Форду и ДжиЭму, и Крайслеру. И форды эти, нет чтоб нахамить своим клиентам - напротив, пытаются выяснить, что же все-таки людям в них не нравится. И называется это умным английским словом Customer Service - не подскажете перевод на русский? Или, быть может, его и нет, за ненадобностью-то?

Вы все же не ответили на мой вопрос: не считаете ли Вы, что разработчик не имеет права на отмазки типа "нам никто не предложил решения проблемы"? Не думаете ли Вы, что это Ваша, разработчиков, прямая обязанность - эти решения искать денно и нощно, дабы Ваши клиенты смогли наконец-то получить качественный продукт за свои немалые деньги?

Очень буду признателен, если ответы Ваши на этот раз будут по существу, без обсуждения моей личности, настроения, здоровья и прочих вещей, не относящихся к делу.

С уважением,

Дмитрий Перепелов.

[vleg]

Цитата:

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

Вы знаете, уважаемый г-н Егоров, иногда полезно оказаться "вдали от Родины", дабы понять, как оно на самом деле должно быть. В частности, вы не поверите - приходят и говорят. И Форду и ДжиЭму, и Крайслеру. И форды эти, нет чтоб нахамить своим клиентам - напротив, пытаются выяснить, что же все-таки людям в них не нравится. И называется это умным английским словом Customer Service - не подскажете перевод на русский? Или, быть может, его и нет, за ненадобностью-то?

Вы все же не ответили на мой вопрос: не считаете ли Вы, что разработчик не имеет права на отмазки типа "нам никто не предложил решения проблемы"? Не думаете ли Вы, что это Ваша, разработчиков, прямая обязанность - эти решения искать денно и нощно, дабы Ваши клиенты смогли наконец-то получить качественный продукт за свои немалые деньги?

Очень буду признателен, если ответы Ваши на этот раз будут по существу, без обсуждения моей личности, настроения, здоровья и прочих вещей, не относящихся к делу.

С уважением,

Дмитрий Перепелов.

Уважаемый Дмитрий!

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

Что касается существа - могу вам много и подробно отвечать и про Customer Service, и про обязанности разработчиков, и про взаимодействие Customer Service и этих самых разработчиков. Как на ассоциативном уровне, так и на конкретных примерах из своей практики. Однако понимаю, что не хочу. Ваш тон не распологает, извините. Вы здесь не ищите ни правды, ни информации. А эмоциями плескаетесь. Так что в другой раз.

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

[vleg]

Цитата:

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

2 vleg, если Вам интересна тема налогового учета:

1. Не пользовался НУ в аксапте
2. Исходя из практики: заранее уверен что ничего хорошего из этого не получилось бы, извиняйте уж ))

А теперь бонус:

Если интересно, почитайте описание того как реализован налоговый учет в программе "Инфо-предприятие". По мнению всех бухгалтеров которые работали с НУ в ИП и других системах - это бест-оф-зе-бест реализация.
http://www.real-soft.ru/cgi-bin/h.pl?ipb_nure#skp

Демку можно скачать с моего сайта. Если заинтересует - готов ответить на вопросы.

ЗЫ: появилась правда позже аксапты, в 1 квартале 2002 года. Но потом за пару часов - регистры были сформированы автоматизировано.

Спасибо за ссылку. Выглядит вполне вменяемо.

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

По-моему, в подобной идеологии реализованы лишь расходы будущих периодов и какая-то часть ПБУ-18, но здесь могу ошибаться.

[Тимур]

Цитата:

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

А сами-то как считаете ? Для сведения, методические инструкции МНС на тот момент предусматривали порядка 50-55 регистров в системе, которыми должна была подкрепляться декларация по налогу на прибыль. Почему именно эти 3-4 десятка? Потому что их можно было заполнить автоматически данными из других операций в системе. Почему не другие? Потому что автоматический сбор некоторых экзотические регистров был невозможен - неоткуда было собирать информацию. И для выхода из такой ситуации была предусмотрена возможность ручного ввода недостающих регистров.

Для сведения: на начало первого квартала 2002 г. инструкции МНС с регистрами еще в природе не существовало. Она была опубликована в феврале. К тому же необходимость тех или иных регистров - это суть волеизъявление конкретного предприятия. Регистры имеет смысл вести только в случае, если конкретные доходы/расходы нельзя собрать по данным бухгалтерского учета.

[Pavel]

Цитата:

Сообщение от Тимур

Для сведения: на начало первого квартала 2002 г. инструкции МНС с регистрами еще в природе не существовало. Она была опубликована в феврале. К тому же необходимость тех или иных регистров - это суть волеизъявление конкретного предприятия. Регистры имеет смысл вести только в случае, если конкретные доходы/расходы нельзя собрать по данным бухгалтерского учета.

Налоговая отчетность может быть сформирована через существующий в системе генератор финансовых отчетов (отчеты, строки, маппинг на счета, расхождение - ручными проводками на забаланс). И не требуется наворот с регистрами. Хотя, для маркетинга - это галочка.

[komar]

vleg, извините, но модули для демонстрации выбраны явно неудачно. Все эти примочки без переписывания практически нигде не работали. Причины -

- крайне низкая производительность (что регистры, что основные средства, что зарплата)
- корявая архитектура и отсутствие некоторой функциональности (реализовывать полноценный учет капвложений, наложенный на суммовые разницы, на еще и с учетом налогового учета, да еще и с учетом ПБУ-18, да еще и с учетом всех новшеств по НДС - это была радость! Крайне обрадовало то, что структура БД настолько хороша, что это даже и переписывать-то по-человечески нельзя. Модуль зарплаты - настолько хорош, что некоторые партнеры до сих пор предпочитают приделывать зарплату из российских систем - интерфейс реализовать проще, чем ползать с отладчиком по Вашим наворотам (вот, кстати, одно из полнофункциональных решений http://www.fincomplex.spb.ru/new/pro...rusfincomplex/ ). А налоговые регистры - как уже верно говорилось, крайне негибкое решение.)

[vleg]

Цитата:

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

vleg, извините, но модули для демонстрации выбраны явно неудачно. Все эти примочки без переписывания практически нигде не работали. Причины -

- крайне низкая производительность (что регистры, что основные средства, что зарплата)
- корявая архитектура и отсутствие некоторой функциональности (реализовывать полноценный учет капвложений, наложенный на суммовые разницы, на еще и с учетом налогового учета, да еще и с учетом ПБУ-18, да еще и с учетом всех новшеств по НДС - это была радость! Крайне обрадовало то, что структура БД настолько хороша, что это даже и переписывать-то по-человечески нельзя. Модуль зарплаты - настолько хорош, что некоторые партнеры до сих пор предпочитают приделывать зарплату из российских систем - интерфейс реализовать проще, чем ползать с отладчиком по Вашим наворотам (вот, кстати, одно из полнофункциональных решений http://www.fincomplex.spb.ru/new/pro...rusfincomplex/ ). А налоговые регистры - как уже верно говорилось, крайне негибкое решение.)

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

[Falcon]

Цитата:

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

Так, ну мы уже дошли до обвинений тех, кто пытается довести Аксапту до ума - в корысти И впрямь, какие, с позволения сказать, козлы: не хотят платить деньги Майкрософту и Коламбусунеизвестно за что, а хотят получить то, что реально работает, пусть даже потратив на это свои ресурсы. Ох, неспроста это они, ох неспроста...

Забавно рассуждаете, г-н Егоров - продолжайте пожалуйста.

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

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

[vleg]

Цитата:

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

Так, ну мы уже дошли до обвинений тех, кто пытается довести Аксапту до ума - в корысти И впрямь, какие, с позволения сказать, козлы: не хотят платить деньги Майкрософту и Коламбусунеизвестно за что, а хотят получить то, что реально работает, пусть даже потратив на это свои ресурсы. Ох, неспроста это они, ох неспроста...

Забавно рассуждаете, г-н Егоров - продолжайте пожалуйста.

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

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

Мой предыдущий комментарий не об обвинениях в корысти. Фантазируете.

[Insane]

Цитата:

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

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

Хммм, vleg, касательно штатной функциональности, может быть вы расскажете нам, неграмотным, как решить следующие вопросы штатными средствами:
1. Рассчитать амортизацию по ОС (три модели учета, тысяч 40 ОС). Мне кажется когда вы попробуете сформировать этот волшебный журнальчик - вопрос о быстродейтсвии модуля больше у вас возникать не будет.
2. Суммовые разницы, да с дооценкой склада, да с нюансами по НДС. Что то опять не очень верится.
и список этот можно продолжать и продолжать... И мне кажется что партнеры переписывают АХАРТА не от неграмотности, а от того, что иначе ее не внедрить...

[mazzy]

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

Например, вопрос про тысяч 40 ОС... Я конечно не утверждаю, что этот вопрос от безграмотности... Но зачем вы заталкиваете в один журнал столько ОС? Вы сейчас скажете, что это требование клиента и т.п... Вы не пробовали сделать несколько журналов с различными пресетами?

В какой-то момент все чаще вспоминаю анекдот:
Русские мужики купили японскую бензопилу. Решили ее испробовать.
Подсунули ей доску.
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули ей бревно.
- Вжик, - сказала японская бензопила
- О! - сказали русские мужики.
Подсунули ей железный лом.
- Кряк, - сказала японская бензопила
- Э-э-э! - махнули рукой русские мужики.

[mazzy]

кстати, приведенный анекдот, не повод для Майкрософта не работать по повышению производительности.

Еще кстати, vleg читает форум.
Поэтому не стоит раздувать оффтопиком любую тему, где он появляется.
Открывайте темы в соответствующих разделах.
Если считаете нужным, напишите ему письмо в личку, чтобы он обратил внимание на ваш вопрос.

Пожалуйста, вернемся к теме этой ветки.

[vleg]

Цитата:

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

Хммм, vleg, касательно штатной функциональности, может быть вы расскажете нам, неграмотным, как решить следующие вопросы штатными средствами:
1. Рассчитать амортизацию по ОС (три модели учета, тысяч 40 ОС). Мне кажется когда вы попробуете сформировать этот волшебный журнальчик - вопрос о быстродейтсвии модуля больше у вас возникать не будет.
2. Суммовые разницы, да с дооценкой склада, да с нюансами по НДС. Что то опять не очень верится.
и список этот можно продолжать и продолжать... И мне кажется что партнеры переписывают АХАРТА не от неграмотности, а от того, что иначе ее не внедрить...

Ничего личного, Insane

Как минимум первый случай (40 тыс ОС, 120 тыс операций амортизации) - не самый типичный.

Тем не менее, такая проблема изучалась пару-тройку лет назад. Проблема заключалась не столько в формировании журнала, сколько в его разноске в Главную Книгу. Модуль ОС тут не причем - для того, чтобы убедиться, достаточно сгенерить такой же по объему журнал ГК и попытаться разнести его. Core development признал ошибку работы с памятью в ядре. С тех пор, по-моему, была исправлена как ошибка ядра, так и сделана возможность формировать \ разносить амортизацию через набор журналов. Деталей уже не помню. Если обратитесь в техподдержку (можете это сделать через партнера), там вам расскажут, что надо делать.

Конечно, для авторитету полезнее все самому сделать. .

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

[ALEG]

Проблема разноски больших журналов ГК была и служба поддержки предоставляла обходной путь. Насколько я знаю в последних SP эта проблема больше не появляется. Если есть конкертные вопросы, но нет возможности через партнера занести вопрос в сервисную службу, то можно задать вопрос в соответствующем разделе на этом форуме или в новостной группе
RU
http://www.microsoft.com/communities...&lang=ru&cr=RU
EN
http://www.microsoft.com/communities...&lang=en&cr=US

[komar]

Цитата:

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

Ничего личного, Insane

Как минимум первый случай (40 тыс ОС, 120 тыс операций амортизации) - не самый типичный.

Тем не менее, такая проблема изучалась пару-тройку лет назад. Проблема заключалась не столько в формировании журнала, сколько в его разноске в Главную Книгу. Модуль ОС тут не причем - для того, чтобы убедиться, достаточно сгенерить такой же по объему журнал ГК и попытаться разнести его. Core development признал ошибку работы с памятью в ядре. С тех пор, по-моему, была исправлена как ошибка ядра, так и сделана возможность формировать \ разносить амортизацию через набор журналов. Деталей уже не помню.

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

insane - а если еще и суммовые по ОС по-разному учитываются разными моделями учета, да еще и по ним НДС должен предъявляться в тот же момент, что и НДС по самому ОС, да еще и этот самый НДС может списываться за счет разных источников, и тянуть всю эту информацию приходится с момента закупки ОС, а закупка производится через модуль склада, что вообще отдельная радость....и это еще только начало формирования снежкного кома, который в конечном итоге докатывается до налоговых регистров, а ОС попутно переоцениваются, разбираются, ремонтируются, дооцениваются.... Что делать, в "65 примеров" все на свете не впихнешь, а сертификат получать надо!

vleg, ругаться будем? конечно, знакомые мне кейсы именно такие! Зато какие про эти кейсы на Вашем сайте висят прессрелизы.......

[ppson]

Не по тому делу на MBS наехали :-)
если вспомнить то время (рубеж 2001-2002), то собственно говоря никто и не знал сколько/какие/и в каком виде регистры должны быть. Методологии не было.
Поэтому и выпущенный продукт на то время в принципе более менее сносным.
Только с тех пор прошло 4 года, уже есть практики применения регистров (например см. постинг Тимура Слов нет ).
Только вот непонятно будет ли MBS развивать регистры или они так остануться еще одним способом вывода на экран данных из таблиц .

[mazzy]

Цитата:

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

Только вот непонятно будет ли MBS развивать регистры или...

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

В международной Аксапте можно создавать обычные финансовые проводки с признаком Налоги по счетам из того же плана счетов. (Хотелось бы заметить, что для налоговых проводок можно создать и забалансовые счета) А затем в обычных финансовых отчетах получать итоги с учетом налоговых проводок, без учета налоговых проводок, только налоговые проводки и т.п...

Но к сожалению, буржуйские налоговые проводки не работали совместно с корреспонденцией (конечно, надо бы проверить последние сервис-паки, но верится в чудо с трудом).

АНГЛИЧАНЕ РУЖЬЯ КИРПИЧОМ НЕ ЧИСТЮТ!

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

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

Что-то мы совсем от темы отклонились...

[ppson]

Цитата:

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

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

Не сделают как минимум по двум причинам:
1) Кто разрешить выкинуть инвестиции в мусорный бачок ?
2) Необходимо признать что получивший орден модуль оказался со времением невостребованным. Надо будет возвращать медаль (((.

[mazzy]

Ну почему же логика ИЛИ-ИЛИ?
Зачем выкидывать?

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

Скажу больше - в международной Аксапте есть книга покупок и книга продаж. Международные tax reporting надо чуть доработать, чтобы они выгядели как наши книги покупок и продаж. Но и эти отчеты загублены локализацией. Есть автоматический зачет 19-68... Тот же кассовый модуль, те же инструменты трансляции и консолидации... И так далее.

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

Конечно, в идеале хотелось бы получить работающую И международную, И российскую функциональность.

[mazzy]

Цитата:

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

2) Необходимо признать что получивший орден модуль оказался со времением невостребованным. Надо будет возвращать медаль (((.

Опять какая-то логика ИЛИ-ИЛИ.
Медаль была получена не за востребованность, а за программирование, насколько я помню. Программирование в этом модуле действительно амбициозное. Зачем же медаль возвращать?

См. скриншот медали Вложение 1895