iscrafmm_a_r_i_n_a

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

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

1) А можно хоть один пример, когда что-то надо срочно "провести в бухгалтерии"? Я говорю именно о бухгалтерском учете, а не об оперативном.
Еще один момент, о котором часто забывают - в правильно внедренной системе первоначальный ввод новой позиции номенклатуры (после чего ее можно использовать в документах) занимает не более 10 минут и выполняется одним человеком. И нет никаких многодневных согласований между отделами. И правильно настроенная перегрузка между системами тоже занимает никак не больше 10 минут. Итого 20 минут - вполне приемлемое время.

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

Как и в большинстве случаев, все эти проблемы возникают из-за "высокой" квалификации сотрудников (как у внедренцев, так и у заказчиков).

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

ЛагманНехорошая денормализация, слишком экстенсивно. Потом появится колонка НазваниеДляСклада, НазваниеДляСтройОтряда и т.д.
А если например отдел продаж, по какой-то причине (например, кривая схема данных в области хранения остатков), захочет внести цель продаж в имя товара, (из жизни пример же), вроде "железка квадратная не крупная ПРОМО", то начнется вообще дублирование сущностей, или 2 группы верхнего уровня - "товары нормальные" и "товары отдела продаж", что по сути уж и есть те же 2 справочника, плюс неуправляемая копипаста и соответствие товаров, поддерживаемое "в уме".
Вы, как мне кажется, рассматриваете ситуацию в отрыве от реальности.
Что такое запасы? это огромная куча всяких фиговин.
а что такое справочник номенклатуры? это способ разделить эту огромную кучу на много маленьких кучек.
единственный более-менее обоснованный критерий детализации справочника, о котором слышал - взаимозаменяемость. то есть если на конкретном предприятии одна деталька прекрасно может использоваться вместо другой - это одна позиция номенклатуры (один Item_ID), если нет - разные. и если этот принцип соблюдать, то никаких проблем нет. можно создать для одного Item_ID кучу названий-синонимов, кучу иерархий и кучу признаков. можно также указать, как каждый из поставщиков этот товар называет. разумеется, не все имеет смысл делать в основной таблице справочника - в большинстве систем есть куча вспомогательных таблиц. а вот если используется самописка с кривой схемой данных и на справочник возлагают не его задачи - то будут проблемы. но проблемы будут не от количества названий-синонимов, а по причине кривых рук.

iscrafm__а если не "самописка", а система написанная инопланетянами, но тоже с кривой схемой данных, то проблем не будет?
будут проблемы!

а вы не ошиблись с адресатом? вроде бы этот вопрос Капитану Очевидность...

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

iscrafm__на крупных промпредприятиях есть службы АСУ, которым могут позавидовать и некоторые софтверные компании в плане проектировщиков, архитекторов, аналитиков и т.д.. Понятно, что в последние годы была тенденция на их размазывание, люди уходили, системы заменялись на неработающие ERP и т.д. А описанная вами проблема справедлива и к продуктам, выпускаемым софтверными компаниями: разрабатывается для узкого круга задач, чудовищная структура базы данных, неэффективный код и т.д. Т.е. из приведенных вами характеристик можно оставить разве что " продукт, который создается сотрудниками предприятия", без эпитетов, которые к тиражным ERP иногда подходят больше
я не спорю, что к тиражным иногда тоже подходит термин самописка
продукт, успешно внедренный в более чем 200-300 компаниях, скорее всего будет иметь меньше косяков, чем продукт, работающий на одном предприятии

iscrafm__ Так что количество внедрений не показатель. Показателем является то, какой ценой поддерживается хотя-бы одно внедрение и насколько эти "косяки косячные"
Тут уже зона очень субъективных суждений. Разумеется косяки могут быть (и есть) в любом продукте. Но если есть очень грубые ошибки в структуре БД и подобные вещи - внедрить на более менее разных предприятиях просто не получится.
я однажды наблюдал подобную самописку - сперва написали на делфи для учета остатков товаров, а потом в течении 7 лет добавляли возможностей. Это было что - то жуткое. правда там среди разработчиков никто в базах данных не разбирался...
а среди тиражных продуктов я такой жути не наблюдал ни разу, хотя ошибки были во всех

iscrafm__посмотрите на базы сапа или оракла. Кого вы пытаетесь развести?
видел. я как раз про них и говорил, что косяки есть везде...
только давайте посмотрим с другой стороны. предположим, есть предприятие, которому нужно 5-10% от функционала оракла или сапа. то есть далеко не только финансы, а еще и куча всего остального - одним словом, много функционала. какие у такого предприятия альтернативы ораклу или сапу? самому собрать команду разработчиков и написать?
вы то должны представлять себе сложность подобной системы и какие шансы у обычной (не ИТ) фирмы успешно завершить проект подобного уровня.