Бухучет на PHP

autosoft

Guest
Re: Бухучет на PHP

Автор оригинала: Tok
Очень хочется узнать мнения гуру по следующим вопросам:
1.Оценка идеи написания системы бухгалтерского учета на PHP;
Я занимаюсь созданием подобной системы чуть больше года. Заказчик пришел к выводу что ему нужен именно такой бухучет поскольку это даст возможность избавиться от винды и не тратить деньги на её лицензирование. Самое сложное – выработка концепции системы. Начиная с проектирования структуры базы данных и заканчивая единым стилем интерфейса пользователя. Последнее, как нестранно - самое тяжелое :)

2.Какая из БД подойдет лучше всего (желательно GPL);
Firebird например. Уже отмечали как-то - из-за наличия хранимых процедур и тригеров.

3.Стоит ли использовать Smarty и т.п.
Думается что по вкусу...

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

Alexandre

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

По экранным формам выработай требования к своему интерфейсу пользователя.

вычлени одинаковые эл-ты, такие как календарные поля (поля даты), товарные позиции .. и пр...

определись в стиле всплывающих окон.

короче - догадываюсь, что мароки много
формирователь

Конечно - есть фишка в разработке собственного... свое - всегда роднее и приятнее :)
 

kolemming

Новичок
Originally posted by Alexandre
смотри образцы, например, Парус, Ахапта или Галактика.

И на их цены тоже взгляните. :) Сразу все на свои места встанет. (1С правда не так дорога как выше названные, но там политика другая).

На php как на общей среде разработки, которой обладают почти все серьезные пакеты такого класса(от 400 у.е. за раб. место), ну да можно немного сэкономить, как и на остальном что "free", но чтобы повторить или переплюнуть функционал любого, даже самого небольшого модуля, той же 1С...ИМХО это утопия.

Более того, в один момент, по мере роста функционала, может случится так, что на php дальше писать будет таки безполезно и вот тут все затонет, как Титаник, ибо реализовавывать транслятор на php хмм...

В общем, всем Удачи.
 

Alexandre

PHPПенсионер
Более того, в один момент, по мере роста функционала, может случится так, что на php дальше писать будет таки безполезно и вот тут все затонет
kolemming - обоснуй

вообще-то, если писать свой транслятор форм, то скорее всего его надо реализовывать как подгружаемый DSO-модуль.

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

-~{}~ 23.11.04 11:56:

[offtop] глаза бояться, а руки код пишут
[offtop]
 

autosoft

Guest
Автор оригинала: Alexandre
смотри образцы, например, Парус, Ахапта или Галактика.

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

Могу показать, как это делаю я - пишите по e-mail. Создавать сайт, чесно говоря. просто нет времени.

Конечно - есть фишка в разработке собственного... свое - всегда роднее и приятнее :)
Я бы сказал что в случае web - выбора особого нет
 

Alexandre

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

А так как к бухгалтерии имеет достум строго органиченного контингента, таким образом система является крапоротивной. В этом случае можно выставить требования к браузерам (почти все используют IE 6.0) и использовать на клиенте такие элементы как treeView ListView (уже начиная с IE 5.5 ессть такая возможность)

используя treeView и ListView можно организовать DragDrop
обработка левой кнопки мыши и др. красивые режимы.

И вообще сегодня программирование браузера по возможностям мало уже отличается от программирования оконного приложения.

так же используя ActivX можно сделать простейшую криптозащиту передачи инфы...

-~{}~ 23.11.04 18:06:

Я бы сказал что в случае web - выбора особого нет
я бы так не сказал, выбор есть всегда:)

нет выбора для слизывания, но есть выбор для творческоой деятельности и довольно обширный
 

kolemming

Новичок
to Alexandre

Обосновываю. Если предполагается написание продукта, который будут всю жизнь поддерживать одни и те же люди(его создатели) и круг клиентов будет ограничен 10-ю клиентами(у самого крутого из них-сеть палаток по ср. России), то да, ничего не затонет, уйдут разработчики на пенсию и на клиентов им будет уже фиолетово :). Да и палатки станут магазинами и уйдут к 1С-никам или на что побольше денег хватит. Если судить по масштабам этой темы, то писать собираются прям таки систему автоматизации учета на предприятиях!!!
Почему нельзя обойтись php и почему нужно создавать среду разработки или очень гибкие возможности настройки(это актуально, если мы все про масштабы говорим)? Бесконечный разговор, но самая близкая ассоциация, которая у меня назрела, это шаблонные движки(и их подобие), когда программист не ограничивает верстальщика html в дизайне, но и не дает ему вписать "drop database".

p/s/ 1C готовит тонкого клиента на основе web-интерфейса, у скольких он уже есть в прослойке между MBS и 1С нужно считать, но думаю у многих.
 

autosoft

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

А так как к бухгалтерии имеет достум строго органиченного контингента, таким образом система является крапоротивной. В этом случае можно выставить требования к браузерам (почти все используют IE 6.0) и использовать на клиенте такие элементы как treeView ListView (уже начиная с IE 5.5 ессть такая возможность)
Так и есть - IE & Opera

так же используя ActivX можно сделать простейшую криптозащиту передачи инфы...
Я использую Linux и тут говорили о том же. Как в такой ситуации использовать ActivX? Или я чего-то не понимаю?

нет выбора для слизывания, но есть выбор для творческоой деятельности и довольно обширный
Maybe
 

Alexandre

PHPПенсионер
Криптование в учетной системе

Я использую Linux и тут говорили о том же. Как в такой ситуации использовать ActivX? Или я чего-то не понимаю?
autosoftскорее всего ты что-то недопонимаешь.
ты используешь Линукс на сервере, как я понял, а речь идет о клиенте. Если ты используешь Линукс на клиенте, то см. п. 1 -
А так как к бухгалтерии имеет достум строго органиченного контингента, таким образом система является крапоротивной. В этом случае можно выставить требования к браузерам
ну и конечно к ОС компьютера.

теперь пару слов о защите, хотя это отдельный флейм. алгоритм сл:
клиент (то биш браузер) с использованием msxml или др. http сендера делает запрос на сервер. Я предпочитаю msxml Запрос можно не шифровать.

Сервер - принимает запрос,
осуществляет его парсинг, формирует ответ,
шифрует RC2 или RC4 (это поддерживает mcrypt)
далее данные преобразуются в base64
и формируется ответ на клиент.
ОСь Сервера на алгоритм криптования ни как не влияет :)

Клиент - получает шифрованный запрос
передает его в ActivX

ActivX - расшифровывает его, и строит соответствующий DOM
далее этот DOM - выводим туда - куда нужно.

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

Как в такой ситуации использовать ActivX?
ну нет желание работать с ActivX - напиши аплет на Java

алгоритмя RC2 и RC4 поддерживаются везде: Java, PHP, C++, C# и на любых платформах.

Если хочешь что-то более навороченное, то большинство платформ имеют библиотеки более криптостойких алгоритмов :)) но мне кажется, что и RC4 вполне предостаточно.

-~{}~ 24.11.04 09:03:
:p
Клиент - получает шифрованный запрос
передает его в ActivX
в догонку будет сказанно, что ActivX состоит всего лишь из одной функции encrypt() ну и конечно вспомогательных... чтоб построить соотвествующую структуру и блок данных.
Процедуру криптования можно чуть-чуть усложнить, используя вектор инициализации, тогда увеличивается криптостойкость. :eek:

просто флейм:

Бесконечный разговор, но самая близкая ассоциация, которая у меня назрела, это шаблонные движки(и их подобие), когда программист не ограничивает верстальщика html в дизайне, но и не дает ему вписать "drop database".
kolemming юзай MVC, я как раз заканчиваю по ней проект, там тебе в движке:
- и распределение прав доступа на классы
- и гибкий (относительно :) ) доступ к БД - по крайней мере DROP и TRANCATE точно непролезут
- и шаблонизирование .....
все в одном компотеЯ, так что следи за новостями.


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

Результат : лучше, удобнее, функциональнее и надежнее ?)
 

vitus

мимо проходил
Либо я что-то не понял, либо вы ребята всё смешали в одну кучу, я как-то раз разрабатывал тз+проект подобной системы (до реализации не дошло по причинам кусачего бюджета :) ), только эта система называлась "корпоративная информационная система", не система бух учёта, заметьте!

системы подобные той, которую вы обсуждаете по сложившейся практике принято пилить на Документооборот, CRM и собственно бух учёт.

делать всё это в рамках проекта на пыхе, - имхо гимор страшный, на пыхе имеет смысл реализовать ту часть, которая отвечает за web interface тоесть лишь часть V, в любимой аббривеатуре MVC.

модель (даже скорее модели) лучше делать на чём нибудь более жёстком, а контроллер на каком-нибудь мидлеваре, это даст большую гибкость и масштабируемость.

часть бухучёта (вот честно вам скажу) будет не самой сложной.
 

Alexandre

PHPПенсионер
Либо я что-то не понял, либо вы ребята всё смешали в одну кучу
скорее всего второе :), но в данном топике речь идет только об учете. Документооборот и СРМ мы пока не рассматриваем.vitus, поясни плииз:
имеет смысл реализовать ту часть, которая отвечает за web interface тоесть лишь часть V, в любимой аббривеатуре MVC.

модель (даже скорее модели) лучше делать на чём нибудь более жёстком, а контроллер на каком-нибудь мидлеваре, это даст большую гибкость и масштабируемость.
что подразумевается под - более жестким: С++? или Java?
разработка на С++ или Java могут повысить стоимость разработки, хотя увеличит скорость работы....

и еще - vitus, как ты собираешься соединять эти три составляющих MVC, если они написаны на разных платформах...

В принципе, я твою идею одобряю, за исключением некоторых НО :)
 

vitus

мимо проходил
Документооборот и СРМ мы пока не рассматриваем
- Это вопрос спорный, вы рассматриваете составление, заполнение первичных документов, - эту часть лучше отнести к документообороту (они используются не только в бухучёте).

Косвенно вы обсудили некоторые моменты, которые можно отнести к CRM.

- собственно бухучёт - это проводка первичного документа по счетам и суммирование этих счетов, самое сложное здесь - проводка.
что подразумевается под - более жестким: С++? или Java?
то, что вам больше нравится :) и для чего есть подходящий апп сервер.

как ты собираешься соединять эти три составляющих MVC
для этого тоже есть вполне доступные, достойные технологии, фишка в том, что и M и V и C - тоже могут быть сделаны в архитектуре MVC, или ещё какой - нибудь :) .
 
Сверху