leonmbsЭто стандартный прокол неопытных разрабов -смотрит разраб на чужую прогу - да я с нуля напишу лучше и быстрее.
А я дурак мало опытный в свое время всей этой "мудрости" не знал и года за два разработал все основные
подсистемы бухгалтерского учета.
И работали они на весьма разных по областям деятельности организациях и не требовалось в них ни каких "хаков" /то бишь один и тот же АРМ успешно использовался в организациях любого профиля/.

Хотя честно скажу когда начинал разработку к примеру АРМ "Учет труда и заработной платы", то мыслил также как и вы, типа - "что мол не возможно это сделать" и.т.п.

Думаете расчет заработной платы принципиально отличается в России и на Украине?
Да различие имеются в некоторых расчетных алгоритмов /в частности удержаний .../, а в целом все то же самое.

PS: Прошу не развивать это мое суждение ...
Мне это не интересно и не нужно /"вспомнил молодость"/.

dma_caviarЯ вам ничего не толковал, я ответил leonmbs-у о том что чаще всего с нуля реально быстрее и качественней. При использовании нормальной _платформы_, а не очередной заготовки под проект.
Sorry.
Этот пост относился не вам.

leonmbsостальное свободно добавляется и заменяется - первичка, справочники, отчеты.
Это просто файлы на PHP И HTML но приведены к однообразному интерфейсу чтобы система могла их пользовать без хардкода.
например документы наследуются от класса Document которые умеет сохранять и вынимать себя из хранилища ивыполнять станлдартные для всех документов операции - например подтянуть печатную форму и скормить ее шаблонизатору.
Ничего военого технически - просто сайт на PHP.
До некоторой степени с вами согласен.
Действительно с использованием HTML + javascript + PHP /Perl,Pyton, ... / + какая либо СУБД не сложно
произвести разработку и диалоговых форм и отчетов и тем самым как бы решить задачу.
При этом и формы и отчеты красивые ...
Но имеются много не явных "но".

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

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

С другой стороны не станете же вы 1С использовать в качестве основного инструмента для разработки сайта?

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

leonmbsне верю ни секунды. Во первых два года - это не быстрее.
Во вторых "подсистемы учета" понятие растяжимое.
Максимум что вы могли сделать - узкоспециализирование решение работающее о первого серьезного изменения в законодательстве..
Ваше право.

Но в начале 90-х знаете ли "стырить" где либо чего либо негде было ...

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

Кстати АРМ-ы были разработаны с использованием мной разработанных designers и генератора отчетов.
Т.е. не было "ручного жесткого кодирования".
Чтобы ранее выполненная работа не "пропала даром", разработал конвертер этих meta данных в некую иную платформу.

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

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

leonmbsэто намек на то что понятие "designer" сейчас и то что вы написали (что бы вы не написали) в начале 90х под MS-DOS с 640кб ОЗУ это как сравнивать самолет братев Райт с Аербас 380. Конечно они оба летали, никто не спорит.Конечно.
А кто говорит о "бездумном" использовании мета данных для получения результата хорошего по "меркам" 80-х годов?