Мое мнение - писать свое, с нуля на самых современных технологиях. Я бы посоветовал из MS Visual Studio + SQL Server (если выбор MS Visual Studio, то и сервер от Microsoft)
Программист, который не атрофирован на 1С решениях, очень (ОЧЕНЬ!) быстро освоится с этитм продуктам и еще будет приятно удивлен в простоте и мощи предоставленных средой реализаций, о которых в 1С можно только мечтать.

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

Позвольте спросить, а что же тогда это важное, если предыдущее не важно? Нет, предыдущее важно, но оно уже сделано и его не надо реализовывать. Согласен, сделано. Но как?
Может стоит подумать о том, как это сделано, позволит ли это сделанное развивать дальше Вашу систему.

Вот частенько приходится слышать, типа того, что например, на Delphi или чем-то другом, кроме 1С надо писать много кода. Получается, что на 1С кода надо писать меньше!? Блажен тот, кто так думает.

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

Для реализации задачи на 1С, Вам надо нанимать на работу не программистов, а машинисток, потому как писать прийдется не мало.

авторЯ бы хотел обсудить техническую сторону.
например, в Делифи придется создавать Базовые классы (ядро бедующей системы) как я понимаю в 1С данный вопрос отпадает.

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

Хотите жить вчера? Вам к 1С.

авторВ делфи мне придется разрабатывать и отлаживать учетный механизм, в 1С он разработан и отлажен.

Разрабатывать прийдется. А с отладкой в 1С у Вас удет врямя необходимое для разработки и отладки в новых системах. Еще учтите следующее. Отладка в 1С это попытка понять, что хотели реализовать программисты, которых никто, никогда в глаза не видел. Проще говоря, надо рыться в чужих мыслях. И поверте эти мысли не всегда правильны или соответствуют вашей задаче. Исходя из этого Вас ждет частичная доработка. предположим, что это все делают внедренцы. Поинтересуйтесь как это делается? В основном методом налепливания кода для реализации специфичной задачи.

авторВ делфи мне придется отслеживать периодичность данных, в 1С это ....

Ни какой сложности нет реализовать ведение истории значений на SQL Server. Конечно это прийдется делать. Но 1 раз и "туча в ваших руках".
Это не нак важно, как то, как Вы сможете развивать вашу систему, а не ограничиваться тем, что кто-то реализовал в сущности своим функционалом обеспечивая объем, который Вы получаете вместе с 1С - это типовая конфигурация. Потом огромнейшее количество программистов с "напильниками" из этой типовой конфигурации пытались сделать что-то похожее на работающий прототип учетной системы. Если учесть удобство программирование и простоту в 1С, представьте сколько ьам в коде будет мусора.
Вы поверите в эту "сказку", отдадите свои деньги уйме внедренцев, тех.сопровождению и др. настройщикам этого, к стати со слов многих уже решенного продукта, в моем понимании это должна быть программа после инсталяции которой, моя задача должна быть решена, без вмешательства сторонних настойщиков. Ан нет, не Америка. Остров Буян, будь он окаян. Вот и попали Вы в зависимость от целой гурьбы настройщиков, наладчиков и других "сказочников".

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

saasa Писать заново учетную систему занятие бесперспективное.
Мой совет, воспользуйтесь готовой учетной системой исходя из ваших потребностей:
1cv7,1cv8,Парус,Галактика,Axapta,Navision,Oracle EBS, SAP R\3

Не правда. Писать программу очень перспективное занятие. Воспользоваться готовой учетной системой менее перспективное занятие.
Когда вы пишите свою программу, вы нарабатываете свои решения, повышаете профессионализм вашего коллектива. вам не нужны настройщики и не надо конфигурирование, ваша разработка и есть конфигурирование. Ваши настройщики - ваш коллектив. К примеру разработчики 1С, Парус, Галактика, Axapta, Navision, Oracle EBS, SAP R\3 думаю не считают что писать программу занятие не перспективное. Кто против может ложиться под перечисленных.

saasa То All, самописная система для ведения финансово-хозяйственной деятельности (если только она не стоит мега$) почти всегда окажется хуже тиражного продукта( в плане функционала,перспектив развития и техсапорта(законодательство,релизы и т.п.))

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


автор
Можно и С#
речь идет о предметно-ориентированной системе и нет.

и почему вы считаете 1С и Делфи злом а С# нет.

Потому-что С# (.NET), например, сегодня и завтра, а 1С - вчера и позавчера.

except Но если стоит вопрос только в 1С или Delphi, то лучше 1С. На дельфях вы задолбаетесь потом кусочки слепливать. И бухгалтерия либо убогая получится, либо угрохаете кучу времени и сделаете один из многих программных продуктов, которые залеживаются на рынке.

На счет Delphi утверждать ничего не буду, а вот на технологии .NET ни каких сложностей нет, все предельно ясно и понятно. Меня немного смущает суждение о том, что если я буду писать программу, по какой причине меня должно затруднить ее окончательная сборка?

И почему у разработчиков 1С бухгалтерия получилась толковая, а у меня, например, должна получиться убогая? У меня шансов сделать лучше на много больше, чем у 1С переделать свою убогость. Они обременены наследием прошлого, что и составляет их убогость. А у меня есть возможность оценить неудачи 1С и реализовать более оптимизированную систему, если конечно мне не лень думать.

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

AISOFTКак по мне, так надо выбирать или Delphi 5 (6) или VS NET (C#). Времени на разработку уйдет, может быть, больше. Но если, все сделать правильно, то в итоге получится лучший продукт. 1С не умеет работать с большими объемами данных, в многопользовательской среде.

Вот с этим мнением я согласен. На разработку может быть и больше уйдет времени, но если брать время от покупки лицензии до отлаженной эксплуатации, тут я и не уверен где будет больше. Например, в Киеве есть витаминный завод, так вот там, 1С бухгалтерию для Украины налаживали 6 месяцев (10 машин в сети) - начали в 2003 году, по сей день в полном объеме она не работает.

GaryaИМХО, концептуальная модель, используемая в 1С, довольно удачная. Не очень качественная реализация этой модели. Это уже проблемы практического воплошения идей силами реальных программистов при использовании реальных инструментариев, каждого со своей спецификой. Но не думайте, что в обозримые сроки числом программистов меньше, чем в 1С сможете качественно решить эту задачу. Вас ждут сплошные разочарования.

Получается, что вот придумал человек, класную штуку а какие-то программисты взяли и не сделали. У 1С было 7 версий и в каждой толпы релизов. Скажите от релиза к релизу в одной версии вы заметили хоть какие-нибудь концептуальные улучшения. Нет. Исправление глюков. У буржуев это называется ServicePak и к примеру Microsoft их раздает бесплатно. Этим люди не отрицают наличие ошибок, ну и не берут за это денег.
Ну да, 1С тоже за это денег не берет - это "злые" франчайзи.

Например, почему в 8-й версии 1С тянет за собой DBF? Что 7.7 плохо с этим справлялась. Нет. А (по-моему) для того, чтобы иметь вескую отговорку, в оправдание старых методов. Почему с SQL Server опять работает как с ДБФ? Кто им мешал похоронить ДБФ на 7-й версии? Кто им мешал реализовать всю мощь SQL Server на 8-ке, а не пудрить мозги утопичностью использования хранимых процедур?

Числом программистов меньше, чем в 1С можно решить качественно задачу. Может в том и проблема, что в 1С слишком много поднимающих пыль? На мой взгляд, для решения конкретной подзадачи, группа программистов должна быть не больше не меньше 3-х человек. Другая подзадача - еще 3 человека. Вполне возможно, что этих людей может быть и достаточно. Конечно, нагородили конфигураторов и другой пурги и теперь не знают что с этим всем делать.

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

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

============================

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

Во-первых, суть темы такова:

авторПодскажите, пожалуйста.

Для создания учетной системы, какою среду выбрать ?
Кол-во пользователей 30-60.
Планируется подключение стороннего оборудования .

Спасибо.

Но ответить я на ваши вопросы смогу...

saasalisichanec,
объясните пожалуйста почему компании тратят десятки (если не сотни миллионы долларов) на покупку и внедрение тиражных систем (SAP,Oracle и т.п), а не пишут с нуля ???

Во-первых, сотни и миллионы долларов на это тратят в основном зарубежные компании, потому как отечественные просто нищие, и как правило берут низкокачественные продукты. Кроме того эти продукты ни в какие рамки не водят по вопросу функционала, который бы полностью отвечал "Особенностям национального документооборота".
А зарубежные компании покупают готовые, по простой причине. Чтобы за рубежом собрать группу программеров для написания, скажем архиватора им надо человек 10-15. И заплатить каждому 3-5 тыс баксов в месяц. А что за квалификация у западных программеров? Не подумайте ничего. Они очень высокого уровня специалисты, но в такой узкой сфере, что просто их нужна толпа. За рубежом никто не найдет программиста, способного написать прогу с нуля до релиза (если это конечно не прграммер из бывшей совдепии). И сколько бы Вы пыль не поднимали, я знаю, что их программер будет делат все по бумажке, по схеме, по готовому алгоритму. И только потом они будут тестировать это творение, потом будут искать новые решения. А наш программер способен на лету менять алгоритмы, в процессе создания тестировать и оптимизировать. Сравните. Сколько людей написали к примеру, DrWeb = 6 чел., и сколько создавали VeriSign = 28 . Улавливаете разницу?

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

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

А вот интересно, Вы хоть что-нибудь сами написали? И на чем? Если не секрет.


ВадимДа он просто не представляет что такое SAP или OEBS да даже 1Сv8...
Что такое управление проектом и ответственность.
Что такое удерживать людей и развивать сеть партнеров.

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

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

Да небыло у Вас такого и близко. Вы чем-то напуганы в этой жизни. Вам видимо страшно подумать о том что такое "SAP или OEBS да даже 1Сv8..." (см. свой топик). Почему я этого должен бояться? Почему, те кто это уже сделал не боялись, а я должен бояться?

Почему? Я и мои товарищи (втроем) с нуля сделали Биллинг (за семь месяцев) сдали его в эксплуатацию, сейчас он проходит тестирование на живом предприятии. Почему я должен бояться? Должен с благоговением использовать 1С или что-то там еще. А до этого, это предприятие пользовалось Биллингом, который разработал коллектив из 50-ти человек. Даже звучная фирма. Поверьте я не хвастаю - это факт. Не хочу уточнять - получится реклама или антиреклама.
Вы просто хоть раз в жизни попробуйте, да инструменты возьмите не "каменные" и через полгода будете вспоминать про 1С как про кошмар летящий на крыльях ночи. А то Вы прямо запугали тут всех, "Знаете что значит сделать бухучет?" - ничего сложного в этом нет, он до такой степени упорядочен, что прямо бери, без постановщика задачи, с учебника пиши. Вы бы лучше сказали, а знаете как сложно угнаться за текущими изменениями законодательства, вот тут я согласен, так Вам для того и дана голова, чтобы как-то облегчить себе сопровождение и поддержку в этом и есть кайф программирования - находить ответы на сложные вопросы.

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

LSVЗабыли упомянуть про риск инвестиций. В случае внедрения своего продукта этот риск заметно ниже. Своих программистов всегда можно заставить/заинтересовать сделать как надо и очень быстро (время - деньги !), даже если это иногда несколько противоречит здравому смыслу ! Внедренец же за это запросит баснословные деньги и сроки, причём зная что их не заплатят, делать ничего не будет. Проект останется форева недоделанный, эффективность работы останется низкой, опять таки форева. И за что только бешеные деньги были плачены ?

Глубокая иллюзия, что в уже готовом коммерческом продукте проще доработать под свои требования. Эти продукты очень сложные и разбор чужих (и глючных) мыслей может занять времени/денег даже больше, чем переписать всё заново.... :) Но никто не переписывает.... И глюки форева ! ! ! :)

Видимо LSV хлебнул в своей жизни счастья от внедрения готовых высокотиражных систем.
Хочу уточнить одни нюанс. Наверное надо разграничить ситуацию. В чем различия внедрения готового и создания своего.

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

А вот когда разработка вдется силами своих программеров или выполняется конкретный заказ, тут происходит совершенно другая ситуация.
Во-первых, тут нет как такового внедрения. Потому-что выполняя задачу Вы и создаете и тестируете и тут же внедряете. Если утвержден функционал и результаты производительности заказчиком - считайте внедрили. В процессе разработки и тестирования Вы умышленно нагружаете каждый процесс заведомо черезмерными объемами данных или другими нагрузками, которые превышают повседневные ситуации. Это Вы делаете для получения гарантий в первую очередь для себя. Вы неоднократно откатываете раз-за-разом один и тот же режим. И когда получаете результат принимаете решение о внедрении его в проект. Дальше в его работоспособности Вы уверены. Что же еще надо для внедрения.
Если заказчик, предъявляет обоснованные претензии, ВЫ имеете возможность изменить все что угодно. И заметьте изменаете (дорабатываете) очень малую толику из всего проекта, при это Вам на руку - Вы совершенствуете свою разработку.
Кроме того, Вы имеете решенную подзадачу "кирпичик" из которого будете в дальнейшем (при необходимости) строить другой дом. Позвольте спросить, что стоит человеку реализовавшему скажем План счетов, который работает в определенном внедренном проекте, при необходимости доработать его или подключить без изменения в другой проект?

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