Правильная локализация. Какой она должна быть?

[rov_imported]

Цитата:

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

Бухгалтерия без переписывания не работает. Это неоспоримый факт. Нет ни ОДНОЙ базы в России без дописывания-переписывания. Может у вас есть примеры?

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

[romtex_imported]

Цитата:

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

Однако говоря неформально, у меня был проект в котором было переписано 4(четыре) строки в уч. функции и
подправлено (далеко не переписано!) 4-5 отчетов - это все, что было сделано в части доработки бухгалтерии.
При этом бухучет велся полностью в НАВ - и регламентная отчетность печаталась из НАВа сдавалась в нал. органы.
Так что с натяжкой - но без переписки функционала обойтись можно.

Готов поверить, если это:
1. Небольшая организация <15 юзеров
2. Не торгует товарами (Вероятнее всего торговля услугами)
3. Заработная плата и кадры не ведутся в Navision.
4. Старт Navision был вместе с бизнесом (БУ не велся в других программах, нет хотелок "как в 1С", подкрепленных ПБУ)
Да и то, мне кажется, все-таки 4 строки и 4-5 отчетов были переписаны для быстрого старта, а далее, вероятнее всего было сделано немало доработок.

[rov_imported]

1. Да, порядка 12 человек - юзеров.
2. Как раз этим она и занимается - оптовая торговля товарами с удаленным складом
3. Само собой - при внедрении ЗиК без переписок 100%-но не обойтись.
4. Нет естественно - до этого фиг знает уже сколько работали.
Товародвижение было в 1С, бухгалтерия - в ИНФИН.
Много хотелок было - просто нам удалось настоять на своем.

4 строки - это всем известная проблема, когда при постановке на аванс терялся тип и номер источника, что
и было исправлено. 4-5 отчетов - менялась в основном графика - но это были основные отчеты для бухов.
Карточка счета, сводные проводки и пр.
В таком состоянии система проработала порядка 8 месяцев - начиная с go-live. Дальнейшей судьбы в силу
обстоятельств - не знаю.

[mazzy]

Цитата:

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

Да, это очень удачный пример - что оперативным данным верить нельзя (они не верны) и на их основании можно сделать ошибочные решения.

Ошибочные решения можно сделать на основании любых данных.
Мало того, 100% достоверных данных не бывает

Задача - предоставить вовремя информацию с достаточной достоверностью.

Цитата:

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

Вывод: объяснение отсутствия функции отмены, коррекции документов из-за того что на основании каких-то данных могли быть, которые могли быть использованы неверно, т.к. начальные данные неверны - и принимать по ним решения нельзя!

Как это нельзя, если решение об увольнении принято?
Если вы имеете в виду решения о закупках, выдаче кредитных лимитов, то не спорю - на основании ошибочных данных будут приняты ошибочные решения. Исправление исходных данных должно автоматически привести к тому, что зависимые тоже будут исправляться обычным образом.

Ок. завязываем или выделяйте в отдельную ветку.

Цитата:

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

Не надо считать всех идиотами (переписывает только тот - кто не думает). Бухгалтерия без переписывания не работает.
Это неоспоримый факт. Нет ни ОДНОЙ базы в России без дописывания-переписывания. Может у вас есть примеры?

А вот это интереснее.

Для КОГО предназначен Навижин?
Для бухгалтерии? или для управленцев?

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

бухглатерских баз без правки я не знаю.
управленческих без правки знаю очень много.

Об этом и был мой вопрос: правильная локализация ДЛЯ КОГО?

Цитата:

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

Да уж. С тем же успехом я могу утверждать что "Код Менеджера" это тоже договор.
У клиента 10 договоров, по каждому из них он вносит предоплату. В 3.X я в журнале оплат выбрал № договора и учел оплату и отлично вижу по какому договору была оплата. Как же мне в 4-ке с "заказом" такое сделать???

есть еще пункты, которые мешают вам воспринимать Заказ как договор?

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

Локализация должна быть локальной.

Цитата:

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

Заказ - это предварительный заказ товара (услуг), необходимый для отслеживания отгрузок. По одному договору в 3.х может быть несколько заказов

Договор - это предварительная договоренность о условиях поставки товара (услуг).
Используется для отслеживания отгрузок и оплат.

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

Не правда ли, подходит с точностью то терминологии?
Единственное отличие - в стандартном функционале заказы нельзя указать в предоплатах.

Цитата:

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

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

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

Цитата:

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

Очень станнное высказывание. Договор это юридический документ на поставку чего-то на определенных условиях. И никто никогда не писал, что это ЕДИНОРАЗОВАЯ операция.

Да.

[Corleone]

Цитата:

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

Для КОГО предназначен Навижин?
Для бухгалтерии? или для управленцев?

Об этом и был мой вопрос: правильная локализация ДЛЯ КОГО?

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

[mazzy]

Цитата:

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

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

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

Цитата:

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

А если он не нужен, зачем тогда майкрософт его анонсирует а продает откровенное г? В таком виде как он есть, он не нужен.

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

Если хочется, то открывайте новую ветку.


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

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

Какие группы пользователей есть еще?

[Corleone]

Цитата:

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

Если встречается некая фича, которая должна совершенно по-разному реализовываться для разных групп, то какая группа является приоритетной?

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

[mazzy]

Цитата:

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

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

Для начала стоит составить список таких вещей, не так ли?

[RedFox]

Цитата:

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

Задача - предоставить вовремя информацию с достаточной достоверностью.
...
Для КОГО предназначен Навижин?
Для бухгалтерии? или для управленцев?

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

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

Изначально нужно определиться не под кого мы будем классифицировать, а для кого. А уж после этого сразу второе либо отмести, либо последовательно добавлять!

Цитата:

бухглатерских баз без правки я не знаю.
управленческих без правки знаю очень много.
Об этом и был мой вопрос: правильная локализация ДЛЯ КОГО?

Ну тут я даже писать ничего не буду, чтобы не раздувать обсуждение.. {просто устал писать}
Нужно понимать, что это не аналитическая система с прогнозированием!!!Которая, кстати, нужна больше для управленцев, чем для бухгалтеров. Здесь нет нормального тредрового анализа, стуктурного и т.д.
Поэтому по всем обычным признакам она больше смахивает все-таки на бухгалерскую.

Цитата:

есть еще пункты, которые мешают вам воспринимать Заказ как договор?

А зачем?? Есть одно понятие и есть другое? Зачем их пытаться "заменить"?

Цитата:

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

Вы же профи, подскажите!!! Если человек не знает как решить правильно, то он начинает городить такое ... {сами знаете продолжение}

Цитата:

Локализация должна быть локальной.
Договор - это предварительная договоренность о условиях поставки товара (услуг).
Используется для отслеживания отгрузок и оплат.

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

Не правда ли, подходит с точностью то терминологии?

Ну как Вам сказать, вообще-то тут многого чего не хватает {если по терминологии}. Например, где условия поставки, дотсавки, оплаты {список приведен в качестве примера}?

Цитата:

Единственное отличие - в стандартном функционале заказы нельзя указать в предоплатах.

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

Цитата:

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

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

[RedFox]

Цитата:

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

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

Хотелки и требования - это РАЗНЫЕ ВЕЩИ (Я вижу, что в Вашей работе больше преобладали "бухгалтеры-хотелки" с точнымы 1С-требованиями - только без обид)!!

Цитата:

Какие группы пользователей есть еще?

Самая главная группа - пользователи-managers, которые делаю весь этот "сбор информации"!!
Но хорошо, что тут трудно написать их "хотелки"! Хотя CRM для них стоило бы, как мне кажется, подработать немного.

Цитата:

Для начала стоит составить список таких вещей, не так ли?

Мы определили для кого пишется система? Или мы условно принимаем, что система пишется под управленцев?
Но извините, но кроме себестоимости в NAV особо я ничего не вижу. Ну нету здесь аналитической части, ну нету!!!

[Corleone]

Цитата:

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

Для начала стоит составить список таких вещей, не так ли?

Ну так для этого тема и придумана, работаем над этим
Я правда так и не понял ваше мнение, нужен бухучет в навижене или нет.

[mazzy]

Цитата:

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

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

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

Я так, рассуждаю из общих предположений.

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

Тогда мы с вами попусту спорить не будем

Цитата:

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

Изначально нужно определиться не под кого мы будем классифицировать, а для кого. А уж после этого сразу второе либо отмести, либо последовательно добавлять!

Хорошо, "Для кого". Я об этом и писал вроде.

Цитата:

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

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

Можно попросить вас развить эту мысль поподробнее?

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

Почему это вы считаете, что Навижин только для финансистов?

Цитата:

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

А зачем?? Есть одно понятие и есть другое? Зачем их пытаться "заменить"?

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

Цитата:

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

Ну как Вам сказать, вообще-то тут многого чего не хватает {если по терминологии}. Например, где условия поставки, дотсавки, оплаты {список приведен в качестве примера}?

См. скриншоты
чего еще не хватает?

Еще раз: поймите одну мысль - заказ, это договор со строками (с спецификацией)

[attachment=728:1.gif] [attachment=729:2.gif]

Цитата:

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

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

Нет конечно.
Обычно предоплата делается по счету на оплату. А счет действительно делается по договору.

[RedFox]

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

[mazzy]

Цитата:

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

Когда человек хочет видеть только одно, то он это видит.

Эт-то точно.

[artkashin]

1. Если заказ- договор, то как получить из заказа оплаты по данному заказу-договору?
2. Если заказ - договор, то почему, после учета всех операций по заказу - он удаляется из заказов(настроек это отменяющее в Наве нет). Значит ли это что договор расторгнут? Как увидеть список всех(как рабочих так и завершенных) договоров - заказов из карточки клиента?
Почему тогда нет учтенных заказов?
Заказ - не есть договор. Заказ - есть механизм отслеживания отгрузок и выставления счетов на основании заключенного договора, и только до момента исполнения условий договора (всё отгружено и выставлено) в рамках товарных движений.

[romtex_imported]

Цитата:

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

Ошибочные решения можно сделать на основании любых данных.
Мало того, 100% достоверных данных не бывает

Ну во-первых нужно быть последовательным.

Цитата:

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

учтенные данные сразу же могут стать основанием для других документов.

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

Цитата:

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

А вот это интереснее.
Для КОГО предназначен Навижин?
Для бухгалтерии? или для управленцев?

Не надо приоритетов. Система должна отвечать собственным рекламным материалам или хотя бы стремится к этому.
Майкрософт утверждает, что БУ в навижене "полностью соответсвует.." Покупатели читают. Покупатели ведутся и покупают. Локализация должна соответствовать рекламе. Есть реклама по БУ, значет БУ должен быть реализован. Есть НУ в рекламе, значит НУ должен быть реализован. Если что-то не реализовано - должна быть оперативная реакция на это. Не может реализовать/поддерживать - не рекламируй, позиционируй как БД "для управленцев" и отрежь все лишнее.

Цитата:

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

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

Сразу добавить возможность - переписывать/дописывать. А как же "сначала думать"??
Ну а пунктов полно: читай пост Кашина, от себя добавлю еще, например, возможность посмотреть в 3.х оборотные ведомости (фин., клиент, поставщик) в разрезе договора/договоров, просто указав в поле "Договор Фильтр" необходимый договор.
Еще? Пожалуйста: есть договор на год, в течении которого каждую неделю у поставщика заказываем какие-либо товары. Как реализовать в 4.0??
Сразу уберегу от ответа открывать/дополнять/выпускать "общий заказ", т.к. договором, во вашему является именно заказ.
Может для всего этого тоже делать "локальную локализацию" или все-таки думать?

[Corleone]

Цитата:

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

Система должна отвечать собственным рекламным материалам или хотя бы стремится к этому.
Майкрософт утверждает, что БУ в навижене "полностью соответсвует.." Покупатели читают. Покупатели ведутся и покупают. Локализация должна соответствовать рекламе. Есть реклама по БУ, значет БУ должен быть реализован. Есть НУ в рекламе, значит НУ должен быть реализован. Если что-то не реализовано - должна быть оперативная реакция на это. Не может реализовать/поддерживать - не рекламируй, позиционируй как БД "для управленцев" и отрежь все лишнее.

Все это верно про то что МС это лохотрон, но как заставить их вырезать говномодули?

[romtex_imported]

Цитата:

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

1. Да, порядка 12 человек - юзеров.
2. Как раз этим она и занимается - оптовая торговля товарами с удаленным складом
3. Само собой - при внедрении ЗиК без переписок 100%-но не обойтись.
4. Нет естественно - до этого фиг знает уже сколько работали.
Товародвижение было в 1С, бухгалтерия - в ИНФИН.
Много хотелок было - просто нам удалось настоять на своем.

4 строки - это всем известная проблема, когда при постановке на аванс терялся тип и номер источника, что
и было исправлено. 4-5 отчетов - менялась в основном графика - но это были основные отчеты для бухов.
Карточка счета, сводные проводки и пр.
В таком состоянии система проработала порядка 8 месяцев - начиная с go-live. Дальнейшей судьбы в силу
обстоятельств - не знаю.

Завидую!! Честно, без иронии.
Лично у меня всегда по товарам всегда возникают большие проблемы с расходными документами. Во внутренних перемещениях в м-11 нулевая сумма никого не устраивает. В акте списания М-11 с одной суммой, после коррекций по финансам совсем другая. Интересно как относится бухгалтерию, что если был один акт списания в месяц и в нем стоит 100 руб, а по 41 счету в кредит попала 120 руб.
Сделали какой-нибудь реестр документов типа ТОРГ-29 распечатали, положили на полку. Запустили коррекцию - сумма совсем другая.
Так же мне непонятно как можно работать без элементарного отчета "Остатки товаров" с кол-вом и суммой. Можно конечно обороткой громоздкой заменить. Всегда проблем с прибылью в стандарном отчете "Клиент/Товар Продажи", которая скачет после каждой коррекции. В общем большинство этих проблем из-за того, что себестоимость меняется задним числом. Ну и всем хочется М-1, Т-1, М-17, М-19, Торг-29, Торг-12 и т.п. и т.д.
Может поделитесь опытом убеждения?

[mazzy]

Цитата:

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

1. Если заказ- договор, то как получить из заказа оплаты по данному заказу-договору?

В проклятой буржуинии (да и у нас тоже) оплаты не делаются по договору/заказу.
Оплаты делаются по счету на оплату по данному договору/заказу.

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

Но об этом уже говорили. Другие возражения есть?

Цитата:

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

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

Нет, не расторгнут, а выполнен.
Фактические документы по данному заказу остались.

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

Может быть таким образом.
Но повторюсь - вопрос "как получить" список договоров/заказов и для меня пока не очень понятен.

Возможно, долгосрочные договора все-таки лучше оформлять Общими заказами. И смотреть там учтенные строки.

Но непонимание опять же это не повод вводить новую сущность, а повод всего-лишь разобраться с существующим.

Цитата:

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

Почему тогда нет учтенных заказов?

Почему нет? В общих заказах.

Цитата:

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

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

Ок. Предположим. А что такое договор и чем он отличается от заказа?

[mazzy]

Цитата:

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

Ну во-первых нужно быть последовательным.

А я очень последователен.
решения можно и нужно принимать даже на основании не 100% достоверных данных

Цитата:

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

Во-вторых зачем принимать решения на заведомо неверных данных?

Во-первых, а почему заведомо неверных?
Во-вторых, а где взять другие данные?

У нас есть входные данные.
Мы верифицировали программу. Мы уверены, что преобразование входных в выходные делается правильно.
Но мы мало знаем о достоверности входящих данных.
Но даже в этих условиях мы должны принимать управленческие решения, желательно правильные.

Цитата:

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

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

Почему это точные данные получаются после?
До учета коррекция возможна, но и на итоги неучтенные данные не влияют.
До учета система проверяет/верифицирует данные на соответствие бизнес-правилам предприятия.

Цитата:

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

Кроме этого не нужно за пользователей решать, нужна ли им возможность корректировки или нет. Если не нужна, то они, даже при ее наличии, просто ей пользоваться не будут. Все закончили.

Нужно, romtex, нужно.
Будут, romtex, будут.

Цитата:

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

Не надо приоритетов. Система должна отвечать собственным рекламным материалам или хотя бы стремится к этому.

Если принять такой критерий, то решение простое - переписать маркетинговые материалы.

Я уже предложил другой критерий - специалисты и клиенты должны считать данную систему качественной.

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

Цитата:

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

Майкрософт утверждает, что БУ в навижене "полностью соответсвует.." Покупатели читают. Покупатели ведутся и покупают. Локализация должна соответствовать рекламе. Есть реклама по БУ, значет БУ должен быть реализован. Есть НУ в рекламе, значит НУ должен быть реализован. Если что-то не реализовано - должна быть оперативная реакция на это. Не может реализовать/поддерживать - не рекламируй, позиционируй как БД "для управленцев" и отрежь все лишнее.

А почему мы должны тратить свое время на то, чтобы показать как надо соответствовать ПБУ?
Это проблема майкрософта.

Я лично считаю, что система не должна полностью соответствовать ПБУ.
Я лично считаю, что система должна соответствовать сложившимся бизнес-практикам.

Например, в ПБУ сказано, что кассу надо закрывать день в день (в Аксапте в свое время даже запрет был на ввод кассовых операций нетекущей датой). Но по сложившиеся бизнес-практике, так практически никто не делает. Чему должна соответствовать система?

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

Цитата:

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

Сразу добавить возможность - переписывать/дописывать. А как же "сначала думать"??
Ну а пунктов полно: читай пост Кашина, от себя добавлю еще, например, возможность посмотреть в 3.х оборотные ведомости (фин., клиент, поставщик) в разрезе договора/договоров, просто указав в поле "Договор Фильтр" необходимый договор.

или заказ

Цитата:

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

Еще? Пожалуйста: есть договор на год, в течении которого каждую неделю у поставщика заказываем какие-либо товары. Как реализовать в 4.0??

Общие заказы

Цитата:

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

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

Почему именно?

Цитата:

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

Может для всего этого тоже делать "локальную локализацию" или все-таки думать?

Все-таки сначала думать.
И только потом трясти.