Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 434
интересно, у минусующих есть какие то аргументы кроме «я зарабатываю на внедрении 1С и нефиг тут альтернативы предлагать»
Я, например, на внедрении 1С не зарабатываю, но тоже бы минуснул, если бы карма позволяла :) Как-то оно… наивно выглядит. Вроде «а давайте запилим новую ОС, чтобы опенсурсная была и я вот предлагаю файловую систему нового типа».
Аргументы? Пожалуйста:
Давайте сразу к выводам перескочим.
> Итак, сухой остаток — выкинуть по возможности все, что не относится к бизнес логике, сделать простым и универсальным все, что можно
> сделать просто и универсально. На мой взгляд, такой подход единственно конкурентоспособен,
Вы всерьез считаете, что кого-то из потребителей учётных систем вообще хоть капельки волнует абстрактность/универсальность их внутренней архитектуры? Не, серьёзно? Какие проблемы потребителей решает, например, вот такой выподвёрт?
> Предлагается хранить все докуменнты в одной таблице в блобе, упакованными в XML.
> Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус."
Какие проблемы создаёт, придумать несложно. Производительность будет хилая, возможность массовых обработок с помощью SQL пропадёт и т.д. А вот что решает?
Я вам открою секрет: потребителям надо:
а) актуальные формы и формулы. Как только законодатели родят новую схему налогообложения или новые формы отчётности, они должны попасть в эту систему.
б) удобный и привычный интерфейс. Который преподают на курсах бухгалтеров
в) наличие специалистов и компаний-саппортеров
Вот это их интересует, а не очередной самодельный гибкий универсальный всеобъемлющий ORM.
Аргументы? Пожалуйста:
Давайте сразу к выводам перескочим.
> Итак, сухой остаток — выкинуть по возможности все, что не относится к бизнес логике, сделать простым и универсальным все, что можно
> сделать просто и универсально. На мой взгляд, такой подход единственно конкурентоспособен,
Вы всерьез считаете, что кого-то из потребителей учётных систем вообще хоть капельки волнует абстрактность/универсальность их внутренней архитектуры? Не, серьёзно? Какие проблемы потребителей решает, например, вот такой выподвёрт?
> Предлагается хранить все докуменнты в одной таблице в блобе, упакованными в XML.
> Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус."
Какие проблемы создаёт, придумать несложно. Производительность будет хилая, возможность массовых обработок с помощью SQL пропадёт и т.д. А вот что решает?
Я вам открою секрет: потребителям надо:
а) актуальные формы и формулы. Как только законодатели родят новую схему налогообложения или новые формы отчётности, они должны попасть в эту систему.
б) удобный и привычный интерфейс. Который преподают на курсах бухгалтеров
в) наличие специалистов и компаний-саппортеров
Вот это их интересует, а не очередной самодельный гибкий универсальный всеобъемлющий ORM.
Вы всерьез считаете, что кого-то из потребителей учётных систем вообще хоть капельки волнует абстрактность/универсальность их внутренней архитектуры?
а что есть потребители которых волнует архитектура 1С?
Данная архитектура ориентирована на разработчиков а не потребителей.
поскольку без разработчиков все равно не обойтись то есть смысл
предложить решение гораздо более простое и саппорте чем 1С.
актуальные формы и формулы. Как только законодатели родят новую схему налогообложения или новые формы отчётности, они должны попасть в эту систему.
на практике \то попадает далеко не сразу а уж тем более не сразу попадает потребителю которому еще надо заплатить програмеру ха обновление.
б) удобный и привычный интерфейс. Который преподают на курсах бухгалтеров
веб интерфес не менее привычный. И он гораздо проще чем десятки пунктов меню на форме 1С. как то люди управляются с системами тиа Мой склад.
в) наличие специалистов и компаний-саппортеров
дело наживное.
> Данная архитектура ориентирована на разработчиков а не потребителей.
Значит, она мертворожденная по своей сути. Уж поверьте, невозможно убедить потребителя поменять учётную систему ради архитектуры. А разработчик не будет заниматься системой, которую он не сможет внедрить у клиента. Замкнутый круг.
> на практике \то попадает далеко не сразу а уж тем более не сразу попадает потребителю которому еще надо заплатить програмеру ха
> обновление.
На практике — попадает сразу всем клиентам, кроме тех, у которых конфигурация сильно кастомизирована.
> веб интерфес не менее привычный. И он гораздо проще чем десятки пунктов меню на форме 1С. как то люди управляются с системами
> тиа Мой склад.
Что значит «он гораздо проще»? Интерфейс несуществующей системы не может быть «проще» или «сложнее». Его вообще нет, и неизвестно, каким он будет. Если вы имеете в виду, что сам факт нахождения интерфейса программы в браузере сделает его гораздо проще, чем интерфейс 1С, то… вы сами к этому моменту, надеюсь, поняли, что это крайне нелепое утверждение?
Значит, она мертворожденная по своей сути. Уж поверьте, невозможно убедить потребителя поменять учётную систему ради архитектуры. А разработчик не будет заниматься системой, которую он не сможет внедрить у клиента. Замкнутый круг.
> на практике \то попадает далеко не сразу а уж тем более не сразу попадает потребителю которому еще надо заплатить програмеру ха
> обновление.
На практике — попадает сразу всем клиентам, кроме тех, у которых конфигурация сильно кастомизирована.
> веб интерфес не менее привычный. И он гораздо проще чем десятки пунктов меню на форме 1С. как то люди управляются с системами
> тиа Мой склад.
Что значит «он гораздо проще»? Интерфейс несуществующей системы не может быть «проще» или «сложнее». Его вообще нет, и неизвестно, каким он будет. Если вы имеете в виду, что сам факт нахождения интерфейса программы в браузере сделает его гораздо проще, чем интерфейс 1С, то… вы сами к этому моменту, надеюсь, поняли, что это крайне нелепое утверждение?
Значит, она мертворожденная по своей сути. Уж поверьте, невозможно убедить потребителя поменять учётную систему ради архитектуры
А зачем вообще произносить слово архитектура? Слово «бесплатная програма», «дешевый саппорт» и «возможность набивать заказы на планшете через инет» гораздо доходчивее.
Если вы имеете в виду, что сам факт нахождения интерфейса программы в браузере сделает его гораздо проще, чем интерфейс 1С,
Он проще потому что нет смысла его делать сложнее а не потому что он в браузере.
Интерфейс несуществующей системы не может быть «проще» или «сложнее». Его вообще нет, и неизвестно, каким он будет
Во первых есть и известно.
Во вторых в статье ДЛЯ ДЕВЕЛОПЕРОВ изложены принципы построения и решения недостатков 1С — а не расписано план что когда будет. Не волнуйте пока без работы не останетесь.
> А зачем вообще произносить слово архитектура? Слово «бесплатная програма», «дешевый саппорт» и
«возможность набивать заказы на планшете через инет» гораздо доходчивее.
Может, кто-то и клюнет. Хотя маркетинг так себе. Хорошие бесплатные учетные системы есть, но стоят они примерно столько же, сколько и платные. Если не произносить фразу «дешевый саппорт» — от этого любой мало-мальски вменяемый клиент убежит как от черта лысого.
> Он проще потому что нет смысла его делать сложнее а не потому что он в браузере.
Вы хотите сказать, что все те кнопочки/менюшки в учетных системах сделаны для усложнения интерфейса, а не потому, что это нужно бухгалтерам, операционистам, финансистам и т.д.?
> Во вторых в статье ДЛЯ ДЕВЕЛОПЕРОВ изложены принципы построения и решения недостатков 1С
Так в том же и вопрос — недостатки-то в чём? То, что там для добавления фич надо писать вот так, а тут вот этак — это просто факт, а не недостаток/преимущество. Ни по производительности, ни по простоте сопровождения конкретных данных нет.
> Не волнуйте пока без работы не останетесь.
Я не 1Сник. Я сейчас занимаюсь NAV и CRM-системами MS Dynamics и vTiger. Просто хотел за вашим энтузиазмом увидеть здравое зерно, но пока никак. Только «опенсурс», «сообщество напишет», «программисты PHP дешевые».
«возможность набивать заказы на планшете через инет» гораздо доходчивее.
Может, кто-то и клюнет. Хотя маркетинг так себе. Хорошие бесплатные учетные системы есть, но стоят они примерно столько же, сколько и платные. Если не произносить фразу «дешевый саппорт» — от этого любой мало-мальски вменяемый клиент убежит как от черта лысого.
> Он проще потому что нет смысла его делать сложнее а не потому что он в браузере.
Вы хотите сказать, что все те кнопочки/менюшки в учетных системах сделаны для усложнения интерфейса, а не потому, что это нужно бухгалтерам, операционистам, финансистам и т.д.?
> Во вторых в статье ДЛЯ ДЕВЕЛОПЕРОВ изложены принципы построения и решения недостатков 1С
Так в том же и вопрос — недостатки-то в чём? То, что там для добавления фич надо писать вот так, а тут вот этак — это просто факт, а не недостаток/преимущество. Ни по производительности, ни по простоте сопровождения конкретных данных нет.
> Не волнуйте пока без работы не останетесь.
Я не 1Сник. Я сейчас занимаюсь NAV и CRM-системами MS Dynamics и vTiger. Просто хотел за вашим энтузиазмом увидеть здравое зерно, но пока никак. Только «опенсурс», «сообщество напишет», «программисты PHP дешевые».
Вы хотите сказать, что все те кнопочки/менюшки в учетных системах сделаны для усложнения интерфейса, а не потому, что это нужно бухгалтерам, операционистам, финансистам и т.д.?
Типично для постсоветского разраба который лучше валенка-заказчика знает что тому нужно в его бизнесе…
Так в том же и вопрос — недостатки-то в чём?
в статье есть ссылка на соответствуюзую статью зачем повторятся
Кроме дополнительных отсутсвующих в 1С — кроспатформенность, модульность, открытый код, бесплатность, простота кодирования, веб интерфейс (не тот что в 1с а тот что нормально работает в мобильном устройсте)
. Я сейчас занимаюсь NAV и CRM-системами MS Dynamics и vTiger.
а зачем? Ведь 1С, по вашему, не имеет недостатков.
.
> Типично для постсоветского разраба который лучше валенка-заказчика знает что тому нужно в его бизнесе…
Критерий «мелкий и средний бизнес у нас сплошь и рядом пользуется 1С, а все её новоявленные конкуренты на рынке под лупой не заметны» вас чем не устраивает?
> Кроме дополнительных отсутсвующих в 1С — кроспатформенность, модульность, открытый код,
Эээ, а что, у 1С уже украли поддержку линукса, мобильные клиенты, модульность и закрыли код? Или вы раз увидели это в какой-то статье, то сразу поверили и приняли к действию?
> бесплатность
Для бизнес-пользователей? Зачем им это?
> простота кодирования
С каких это пор PHP стал проще, чем 1С?
> а зачем? Ведь 1С, по вашему, не имеет недостатков.
Потому что авторы этих систем, в отличие от вас, предлагают не воздушные замки крутых архитектур, а нужный клиентам функционал.
Критерий «мелкий и средний бизнес у нас сплошь и рядом пользуется 1С, а все её новоявленные конкуренты на рынке под лупой не заметны» вас чем не устраивает?
> Кроме дополнительных отсутсвующих в 1С — кроспатформенность, модульность, открытый код,
Эээ, а что, у 1С уже украли поддержку линукса, мобильные клиенты, модульность и закрыли код? Или вы раз увидели это в какой-то статье, то сразу поверили и приняли к действию?
> бесплатность
Для бизнес-пользователей? Зачем им это?
> простота кодирования
С каких это пор PHP стал проще, чем 1С?
> а зачем? Ведь 1С, по вашему, не имеет недостатков.
Потому что авторы этих систем, в отличие от вас, предлагают не воздушные замки крутых архитектур, а нужный клиентам функционал.
Критерий «мелкий и средний бизнес у нас сплошь и рядом пользуется 1С, а все её новоявленные конкуренты на рынке под лупой не заметны» вас чем не устраивает?
меня устраивает — мен все равно. Не устаривает многих пользователей у них нет ПОКА выбора.
С каких это пор PHP стал проще, чем 1С?
дело не в синтаксисе языка. А в том что написано в модулях и формах документов 1С. Я знаю что говорю — сам когда-то внедрял 7.7.
а нужный клиентам функционал.
То есть счета, накладные и прочая первичка ненужный фунционал? А шо тогда нужно владельцу малого бизнеса для учета.
> меня устраивает — мен все равно. Не устаривает многих пользователей у них нет ПОКА выбора.
Вы сейчас кривите душой. На самом деле вам надо было писать «мне кажется, что не устраивает многих пользователей». Потому что на самом деле 1С устраивает практически всех. Она дешёвая, простая, все бухгалтеры ей умеют пользоваться. Исключения бывают, но это именно исключения, а не «многие пользователи».
> дело не в синтаксисе языка. А в том что написано в модулях и формах документов 1С.
В вашей системе, если она будет развиваться, через пару лет будет то же самое.
Вы сейчас кривите душой. На самом деле вам надо было писать «мне кажется, что не устраивает многих пользователей». Потому что на самом деле 1С устраивает практически всех. Она дешёвая, простая, все бухгалтеры ей умеют пользоваться. Исключения бывают, но это именно исключения, а не «многие пользователи».
> дело не в синтаксисе языка. А в том что написано в модулях и формах документов 1С.
В вашей системе, если она будет развиваться, через пару лет будет то же самое.
Потому что на самом деле 1С устраивает практически всех.
а у них есть выбор?
В вашей системе, если она будет развиваться, через пару лет будет то же самое.
не будет. система модульная — нет никакой необходимости напихивать весь возможный функционал.
> а у них есть выбор?
Есть, конечно. Инфобухгалтер, Галактика, Акцент… уже не говоря про массу разного рода бесплатных изделий, в том числе и на php. Тот же vTiger, хоть и CRM по сути, но задачки «клиент-товар-заказ-счет-накладная» вполне решает.
Но какова их популярность в сравнении с 1С?
> система модульная — нет никакой необходимости напихивать весь возможный функционал.
Напихивать куда? В 1С тоже учет покупок, основных средств или там отчет «товар-оборотна ведомость» находятся в разных модулях, а не свалены в кучу. Функционал там разросся потому, что одному клиенту нужно вот в покупках расчет налогового кредита, другому клиенту раздельно финансовый, раздельно управленческий учет, третьему ещё что-то. Причем этих «что-то» тысяча и одна хрень, и в модуле закупок всё это учтено. И никуда их в другой модуль не выбросишь, ибо касается как раз закупок.
Есть, конечно. Инфобухгалтер, Галактика, Акцент… уже не говоря про массу разного рода бесплатных изделий, в том числе и на php. Тот же vTiger, хоть и CRM по сути, но задачки «клиент-товар-заказ-счет-накладная» вполне решает.
Но какова их популярность в сравнении с 1С?
> система модульная — нет никакой необходимости напихивать весь возможный функционал.
Напихивать куда? В 1С тоже учет покупок, основных средств или там отчет «товар-оборотна ведомость» находятся в разных модулях, а не свалены в кучу. Функционал там разросся потому, что одному клиенту нужно вот в покупках расчет налогового кредита, другому клиенту раздельно финансовый, раздельно управленческий учет, третьему ещё что-то. Причем этих «что-то» тысяча и одна хрень, и в модуле закупок всё это учтено. И никуда их в другой модуль не выбросишь, ибо касается как раз закупок.
Но какова их популярность в сравнении с 1С?
никакая. Потому и говорю — выбора нет
В 1С тоже учет покупок, основных средств или там отчет «товар-оборотна ведомость» находятся в разных модулях
там вообще дин модуль все — то что именуется конфигурацией.
я не ставлю задачу охватить весь сегмент перекрываемый 1С. Потому и не надо реализовывать все на все случаи жизни.
Да и 1с тоже не все равлизовывает потому и требует допиливания под клиента.
а раз надо допиливать то зачем все реализовывать? пусть програмер допилит только то что нужно не проираясь через километр исходников.
> никакая. Потому и говорю — выбора нет
А причина этого — в чём? Их разработчики не догадались сделать так хорошо, как догадались вы? Или может быть потому, что 1С просто покрывает бухгалтерские потребности подавляющего большинства клиентов, и они «проголосовали» своим выбором?
> там вообще дин модуль все — то что именуется конфигурацией.
Вообще, нет. Модульность на уровне функциональных компонент там есть. Другое дело, что там между ними есть связи, но… в вашем случае будет абсолютно то же самое.
> я не ставлю задачу охватить весь сегмент перекрываемый 1С.
> Потому и не надо реализовывать все на все случаи жизни.
Вы понимаете, что все эти «мелкие фичи» — они у всех клиентов разные. И потому их так много, что в чистом виде оно вообще мало кому понадобится. Ну найдете вы десяток-другой клиентов. Это того стоит?
А причина этого — в чём? Их разработчики не догадались сделать так хорошо, как догадались вы? Или может быть потому, что 1С просто покрывает бухгалтерские потребности подавляющего большинства клиентов, и они «проголосовали» своим выбором?
> там вообще дин модуль все — то что именуется конфигурацией.
Вообще, нет. Модульность на уровне функциональных компонент там есть. Другое дело, что там между ними есть связи, но… в вашем случае будет абсолютно то же самое.
> я не ставлю задачу охватить весь сегмент перекрываемый 1С.
> Потому и не надо реализовывать все на все случаи жизни.
Вы понимаете, что все эти «мелкие фичи» — они у всех клиентов разные. И потому их так много, что в чистом виде оно вообще мало кому понадобится. Ну найдете вы десяток-другой клиентов. Это того стоит?
Их разработчики не догадались сделать так хорошо, как догадались вы?Одна из причин. Мне бы их бабло. Впрочем их системы разрабытывались давно и морально устарели.
Ну найдете вы десяток-другой клиентов. Это того стоит?
это опенсорс проект
В отличие от остальных у меня нет цели сделать систему чтобы ее продавать за деньги. Я бы даже не брался за такое или устанавливал 1с как по молодости в начале нулевых…
> Одна из причин.
Самоуверенность, конечно же, это наверное хорошо :)
> это опенсорс проект
Делая опенсорсные приложения, все равно разработчик обычно хочет, чтобы ими пользовались. Тут вон целая армия айтишников показывает вам свой скепсис, но вы безапеляционно им возражаете: «Мой тысячепервый велосипед намного лучше, чем тысяча велосипедов, сделанных до него! Он обязательно победит!»
Самоуверенность, конечно же, это наверное хорошо :)
> это опенсорс проект
Делая опенсорсные приложения, все равно разработчик обычно хочет, чтобы ими пользовались. Тут вон целая армия айтишников показывает вам свой скепсис, но вы безапеляционно им возражаете: «Мой тысячепервый велосипед намного лучше, чем тысяча велосипедов, сделанных до него! Он обязательно победит!»
Мой тысячепервый велосипед намного лучше, чем тысяча велосипедов, сделанных до него! Он обязательно победит!
я не говорю что он победит. Но я говорю о технических решениях которые лучше. Причем лучше не по отдельности а именно в таком комплексе и взаимосвязи.
.
Вы предложили, например, для решения нетиповых задач поиск по текстовым документам:
> select from documents where details like '%вася пупкин %'
Например, этот запрос на выборку отгрузок по контрагенту у очень небольшой фирмы за год должен будет перелопатить несколько десятков мегабайт данных. Думаете, секунда потребуется?
> select from documents where details like '%вася пупкин %'
Например, этот запрос на выборку отгрузок по контрагенту у очень небольшой фирмы за год должен будет перелопатить несколько десятков мегабайт данных. Думаете, секунда потребуется?
думаю намного меньше. Шо такое несколько десятков мегабайт для mysql при линейной выборке для одной простой таблицы. Да он все это в память закинет и перелопатит в мгновение ока.
Опять же такие запросы — исключение — штатная работа ведется по таблице аналитики.
.
Опять же такие запросы — исключение — штатная работа ведется по таблице аналитики.
.
В реальности скорее больше. Ну вот простая математика — я сейчас смотрю на CRM небольшой фирмы, которая торгует разного рода лампочками/батарейками. Два товароведа, несколько продажников, бухгалтер, директор. Обычная «сферическая мелкая фирма в вакууме». Заказы — XML-документы, которые падают из EDI, и это как раз примерно то, что вы будете там хранить. Заказ в пару десятков позиций «весит» килобайт 20 ±. В день их около десятка. Заказ порождает как минимум накладную и счет. Итого полсотни килобайт на заказ, полмегабайта в день… и соответственно, полторы сотни мегабайт в год только на базовые торговые документы. Т.е. пересмотрите ваши прогнозы. Это узкое место у вас реально станет катастрофой, причём архитектурной, фундаментальной.
шо то до фига 20 кил на документ.
нет. Поиск по документам — это запасной вариант для экстренных случаев когда время выборки не будет иметь значения. Например как в 1с когда видишь в оборотно-сальдовой минус на остатке и начинаешь перерывать все документы откуда это минус нарисовался.
Штатная работа по таблице фактов.
Это узкое место у вас реально станет катастрофой, причём архитектурной, фундаментальной.
нет. Поиск по документам — это запасной вариант для экстренных случаев когда время выборки не будет иметь значения. Например как в 1с когда видишь в оборотно-сальдовой минус на остатке и начинаешь перерывать все документы откуда это минус нарисовался.
Штатная работа по таблице фактов.
> шо то до фига 20 кил на документ.
Ничего лишнего. Контрагент, наименование, способ оплаты, дата поставки, договор, валюта. И по товарам наименование, штрих-код, цена, единица измерения, количество, НДС, сумма. И всё это в тэгах.
Видите, даже про этот очевидный момент вы не в курсе.
> Поиск по документам — это запасной вариант для экстренных случаев
> когда время выборки не будет иметь значения.
А мне казалось, что это для тех случаев, когда ваша таблица фактов не позволяет сделать выборку, а не когда её время не имеет значения. Существенную разницу между первым и вторым видите?
А как вы в вашей таблице фактов будете хранить, например, такие факты как «применение оплаты к счетам»? У вас там отдельной строкой будет проводка по оплате, и отдельные строки — её применение к документам?
Ничего лишнего. Контрагент, наименование, способ оплаты, дата поставки, договор, валюта. И по товарам наименование, штрих-код, цена, единица измерения, количество, НДС, сумма. И всё это в тэгах.
Видите, даже про этот очевидный момент вы не в курсе.
> Поиск по документам — это запасной вариант для экстренных случаев
> когда время выборки не будет иметь значения.
А мне казалось, что это для тех случаев, когда ваша таблица фактов не позволяет сделать выборку, а не когда её время не имеет значения. Существенную разницу между первым и вторым видите?
А как вы в вашей таблице фактов будете хранить, например, такие факты как «применение оплаты к счетам»? У вас там отдельной строкой будет проводка по оплате, и отдельные строки — её применение к документам?
я в курсе — я вижу сколько занимает документ у меня в БД.
конечно десятки позиций займут столько места но обычно столько не набивают.
Закупка на склад может быть но продажи — обычно одна две позиции. Система не для супермаркетов.
в таблице документов есть отдельное поле — статус. Проведен, оплачен, утвержден и т.д.
конечно десятки позиций займут столько места но обычно столько не набивают.
Закупка на склад может быть но продажи — обычно одна две позиции. Система не для супермаркетов.
«применение оплаты к счетам»
в таблице документов есть отдельное поле — статус. Проведен, оплачен, утвержден и т.д.
таки провел проверку — сто тыщ доков с пятью позициями.
размер таблицы около 60 мегабайт
поиск LIKE по двум тегам отработал 4.9 сек.
но это на моем не первой свежести офисном компе с дефолтовой настройкой mysql.
на нормальном железе в секунду-две запросто впишется.
размер таблицы около 60 мегабайт
поиск LIKE по двум тегам отработал 4.9 сек.
но это на моем не первой свежести офисном компе с дефолтовой настройкой mysql.
на нормальном железе в секунду-две запросто впишется.
поиск LIKE по двум тегам отработал 4.9 сек.
Серьезно? На 60мб данных? Это, прямо скажем, отвратительно.
на офисном 32х компе с двумя ядрами и mysql под денвером
на нормальном серваке время будет сопоставимо с временем загрузки страницы.
опять же это запрос нештатный.
обычный запрос по таблице фактов = 0.05 сек
на нормальном серваке время будет сопоставимо с временем загрузки страницы.
опять же это запрос нештатный.
обычный запрос по таблице фактов = 0.05 сек
на офисном 32х компе с двумя ядрами и mysql под денвером
Да какая разница? Это неприемлемо медленно для СУБД.
на нормальном серваке время будет сопоставимо с временем загрузки страницы.
Угу, осталось понять, у всех ли заказчиков будут «нормальные серваки».
вы же на малый и средний бизнес ориентируетесь? Откуда у них «нормальные» серваки возьмутся? Скорее всего все это добро будет стоять на каком-нибудь десктопе с каким core i3.
Я не понимаю почему вы не понимаете очевидного. Ваша идея по совмещению реляционной модели и nosql не нова. Просто вместо кастылей обычно применяют чуть более разумные решения, вроде… часть данных хранится в mysql и для выборок агрегируются данные в другой СУБД которая больше для этого подходит. Всякие там elastic search идеально подходят для таких вещей.
Я не понимаю почему вы не понимаете очевидного. Ваша идея по совмещению реляционной модели и nosql не нова. Просто вместо кастылей обычно применяют чуть более разумные решения, вроде… часть данных хранится в mysql и для выборок агрегируются данные в другой СУБД которая больше для этого подходит. Всякие там elastic search идеально подходят для таких вещей.
вы же на малый и средний бизнес ориентируетесь?
в 1С кастомного поиска нет ВООБЩЕ. И как то ведут учет и даже захватили весь рынок. не понимаю откуда проблема.
часть данных хранится в mysql и для выборок агрегируются данные в другой СУБД
нет смысла делать проект пстым если там будут две субд. особенно если одна из них будет использоватся только по большим праздникам.
Скорее всего все это добро будет стоять на каком-нибудь десктопе с каким core i3.
а если туда 1С8 поставить? думаете быстрее моего добра работать будет?
я кстати тестировал вообще на
AMD Athlon(tm) II X2 250
Я никогда не работал с 1C8, но зато у меня есть опыт в проектировании архитектур систем автоматизации, CRM и прочем шлаке. И я не вижу ровным счетом никаких проблем с тем что бы организовать все адекватным образом без этих кастылей с xml и like.
в других архитектурах это были бы костыли. здесь нет — здесь оно в комплексе с остальными решениями. Тут костыли как раз nosql и прочие прибамбасы.
есть определенная идеология проекта и быстродействие тут не главное.
1с7.7 завоевала рынок используя как хранилище данных DBF файлы.
есть определенная идеология проекта и быстродействие тут не главное.
1с7.7 завоевала рынок используя как хранилище данных DBF файлы.
здесь нет — здесь оно в комплексе с остальными решениями.
Да те же костыли. Нет ровным счетом никаких аргументов ни за то, чтобы использовать псевдоструктурированные данные, ни за то, чтобы делать по ним поиск без использования встроенной функциональности СУБД.
аргументы есть — просто вы их услышать не хотите. Этот поиск — дополнительный бонус. В 1с работают и без него. Просто упаковка в XML вместо сериализации дает такую возможность — в журнале документов добавить поле для произвольного текста.
будет тормозить уберу и все.
.
будет тормозить уберу и все.
.
Просто упаковка в XML вместо сериализации дает такую возможность — в журнале документов добавить поле для произвольного текста.
Для поля для произвольного текста XML не нужен. Более того, в такой формулировке это ваше решение с XML не решает (простите) заявленную в посте задачу хранения разнородных документов в одной таблице.
будет тормозить уберу и все.
Без потери функциональности?
Для поля для произвольного текста XML не нужен.
тогда вернется много лишнего, особенно если буду какуюто цифру искать. в том то и суть что теги позволяют указать конкретное имя атрибута документа.
не решает (простите) заявленную в посте задачу хранения разнородных документов в одной таблице.
пока с теми документами что уже сделал (склад, закупки, продажи, малоценка) решает. не вижу пролбемы почему дальше не решит
Без потери функциональности?
функциональность — это поиск как дополнительная фича. Зато с сериализацией размер Бд буде меньше.
вообще поиск тут нужен не столко для пользователя сколько для внедренца — выискать какие то проблемные данные.
впрочем програмер может доки и по аналитике отсеять. Да, подумаю может таки сэкономлю размер БД, применив сериализацию. Пользаки все равно не запомнят что такое тэг в XML. просто текст, согласен и по сериализованому вернется. тем более что я пишу не только id а и названия бизнес сущностей.
кароче считайте что XML нет — а то вы наверно и по ночам не спите так переживаете :)
неважно. В статье это просто как идея которая может кому то пригодится в другой системе., в документообороте например. Для того и статья. Сериализация и так очевидное решение.
тогда вернется много лишнего, особенно если буду какуюто цифру искать.
Какую цифру? Мы же о произвольном тексте говорим.
пока с теми документами что уже сделал (склад, закупки, продажи, малоценка) решает.
И насколько различна структура тех документов, которые вы храните в одной таблице? Сколько их атрибутов хранится только в XML?
функциональность — это поиск как дополнительная фича
А я-то думал, что функциональность — это расширяемость атрибутивного состава документов без изменения структуры БД.
Сериализация и так очевидное решение.
Хранение в XML — это тоже сериализация. И да, это настолько очевидное решение, что у адекватных БД давно есть встроенная поддержка в том или ином виде, только вы ее игнорируете.
Какую цифру? Мы же о произвольном тексте говорим.
количество товара тоже текст но \то цифра
И насколько различна структура тех документов, которые вы храните в одной таблице? Сколько их атрибутов хранится только в XML?
ну, как например отличается договор, накладная и начисление амортизации.
хранятся все атрибуты кроме самых общих — номер дока, его тип, статус, общая сумма.
А я-то думал, что функциональность — это расширяемость атрибутивного состава документов без изменения структуры БД.
так и есть. Это ОСНОВНАЯ функциональность. Поиск как бонус.
Хранение в XML — это тоже сериализация.
имелась ввиду сериализация обьекта в PHP/
адекватных БД давно есть встроенная поддержка
да, только синтаксис разный. А я хочу сохранить переносимость. Как минимум на том уровне что обеспечивает ADODB
количество товара тоже текст но \то цифра
Нет, количество товара — это число.
хранятся все атрибуты кроме самых общих — номер дока, его тип, статус, общая сумма.
То есть, скажем, даты открытия/закрытия — хранятся только в XML?
так и есть. Это ОСНОВНАЯ функциональность
Из ваших объяснений так и не понятно, какой объем расширений вы планируете так поддерживать.
А я хочу сохранить переносимость.
Зачем?
Нет, количество товара — это число.
для аналитики — число, для просмотра и печати -текст
скажем, даты открытия/закрытия
для изменения состояния документа есть отдельная таблица аудита где хранятся оные даты.
хотя эти даты в вычислениях не учавтсвуют и вполне могут хранится только в XML
Из ваших объяснений так и не понятно, какой объем расширений вы планируете так поддерживать.
.с точки зрения документов — любой.
Зачем?
ну например внедренец захочет заюзать mssql или оракл. например у клиента уже будет один сервер БД он скажет на фига мне еще mysql
тем более это ничего не стоит — просто использовать правильно adodb
для аналитики — число, для просмотра и печати -текст
Всегда число. Оно в доменной модели число. То, что оно для печати форматируется как-то, на домен не влияет.
для изменения состояния документа есть отдельная таблица аудита где хранятся оные даты.
А если эта дата не входит в то, что вы считаете состоянием документа?
с точки зрения документов — любой.
Суммы и даты тоже?
например у клиента уже будет один сервер БД он скажет на фига мне еще mysql
У вас же легкая инсталляция, нет?
тем более это ничего не стоит — просто использовать правильно adodb
Это стоит как минимум тестирования на всех поддерживаемых БД. Вы это делаете?
Всегда число. Оно в доменной модели число. То, что оно для печати форматируется как-то, на домен не влияет.
это теоритизирование не имеет никакого отношения к конкретно этому проекту.
Суммы и даты тоже?
да.
мне надоело ходит по кругу ы хотите мнея гдле то подловить перекрестным допросом? Не тратьте время — я знаю что делаю
У вас же легкая инсталляция, нет?
да. и даже можно без инсталяции — скопировать WAMP сервер с проектом.
Но кто то возможно захочет внедрить там где mysql не подходит. Переносимость в данном случае не требует дополнительного кодирования. Это как бонус, так же как с поиском.
Это стоит как минимум тестирования на всех поддерживаемых БД. Вы это делаете?
Теоретически тестирование не нужно — это обеспечивает ADODB/ Но могут быть нюансы конечно.
В любом случае я не говорю что система переносима (я не создавал sql скрипты по другие БД) Я говорю что система может быть легко портируема на другой сервер БД. Теоретически — без изменения исходников. Но это не такая существенная фича чтобы тратить время на проверку.
это теоритизирование не имеет никакого отношения к конкретно этому проекту.
Имеет, и вполне конкретное. Это та самая проблема типизации, которую вы игнорируете.
Теоретически тестирование не нужно — это обеспечивает ADODB
Зато практически нужно (это говорит человек, который регулярно видит различные баги на системе, работающей с MySQL и MS SQL).
В любом случае я не говорю что система переносима (я не создавал sql скрипты по другие БД) Я говорю что система может быть легко портируема на другой сервер БД. Теоретически — без изменения исходников. Но это не такая существенная фича чтобы тратить время на проверку.
Пока эта «фича» не проверена, ее не существует.
в журнале документов добавить поле для произвольного текста
Может вам в сторону MongoDB посмотреть?
суть хорошей архитектуры в том, что с оной мы можем решить сильно позже, где и как будут храниться наши данные и как мы будем делать выборки.
В вашем случае вы сознательно на раннем этапе проектирования системы делаете конкретный выбор в сторону конкретного способа хранения данных и соответственно все проблемы связанные с этим закладываются в фундамент вашей архитектуры.
Поймите, я считаю что если это будет работать, то почему бы и да, тем более что производительность для вас на втором месте. Я просто не понимаю этой зацикленности, как будто бы это самая крутая штука в приложении. Но если мы планируем хорошую архитектуру, решение использовать xml + like или nosql хранилище мы должны принимать в последнюю очередь.
В вашем случае вы сознательно на раннем этапе проектирования системы делаете конкретный выбор в сторону конкретного способа хранения данных и соответственно все проблемы связанные с этим закладываются в фундамент вашей архитектуры.
Поймите, я считаю что если это будет работать, то почему бы и да, тем более что производительность для вас на втором месте. Я просто не понимаю этой зацикленности, как будто бы это самая крутая штука в приложении. Но если мы планируем хорошую архитектуру, решение использовать xml + like или nosql хранилище мы должны принимать в последнюю очередь.
вы тоже не хотите услышать — см коментарий выше. Забудте вообще про поиск.
упаковка в xml универсальное не зависящее от структуры документа способ хранить данные которые нужны не для вычислений а для обработки атрибутов документа. Все потроха тима имени и адреса кантрагента могу туда воткнуть и будет под руками при печати.
Для бизнес-данных — таблица фактов.
расширятся будет если когда то добавится новая бизнес-сущность в систему.
суть в том что в систему может быть добавлен любой документ или отчет без изменения структуры БД.
скопировал в папку сайта пару файлов прописал в пункт меню и все.
упаковка в xml универсальное не зависящее от структуры документа способ хранить данные которые нужны не для вычислений а для обработки атрибутов документа. Все потроха тима имени и адреса кантрагента могу туда воткнуть и будет под руками при печати.
Для бизнес-данных — таблица фактов.
расширятся будет если когда то добавится новая бизнес-сущность в систему.
суть в том что в систему может быть добавлен любой документ или отчет без изменения структуры БД.
скопировал в папку сайта пару файлов прописал в пункт меню и все.
суть в том что в систему может быть добавлен любой документ
Не может, если у него есть не-текстовые поля.
шо то не припомню учетных документов с нетекстовыми полями. как люди вели учет без компов?
кстати в системе предусмотрен атач стороних документов, pdf или сканов оригиналов например. как доп фича разумеетя. к хранению первички это не относится
кстати в системе предусмотрен атач стороних документов, pdf или сканов оригиналов например. как доп фича разумеетя. к хранению первички это не относится
шо то не припомню учетных документов с нетекстовыми полями.
Даты, суммы — нетекстовые поля. Связи с другими сущностями — семантически нетекстовые поля.
как люди вели учет без компов?
Медленно.
Даты, суммы — нетекстовые поля. Связи с другими сущностями — семантически нетекстовые поля.
в данном случае текстовые птому что используются как текст.
то что используется как суммы даты и ссылки — в таблице аналитики.
в данном случае текстовые птому что используются как текст.
То есть вы суммы складываете как текст (=конкатенируете)? По датам сортируете как по тексту (т.е., в лексикографическом порядке)?
то что используется как суммы даты и ссылки — в таблице аналитики.
То есть при добавлении в документ новой суммы/даты/ссылки — структура аналитической таблицы должна поменяться?
То есть вы суммы складываете как текст (=конкатенируете)? По датам сортируете как по тексту (т.е., в лексикографическом порядке)?
это выполняется в таблицах аналитики — там поля соответствующего типа.
структура аналитической таблицы должна поменяться?
с какого перепугу?
в аналитике хранятся движения по синтетическим и аналитическим счетам.
и по ним выполняются вычисления остатков и оборотов.
если это ссылка на товар, контрагента и т.д.
это будет измерение в таблице аналитики — оно там уже есть.
Если это какая то специфична дата/ссылка для документа она в нем и хранится в упакованом виде.
с какого перепугу?
С такого, что вы выше пишете, что даты и суммы хранятся в таблицах аналитики.
в аналитике хранятся движения по синтетическим и аналитическим счетам.
И больше ничего?
С такого, что вы выше пишете, что даты и суммы хранятся в таблицах аналитики.
в тех же полях независимо от типа документа
И больше ничего?
а больше ничего и не надо для УЧЕТНОЙ системы
.
а больше ничего и не надо для УЧЕТНОЙ системы
Видимо, у вас очень ограниченное понятие учетной системы. Например, для системы учета федерального имущества, находящегося в ведении правообладателя, нужно совсем другое.
для системы учета федерального имущества, находящегося в ведении правообладателя, нужно совсем другое.
Я не делаю проект для учета имущества.
Проект для бухгалтерского и складского учета в пределах стандартного функционала 1С. И уж точно не для федеральных органов.
вы бы еще андронный колайдер сюда приплели
А правообладателем федерального имущества не обязан быть федеральный орган. Более того, это имущество вполне может быть на складе.
Складской учет, говорите? А в складском учете бывают такие странные вещи как «Дата истечения срока годности» и «Предполагаемая дата следующей поставки». Их вы как предлагаете обрабатывать?
Складской учет, говорите? А в складском учете бывают такие странные вещи как «Дата истечения срока годности» и «Предполагаемая дата следующей поставки». Их вы как предлагаете обрабатывать?
так же как в 1С — никак.
Это задача кладовщика.
и не путайте учетную систему с планированием ресурсов.
Это задача кладовщика.
и не путайте учетную систему с планированием ресурсов.
Ну то есть заказчик, которому нужно, чтобы за его склад отвечала одна система, в ней велся складской учет (что бы вы под этим ни понимали), а так же учитывались сроки годности, на вашу платформу может не смотреть?
да, есть специфические типы учета
Например в аптеках.
Сам по себе учет никак не зависит от срока годности но програма должна преупреждать о том что такие товары есть и надо лезть на полку выкидывать их.
стандатно там и 1С не пойдет. Подпилить напильником -и я могу в принципе,
но зачем пытатся обьять необьятное.
рестораны тоже имеют свою специфику.
и что мне рецептуру блюд засовывать чтобы расходы считать?
.
Например в аптеках.
Сам по себе учет никак не зависит от срока годности но програма должна преупреждать о том что такие товары есть и надо лезть на полку выкидывать их.
стандатно там и 1С не пойдет. Подпилить напильником -и я могу в принципе,
но зачем пытатся обьять необьятное.
рестораны тоже имеют свою специфику.
и что мне рецептуру блюд засовывать чтобы расходы считать?
.
Вам — нет. Но платформа должна это позволять, причем без существенной потери производительности (как разработки, так и времени выполнения), чтобы разработчик, которому такая задача прилетела от бизнеса (или который решил покрыть этот сегмент бизнеса), смог это реализовать без костылей.
моя не должна
я не собираюсь перекрывать весь сегмент для 1с, CRM и прочего.
кому приспичит или хорошо заплатят — добавит поле в таблицу документов и все дела.
считайте что подпилить саму платформу — дополнительная фича, котрой нет у разрабов конфигураций 1С.
я исхожу из принципа Парето. Пусть остальные 20% остаются на 1С.
я не собираюсь перекрывать весь сегмент для 1с, CRM и прочего.
кому приспичит или хорошо заплатят — добавит поле в таблицу документов и все дела.
считайте что подпилить саму платформу — дополнительная фича, котрой нет у разрабов конфигураций 1С.
я исхожу из принципа Парето. Пусть остальные 20% остаются на 1С.
Между прочим, у 1С есть модуль учета имущества.
а больше ничего и не надо для УЧЕТНОЙ системы
Это все шикарно, но есть одна проблема. Как то раз нам заказали простенькую систему учета движения документов в административной комиссии. По ТЗ она задумывалась крайне просто: входящие, исходящие, внутренние и пара проводок — вот весь функционал. После года эксплуатации число запросов новых функций переросло в отдельное ТЗ, которое мы успешно закрыли. На следующий год история повторилась. К чему это я? Вы клиенту не сможете объяснить — простите, но это учетная система, тут такого сделать нельзя — клиент просто уйдет к конкуренту, у которого можно. Как думаете, почему 1С выпустили Битрикс? Ведь сайты для бухгалтеров тоже не край как нужны.
в вашем случае это система документооборота.
Я клиенту делаю то что делает бухгалтерская или складская учетная система. А битрикс это сорее инет магазин интегрированй с 1С она действительно не нужна бухгалтерам.
Она нужна тем у кого электронная комерция и ведение учета в 1С. А обмен данными сайтов с 1с — стандартный гемор — пройдитесь п форумам.
Я клиенту делаю то что делает бухгалтерская или складская учетная система. А битрикс это сорее инет магазин интегрированй с 1С она действительно не нужна бухгалтерам.
Она нужна тем у кого электронная комерция и ведение учета в 1С. А обмен данными сайтов с 1с — стандартный гемор — пройдитесь п форумам.
Да хоть тролейбусом это назовите. Клиент завтра вас спросит:
Вы ему скажате:
В лучшем случае клиент молча начнет искать новую систему в которой «можно».
Да не важно нужна она или нет, клиент скажет вам — надо — и вы должны ему это прикрутить, причем прямо в систему, чтоб и данные оттуда брало и новые кнопочки добавить можно было. Это не вопрос — зачем 1С выпустил Битрикс? — это вопрос — понимаете как клиенты запарили 1С, что они решились выпустить Битрикс?
дорогой мой caballero, мне нужно что вот здесь была кнопочка по нажатию на которую, система разашлет всем лицам из справочника «клиенты» поздравление с новым годом. Это можно сделать?
Вы ему скажате:
нет, ибо моя система на это не расчитана, если вам это нужно, купите вот еще эту и эту систему, и тогда это можно будет сделать.
В лучшем случае клиент молча начнет искать новую систему в которой «можно».
А битрикс это сорее инет магазин интегрированй с 1С она действительно не нужна бухгалтерам
Да не важно нужна она или нет, клиент скажет вам — надо — и вы должны ему это прикрутить, причем прямо в систему, чтоб и данные оттуда брало и новые кнопочки добавить можно было. Это не вопрос — зачем 1С выпустил Битрикс? — это вопрос — понимаете как клиенты запарили 1С, что они решились выпустить Битрикс?
В лучшем случае клиент молча начнет искать новую систему в которой «можно».
если рассылка поздравлений — основная функция системы то ему не ко мне.
Но в принципе можно. напишу обработку на крон пройдет по справочнику и разошлет.
Еще раз — стандартный функционал у меня не выходит за рамки СТАНДАРТНОГО функционала 1С.
Написать специальный код который че то там делает можно. Так же как и там.
Возможно будет работать неоптимально и медленно — так же как и в 1с от которой пока никто не отказался потому что нельзя разослать открытки клиентам.
если рассылка поздравлений — основная функция системы
Не основная, возможно клиент даже пользоваться ей не будет, просто он увидил у «соседа» эту функцию и тоже хочет.
Возможно будет работать неоптимально и медленно — так же как и в 1с от которой пока никто не отказался потому что нельзя разослать открытки клиентам
А зачем отказываться когда можно за пару тысяч допилить нужный функционал, благо платформа это позволяет и разработчиков уйма )
Ого, длинная ветка комментария получилась. Не буду по статье, так как ниже вероятно уже перемололи косточки, а остановлюсь только на ваших ошибках в этом треде.
Это кто не набивает? Если мы говорим не про бизнес, а про посетителя интернет магазина, то он в своем заказе действительно редко набивает больше 5-6 позиций. А теперь не смотрим на на средний бизнес, а переходим сразу к самым маленьким. Выйдите в киоск под домом за сигаретами/кофем/жвачкой/сникерсом или что вы там обычно покупаете — обратите внимание на разнообразие ассортимента в каждой из категорий; все это добро завозят в киоски в течении недели по несколько раз, но не смотря на это в накладных все равно десятки позиций. У классического мелкого дистрибютора (купил на заводе, развез по магазинам) по несколько сотен заказов в день, в каждом из которых до 20 позиций.
Из бизнеса, которому достаточно документооборота с количеством позиций меньше десяти мне приходят на ум только дорогие бутики, где 10 консультантов, 3 пары женской обуви, 2 сумочки и шарфик, но им даже 1С не подходит (не говоря про ваш опенсорс) — только SAP/R3!
Вы упоминали, что программировали 15 лет назад на 1С7.7. Видимо с тех пор вообще никаких новостей не видели. Универсальный поиск на формах списков появился еще в 8.0, а в 8.1 появился разухабистый полнотекстовый поиск по всем реквизитам объектов (включая реквизиты табличных частей) — последний использует не просто прямое символьное соответствие, а позволяет задавать правила поиска, использует спецсимволы и ключевые слова, а так же ищет по синонимам — делалось по аналогии с поиском информации в яндексе/гугле.
На счет стандартного функционала — только по платформе: работа из коробки под Windows и Linux серверами; наличие 32- и 64-битных сборок, легкая публикация на веб-серверах IIS и Apache, кросс-браузерность, наличие мобильных клиентов под Android, iOs и Windows, использование в качестве СУБД MsSQL, PostgreSQL, IBM DB2 и Oracle. Перечислять же стандартный функционал для разработки прикладных решений и дня не хватит, но пусть тут будет парочка: на базе указанного программистом источника данных, платформа сама генерирует форму отчета, его внешний вид и дает пользователю возможность управлять группировками, сортировками и оформлением; к платформе можно подключить произвольный источник данных, к которому есть ODBC-драйвер, и далее пользователь может работать с данными любой внешней таблицы как со справочником — добавлять/редактировать/удалять произвольные записи, а так же использовать эти значения в реквизитах родных справочников и документов конфигурации.
Планирование ресурсов — это одна из задач учетной системы. В самой первой конфигурации, которую 1С написали, что бы отладить платформу 8.0 (я про УПП 1.0) это уже было реализовано и далее только дорабатывалось.
Неужели вы не видите, как сами себе противоречите? 1С и их партнеры «насочиняли» сотни разных конфигураций для тех же аптек и общепитов, именно для того что бы пользователи могли сесть за рабочее место и им все было понятно и очевидно — только нужные документы, только нужные отчеты, только нужные кнопочки на формах. И никакой путаницы! В результате для конечного потребителя получается очень дешево — вместо того, что бы платить программистам за обучение предметной области, за разработку «велосипеда», за исправление багов, владелец бизнеса просто покупает готовое решение, которое используется уже у сотен тысяч его конкурентов по всей стране и приносит им прибыль (а еще можно сотрудников переманивать, которых даже переучивать не нужно).
я в курсе — я вижу сколько занимает документ у меня в БД.
конечно десятки позиций займут столько места но обычно столько не набивают.
Это кто не набивает? Если мы говорим не про бизнес, а про посетителя интернет магазина, то он в своем заказе действительно редко набивает больше 5-6 позиций. А теперь не смотрим на на средний бизнес, а переходим сразу к самым маленьким. Выйдите в киоск под домом за сигаретами/кофем/жвачкой/сникерсом или что вы там обычно покупаете — обратите внимание на разнообразие ассортимента в каждой из категорий; все это добро завозят в киоски в течении недели по несколько раз, но не смотря на это в накладных все равно десятки позиций. У классического мелкого дистрибютора (купил на заводе, развез по магазинам) по несколько сотен заказов в день, в каждом из которых до 20 позиций.
Из бизнеса, которому достаточно документооборота с количеством позиций меньше десяти мне приходят на ум только дорогие бутики, где 10 консультантов, 3 пары женской обуви, 2 сумочки и шарфик, но им даже 1С не подходит (не говоря про ваш опенсорс) — только SAP/R3!
в 1С кастомного поиска нет ВООБЩЕ. И как то ведут учет и даже захватили весь рынок. не понимаю откуда проблема.
Еще раз — стандартный функционал у меня не выходит за рамки СТАНДАРТНОГО функционала 1С.
Вы упоминали, что программировали 15 лет назад на 1С7.7. Видимо с тех пор вообще никаких новостей не видели. Универсальный поиск на формах списков появился еще в 8.0, а в 8.1 появился разухабистый полнотекстовый поиск по всем реквизитам объектов (включая реквизиты табличных частей) — последний использует не просто прямое символьное соответствие, а позволяет задавать правила поиска, использует спецсимволы и ключевые слова, а так же ищет по синонимам — делалось по аналогии с поиском информации в яндексе/гугле.
На счет стандартного функционала — только по платформе: работа из коробки под Windows и Linux серверами; наличие 32- и 64-битных сборок, легкая публикация на веб-серверах IIS и Apache, кросс-браузерность, наличие мобильных клиентов под Android, iOs и Windows, использование в качестве СУБД MsSQL, PostgreSQL, IBM DB2 и Oracle. Перечислять же стандартный функционал для разработки прикладных решений и дня не хватит, но пусть тут будет парочка: на базе указанного программистом источника данных, платформа сама генерирует форму отчета, его внешний вид и дает пользователю возможность управлять группировками, сортировками и оформлением; к платформе можно подключить произвольный источник данных, к которому есть ODBC-драйвер, и далее пользователь может работать с данными любой внешней таблицы как со справочником — добавлять/редактировать/удалять произвольные записи, а так же использовать эти значения в реквизитах родных справочников и документов конфигурации.
так же как в 1С — никак. Это задача кладовщика.
и не путайте учетную систему с планированием ресурсов.
Планирование ресурсов — это одна из задач учетной системы. В самой первой конфигурации, которую 1С написали, что бы отладить платформу 8.0 (я про УПП 1.0) это уже было реализовано и далее только дорабатывалось.
да, есть специфические типы учета
Например в аптеках…
рестораны тоже имеют свою специфику.
и что мне рецептуру блюд засовывать чтобы расходы считать?
там ща наплодили десятки конфигураций которые друг друга на три четверти дублируют но почему то отличаются внутренним интерфейсом.
Одна из причин почему стало сложнее и дороже с 1С.
С семеркой было гораздо проще.
Неужели вы не видите, как сами себе противоречите? 1С и их партнеры «насочиняли» сотни разных конфигураций для тех же аптек и общепитов, именно для того что бы пользователи могли сесть за рабочее место и им все было понятно и очевидно — только нужные документы, только нужные отчеты, только нужные кнопочки на формах. И никакой путаницы! В результате для конечного потребителя получается очень дешево — вместо того, что бы платить программистам за обучение предметной области, за разработку «велосипеда», за исправление багов, владелец бизнеса просто покупает готовое решение, которое используется уже у сотен тысяч его конкурентов по всей стране и приносит им прибыль (а еще можно сотрудников переманивать, которых даже переучивать не нужно).
вы не первый здесь кто пытается доказать что 1с решает все проблемы, решает дешево, не имеет недостатков и сколько не ройся по бухгалтерским форумам не найдешь ни одного пользователя который бы жаловался на 1С.
Не будем начинать дискусию по второму кругу.
Не будем начинать дискусию по второму кругу.
Еще раз — стандартный функционал у меня не выходит за рамки СТАНДАРТНОГО функционала 1С.
Какой из конфигураций 1С? Срок годности товара входил в базовую конфигурацию «торговля и склад» ещё в 7.7, за счет чего она, кстати, вытеснила многих конкурентов.
xml поля с xpath запросами — это и есть чистой воды nosql. Вопрос выбора хранить документы или в xml в postgre, или в xml в basex, или в json в postgre, или в json в mongo — это вопрос выбора костыля, если основная база реляционная.
Тупое = у мускуля по текстовому полю на однобайтовом значении на порядка 50 млн записей (средний бизнес за 5 лет нагенерировал фктов) занял вот прямо сейчас специально для вас на сервере с 32 гигами оперативки больше минуты.
Поддержка xpath на уровне запросов лишь синтаксический сахар по сути для поиска по текстовому полю, куда важнее поддержка его на уровне индексов, чтобы не было фулл-скана таблицы.
Поддержка xpath на уровне запросов лишь синтаксический сахар по сути для поиска по текстовому полю, куда важнее поддержка его на уровне индексов, чтобы не было фулл-скана таблицы.
и часто вы ищете по документам за пять лет?
в реальности разумеется будет выбран какой то период за последнее время. Ну и тип документа будет указан а не тупо по всем подряд
а если уж кому надо найти документ из его молодости то уж как нибудь минуту подождет
в реальности разумеется будет выбран какой то период за последнее время. Ну и тип документа будет указан а не тупо по всем подряд
а если уж кому надо найти документ из его молодости то уж как нибудь минуту подождет
В общето «open source» вполне себе может быть «за деньги». Открытое ПО != бесплатное ПО
Открытое ПО != бесплатное ПО
да, один из вариантов монетизации
можно зарабатывать на внедрении, саппорте, консультациях, посещении оф. сайта проекта, какое нибудь хитрое лицензироание т.д.
Иногда это просто имя в айтишном мире с вытекающим отсюда возможностями. вариантов много. Че об этом думать, сначала надо проект до ума довести.
Если бы я бросил работу и вложил кучу бабла в проект тогда бы переживал по этому поводу.
Вот что я только что прочитал?
Нет, честно. Давайте уже смеритесь с тем, что 1С — решает бизнес логику, а всякие вои там веб интерфейсы вы можете приклееть к 1С через http сервисы, даже протокол OData есть. И лепите себе там всякое, что душа пожелает.
Но оставьте в покое 1С. Вы все время говорите о том, что 1С крупная компания и с ней нет смысла тягаться, но тягаетесь, так как всегда ставите заведомо 1С на равне с вашим решением.
Например, про программиста и счета — позвать 1С программиста и php — это как бы разные вещи.
Поймите наконец, у 1С преимущество не в платформе, отчетностях, деньгах. А в том, что у 1С армия разработчиков, т.е. вы в любом захолустье найдете программиста 1С.
А у всех аналогов 1С — один ключевой недостаток, причем для клиентов — если ваш проект аналогов загнется, то клиент будет просто у разбитого корыта.
Плюс — обучение и т.д. Вот сила 1С, а не ее конфигуратор, или гибкость/не гибкость.
Нет, честно. Давайте уже смеритесь с тем, что 1С — решает бизнес логику, а всякие вои там веб интерфейсы вы можете приклееть к 1С через http сервисы, даже протокол OData есть. И лепите себе там всякое, что душа пожелает.
Но оставьте в покое 1С. Вы все время говорите о том, что 1С крупная компания и с ней нет смысла тягаться, но тягаетесь, так как всегда ставите заведомо 1С на равне с вашим решением.
Например, про программиста и счета — позвать 1С программиста и php — это как бы разные вещи.
Поймите наконец, у 1С преимущество не в платформе, отчетностях, деньгах. А в том, что у 1С армия разработчиков, т.е. вы в любом захолустье найдете программиста 1С.
А у всех аналогов 1С — один ключевой недостаток, причем для клиентов — если ваш проект аналогов загнется, то клиент будет просто у разбитого корыта.
Плюс — обучение и т.д. Вот сила 1С, а не ее конфигуратор, или гибкость/не гибкость.
во первых проект опенсорс. Гораздо хуже сидеть «на игле» у 1С и платить бабло за каждое изменение или ждать пока дистрибутор выпустит обновление. И хорошо если не менял чтото в конфигурации иначе плати програмерам чтобы мержили…
Во вторых что это за аргумент — армия разработчиков? Зачем придумали яву — на С++ армия разработчиков. Зачем придумали PHP — на яве — армия разработчиков. Заем придумали опенофис — с майкрософтом тягаться вздумали?
Во вторых что это за аргумент — армия разработчиков? Зачем придумали яву — на С++ армия разработчиков. Зачем придумали PHP — на яве — армия разработчиков. Заем придумали опенофис — с майкрософтом тягаться вздумали?
А разве 1С скрывает исходники своих конфигураций? Это тоже опенсорс, хоть и проприетарный.
> И хорошо если не менял чтото в конфигурации иначе плати програмерам чтобы мержили…
В предлагаемом вами решении саппорт/кастомизация ведь не бесплатные будут, верно? Это тоже работа программеров.
> И хорошо если не менял чтото в конфигурации иначе плати програмерам чтобы мержили…
В предлагаемом вами решении саппорт/кастомизация ведь не бесплатные будут, верно? Это тоже работа программеров.
возможно и бесплатно — например будет комунити которое на гитхабе оперативно скоректирует логику после изменения законодательства. А заменить отдельный файл в приложении не составит труда даже среднему юзеру.
Но даже если небесплатно — веб програмер гораздо дешевле програмера 1С. С учетом что изменения вносить проще (изза простоты системы) — еще в два раза дешевле.
Но даже если небесплатно — веб програмер гораздо дешевле програмера 1С. С учетом что изменения вносить проще (изза простоты системы) — еще в два раза дешевле.
> Но даже если небесплатно — веб програмер гораздо дешевле програмера 1С.
Веб-программер гораздо дешевле программера 1С исключительно потому, что программер 1С понимает и умеет использовать такие неведомые веб-разработчикам штуки, как «проводки», «план счетов», «амортизация» и т.д. Ставя задание 1Снику, клиент будет говорить: «Нам нужно, чтобы товары, приобретаемые от клиентов из категории „велосипеды“, проходили только по управленке, с возможностью реализации только за нал». Ставя задачу веб-разработчику, клиенту нужно рассказывать: «Здесь в поле „Тип учёта“ нужно проставлять флаг „управленческий“, если клиент находится в группе такой-то, при этом при продаже проверять метод оплаты, и запрещать проводить накладную, если в строках есть хоть один товар, партия которого имеет тип учета „управленческий“, а метод оплаты накладной равен „безналичная оплата“. И у клиента в штате при этом должен быть хоть один человек, способный это сформулировать. А как только веб-разработчик будет знать эту предметную область, уж поверьте, его стоимость труда сразу заметно вырастет.
> С учетом что изменения вносить проще
А за счет чего проще? Поля в реляционной СУБД как-то сложнее добавляются, чем в этом ОРМ?
Веб-программер гораздо дешевле программера 1С исключительно потому, что программер 1С понимает и умеет использовать такие неведомые веб-разработчикам штуки, как «проводки», «план счетов», «амортизация» и т.д. Ставя задание 1Снику, клиент будет говорить: «Нам нужно, чтобы товары, приобретаемые от клиентов из категории „велосипеды“, проходили только по управленке, с возможностью реализации только за нал». Ставя задачу веб-разработчику, клиенту нужно рассказывать: «Здесь в поле „Тип учёта“ нужно проставлять флаг „управленческий“, если клиент находится в группе такой-то, при этом при продаже проверять метод оплаты, и запрещать проводить накладную, если в строках есть хоть один товар, партия которого имеет тип учета „управленческий“, а метод оплаты накладной равен „безналичная оплата“. И у клиента в штате при этом должен быть хоть один человек, способный это сформулировать. А как только веб-разработчик будет знать эту предметную область, уж поверьте, его стоимость труда сразу заметно вырастет.
> С учетом что изменения вносить проще
А за счет чего проще? Поля в реляционной СУБД как-то сложнее добавляются, чем в этом ОРМ?
Веб-программер гораздо дешевле программера 1С исключительно потому, что программер 1С понимает и умеет использовать такие неведомые веб-разработчикам штуки, как «проводки», «план счетов», «амортизация» и т.д
если вебпрограмист займется саппортом то уж как нибудь он разберется с проводками. Особенн с учетом того что здесь с ними работать гораздо проще. А если изменения не заточены на конкретный бизнес — то достаточно чтобы это сделал кто то один — остальные просто скопируют нужный файлик.
А за счет чего проще? Поля в реляционной СУБД как-то сложнее добавляются, чем в этом ОРМ?
это не ОRМ. Точнее это такой же ORM как 1C
Вы ж не добавляете в 1С поля в БД вручную?
Вот и здесь — никто никакие поля не добавляет -добавляются атрибуты документов и справочников. С учетом что PHP слаботипизированный язык и добавления как такового нет — просто добавляете элемент в асоциативный массив. То есть не нужен никакой визуальный мастер.
.
Вот и здесь — никто никакие поля не добавляет -добавляются атрибуты документов и справочников.
… и как это отражается в БД?
Автоматически (в базовом классе документа) упаковывается в XML
Я понимаю что сложно представить ситему не требующую расширения БД но именно так я и проектировал — иначе нет смысла.
По той же причине я использую библиотеку ADODb которая автоматом генерит SQL запросы. Причем не тупо генерит а сравнивает асоциативный массив со структурой таблицы и генерит совпадающие поля с учетом типов.
На ее основе построен класс Entity по шаблону Active Record. от которого наследуются все бизнес-сущности.
Иными словами, в системе практически не используются прямые SQL запросы.
То есть здесь не просто сайт на PHP — тщательно подобран стек технологий.
То же касается самого сайта — в основе компонентный не MVC фреймворк который обеспечивает персистентность страницы после переагрузки.
То есть програмер работает как на делфи или .NET WebForms — через компоненты которые генерят события (нажатие на кнопку, переход по ссылке)
Разраб просто пишет бизнес-логику в обработчиках.
Ну и т. д.
Я понимаю что сложно представить ситему не требующую расширения БД но именно так я и проектировал — иначе нет смысла.
По той же причине я использую библиотеку ADODb которая автоматом генерит SQL запросы. Причем не тупо генерит а сравнивает асоциативный массив со структурой таблицы и генерит совпадающие поля с учетом типов.
На ее основе построен класс Entity по шаблону Active Record. от которого наследуются все бизнес-сущности.
Иными словами, в системе практически не используются прямые SQL запросы.
То есть здесь не просто сайт на PHP — тщательно подобран стек технологий.
То же касается самого сайта — в основе компонентный не MVC фреймворк который обеспечивает персистентность страницы после переагрузки.
То есть програмер работает как на делфи или .NET WebForms — через компоненты которые генерят события (нажатие на кнопку, переход по ссылке)
Разраб просто пишет бизнес-логику в обработчиках.
Ну и т. д.
Автоматически (в базовом классе документа) упаковывается в XML
Угу. То есть все реляционные действия недоступны. Вот захотел я добавить новое числовое поле, чтобы потом по нему делать суммы — фиг. Захотел добавить новую дату для условий фильтрации — фиг. Захотел добавить новый классификатор. и по нему делать выборки — фиг. Ну то есть нет, можно достать в клиент и в нем обработать — но прощай производительность.
Я понимаю что сложно представить ситему не требующую расширения БД
Да нет, ничего сложного, имя им легион. Вопрос того, какие компромисы туда заложены.
Вот захотел я добавить новое числовое поле, чтобы потом по нему делать суммы — фиг
Вообще то атрибуты первичных документов и справочников — общеприняты. Пока что мне ни разу не понадобилось добавит какое то экзотическое поле чтобы по нему что то вычислять.
Подобные костыли нужны как раз в системах негибких где все надо зардкодить включая поля в таблицах БД.
Любые бизнес-данные выбираются с таблиц аналитики.
А представте как люди работают с прогами писаными на делфи где вообще ничего не добавишь.
Речь идет о компромисном варианте.
Опять же напомню ориентация на небольшой бищне где не нужны какието выкрутасы.
Да нет, ничего сложного, имя им легион. Вопрос того, какие компромисы туда заложены.
скажем так — система проектируется на решение ТИПОВЫХ задач. То есть работу с типовыми стандартными первичными документами и отчетами малого предприятия с несколькими десятками первички в день, не торгующему за валюту, не требуюзему консолидированой отчетности и т. д.
Но в то же время требующего если не бухгалтерского то хотя бы управленческого учета с набором ходовых отчетов типа движение по складу…
.
Вообще то атрибуты первичных документов и справочников — общеприняты. Пока что мне ни разу не понадобилось добавит какое то экзотическое поле чтобы по нему что то вычислять.
«мне не понадобилось — никому не понадобится». В итоге получается, что система легко модифицируема только в одном очень узком направлении.
Любые бизнес-данные выбираются с таблиц аналитики.
Можно подумать, у них нет тех же проблем со структурой.
скажем так — система проектируется на решение ТИПОВЫХ задач.
… и, видимо, эти типовые задачи заморожены во времени.
«мне не понадобилось — никому не понадобится». В итоге получается, что система легко модифицируема только в одном очень узком направлении.
система модифицирована в стандартном направлении. Кому надо узкое — берите 1С или что там. Не встречал бухгалтера который говорит — сделай мне доп. поле с вычислениями. Бухгалтер говорит — реши такую то задаччу.
Можно подумать, у них нет тех же проблем со структурой
Нет пока не добавятся совсем уж новые бизнес-сущности — например управленение проектами.
Но в таком случае изменение БД это ничто по сравнении с тем что надо понаписать.
.… и, видимо, эти типовые задачи заморожены во времени.
Не поверите но некоторые из них заморожены со времен Пачоли. Бухучет исключительно консервативное направление.
система модифицирована в стандартном направлении.
А где «стандарт» — определили вы. Ну да.
Не встречал бухгалтера который говорит — сделай мне доп. поле с вычислениями. Бухгалтер говорит — реши такую то задаччу.
… а задача требует допполя с вычислениями.
А где «стандарт» — определили вы.
Нет. ПСБУ или как их там.
… а задача требует допполя с вычислениями.
задача требует решения. а как мои трудности.
в той первичке что уже успел написать (закупки продажи, малоценка, ОС) ни разу не понадобилось никакого поля.
Нет. ПСБУ или как их там.
О, регламенты и регламентирующие ведомства. У них есть та замечательная особенность, что они иногда меняются, причем в формате «а теперь с первого мартобря все подаем по новому стандарту». Так что тут тем более без модифицируемости не обойдешься.
задача требует решения. а как мои трудности.
… до тех пор, пока выполнены нефункциональные требования заказчика.
в той первичке что уже успел написать (закупки продажи, малоценка, ОС) ни разу не понадобилось никакого поля.
Сколько у вас ушло на это времени?
ну я как бы вынужден на жизнь зарабатывать, ишачить на аутсорсе и все такое.
скажем так — средний первичный документ с ненавороченым, как в налоговой накладной печатной формой, делается за полдня.
Конечно надо понимать архитектуру и предметную облсть Впрочем я просто заглядываю в 1С какие проводки и все такое — так быстрее.
в любом случае быстрее и проще чем в 1С. Хотя сравнение в отрыве от всего остального в комплексе. не имеет смысла.
скажем так — средний первичный документ с ненавороченым, как в налоговой накладной печатной формой, делается за полдня.
Конечно надо понимать архитектуру и предметную облсть Впрочем я просто заглядываю в 1С какие проводки и все такое — так быстрее.
в любом случае быстрее и проще чем в 1С. Хотя сравнение в отрыве от всего остального в комплексе. не имеет смысла.
Конечно надо понимать архитектуру и предметную облсть
… и мы снова к этому возвращаемся.
Но мой вопрос был не к производительности, а к количеству эволюционных изменений, которые вам пришлось внести в уже работающую у заказчика систему.
система в разработке пока. тчнее сама платфма готова но надо понаделывать все первичку отчеты и все такое — в терминах 1С — написать конфигурацию с нуля…
Думаю изменений у заказчика будет не больше чем в случае с 1С. Там в Бд никто не лезет — все работают на языке програмирования через высокоуровневые обьекты. И у меня так же.
Думаю изменений у заказчика будет не больше чем в случае с 1С. Там в Бд никто не лезет — все работают на языке програмирования через высокоуровневые обьекты. И у меня так же.
Угу. Поэтому вы и не можете утверждать, насколько сложно будет ее поддерживать и развивать со временем.
могу потому что она на порядок проще.
То что по факту 1с уже есть програмисты а тут еще конь не валялся — не относятся к обсуждаемой технической стороне.
То что по факту 1с уже есть програмисты а тут еще конь не валялся — не относятся к обсуждаемой технической стороне.
могу потому что она на порядок проще.
Это еще не значит, что ее проще развивать. Если система проста, но в ней не заложена модифицируемость, развивать ее будет дорого.
разумеется заложена иначе нет смысла.
Поэтому система модульная, поэтому изменение бизнес логики не требует изменения структуры Бд и не влияет на остальные части системы.
замена документа новой версией — заменить пару файлов и т.д.
она простая не потому что я взял файл PHP и тупо захардкодил накладную. В большинстве систем которые не имеют как в 1с визуальных редакторов и прочего, так кстати, и делают. Потому они и не развиваются — там черт ногу сломит.
Поэтому система модульная, поэтому изменение бизнес логики не требует изменения структуры Бд и не влияет на остальные части системы.
замена документа новой версией — заменить пару файлов и т.д.
она простая не потому что я взял файл PHP и тупо захардкодил накладную. В большинстве систем которые не имеют как в 1с визуальных редакторов и прочего, так кстати, и делают. Потому они и не развиваются — там черт ногу сломит.
поэтому изменение бизнес логики не требует изменения структуры Бд и не влияет на остальные части системы.
Вы так пишете, как будто это что-то особенное. Хотя это, на самом деле, свойство любой системы с приличной (даже не хорошей) архитектурой. И это все еще не означает, что ее легко развивать.
Мы уже выясняли, скажем, что в вашей системе не заложено механизмов развития любых значимых полей в БД.
Вы так пишете, как будто это что-то особенное.для систем где нет визуальных построителей — таки да особенное.
Иначе надо лазить в Бд. Либо выполнять еще какую мудреную конфигурацию.
А потом вы обновляете документ а он не стыкуется с измененной структрурой.
Мы уже выясняли, скажем, что в вашей системе не заложено механизмов развития любых значимых полей в БД.
все значимые там уже есть.
более того — даже если вы добавите новое поле в таблицу какого нибудь справочника — вы автоматом сможете работать с ним как с атрибутом бизнес-обьекта. Ничего не надо конфигурить ничего не надо дописывать.
просто
$c = new Contragent();
$c->somenewfield = 666;
$c->save();
главное чтобы свойство совпало с именем поля. Никаких изменений в sql никакого маппинга.
Куда уж больше возможностей к расширению.
для систем где нет визуальных построителей — таки да особенное.
Серьезно? Изоляция бизнеса от инфраструктуры — это что-то особенное?
все значимые там уже есть.
Вы не можете этого знать.
более того — даже если вы добавите новое поле в таблицу какого нибудь справочника
То есть все-таки надо будет изменять структуру БД для добавления новых полей?
Куда уж больше возможностей к расширению.
Это тривиальный ORM, вы серьезно это считаете «возможностями к расширению»?
Изоляция бизнеса от инфраструктуры — это что-то особенное?
особенно е то что он РЕАЛЬНО изолирован
Вы не можете этого знать.
могу — у меня достаточно опыта с учетными системами.
То есть все-таки надо будет изменять структуру БД для добавления новых полей?
нет. Я просто написал что даже если вы что то добавите система подхватит это поле и буде с ним работать. но добавлять новые поля к существущей структуре не вижу смысла.
Это тривиальный ORM,
это не ОRМ. нигде не задаются и не конфигурятся реляции между бизнес обьектами.
Вобще как я уже писал бизнес обьекты строятся на паттерне Active Record
Точнее они наследуются от библиотечного который так построен.
особенно е то что он РЕАЛЬНО изолирован
Угу. Можете чем-то подтвердить, что он у вас «реальнее» изолирован, чем во всех других системах?
у меня достаточно опыта с учетными системами.
Он в будущее тоже распространяется?
но добавлять новые поля к существущей структуре не вижу смысла.
Тогда как же изменять структуру данных при эволюции бизнес-требований?
это не ОRМ
То есть вы не маппите таблицы в БД на объекты языка программирования?
нигде не задаются и не конфигурятся реляции между бизнес обьектами.
Это ни на что не влияет.
Вобще как я уже писал бизнес обьекты строятся на паттерне Active Record
Который в широком смысле подвид ORM.
Можете чем-то подтвердить, что он у вас «реальнее» изолирован, чем во всех других системах?
это требует уточнения всез терминов вклюяя переделение критерия излированости.
не собираюсь заниматся казуистикой.
Он в будущее тоже распространяется?
в такой же степени как у разработчиков 1С.
Что за словоблудие ей богу.
То есть вы не маппите таблицы в БД на объекты языка программирования?
я просто указываю в обьекте имя таблицы и имя ключевого поля.
с полями он само разбирается. Но в любом случае ОРМ тут ни причем. я не задаю реляции между обьектами.
Это ни на что не влияет.это влиячет на определение ОРМ или нет.
Который в широком смысле подвид ORM.
по моему вы просто придираетесь
считаете что у меня просто ОРМ. не вопрос
Возьмите напрмер .NET TF и назовите его готовой учетной системой.
вы придираетесь непонятно к чему и главное непонятно зачем.
это требует уточнения всез терминов вклюяя переделение критерия излированости.
Ну тогда и не говорите, что у вас система проще и в ней легче вносить изменения.
с полями он само разбирается. Но в любом случае ОРМ тут ни причем. я не задаю реляции между обьектами.
Это не имеет отношения к тому, ORM это или нет.
это влиячет на определение ОРМ или нет.
Нет.
считаете что у меня просто ОРМ. не вопрос
Нет. Я считаю, что та функциональность, которую вы описываете как достоинство — это обычный ORM, и, как следствие, я не понимаю, как он может давать вам те преимущества, которые вы заявляете.
Вобще как я уже писал бизнес обьекты строятся на паттерне Active Record
Который в широком смысле подвид ORM
Проекция реляционной структуры в объекты и объектный интерфейс это не одно и тоже. Первое это ORM, второе это AR.
Это неоднозначный вопрос. В широком смысле слова ORM — это любая технология, которая отражает реляционную БД на прикладную (в противовес generic table) структуру. Дальше уже есть детали, которые разделяют AR и Mapper.
В широком смысле слова ORM
Это ваше мнение, или вы цитируете?
en.wikipedia.org/wiki/Object-relational_mapping
Далее, en.wikipedia.org/wiki/Active_record_pattern: «This pattern is commonly used by object persistence tools, and in object-relational mapping (ORM).»
Далее, en.wikipedia.org/wiki/Active_record_pattern: «This pattern is commonly used by object persistence tools, and in object-relational mapping (ORM).»
Вика? Серьезно?
Давайте мы лучше обратимся к основоположнику AR и AT моделей, товарищу Фаулеру, который ясно сообщает:
Как видно никакого «Объектно-реляционного отображения» здесь нет.
Давайте мы лучше обратимся к основоположнику AR и AT моделей, товарищу Фаулеру, который ясно сообщает:
Шлюз записи данных выступает в роли объекта, полностью повторяющего одну за-
пись, например одну строку таблицы базы данных. Каждому столбцу таблицы соответст-
вует поле записи
Как видно никакого «Объектно-реляционного отображения» здесь нет.
Во-первых, Фаулер не «основоположник», он всего лишь собрал используемые паттерны в книжку.
Во-вторых, ваша цитата относится к Row Data Gateway («A Row Data Gateway acts as an object that exactly mimics a single record, such as one database row. In it each column in the database becomes one field»), а не к Active Record.
В-третьих, все эти шаблоны относятся к разделу Data Source Architectural Patterns, и термин O/R mapping там употребляется постоянно, равно как и в разделе Mapping to Relational Databases, где — опять-таки — они все перечисляются.
Наконец, в-четверых, шаблон называется Data Mapper, а не ORM.
Так что не, don't pull your book on me.
Во-вторых, ваша цитата относится к Row Data Gateway («A Row Data Gateway acts as an object that exactly mimics a single record, such as one database row. In it each column in the database becomes one field»), а не к Active Record.
В-третьих, все эти шаблоны относятся к разделу Data Source Architectural Patterns, и термин O/R mapping там употребляется постоянно, равно как и в разделе Mapping to Relational Databases, где — опять-таки — они все перечисляются.
Наконец, в-четверых, шаблон называется Data Mapper, а не ORM.
Так что не, don't pull your book on me.
Так где же там объектно-реляционное отображение? Не во взаемодействии ли с РБД через объектный интерфейс?
Так где же там объектно-реляционное отображение? Не во взаемодействии ли с РБД через объектный интерфейс?
Нет. В том, что в ActiveRecord программист работает с объектом доменной модели, который при этом соответствует какой-то записи в БД.
Фаулер не «основоположник», он всего лишь собрал используемые паттерны в книжку
Будьте любезны тогда ссылку на первое упоминание сего шаблона в подтверждение ваших догадок
Мне хватает высказывания самого Фаулера (это вступление к PoEAA):
Patterns aren’t original ideas; they’re very much observations of what happens in the field. As a result, we pattern authors don’t say we “invented” a pattern but rather that we “discovered” one.
То есть упоминание термина есть применение ORM?
Нет. Поймите, у Фаулера вообще нет такой вещи как «ORM». Он говорит про O/R-mapping как подход (без особого, кстати, определения, что это), а интересующие нас шаблоны перечисляет в разделе шаблонов доступа к данным, располагая по их по степени увеличения сложности доменной модели.
Шаблон называется — Active Record — в остальном вы что-то путаете
Какой шаблон? Тот, который используется у автора поста? Вероятно, он сам так говорит. Тот, который используется во многих (не во всех) ORM-фреймворках? В EF, по крайней мере, Data Mapper (с кучкой вспомогательных, понятное дело).
Какой шаблон? Тот, который используется у автора поста? Вероятно, он сам так говорит
Вероятно, я лишь «услышал звон» и решил что «в интернете кто то не прав».
В том, что в ActiveRecord программист работает с объектом доменной модели, который при этом соответствует какой-то записи в БД
Так AR не обязана реализовываться в качестве доменной модели. Основная идея лишь в добавлении логики, позволяющей легко восстанавливать, сохранять и удалять данные записи. Цели проекции этой записи в домен у этого шаблона нет. В отличии от Mapper.
Так AR не обязана реализовываться в качестве доменной модели.
Обязана.
The essence of an Active Record is a Domain Model (116) in which the classes match very closely the record structure of an underlying database.
Основная идея лишь в добавлении логики, позволяющей легко восстанавливать, сохранять и удалять данные записи.
Мне кажется, вы путаете с Row Data Gateway.
Фаулер не «основоположник», он всего лишь собрал используемые паттерны в книжку
Будьте любезны тогда ссылку на первое упоминание сего шаблона в подтверждение ваших догадок
Суть в том что Фаулер не придумал этот шаблон. Шаблоны проектирования (те что описаны в той же книге фаулера) вообще никто не придумывал, они просто были. Их просто выделили и описали.
Но вроде как название AR получило именно от него, если мне память не изменяет.
Но вроде как название AR получило именно от него, если мне память не изменяет.
Но вроде как название AR получило именно от него, если мне память не изменяет.
Ну, по крайней мере, википедия с вами в этом согласна.
Шаблоны проектирования (те что описаны в той же книге фаулера) вообще никто не придумывал, они просто были
Мы уедем в область философии такими темпани. Не считаю, что без мыслительной деятельности отдельно взятых программистов, шаблоны существовали как данность. Да, если выделить все возможные вариации алгоритмов, то в них можно выделить несколько шаблонов, но рассуждая аналогично можно выделить и множество вариаций сочетаний цветом и звуков, тогда деятельность художников и музыкантов будет сводится лишь к именованию картин и музыки, а не к их созданию.
Если вы считаете шаблоны данностью, то в аналогии с природоиспытателями, различные законы (шаблонов алгоритмов) кто то должен был открыть, его я и называю — основоположником.
Если вы считаете шаблоны данностью, то в аналогии с природоиспытателями, различные законы (шаблонов алгоритмов) кто то должен был открыть, его я и называю — основоположником.
… хотя их принято называть «первооткрывателями». Основоположниками называют тех, кто заложил основы теории или учения. Основоположником идеи шаблонов проектирования, если что, считается Кристофер Александер.
Так чем же конкретный шаблон не есть теория?
Ничем не теория, в общем-то.
Я не могу позволить себе использовать термин «первооткрыватель», так как не считаю шаблоны чем то данным. Для меня это как предмет искусства, его нужно создать, а не открыть, как силу притяжения.
Кто «создал» шаблон — тот, кто написал удовлетворяющий ему код, или тот, кто придумал название?
Тот кто описал и доказал его состоятельность. Аналогично описанию и доказанию теорем.
А чем тогда был уже написанный и работающий код до того, как это назвали шаблоном?
Написанным и работающим кодом. Так же, как и картина является просто мазней по хосту до тех пор, пока ценитель не увидит в ней произведение искусства.
Написанным и работающим кодом.
А после того, как кто-то другой, кто никогда не видел этого кода, опишет паттерн, этот код внезапно станет паттерном. Вас это не смущает?
Так же, как и картина является просто мазней по хосту до тех пор, пока ценитель не увидит в ней произведение искусства.
Эээ, может вы еще и скажете, что картина становится картиной в тот момент, когда ее увидел ценитель, а не когда ее написал автор?
А после того, как кто-то другой, кто никогда не видел этого кода, опишет паттерн, этот код внезапно станет паттерном. Вас это не смущает?
Нисколько. Паттерн это категория, категории не существуют как данности, они плод стараний познающих, категоризирующих субъектов, не более того.
Эээ, может вы еще и скажете, что картина становится картиной в тот момент, когда ее увидел ценитель, а не когда ее написал автор?
Хороший вопрос. Если я напишу «картину», она не будет являться картиной до тех пор, пока ее не оценят. То есть предмет искусства есть совокупность создающего и оценивающего субъекта, а не только создающего. Другими словами чтоб предмет искусства стал таковым, его не достаточно просто создать (намазюков на холсте), его еще необходимо оценить (кем либо, помимо автора). С другой стороны данности, как сила притяжения, не нуждаются ни в создателе, ни в оценщике чтоб быть данностью.
Другими словами чтоб предмет искусства стал таковым, его не достаточно просто создать (намазюков на холсте), его еще необходимо оценить (кем либо, помимо автора).
Извините, история искусства с вами не очень согласна.
Вдаваться в философские рассуждения далее не вижу смысла, мы на разных позициях стоим.
Нисколько. Паттерн это категория, категории не существуют как данности, они плод стараний познающих, категоризирующих субъектов, не более того.
Тот кто описал и доказал его состоятельность. Аналогично описанию и доказанию теорем.
Противоречит друг другу. Категории не нуждаются в доказывании состоятельности, это просто описание условий отбора по которым сущность попадает в категорию или не попадает. В терминах математики паттерны программирования — это определения, не более. Вот эти подмножества множество всех сущностей мы называем натуральными числами, вот эти комплексными, вот эти синглтонами, а вот эти фабриками.
Шаблон (в данном контексте) именно не создается, а открывается — кто-то замечает, что для решения схожих задач (типа объектно-реляционного отображения) множество людей использует очень схожие подходы. Этот кто-то лишь анализирует их, абстрагирует в одно типовое решение и даёт название. Иногда называя этот шаблон «антипаттерном», то есть типичной ошибкой проектирования или реализации :) После этого любой может сказать «мое решение соотвествует <pattern_name>, не объясняя основные принципы, даже если решение создано раньше чем его автор узнал о <pattern_name>, а может даже раньше чем этот шаблон был выделен. Ну или любой может сказать: „это решение соответствует <pattern_name>, поэтому нормально работать не будет“.
Шаблон, по сути, лишь „регулярка“, которую сначала кто-то написал, чтобы выделить из множества уже существующих решений основные, а уж потом другие начинают использовать эту регулярку в качестве „валидатора“, а то и писать код заранее так, чтобы он ей соотвествовал.
Можно ли назвать автора регулярки проверки соответствия решения некоторому шаблону автором решения? Нет. Сначала нужно создать множество решений, а лишь потом открыть, что большие их подмножества соответствуют некоторому шаблону. Обычная аналитика, а творчества там, по сути, лишь в именовании наблюдаемых явлений.
Шаблон, по сути, лишь „регулярка“, которую сначала кто-то написал, чтобы выделить из множества уже существующих решений основные, а уж потом другие начинают использовать эту регулярку в качестве „валидатора“, а то и писать код заранее так, чтобы он ей соотвествовал.
Можно ли назвать автора регулярки проверки соответствия решения некоторому шаблону автором решения? Нет. Сначала нужно создать множество решений, а лишь потом открыть, что большие их подмножества соответствуют некоторому шаблону. Обычная аналитика, а творчества там, по сути, лишь в именовании наблюдаемых явлений.
Если вы считаете шаблоны данностью, то в аналогии с природоиспытателями, различные законы (шаблонов алгоритмов) кто то должен был открыть, его я и называю — основоположником.
Люди каждый день открывают новые виды животных и насекомых. Но животные эти и насекомые существовали до этого открытия. Они родились в ходе эволюции. Только такие структуры для описываемых задач могли выжить в пределах большого количества проектов.
таки да. я помню когда начинал програмировать не то что инета — персоналка не у каждого была. и применял синглетон ы и фабричные методы как очевидные конструкции. И только потом узнал что это оказывается паттернами именуется.
Я не считаю шаблоны данностью, для меня это аналог человеческой идеи, которая не существует без познающего субъекта.
все эти шаблоны относятся к разделу Data Source Architectural Patterns, и термин O/R mapping там употребляется постоянно, равно как и в разделе Mapping to Relational Databases, где — опять-таки — они все перечисляются
То есть упоминание термина есть применение ORM?
лон называется Data Mapper, а не ORM.
Шаблон называется — Active Record — в остальном вы что-то путаете
Шаблон называется Active Record и он, наряду с DataMapper, является одним из шаблонов решений задачи ORM. ORM — это задача, это ответственность какого-то программного артефакта, коль скоро в коде вы используете объекты, данные которых хранятся в реляционной базе данных.
Значит любой доступ к базе через объектный интерфейс есть ORM? ))
Доступ к базе не есть. А представление записей в виде объектов — есть. Банально, PDOStatement::fetchAll(PDO::FETCH_ASSOC) — не ORM, а PDOStatement::fetchAll(PDO::FETCH_OBJ) — уже простейшая ORM по сути, поскольку осуществляет маппинг записей базы на объекты. Примитивный, но маппинг.
То есть если вы получаете из базы данные не в виде массива, а в виде объектов, то это уже ORM?
Да.
Интересно, а где же обратное преобразование? )
Маппинг не обязан быть двусторонним.
Маппинг не обязан быть двусторонним
при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись
То есть эти три правила можно смело отбросить?
Каждому столбцу таблицы соответствует поле записи
Это и есть основное правило объектно-реляционного отображения ORM, широко известного как ActiveRecord. Вы ещё больше его «упростили» добавив в это правило: «с таким же именем».
Оу, а можно тогда сразу увидеть список этих правил?
Каких этих?
О которых вы говорите:
Если правило основное, то есть и другие, не основные правила. Вот их хотелось бы увидеть.
Это и есть основное правило
Если правило основное, то есть и другие, не основные правила. Вот их хотелось бы увидеть.
каждый экземпляр данного класса соответствует одной записи таблицы;
при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись.
при создании нового экземпляра класса (и заполнении соответствующих полей) в таблицу добавляется новая запись;
при чтении полей объекта считываются соответствующие значения записи таблицы баз данных;
при изменении (удалении) какого-либо объекта изменяется (удаляется) соответствующая ему запись.
В широком смысле слова ORM — это любая технология, которая отражает реляционную БД на прикладную
В случае если последняя — объектная :)
это не ОRМ. нигде не задаются и не конфигурятся реляции между бизнес обьектами.
То есть нигде не задается, что счёт имеет коллекцию позиций счета?
главное чтобы свойство совпало с именем поля. Никаких изменений в sql никакого маппинга.
Что?! Это обычный маппинг 1:1 по имени.
поэтому изменение бизнес логики не требует изменения структуры Бд
Такого даже авторы nosql решений не заявляют, они заявляют ровно обратное — вы можете в любой момент изменять структуру БД в соответствии с новыми требованиями бизнес-логики, у вас может одновременно существовать несколько различных структур в одной «таблице».
Конечно надо понимать архитектуру и предметную облсть
То есть обычный веб-разработчик, клепавший сотнями визитки лэндинги, ничего за полдня не сделает, а скорее ничего нормального не сделает и за полгода.
Пока что мне ни разу не понадобилось добавит какое то экзотическое поле чтобы по нему что то вычислять.
Дата остановки начисления пени по договору на основании подачи иска в суд — экзотическое поле в вашем понимании или нет? А это не просто справочный атрибут, а непосредственно влияющий на финансовые расчёты, как управленческие, так и бухгалтерские.
Выходит, что в Вашем случае мониторинг законодательства, реализация свежей формы Декларации по прибыли или ковыряние в дебрях свежего чуда-юда под кодовым названием 275-ФЗ предлагается делать бесплатно? На основе работы волонтеров, видимо?
Удачи, бро )
«Мы все через это прошли» (с)
Когда-то я тоже был молодым максималистом, с идеей о несовершенстве мира.
Удачи, бро )
«Мы все через это прошли» (с)
Когда-то я тоже был молодым максималистом, с идеей о несовершенстве мира.
мониторинг законодательства, реализация свежей формы Декларации по прибыли или ковыряние в дебрях свежего чуда-юда под кодовым названием 275-ФЗ предлагается делать бесплатно? На основе работы волонтеров, видимо?
не поверите но некоторые бесплатно делают целые операционные системы, включая написание драйверов.
Когда-то я тоже был молодым максималистом, с идеей о несовершенстве мира
9 из 10 что я гораздо старше вас. Поэтому я понимаю что делаю и зачем.
Простите, но это пост из серии «Я джва года хочу такую игру»
я ничего не хочу. Есть некоторые идеи которые я реализовываю в своем проекте. 99.9% проектов на гитхабе именно такие. Что именно вас в этом не устраивает?
Да меня в общем-то все устраивает :) Просто статья обрывается на самом интересном месте: что-то вроде потока мыслей, но без конкретной реализации или хотя бы ее начала.
в первом варианте статьи я сослался на реализацию и был забанен на неделю.
В статье описаны ряд идей которые могут реализовать то, что не реализовано или реализовано сложно и дорого у существующих систем.
Есть и всегда будут люди пытающиеся найти альтернативные решения существующим вещам. Независимо от того нравится вам одинэсникам это или нет.
В статье описаны ряд идей которые могут реализовать то, что не реализовано или реализовано сложно и дорого у существующих систем.
Есть и всегда будут люди пытающиеся найти альтернативные решения существующим вещам. Независимо от того нравится вам одинэсникам это или нет.
Как хранить документы, которые очевидно, имеют разнородную структуру. Отдельная таблица под каждый тип документа, общая таблица с кучей универсальных полей, модные нынче NoSQL хранилища… Предлагается хранить все докуменнты в одной таблице в блобе, упакованными в XML.
Угу. Давайте напишем NoSQL сами.
Вы производительность своей схемы хранения тестировали?
тестировал. Нет никаких проблем с производительностью.
Кроме того я неоднократно подчеркнул что речь об автоматизации малого бизнеса. Тех, для кого 1С громоздко и дорого а ексель нефункционально. Иными словами в БД не будет трилиарда документов. Кроме того выполнять поиск по блобу, как показало написание бизнес-логики, придется нечасто.
Кроме того я неоднократно подчеркнул что речь об автоматизации малого бизнеса. Тех, для кого 1С громоздко и дорого а ексель нефункционально. Иными словами в БД не будет трилиарда документов. Кроме того выполнять поиск по блобу, как показало написание бизнес-логики, придется нечасто.
тестировал. Нет никаких проблем с производительностью.
Результатами поделитесь?
Кроме того я неоднократно подчеркнул что речь об автоматизации малого бизнеса. Тех, для кого 1С громоздко и дорого а ексель нефункционально. Иными словами в БД не будет трилиарда документов.
Ну не будет триллиарда. Будет тысяч сто. За несколько лет. Какая нужна конфигурация, чтобы подавляющее большинство операций выполнялось в пределах полусекунды?
не будет тысяч сто хотя бы потому что никто не будет выполнять поиск тупо по всем документам. Будет искаться конкретный атрибут по конкретным типам документам — нет смысла искать контрагента в документе начисление зарплаты. А тип документа — отдельное индексируемое поле. Да и за пять лет никто не будет искать — дата документа опять же отдельное поле.
А в большинстве случаев поиск будет производится по таблице аналитики а не по блобу.
А в большинстве случаев поиск будет производится по таблице аналитики а не по блобу.
… ну и чем это лучше, чем NoSQL?
тем что система состоит не только из таблицы документов. Все восторги по поводу nosql быстро утихают когда оказывается что нужна именно реляционая схема.
Сам недавно портировал после предыдущей команды систему логистики складов с CouchDB на MSSQL. А выглядело вначале многообещающе — упаковал инвойс или ордер в json и радуйся.
Сам недавно портировал после предыдущей команды систему логистики складов с CouchDB на MSSQL. А выглядело вначале многообещающе — упаковал инвойс или ордер в json и радуйся.
тем что система состоит не только и таблицы документов. Все восторги по поводу nosql быстро утихают когда оказывается что нужна именно реляционая схема.
А зачем вам «именно реляционная схема», учитывая, что вы большую часть информации спрячете в XML, над которым реляционные операции проводятся тяжело?
я прячу в XML то что не требует реляционных операций. В этом и суть.
Ну то есть все связи, все суммы — они в XML не попадут?
попадут — там они продублируются для того чтобы если формируется печать документа не надо было подтаскивать другие таблицы (точнее вообще не надо было писать такой код). То есть там не только контрагент а и его имя и если надо адрес. Эти данные все равно под руками во время редактирования документа — они и засовываются в XML.
Но эти же данные (не все а бзнес-данныепо котоым выполняется обработка) сохраняются и в таблице аналитики. Там сумма, количество и ссылки на остальные бизнес сущности (просто вторичные ключи). По этой таблице и выполняются вычисления. Таблица состоит из полей целого типа. А значит обрабатывается очень быстро.
То есть обычная денормализация. Дата документа кроме ссылки на него тоже дублируется в таблице аналитики (хотя есть возможность и приджойнить).
Но эти же данные (не все а бзнес-данныепо котоым выполняется обработка) сохраняются и в таблице аналитики. Там сумма, количество и ссылки на остальные бизнес сущности (просто вторичные ключи). По этой таблице и выполняются вычисления. Таблица состоит из полей целого типа. А значит обрабатывается очень быстро.
То есть обычная денормализация. Дата документа кроме ссылки на него тоже дублируется в таблице аналитики (хотя есть возможность и приджойнить).
Если данные продублируются, значит, они хранятся и в обычном представлении. А если это так, значит, вы, собственно, не решили заявленную задачу: хранение разнородных документов в одной таблице.
решил.
количество бизнес-сущностей ограничено. Ссылки на них хранятся в таблице аналитики (измерения в ROLAP таблице фактов). Только ссылки — например id контрагента.
Я использую это например для подсчета остатков и оборотов.
В самом документе нет необходимости хранить реляционые отношения — там хранится все, что понадобилось бы вытащить при обработке документа. У меня под руками имя контрагента для печати и под руками id товара для выполнения проводок. Для каждого типа документа свой дочерний клас который знает что где упаковано.
Я ж не просто натыкал таблиц — я как раз разрабатываю первичку — голый движок никому не нужен. Потому на практике убедился что данных подход вполне юзабельный. Данные хранятся в разных местах и в разном виде для разного использования. Потому и дублируются. Держать данные в одном месте для разного использования — проблематично. потому то 1С такая тормознутая и надо писать кучу лишнего кода.
количество бизнес-сущностей ограничено. Ссылки на них хранятся в таблице аналитики (измерения в ROLAP таблице фактов). Только ссылки — например id контрагента.
Я использую это например для подсчета остатков и оборотов.
В самом документе нет необходимости хранить реляционые отношения — там хранится все, что понадобилось бы вытащить при обработке документа. У меня под руками имя контрагента для печати и под руками id товара для выполнения проводок. Для каждого типа документа свой дочерний клас который знает что где упаковано.
Я ж не просто натыкал таблиц — я как раз разрабатываю первичку — голый движок никому не нужен. Потому на практике убедился что данных подход вполне юзабельный. Данные хранятся в разных местах и в разном виде для разного использования. Потому и дублируются. Держать данные в одном месте для разного использования — проблематично. потому то 1С такая тормознутая и надо писать кучу лишнего кода.
То есть в вашей системе нет никакой расширяемости механизма хранения?
Его не только нет — смысл в том чтобы он не понадобился вообще.
Чтобы первичку и отчеты можно было делать не меняя структуру БД.
Основные бизнес-сущности — товары, контрагенты, сотрудники, банки, денежные счета уже заложены (для малого бизнеса должно хватить)
С учетом опять же относительно небольших объемов какой то оптимизации, написания хранимок или специальных предствлений из списка таблиц не нужно. Сложная логика будет выполнятся в PHP
Если какой отчет понадобится подождать секунд пять-десять — невелика плата за экономия на саппорте…
Пока у меня такой только один — шахматка.
Да и то потому что не стал писать прямые выборки на sql а тупо дергаю бизнес обьекты — бухгалтерские счета — пока это не критично -переписать и заменить файлик в системе секунда делов.
Чтобы первичку и отчеты можно было делать не меняя структуру БД.
Основные бизнес-сущности — товары, контрагенты, сотрудники, банки, денежные счета уже заложены (для малого бизнеса должно хватить)
С учетом опять же относительно небольших объемов какой то оптимизации, написания хранимок или специальных предствлений из списка таблиц не нужно. Сложная логика будет выполнятся в PHP
Если какой отчет понадобится подождать секунд пять-десять — невелика плата за экономия на саппорте…
Пока у меня такой только один — шахматка.
Да и то потому что не стал писать прямые выборки на sql а тупо дергаю бизнес обьекты — бухгалтерские счета — пока это не критично -переписать и заменить файлик в системе секунда делов.
Его не только нет — смысл в том чтобы он не понадобился вообще.
Не выйдет. Вы не сможете развивать систему вслед за требованиями и законодательством.
выйдет.
Если я пишу первичку с нуля это тоже самое как скорректировать под законодательство.
Настолько кардинально менялось законодательстово один раз когда в Украине перешли но новый план счетов 15 лет назад.
но даже в этом случае нужно было бы только перебить счета на новые номера.
структура БД бы не поменялась.
.
Если я пишу первичку с нуля это тоже самое как скорректировать под законодательство.
Настолько кардинально менялось законодательстово один раз когда в Украине перешли но новый план счетов 15 лет назад.
но даже в этом случае нужно было бы только перебить счета на новые номера.
структура БД бы не поменялась.
.
> не будет тысяч сто хотя бы потому что никто не будет выполнять поиск тупо по всем документам.
Хотел бы я посмотреть, как вы пересчитаете себестоимость остатков на складе при проведении возврата «задним числом» полгода назад.
Хотел бы я посмотреть, как вы пересчитаете себестоимость остатков на складе при проведении возврата «задним числом» полгода назад.
на нормальном железе — не более секунды. Mysql вообще очень хорошо работает с отдельными таблицами с фиксированым размером записи.
А postgresql с нативным jsonb еще быстрее. Или mysql + elasticsearch для агрегаций выборок. CQRS там и все такое…
как в определите где у вас контрагент? смысл XML однозначный способ структуирования данных применимый для поиска обычными текстовыми функциями. LIKE прежде всего.
Эээ, а зачем использовать «обычные текстовые функции», когда есть специализированные парсеры и индексы поверх них?
а так быстрее. зачем какие то парсеры — тут же структуированый код а не произвольный текст.
с парсерами и прочим простота и универсальность системы сойдет на нет.
тем более всякие витиеватые выьборки редко нужны в повседневно работе. Бухгалтеру точно не нужны.
Если речь идет об аналитиках то это немного другая задача и для нее возможно нужны какие то другие инструменты.
Но я веду речь об учетной системе.
с парсерами и прочим простота и универсальность системы сойдет на нет.
тем более всякие витиеватые выьборки редко нужны в повседневно работе. Бухгалтеру точно не нужны.
Если речь идет об аналитиках то это немного другая задача и для нее возможно нужны какие то другие инструменты.
Но я веду речь об учетной системе.
Для вас может парсить регулярками xml это нормально, а для меня как-то не очень.
Да ни капельки. Для велосипеда на коленке может и сойдет но не для opensource продукта.
а так быстрее
Да ни капельки. Для велосипеда на коленке может и сойдет но не для opensource продукта.
я вообще не парсю XML ни регулярками ни чем то иным.
Если речь о прямом поиске в БД на случай какой оказии то просто поиск по тексту. Тэги помоuают прицелится.
я не парсю xml чтобы найти что там есть контрагент вася пупкин я ищу простую строку
Но штатная работа — через высокоуровневые бизнес-обьекты. Так же как в 1С. В этом смысл — свести к минималной простоте большинство задач. Экзотичексие но редкие будут выполнятся неоптимально ну и фиг с ними.
Если речь о прямом поиске в БД на случай какой оказии то просто поиск по тексту. Тэги помоuают прицелится.
я не парсю xml чтобы найти что там есть контрагент вася пупкин я ищу простую строку
select from documents where details like '%<contragentname>вася пупкин </contragentname>%'
Но штатная работа — через высокоуровневые бизнес-обьекты. Так же как в 1С. В этом смысл — свести к минималной простоте большинство задач. Экзотичексие но редкие будут выполнятся неоптимально ну и фиг с ними.
а так быстрее.
Правда? Вы уверены, что поиск по вхождению быстрее поиска по полноценному индексу?
мне пофиг будет оно выполнятся секунду или полсекунды. Зато не надо вообще никаких индекса и вообше ничего. Только таблица с текстовым блобом. И этого достаточно для работы с любым, в том числе наперед неизвестным, типом документа любой структуры.
Такова идеология данного подхода и смысл статьи…
Такова идеология данного подхода и смысл статьи…
мне пофиг будет оно выполнятся секунду или полсекунды.
А, это много объясняет.
И этого достаточно для работы с любым, в том числе наперед неизвестным, типом документа любой структуры.
Интересно, зачем вообще люди придумали структурированные документы, расширяемую разметку, эти вот все глупости?
документ вполне себе структуирован. А как он хранится это вообще не забота разраба.
Он работает с высокоуровневым обьектом -экземпляром класса, например, Invoice и его атрибутами. Мое дело стобы система сохранила и выдала документ однообразным образом независимо от его структуры.
Но на всякий пожарный чтобы осталась возможность поиска напрямую по таблице для каких то нештатных задач… Поэтому с одной стороны упаковка в блоб с другой стороны такая упаковка чтбы можно было сделать ручную выборку.
Он работает с высокоуровневым обьектом -экземпляром класса, например, Invoice и его атрибутами. Мое дело стобы система сохранила и выдала документ однообразным образом независимо от его структуры.
Но на всякий пожарный чтобы осталась возможность поиска напрямую по таблице для каких то нештатных задач… Поэтому с одной стороны упаковка в блоб с другой стороны такая упаковка чтбы можно было сделать ручную выборку.
Он работает с высокоуровневым обьектом -экземпляром класса, например, Invoice и его атрибутами. Мое дело стобы система сохранила и выдала документ однообразным образом независимо от его структуры.
Угу, и как ему к этому объекту написать «хочу сумму по всем счетам, выставленным в мае»?
Серьезно, вы сейчас идете по всем штатным обсуждениям, которые возникают вокруг schemaless storage — и при этом так снисходительно отмахиваетесь от NoSQL.
Угу, и как ему к этому объекту написать «хочу сумму по всем счетам, выставленным в мае»?
поверьте гораздо проще чем в 1с
по сути одной строкой. Хотя на практике такие выборки не имеют смысла. Что бухгалеру скажет эта цифра?
А для взаиморасчетов с контаагентами есть специальный отчет.
schemaless storage — и при этом так снисходительно отмахиваетесь от NoSQL
потому что подавляющее число бизнес-вычислений выполняется по реляционным данным.
Универсально только хранение документов и справочников.
Информация которая нужна для бизнес вычислений и для манипуляций с документом — дублируется.
Мне не нужно применять реляции к атрибутам документа и не надо пихать второстепенные атрибуты там где у меня хранятся движения по количеству и сумме.
поверьте гораздо проще чем в 1с
по сути одной строкой.
Так как же?
А для взаиморасчетов с контаагентами есть специальный отчет.
Который кто-то должен написать.
потому что подавляющее число бизнес-вычислений выполняется по реляционным данным.
Нет. Подавляющее число бизнес-вычислений выполняется по бизнес-данным, а схема их хранения — глубоко вторична. Вы сам себе противоречите: сначала вы предлагаете программисту работать с бизнес-моделью, а потом говорите, что он делает вычисления по реляционным данным.
Так как же?
в бизнес обьекта есть метод find (это как раз напоминает как в ОРМ)
там задам условие. Как в обычном SQL
Который кто-то должен написать.
как и остальные отчеты, оборотно-сальдовую ведомость например. Взаиморасчеты с контрагентами — стандартная задача.
вы предлагаете программисту работать с бизнес-моделью, а потом говорите, что он делает вычисления по реляционным данным.
большиство вычислений ка напрмер, статки и обороты он и выполняет работая с бизнес моделью. Обьект Account например
имеет методы возвращающие остатки и обороты по синтетическому счету. как напрмер.СКД() в 1С.
Но в той же 1с есть и запросы и даже напоминающие SQl если брать восмерку.
И у меня так — маразма с гроздьями обьектов как в ОРМ у меня нет.
то есть все станлартные операции- сохранить докмент или там загрузить документ выполняются встроенными методами. ну а произвольные выборки конечно надо писать с помощью какого набора предикатов.
.
Что бухгалеру скажет эта цифра?
Например, сумму стоимости оказанных услуг, если счета выставляются по факту.
А чего не в текстовых файлах сразу и поиск по документам grep-ом сделать.
а чего бы вам не прочитать статью прежде чем ерничать?
Мне вот интересно, на какую реакцию вы расчитывали? Вы описали идею (причем не науровне концепта а просто… что у вас есть идея написать свою альтернативу какому-то продукту), причем из этого описания видна куча ляпов и мест для улучшения. Оно может для вас все красиво и понятно, мне например все это описание говорит о том что на свет появится еще один проект сложный в поддержке, плохо расширяемы и страдающий проблемами с производительностью.
Люди вам высказывают реально полезные моменты, и к некоторым стоит прислушаться.
Вообще что бы я вам предложил, так это сделать концепт проекта покрытый тестами. Никакого интерфейса или инфраструктуры, тупо бизнес объекты ваши и сервисы. Ну и тесты. Никаких баз данных, просто in-memory заглушки для тестов. Это займет не так много времени (в сравнении с реализацией полноценного проекта это мелочи), зато позволит вам более тщательно проработать архитектуру и идею проекта, сразу наткнуться на гору ляпов и попробовать их исправить. Никаких фреймворков, никаких библиотек (почти, возможно doctrine/collection еще или что-то подобное для работы с коллекциями), только старый добрый PHP.
А уж как будет работающий прототип (по тестам работающий) уже можно будет думать как что где хранить и т.д. У меня пока складывается впечатление что задумка у вас уже есть но вы пока понятия не представляете как это реализовать.
Ну и да, DSL таки построить свой придется.
Люди вам высказывают реально полезные моменты, и к некоторым стоит прислушаться.
Вообще что бы я вам предложил, так это сделать концепт проекта покрытый тестами. Никакого интерфейса или инфраструктуры, тупо бизнес объекты ваши и сервисы. Ну и тесты. Никаких баз данных, просто in-memory заглушки для тестов. Это займет не так много времени (в сравнении с реализацией полноценного проекта это мелочи), зато позволит вам более тщательно проработать архитектуру и идею проекта, сразу наткнуться на гору ляпов и попробовать их исправить. Никаких фреймворков, никаких библиотек (почти, возможно doctrine/collection еще или что-то подобное для работы с коллекциями), только старый добрый PHP.
А уж как будет работающий прототип (по тестам работающий) уже можно будет думать как что где хранить и т.д. У меня пока складывается впечатление что задумка у вас уже есть но вы пока понятия не представляете как это реализовать.
Ну и да, DSL таки построить свой придется.
Мне вот интересно, на какую реакцию вы расчитывали? Вы описали идею (причем не науровне концепта а просто… что у вас есть идея написать свою альтернативу какому-то продукту),
наоборот. Я пишу эту альтернативу. И то что я изложил — уже обкатанные идеи.
У меня пока складывается впечатление что задумка у вас уже есть но вы пока понятия не представляете как это реализовать
вообще то у меня проект на гитхабе и работающий прототип в инете. Законченая платформа с частью первички (пока склад, закупки, продажи).
сложный в поддержке, плохо расширяемы и страдающий проблемами с производительностью.
Наоборот. Проект именно прост в поддержке и максимально расширяемый. Да, производительность меньше- но речь не об ентерпрайз продукте. Потому произвдительность уменьшена за счет простоты, расширяемости и универсальности.
Люди вам высказывают реально полезные моменты, и к некоторым стоит прислушаться.
Да что вы говорите! А я то думаю — на фига они тут мне коменты строчат.
Вообще что бы я вам предложил, так это сделать концепт проекта покрытый тестами
я в курсе что нужны тесты. Это никак не относится к архитектурным принципам проекта. Не надо мне расказывать азбучные истины — я не начинающий програмер.
Ну и да, DSL таки построить свой придется.
не придется — PHP плюс высокоуровневые бизнес объекты.
Вы вообще прочитали что нибудь дальше названия статьи?
а есть фидбек от реальных пользователей для вашей системы?
система в разработке. Вы думаете написать вю первичку и отчеты — пара дней. Глянте в конфу 1с сколько там этого добра. Пока демке только закупки и продажи.
Статья не о моей системе а о технических аспектах реализации на основе опыта написания подобных систем.
Статья не о моей системе а о технических аспектах реализации на основе опыта написания подобных систем.
Я решил тут вместе с автором пофантазировать. Допустим я мелкий биз в глубинке, чаще всего это купи-продай до 100 человек. Что мне нужно?
Цель любого бизнесмена максимально упростить и абстрагироваться от тех вещей которые не приводят к основной цели бизнеса — прибыли. Думаю я поспрашивал у друзей-знакомых, кто имел с этим дело, или я раньше сам видел что все пользуются 1С. Тут появляется неважно откуда у меня информация об альтернативе. Что сподвигнет меня выбрать не 1С? Опенсорс — думаю 90% подобных бизнесменов сочтут слово ругательством и даже не будут гуглить что это, так что не агрумент совсем. Бесплатно — но кто-то это должен будет поставить и настроить, пусть это будет сисадмин даже хотя бы. Думаю найти сисадмина который будет ставить опенсорс по мануалам, которые, как обычно, давно не обновляли, в общем думаю тут я бы уже отказался в пользу 1С. Но допустим я настойчивый и знаю что такое опенсорс иду на принцип. Я нашел сисадмина, но он сказал что ему нужен месяц на внедрение и пару месячных окладов обычного сисадмина за работу. Тут я уже тысяч 50 рублей потратил в глубинке и 150 в Москве и это минимум. При этом я думаю тысяч за 100 можно было уже для начала купить достаточный набор из УТ, ЗУП и Бухгалтерии и вчерашний студент поставит это за 10 тысяч и за пару вечеров. Так можно продолжать бесконечно, не знаю что должно произойти чтобы какой-то продукт мог потеснить 1С на пьедестале, особенно на уровне мелкого бизнеса.
Цель любого бизнесмена максимально упростить и абстрагироваться от тех вещей которые не приводят к основной цели бизнеса — прибыли. Думаю я поспрашивал у друзей-знакомых, кто имел с этим дело, или я раньше сам видел что все пользуются 1С. Тут появляется неважно откуда у меня информация об альтернативе. Что сподвигнет меня выбрать не 1С? Опенсорс — думаю 90% подобных бизнесменов сочтут слово ругательством и даже не будут гуглить что это, так что не агрумент совсем. Бесплатно — но кто-то это должен будет поставить и настроить, пусть это будет сисадмин даже хотя бы. Думаю найти сисадмина который будет ставить опенсорс по мануалам, которые, как обычно, давно не обновляли, в общем думаю тут я бы уже отказался в пользу 1С. Но допустим я настойчивый и знаю что такое опенсорс иду на принцип. Я нашел сисадмина, но он сказал что ему нужен месяц на внедрение и пару месячных окладов обычного сисадмина за работу. Тут я уже тысяч 50 рублей потратил в глубинке и 150 в Москве и это минимум. При этом я думаю тысяч за 100 можно было уже для начала купить достаточный набор из УТ, ЗУП и Бухгалтерии и вчерашний студент поставит это за 10 тысяч и за пару вечеров. Так можно продолжать бесконечно, не знаю что должно произойти чтобы какой-то продукт мог потеснить 1С на пьедестале, особенно на уровне мелкого бизнеса.
Бесплатно — но кто-то это должен будет поставить и настроить, пусть это будет сисадмин даже хотя бы.
Стащите вариант с WAMP сервером. Настраивать в самой системе нечего кроме бизнес-настроек.
Не нужен никакой сисадмин.
Если хотите развернуть как сайт чтобы доступатся с инета — это не сложнее чем развернуть обычный сайт — например сайт визитку вашей компании -любой вебразраб сделает.
Обновление сайта как уже писал — заменой файлов как нибудь FTP освоите если сайт на хостинге. А если внутри то вообще никаких проблем.
Идете на форум, комунити или саппорт или просто к людям которые стороние разрабы и говорите — вот тут вышел бланк накладной теперь к единице измерения еще полагается код писать.
Они вам дают ссылку или кидают пару файлов вы их копируете в соответствующие папки и все. Задача для продвинутого юзера не более того.
Можно, я объясню?
дело не в том, что мне нравится подход автора, нет, скорее как раз наоборот.
Но легко сказать, почему у бизнеса может быть востребована альтернативная система учета: сложность. Даже в мск полно бизнесов, где 1С в многих применениях слишком сложна. Да, в вопросе фискального учета она имеет подавляющую долю рынка, если говорить про мелочь. Но для работы — она категорически неудобна. А налоговый учет очень часто отдан на аутсорс, и штатные сотрудники компании в своей повседневной деятельности никак с ним не связаны!
Вот представьте себе, офис, сидят девочки, продают — не знаю — туры. или страховки. На кой им 1С? Как их обучать? Сколько времени и денег на это надо?
гораздо проще нарисовать что-то типа АРМ с 3 кнопками в веб-морде, и привет.
А потом, отдельно, рисовать выгрузку данных из своей ERP 8-) в 1C. И 1С, конечно, тут будет использоваться уже в предельно стандартной форме.
Логичная схема?
Знаю массу компаний, которые идут именно этим путем. То есть, альтернативная система оказывается уже внедрена, не потому, что кто-то принципиально решил выбрать опенсорс, а потому, что людям работать надо!
Ну, а от такой штуки уже очень недалеко и до «а давайте попробуем 1С вообще выкинуть — эта налог тоже умеет, и формы актуальные все есть!».
так что, альтернативная система вполне может быть. Другой вопрос — удастся ли это кому-то в близкой перспективе или нет…
простой пример: облачные системы вполне себе заменяют 1С по крайней мере для некоторых видов компаний. Мое дело, например, подписку купил — 1С не нужна. В чем вы видите уж такое принципиальное отличие от идей автора?
дело не в том, что мне нравится подход автора, нет, скорее как раз наоборот.
Но легко сказать, почему у бизнеса может быть востребована альтернативная система учета: сложность. Даже в мск полно бизнесов, где 1С в многих применениях слишком сложна. Да, в вопросе фискального учета она имеет подавляющую долю рынка, если говорить про мелочь. Но для работы — она категорически неудобна. А налоговый учет очень часто отдан на аутсорс, и штатные сотрудники компании в своей повседневной деятельности никак с ним не связаны!
Вот представьте себе, офис, сидят девочки, продают — не знаю — туры. или страховки. На кой им 1С? Как их обучать? Сколько времени и денег на это надо?
гораздо проще нарисовать что-то типа АРМ с 3 кнопками в веб-морде, и привет.
А потом, отдельно, рисовать выгрузку данных из своей ERP 8-) в 1C. И 1С, конечно, тут будет использоваться уже в предельно стандартной форме.
Логичная схема?
Знаю массу компаний, которые идут именно этим путем. То есть, альтернативная система оказывается уже внедрена, не потому, что кто-то принципиально решил выбрать опенсорс, а потому, что людям работать надо!
Ну, а от такой штуки уже очень недалеко и до «а давайте попробуем 1С вообще выкинуть — эта налог тоже умеет, и формы актуальные все есть!».
так что, альтернативная система вполне может быть. Другой вопрос — удастся ли это кому-то в близкой перспективе или нет…
простой пример: облачные системы вполне себе заменяют 1С по крайней мере для некоторых видов компаний. Мое дело, например, подписку купил — 1С не нужна. В чем вы видите уж такое принципиальное отличие от идей автора?
обясните тогда каким чудом вообще существуют учетные системы не являющиеся 1С? Ну не 100% же рынка 1С держит. и не потому что пользователи никогда не слышали об 1с и купили что первое попало на глаза.
есть проблема — не все компании согласны засунуть свои бизнес-данные неведомое облако. Как с точки зрения конфиденциальности так с точки зрения сохранности. Не то что облака это не обеспечивают а просто — «терзают смтные сомненья».
облачные системы вполне себе заменяют 1С по крайней мере для некоторых видов компаний
есть проблема — не все компании согласны засунуть свои бизнес-данные неведомое облако. Как с точки зрения конфиденциальности так с точки зрения сохранности. Не то что облака это не обеспечивают а просто — «терзают смтные сомненья».
В чем вы видите уж такое принципиальное отличие от идей автора?
На вскидку у автора есть одно катастрофическое отличие. Он считает, что отвязка разработчика такой платформы от предметной области возможна. Нифига это не возможно. Даже более. В любом мало-мальском проекте разработчик просто обязан быть в предметной области, её проблематике. Иначе он велосипидет в итоге пятое колесо которое приделывает к хромой собаке. Зато архитектура красивая и «опенсурс».
Ну я ведь сразу написал: «дело не в том, что мне нравится подход автора, нет, скорее как раз наоборот». Ничего, что я себя цитирую? 8-)
И ответил не в рут, а на реплику. И то, что написано далее, надо понимать в этом же контексте.
Вопрос был: с чего кто-то вообще начнет новое пробовать?
Ответ: а с того, что есть большой кусок жизни малого бизнеса, который 1С покрывает очень плохо. мучительно плохо. И большая часть нормальных бизнесов вынуждена использовать что-то стороннее. И как только это «что-то» будет уметь еще и бухгалтерию — возникает точка роста.
Вот и все. А про фрейм для построения собственной бухгалтерии любым желающим — тут у меня самого сомнений хватает.
И ответил не в рут, а на реплику. И то, что написано далее, надо понимать в этом же контексте.
Вопрос был: с чего кто-то вообще начнет новое пробовать?
Ответ: а с того, что есть большой кусок жизни малого бизнеса, который 1С покрывает очень плохо. мучительно плохо. И большая часть нормальных бизнесов вынуждена использовать что-то стороннее. И как только это «что-то» будет уметь еще и бухгалтерию — возникает точка роста.
Вот и все. А про фрейм для построения собственной бухгалтерии любым желающим — тут у меня самого сомнений хватает.
Вопрос был: с чего кто-то вообще начнет новое пробовать?
этот вопрос стоит пере каждым разработчиком ПО. и не только ПО. Например колбасы.
И большая часть нормальных бизнесов вынуждена использовать что-то стороннее.
ну скажем так бизнесы иду к програмерам а те уже решают или рекомендуют или еще как.
по любому спрос на льтернативные решения в учете есть. Например портирует сообщество ккакой нибудь опернбраво или адьепер (или как его там)
Но оно требует допиливания, там древний код. некторые на чве написаны и все такое.
Потому и смысл предложить оптимальный набор технологий, платформу с высокоуровневыми бизнес-обьектами и сразу заточить под отечественного клиента.
как то так.
Смысл этого всего предложить плюсы там где не устраивает существующее положение вещей.
Базара нет — устремления благие.
Чего уж там говорить, написав в одно лицо свою первую ERP почти 20 лет назад 8-) и потом еще несколько похожих вещей, я и сам изрядно грешен велосипедизмом.
Но все же, теперь мне кажется, что ваша задача трудноразрешима. Хотя бы потому, что 1С не только в авангарде всех изменений минфина и налоговой, но еще — по злостным слухам — сама является чуть ли не причиной этих изменений.
Любой самый чудный опенсорсный проект/платформа в наших условиях всегда будет догоняющим, увы.
Все внедрения опенбраво, которые я видел, были сделаны энтузиастами. Даже если этот энтузиаст — директор. там в решении немалая часть — волюнтаристское «хочу назло всем». И лично знаю людей, кто в итоге об этом пожалел.
Я не отговариваю — конечно, пилите! Больше того, я и сам раз в несколько месяцев бью себе по рукам, чтоб не начать пилить очередной квази- или прото- ERP 8-)
Другой вопрос — что обольщаться не стоит: шансов немного. на то, что напишете, на то, что написанное будет сколько-то пристойным, и на то, что это хоть кому-то понадобится.
Чего уж там говорить, написав в одно лицо свою первую ERP почти 20 лет назад 8-) и потом еще несколько похожих вещей, я и сам изрядно грешен велосипедизмом.
Но все же, теперь мне кажется, что ваша задача трудноразрешима. Хотя бы потому, что 1С не только в авангарде всех изменений минфина и налоговой, но еще — по злостным слухам — сама является чуть ли не причиной этих изменений.
Любой самый чудный опенсорсный проект/платформа в наших условиях всегда будет догоняющим, увы.
Все внедрения опенбраво, которые я видел, были сделаны энтузиастами. Даже если этот энтузиаст — директор. там в решении немалая часть — волюнтаристское «хочу назло всем». И лично знаю людей, кто в итоге об этом пожалел.
Я не отговариваю — конечно, пилите! Больше того, я и сам раз в несколько месяцев бью себе по рукам, чтоб не начать пилить очередной квази- или прото- ERP 8-)
Другой вопрос — что обольщаться не стоит: шансов немного. на то, что напишете, на то, что написанное будет сколько-то пристойным, и на то, что это хоть кому-то понадобится.
Хотя бы потому, что 1С не только в авангарде всех изменений минфина и налоговой, но еще — по злостным слухам — сама является чуть ли не причиной этих изменений.
ну мое дело представить техническую сторону. Геопллитика и все такое конечно имеет место быть.
что обольщаться не стоит
я не обльщаюсь — я взрослый человек. У меня многолетнихй прграмиский опыт в том числе и автоматизации. Есть какие-то идеи где то свои где то подсмотренные.
Жалко добру пропадать.
Вот и реализовываю потихоньку.
К примеру большинство продуктов майкрософта не чисто их — они просто великий итегратор — берут все полезное что плохо лежит собирают в кучу и вот результат.
Или вот нпример разработчик nginx — тоже наверно говорили ты че апач собрался переплюнуть, да кто этим пользоватся будет. но чел нашел минусы апача и предложил прогу которая без них с приемлемым функционалом.
Конечно для таких дел нужен инвестор раскрутка и все такое. но у меня эта система — не смысл жизни. :)
доделаю попробую предложить тем кто мыкается по форумам в поисках проги потому что все не устраивает. откатаю на реальных клиентах а там видно будет.
nginx — продукт для профессионалов. Там не нужно армию хз кого (пере)обучать.
Офис — ну да, ситуация схожая. Именно поэтому, все конкуренты обязательно делают свои продукты максимально похожими на мелкософт. Максимально!
А тут получается как? Будет платформа, на основе которой любой желающий, вместо того, чтоб тупо внедрить 1С, сможет написать свой клон 1С? Очень трудный путь, как мне кажется.
Офис — ну да, ситуация схожая. Именно поэтому, все конкуренты обязательно делают свои продукты максимально похожими на мелкософт. Максимально!
А тут получается как? Будет платформа, на основе которой любой желающий, вместо того, чтоб тупо внедрить 1С, сможет написать свой клон 1С? Очень трудный путь, как мне кажется.
Нет. он тупо внедрит то что «тут». Потому и разрабатывается то что в 1с называется конфигурацией — первичка отчеты и все такое.
Просто статья о технической стороне реализации самой платформы.
Просто статья о технической стороне реализации самой платформы.
Офис — ну да, ситуация схожая. Именно поэтому, все конкуренты обязательно делают свои продукты максимально похожими на мелкософт. Максимально!
OO и LO не слишком смахивают на продукты Microsoft, как по мне.
тоже наверно говорили ты че апач собрался переплюнуть
Да ладно… Может вы не вкурсе, но nginx изначально разрабатывался для рамблера, то есть это не была какая-то поделка любителя, это было решение разработанное профессианалом для решения проблем рамблера. Получилось неплохо, было решено вкинуть это в опенсурс. Сейчас вот фэйсбуки тоже его юзают.
В целом же сделать лучше чем apache не проблема. Разница только в том что nginx изначально тестировался в боевых условиях и проектировался под нагрузки.
Вроде немного не так. nginx был разработан не в Рамблере, а сотрудником Рамблера в свободное от основных обязанностей время (и использоваться начал не в Рамблере, о нём случайно узнали там, что есть что-то разработанное их сотрудником, что может решить проблемы очередного сервиса), не программистом-профессионалом, а программистом-любителем (сисадмином по профессии). И проект был изначально «для души» и распространялся сразу в исходниках.
я не ставлю самоцелью чтобы програмировали люди с улицы. Речь о том что в системе несложно разобратся. Как например человеку дают сайт допилить. даже если он на знакомом движке — все равно надо разбиратся.
Но иногда и не нужно. Например человеку надо не бизнес логику менять а по другому шапку в отчете сделать. Это может сделать любой кто знает HTML. В 1С уже нужен именно тот кто знаком с 1С
Но иногда и не нужно. Например человеку надо не бизнес логику менять а по другому шапку в отчете сделать. Это может сделать любой кто знает HTML. В 1С уже нужен именно тот кто знаком с 1С
Сколько раз слышал уже размышления и даже про реальные продукты на эту тему :)
Вот например . А ещё есть Compiere, БОСС-Компания, Nexus и многие другие продукты с открытыми исходниками.
Ну вот написали вы такой движок, а что дальше то?
Сильно сомневаюсь, что ценность, добавленная этим движком, мотивирует сотни разработчиков забросить свои разработки и сделать на вашем движке бизнес-логику, достаточную для реальных внедрений. Вот если бы движок исполнял родные 1С конфигурации, тогда да :)
Ну и ИМХО ценность подобных систем, не в движке для хранения произвольных документов и не в языке для конфигурирования, а в глубоком понимании разработчиками предметной области.
Вот например . А ещё есть Compiere, БОСС-Компания, Nexus и многие другие продукты с открытыми исходниками.
Ну вот написали вы такой движок, а что дальше то?
Сильно сомневаюсь, что ценность, добавленная этим движком, мотивирует сотни разработчиков забросить свои разработки и сделать на вашем движке бизнес-логику, достаточную для реальных внедрений. Вот если бы движок исполнял родные 1С конфигурации, тогда да :)
Ну и ИМХО ценность подобных систем, не в движке для хранения произвольных документов и не в языке для конфигурирования, а в глубоком понимании разработчиками предметной области.
Предметную область понимает клиент — то есть бухгалтер. Зачем разрабу знать какие надо проводки — ему надо знать какой функцией их выполнить..
И чего вы решили что если человек веб-разработчик то у него нет опыта в других областях.
В любом случае зайдите на любой бухгалтерский форум и вы найдете вопросы где найти програмку которая делает то то и то то.
А еще до фига разрабов которые пытаются делать учетные системы с нуля. Гораздо проще делать не с нуля а когда есть платформа. В дангм случае бесплатная, кросплатформенная и простая. Что кстати не тносится ни к одному продукту названому вами выше
И чего вы решили что если человек веб-разработчик то у него нет опыта в других областях.
В любом случае зайдите на любой бухгалтерский форум и вы найдете вопросы где найти програмку которая делает то то и то то.
А еще до фига разрабов которые пытаются делать учетные системы с нуля. Гораздо проще делать не с нуля а когда есть платформа. В дангм случае бесплатная, кросплатформенная и простая. Что кстати не тносится ни к одному продукту названому вами выше
Зачем разрабу знать какие надо проводки — ему надо знать какой функцией их выполнить..
Чтобы кто-то мог написать функцию, которая проводки проводит.
Чтобы кто-то мог написать функцию, которая проводки проводит.
такая функция есть — надо только подставить счета которые скажет заказчик. И вычислить данные для вставки, которые он скажет.
Представте что вам надо записать проводу в бумажной системе учета как была всегда. какие нужны знания кроме того какие данные взять и куда записать.
то есть бухгалтер говорит — возьми процент НДС от этой суммы и запиши в дебет такого то счета. он клиент такой у него бизнес-процесс. Чего там надо знать разрабу. А типовые стандартные проводки уже и так будут в системе. Либо будут на гитхабе куда их напишет знающий человек.
такая функция есть
А откуда она взялась?
то есть бухгалтер говорит — возьми процент НДС от этой суммы и запиши в дебет такого то счета. он клиент такой у него бизнес-процесс. Чего там надо знать разрабу.
Угу. Идея, что разработчик — это тупой переводчик с бухгалтерского на
account.Debit += amount * nds, конечно, соблазнительна, но на практике не работает.Либо будут на гитхабе куда их напишет знающий человек.
Ага, все-таки знающий человек нужен. Предсказуемо.
А откуда она взялась?
ну есть функция выполняющая провоку — аодставляешь параметры — счета, дату, сумму. Не прямо ж в БД лезу.
В 1С такая встроеная -как то так и называется прводка или Выполнить проводку — не помню
сама бизнес логика выполняется в предопределенном методе документа. Там все и делается и проводки вставляются и аналитика.
Идея, что разработчик — это тупой переводчик с бухгалтерского на account.Debit += amount * nds, конечно, соблазнительна, но на практике не работает.
Это в 1с не работает (хотя в версии 2.0 помнится очень даже работала.). В этом и проблема.
на само деле бухучет не требует знаний сложнее арифметики. А предметную область вы все равно вынуждены узнавать у клиента.
Ага, все-таки знающий человек нужен. Предсказуемо.для всего нужен знающий человек. Фишка в том что один человек напишет а все будут пользоватся не требуя внедренца.
как билиотека в програмирвнии — один написал остальные подключили и юзают.
ну есть функция
От начала времен есть?
Это в 1с не работает (хотя в версии 2.0 помнится очень даже работала.). В этом и проблема.
Нигде не работает.
А предметную область вы все равно вынуждены узнавать у клиента.
… и так раз за разом, пока не выучишь, да. Только после этого начнут появляться приличные продукты.
Фишка в том что один человек напишет а все будут пользоватся не требуя внедренца.
Угу. И откуда гарантия, что будут пользоваться правильно?
От начала времен есть?
от начала моего написания ее
Нигде не работает.
многие в екселе ведут учет
и так раз за разом, пока не выучишь, да. Только после этого начнут появляться приличные продукты.
а скоклько было програмистов знающих бухгалтерию на момент появления 1С.?
И откуда гарантия, что будут пользоваться правильно?
даже не представляю. как можно неправильно ввести товары в накладную или счет фактуру.
а скоклько было програмистов знающих бухгалтерию на момент появления 1С.?
А вы думаете в 1С за бухгалтерию программисты отвечают? Я вас расстрою: нет, есть специальные люди под названием «бизнес-аналитики».
даже не представляю. как можно неправильно ввести товары в накладную или счет фактуру.
Пятнадцатью разными способами. Везде, где можно ошибиться, будет ошибка. Везде, где можно неправильно что-то применить, применят неправильно.
поэтому чем меньше лишних полей и всяких кнопок тем меньше вероятность ошибки.
поэтому у меня в накладной пользователь не указывает номер счета рискуя вместо товара выбрать малоценку или указать не тот счет затрат.
поэтому у меня в накладной пользователь не указывает номер счета рискуя вместо товара выбрать малоценку или указать не тот счет затрат.
поэтому чем меньше лишних полей и всяких кнопок тем меньше вероятность ошибки.
… и тем меньше доступная функциональность.
А вообще — ничего, что я про программиста говорил, а не про пользователя? Программисту вы тоже доступ к функциональности обрежете?
две трети полей и кнопок в формах 1с в большинстве случаев вообще не используются.
а что прогамисту надо он легко добавит.
а что прогамисту надо он легко добавит.
а что прогамисту надо он легко добавит.
Вот он-то и облажается. Потому что не понимает бизнеса, и не знает, что надо, а что нет.
значит спросит у заказчика.
так работают програмисты в странах, где кремниевые долины. каждый занимается своим делом.
Профессия тыжпрограмист — только у нас.
так работают програмисты в странах, где кремниевые долины. каждый занимается своим делом.
Профессия тыжпрограмист — только у нас.
значит спросит у заказчика.
Который тоже нифига не знает, что ему надо.
так работают програмисты в странах, где кремниевые долины. каждый занимается своим делом.
Серьезно? То есть большой и отдельной дисциплины анализа «в странах, где кремниевые долины» нет? И англоязычная литература по этому поводу (заметим, русскоязычной практически не существует) написана в пустоту?
Который тоже нифига не знает, что ему надо.
Знает. ВСЕГДА знает. Потому что это его бизнес и правильно так как говорит заказчик что бы програмист о себе не возомнил. И не проблема заказчика что програмист не хочет его выслушать потому что ему хочется впарить готовое а не разбиратся и переписывать.
Так работают на западе. И так я работаю в аутсорсе. Заказчик говорит — надо так и ему делают так. Потому что он платит за то что сделали как он считает правильным с точки зрения его бизнеса а не начали расказывать ему что он ничего не понимает.
И западный програмист садится и решает задачу а не ищет причину почему ее не надо так решать.
То есть большой и отдельной дисциплины анализа
она не для програмистов. Там нет професии тыжпрограмист.
Даже при совке у нас по почтовом ящике было отделы теоретиков (аналитиков) отделы програмистов и даже посередине — отделы алгоритмистов.
Знает. ВСЕГДА знает.
Нет. Иначе бы не было целой специализации бизнес-анализа (возникшей на том самом западе, на который вы ссылаетесь).
она не для програмистов.
Именно, она не для программистов. Она для специальных людей, которые сначала достают из заказчика тайное знание, про которое тот сам не знал, что оно у него есть, а потом ставят задачу разработчикам.
Заказчик говорит — надо так и ему делают так. Потому что он платит за то что сделали как он считает правильным с точки зрения его бизнеса а не начали расказывать ему что он ничего не понимает.
Угу. А потом его система работает неправильно, и он винит программиста. Пять лет плавали, спасибо.
.
это просто инструмент. Заказчик говорит что ему нужно. А исполнитель выбирает тот или иной инструмент.
он знал но не мог сформулировать технически правильно для постановки задачи. Но он ЗНАЛ. Кстати интервьирование заказчика тоже не котируется в доморощеных разрабов — они и так все знают.
А какой критерий правильности?
Если исполнитель делает так как хочет заказчик, как бы абсурднв е были требования, никаких претензий быть не может. Вот когда вы сделали по своему тогда конечно — с точки зрения заказчика это не правильно.
я как раз занимаюсь проектом по логистике складов для англичан. Сделал как положено проверки все типа — не может быть отрицательное количество на складе.
А он говорят — убери может быть. Потому как товар может придти на склад раньше чем накладная будет введена в систему. Но физически его уже можно продавать. и пока не введена приходная накладная на складе будет минус. С точки зреня академической правильности — минус на складе абсурд а с точки зрения заказчика так должно быть — так у ни бизнес работает и им виднее.
Вот потому о и плавали. Не надо свои умняки выдвигать — сделайте в точности что заказчик хочет. не может сформулировать не начинайте писать пока все не вытрясите с него и не убедитесь что поняли его правильно.
Иначе бы не было целой специализации бизнес-анализа
это просто инструмент. Заказчик говорит что ему нужно. А исполнитель выбирает тот или иной инструмент.
сначала достают из заказчика тайное знание, про которое тот сам не знал, что оно у него есть
он знал но не мог сформулировать технически правильно для постановки задачи. Но он ЗНАЛ. Кстати интервьирование заказчика тоже не котируется в доморощеных разрабов — они и так все знают.
А потом его система работает неправильно, и он винит программиста.
А какой критерий правильности?
Если исполнитель делает так как хочет заказчик, как бы абсурднв е были требования, никаких претензий быть не может. Вот когда вы сделали по своему тогда конечно — с точки зрения заказчика это не правильно.
я как раз занимаюсь проектом по логистике складов для англичан. Сделал как положено проверки все типа — не может быть отрицательное количество на складе.
А он говорят — убери может быть. Потому как товар может придти на склад раньше чем накладная будет введена в систему. Но физически его уже можно продавать. и пока не введена приходная накладная на складе будет минус. С точки зреня академической правильности — минус на складе абсурд а с точки зрения заказчика так должно быть — так у ни бизнес работает и им виднее.
Пять лет плавали, спасибо.
Вот потому о и плавали. Не надо свои умняки выдвигать — сделайте в точности что заказчик хочет. не может сформулировать не начинайте писать пока все не вытрясите с него и не убедитесь что поняли его правильно.
это просто инструмент. Заказчик говорит что ему нужно. А исполнитель выбирает тот или иной инструмент.
Чтобы выбирать, нужно иметь такой инструмент в арсенале (или хотя бы знать о его наличии), и обладать достаточной квалификацией, чтобы сделать выбор. А вы говорите — программисту не надо ничего знать в предметной области.
он знал но не мог сформулировать технически правильно для постановки задачи. Но он ЗНАЛ.
Не. Понимаете, «заказчик» — это аморфная организация. С вами говорит конкретный человек, который что-то знает — вот только не факт, что это что-то имеет отношение к задаче. Предположим, с вами говорит «технический специалист», и он знает, что задача сводится к «добавьте здесь поле, здесь кнопку, здесь вычисление по формуле». Та ли эта задача, которая нужна заказчику? А не факт. Возможно, заказчику — как организации — нужно выполнение очередного постановления четыреста-шышнадцать-бис, которое прилетело вчера со сроком послезавтра, и кто-то внутри решил, что его можно выполнить этим полем и этой кнопочкой. Но точно ли у них достаточно квалификации для принятия решений? Знают ли они, что 416/бис ссылается на 408-г, а то попадает под 112-ФЗ, в котором написано, что при учете таких активов необходимо еще и учитывать а, б и г?
А какой критерий правильности?
Достижение бизнес-целей заказчика.
Если исполнитель делает так как хочет заказчик, как бы абсурднв е были требования, никаких претензий быть не может.
Не может, но будут. Потому что заказчик несет убытки (в варианте с госухой — получает претензии).
Не надо свои умняки выдвигать — сделайте в точности что заказчик хочет. не может сформулировать не начинайте писать пока все не вытрясите с него и не убедитесь что поняли его правильно.
Угу, особенно это смешно звучит, когда заказчик считает, что он уже все сказал, что там непонятного, и сделать надо позавчера.
Чтобы выбирать, нужно иметь такой инструмент в арсеналено не програмисту
Не. Понимаете, «заказчик» — это аморфная организация. С вами говорит конкретный человек, который что-то знает — вот только не факт, что это что-то имеет отношение к задаче.
заказчик не аморфный хотя бы потому что что у него конкретный счет в банке с котрого ы хотите отстегнуть себе на кусок хлеба. Остальное проблема комуникации. с той стороны может быть конкретный человек не умеющий обьяснить так же как и с вашей человек не умеющий понять
Достижение бизнес-целей заказчика.которые определяет он а не вы.
Не может, но будут. Потому что заказчик несет убытки (в варианте с госухой — получает претензии)но вы можете его послать куда подальше. а в случае если он скажет — вы же говорили так правильней — не сможете, потому что полезли менять бизнес правила его бизнеса
. когда заказчик считает, что он уже все сказал, что там непонятного, и сделать надо позавчера.
тогда сделайте ему ручкой. Или идите ва-банк.
но не програмисту
А кому?
заказчик не аморфный хотя бы потому что что у него конкретный счет в банке с котрого ы хотите отстегнуть себе на кусок хлеба.
Вы не можете поговорить со счетом в банке.
которые определяет он а не вы.
Не вопрос. Но далеко не факт, что он хорошо знает, как их достигать.
но вы можете его послать куда подальше.
То есть отказаться от клиента (и от денег заодно)?
>Знает. ВСЕГДА знает.
Заказчик знает на уровне — «Ой, а давайте сделаем, чтобы у нас еще и вот эта фиговина считалась». Product Owner — предлагает, а вот чтобы ээто считалось — тогда давайте изменим это, и вот это, и еще 5 мест, и вот еще новую фигню вот в этом месте добавим. После чего бизнес-аналитик собственно анализирует и описывает задачу на изменения так, чтобы было понятно, где и что именно придется править программистам, ну и дальше уже разработка(хотя например у нас на проекте еще был этап ревью Acceptance Criteria от разработчиков BD, FE, BE и от QA). Если вам все попадало в виде готовой задачи — это конечно хорошо. но это далеко не всегда так, особенно в крупных проектах.
Заказчик знает на уровне — «Ой, а давайте сделаем, чтобы у нас еще и вот эта фиговина считалась». Product Owner — предлагает, а вот чтобы ээто считалось — тогда давайте изменим это, и вот это, и еще 5 мест, и вот еще новую фигню вот в этом месте добавим. После чего бизнес-аналитик собственно анализирует и описывает задачу на изменения так, чтобы было понятно, где и что именно придется править программистам, ну и дальше уже разработка(хотя например у нас на проекте еще был этап ревью Acceptance Criteria от разработчиков BD, FE, BE и от QA). Если вам все попадало в виде готовой задачи — это конечно хорошо. но это далеко не всегда так, особенно в крупных проектах.
Заказчик знает на уровне — «Ой, а давайте сделаем, чтобы у нас еще и вот эта фиговина считалась».
В этом и задача разраба или внедренца — проинтервьюировать заказчика и перевести требования с его уровня на технический.
Перевести а не придумать свое взамен.
Внедрение своего (оно же уже написано только бабло забирай) заканчивается не добром а тем чем заканчивается внедрение большинства систем.
Open source. Кросплатформенность.
Интересненько.
Веб приложение
Чет подозрительно.
PHP
Ясно, тему дальше можно не читать.
Автор, понимаете какое дело, ни клиентам, ни внедренцам, ни даже программистам не нужна никакая альтернатива. Представьте стандартную компанию занимающуюся внедрением 1С и стандратного клиента, который хочет себе установить эту 1С.
Что нужно компании:
1. Стабильность системы — дабы завтра не краснеть перед клиентом
2. Готовая трудовая база — чтоб легко можно было заменить одного 1С программиста/внедренца на другого
3. Прибыль — чтоб можно было сказать клиенту «Ну это 1С, она не дешевая и внедрять ее нужно уметь»
4. Готовое решение — чтоб ничего не допиливать, а ставить из коробки
Что нужно клиенту:
1. Стабильная и известная система, чтоб не хуже чем в соседнем магазине
2. Стоимость, а часто низкая (или нулевая) стоимость системы это минус. Ну не понимает клиент бесплатных систем
Ваше решение не отвечает ни одному из этих задач.
Предлагается хранить все документы в одной таблице в блобе, упакованными в XML
Я хочу получить документ типа «Счет» с контрагентом «Васюткин Д.И» среди 40к счетов. Как мне это сделать?
Все заданные выше вопросы риторические.
> Я хочу получить документ типа «Счет» с контрагентом «Васюткин Д.И» среди 40к счетов
я бы еще добавили «в которых фигурирует товар „Швейные машинки Зингер“ в количестве от 5 штук и более зарезервированные по складу в городе Самаре»
это еще более похоже на реальный запрос пользователя системы
я бы еще добавили «в которых фигурирует товар „Швейные машинки Зингер“ в количестве от 5 штук и более зарезервированные по складу в городе Самаре»
это еще более похоже на реальный запрос пользователя системы
Ну это без програмиста и в 1С нельзя сделать.
И 1с не построит оптимальную выборку по реляционным данным.
Черти сколько лет 1с вообще было на DBF файлах. И как то такие выборки делали.
Поверте у меня это выберется намного быстрее.
Да и выборки такие большая редкость на практике.
И 1с не построит оптимальную выборку по реляционным данным.
Черти сколько лет 1с вообще было на DBF файлах. И как то такие выборки делали.
Поверте у меня это выберется намного быстрее.
Да и выборки такие большая редкость на практике.
Поверте у меня это выберется намного быстрее.
Благодаря чему?
а почему оно должно быть медленнее?
подобный код 1С превратит в SQL запрос не самым оптимальным образом. Она вынуждена будет переджойнить минимум полдесятка таблиц. Причем таблиц которые сами по себе сгенерены не самой оптимальной структуры (потому что чструктура меняется динамически при редактировании структуры документов и справочников).
у меня — поиск по одному текстовому полю. Даже xpath не нужен — -нет необходимости распаковывать XML на ходу.
Поверьте Mysql это обработает на порядок быстрее. Потому и денормализаци потому и XML
с учетом поиска по резервированию — поиск по этой же таблице уже закешированой в память.
но на самом деле это надуманая ситуация. Подобные выборки большая редкость. и ни в одной СТАНДАРТНЫХ конфигурации 1с таких выборок нет. Это экзотическая однократная ручная выборка.
Могу придумать запрос на котором 1с напрочь ляжет. Но на фига такие соревнования с практической точки зрения
подобный код 1С превратит в SQL запрос не самым оптимальным образом. Она вынуждена будет переджойнить минимум полдесятка таблиц. Причем таблиц которые сами по себе сгенерены не самой оптимальной структуры (потому что чструктура меняется динамически при редактировании структуры документов и справочников).
у меня — поиск по одному текстовому полю. Даже xpath не нужен — -нет необходимости распаковывать XML на ходу.
Поверьте Mysql это обработает на порядок быстрее. Потому и денормализаци потому и XML
с учетом поиска по резервированию — поиск по этой же таблице уже закешированой в память.
но на самом деле это надуманая ситуация. Подобные выборки большая редкость. и ни в одной СТАНДАРТНЫХ конфигурации 1с таких выборок нет. Это экзотическая однократная ручная выборка.
Могу придумать запрос на котором 1с напрочь ляжет. Но на фига такие соревнования с практической точки зрения
1C может быть, я не знаю. Но вы то можете с успехом «переджоинить» сколько нужно таблиц и сделать это оптимальным образом.
И почему структура таблиц не будет оптимальной? Чем добавление одного атрибута отличается от добавления атрибута в ваш XML?
И почему структура таблиц не будет оптимальной? Чем добавление одного атрибута отличается от добавления атрибута в ваш XML?
добавление атрибута в 1с — это добавление поля в таблицу.
это в лучшем случае. А если там до сих пор как в семерке то добавление описания атрибута в таблицу структуры документа. и о реляциях можно забыть.
Добавление атрибута в XML не меняет структуру таблиц БД и поэтому не надо ничего джойнить. Даже SQl не надо коректировать. Его вообше не надо писать в большинстве случаев.
Опять же как я уже писал — большинство бизнес выборок типа сколько товара на складе делается по таблице аналитики а не по документам. По документам это нештатная ситуация.
это в лучшем случае. А если там до сих пор как в семерке то добавление описания атрибута в таблицу структуры документа. и о реляциях можно забыть.
Добавление атрибута в XML не меняет структуру таблиц БД и поэтому не надо ничего джойнить. Даже SQl не надо коректировать. Его вообше не надо писать в большинстве случаев.
Опять же как я уже писал — большинство бизнес выборок типа сколько товара на складе делается по таблице аналитики а не по документам. По документам это нештатная ситуация.
а почему оно должно быть медленнее?
Может потому что вам придется 40к записей сначала получить из базы, потом их в цикле пройти, а затем для каждого получить некоторые связи?
вы все равно не сможете обеспечить реляционные связи для всех фантастических случаев.
Впрочем могу сделать выборку с помощью XPath и тогда могу и связать.
а еще могу отсечь доки с таким контрагентом, периодом по дате и коичеством по товару через аналитику — там мгновеннго и получу уже меньший набор документов
но я не вижу смысла усложнять систему чтобы оьеспечить скорость для экзотических выборок мало встречающихся в реальном учете.
Впрочем могу сделать выборку с помощью XPath и тогда могу и связать.
а еще могу отсечь доки с таким контрагентом, периодом по дате и коичеством по товару через аналитику — там мгновеннго и получу уже меньший набор документов
но я не вижу смысла усложнять систему чтобы оьеспечить скорость для экзотических выборок мало встречающихся в реальном учете.
вы все равно не сможете обеспечить реляционные связи для всех фантастических случаев
Проставив индексы на внешние ключи, очень даже смогу.
Впрочем могу сделать выборку с помощью XPath и тогда могу и связать
Выборку то вы следать должны прежде чем XPath'зить по XML.
но я не вижу смысла усложнять систему чтобы оьеспечить скорость для экзотических выборок мало встречающихся в реальном учете
В реальном учете может быть любая выборка. И когда эта любая выборка понадобится, вы не сможете сказать клиенту — извините, но такой выборки быть не должно по планам. Будьте любезны, обойдитесь более простыми выборками.
я выполню любую выборку. Но такие экзотические большая редкость и в таких редких случаях не проблема десяток секунд подождать.
Зато сэкономлю десятки дней а коиент десятки денег на внедрении остального.
на любой системе можно придумать выборку которая ее положит.
Зато сэкономлю десятки дней а коиент десятки денег на внедрении остального.
на любой системе можно придумать выборку которая ее положит.
я выполню любую выборку
Выполнить любую выборку можно и без использования компьютера.
Но такие экзотические
Откуда такие сведения?
на любой системе можно придумать выборку которая ее положит
Вашу систему положит любая выборка, которая потребует обращения внутрь XML.
Ну это без програмиста и в 1С нельзя сделать.
В общем случае — можно без программиста. Есть такая штука — СКД называется. Вот она и позволяет такие вещи делать без программиста.
На перечисление того, что есть в 1С из того, что автор задолбается делать — уйдет куча времени. Ну и да, начать можно с СКД… :)
Ну это без програмиста и в 1С нельзя сделать
Программист никакой не нужен — все работает из коробки. Были перечислены стандартные действия стандартных пользователей 1С, которые пользуются стандартными складскими отчетами (в лоб отчет «Товары в резерве на складе», но эту же информацию можно получить еще в нескольких других отчетах по анализу остатков и движений склада).
исходя из этого не можгут существовать проги не 1С. не могут существовать опенсорс бизнес приложения и т.д.
но они есть. И будет еще одно как бы вам это не претило.
но они есть. И будет еще одно как бы вам это не претило.
ну вот я доделаю и будет соответствовать. Пусть не самого среднего но в отличие от паруса человек не сядет «на иглу» разрабам.
Была у нас попытка миграции с 1С 7.7 на Парус. Жесть жестяная. Наши 1С-ники офигевали когда простая и привычная для них задача в 1С решалась в Парусе таким образом: «нууу, тут такого нет, надо написать процедурку». И так практически по каждому вопросу. Сначала они удивлялись, потом офигевали, потом уже просто тупо ржали. Потом 2008 год, начальство одумалось и в конце концов мигрировали 7.7 -> 8. Получилось быстрее, дешевле и привычнее для пользователей (а для многих из них изменение надписи на кнопочке с «ОК» на «Да» уже трагедия).
ну я и старюсь делать по максимуму привычно для тех кто с 1с работал. и поэтому не подходит западные системы.
а для того и PHP и простая система хранилища чтобы допилить было проще чем в 1С не то что в хранимках.
а для того и PHP и простая система хранилища чтобы допилить было проще чем в 1С не то что в хранимках.
В любой системе, используемой бизнесом есть всего один-единственный критерий: эффективность. Долбаная 1С (как вы уже поняли, фанатом ее я не являюсь) эффективна прямо здесь и прямо сейчас во многих областях и случаях. Чтобы ее победить не нужна «технически более совершенная» или «более правильная» — нужна всего лишь более эффективная.
Простой пример: хочу сделать небольшой интернет-магазин, нужны сайт и система для обработки прайс-листов (импорт/экспорт/остатки/обработка и т.д.). Есть несколько вариантов:
а)написать самому (неважно на чем) — это, условно говоря, займет 1 год работы по вечерам и 0 денег потому что буду писать сам, а жить в это время на что-то нужно
б)нанять кого-то: 3 месяца и (условно говоря) 500 тысяч плюс еще сколько-то на доводку (не забываем что точно определить требуемое кол-во времени и денег никто еще не смог)
в)взять 1С за 75 тысяч (это вместе с Битриксом) + нанять кого-то или купить уже готовую интеграцию — уложимся по времени в месяц, по деньгам в 150 тысяч.
Для любого бизнесмена выбор из этих трех вариантов абсолютно очевиден: вариант «В». Потом что: а)дешево б)просто в)прямо сейчас, пока есть деньги и конкуренты не затоптали. Что? 1С плохая или некошерная, Битрикс говорят тормозит и вообще опенсорс рулит? Да и пофигу, вот деньги и давайте быстрее запускаться, желательно «еще вчера».
Как уже кто-то здесь писал у 1С есть несколько достоинств, сводящих на нет все остальные недостатки (ооо, а их хватает с избытком!): дешевизна, куча типовых решений, огромная инфраструктура, ну и самое главное, как орал истеричный Балмер: https://www.youtube.com/watch?v=Vhh_GeBPOhs"
Простой пример: хочу сделать небольшой интернет-магазин, нужны сайт и система для обработки прайс-листов (импорт/экспорт/остатки/обработка и т.д.). Есть несколько вариантов:
а)написать самому (неважно на чем) — это, условно говоря, займет 1 год работы по вечерам и 0 денег потому что буду писать сам, а жить в это время на что-то нужно
б)нанять кого-то: 3 месяца и (условно говоря) 500 тысяч плюс еще сколько-то на доводку (не забываем что точно определить требуемое кол-во времени и денег никто еще не смог)
в)взять 1С за 75 тысяч (это вместе с Битриксом) + нанять кого-то или купить уже готовую интеграцию — уложимся по времени в месяц, по деньгам в 150 тысяч.
Для любого бизнесмена выбор из этих трех вариантов абсолютно очевиден: вариант «В». Потом что: а)дешево б)просто в)прямо сейчас, пока есть деньги и конкуренты не затоптали. Что? 1С плохая или некошерная, Битрикс говорят тормозит и вообще опенсорс рулит? Да и пофигу, вот деньги и давайте быстрее запускаться, желательно «еще вчера».
Как уже кто-то здесь писал у 1С есть несколько достоинств, сводящих на нет все остальные недостатки (ооо, а их хватает с избытком!): дешевизна, куча типовых решений, огромная инфраструктура, ну и самое главное, как орал истеричный Балмер: https://www.youtube.com/watch?v=Vhh_GeBPOhs"
Чтобы ее победить не нужна «технически более совершенная» или «более правильная» — нужна всего лишь более эффективная.
верно. Я описываю техническую сторону потому что это место где тусуются девелоперы. Но смысл технических решений не в том чтобы ког то удивить. Они разработаны повышения эфективности системы. Ине для того чтобы переплюнуть 1с в целом — это нереально. А для того чтобы предлоить эфективне решение там где с 1с больше гемора чем пользы. К сожалению большинство альтернатив не менее геморны.
и в этом проблема.
Для любого бизнесмена выбор из этих трех вариантов абсолютно очевиден: вариант «В»
чтобы быстро запустить — да. Вопрос сколько потом саппорт обойдется.
и вам не кажется что битрикс для обрабки прайсов как то громоздковато.
Так вот то что пытаюсь сделать — это вариант Г.
И кстати спасибо за идею — у меня есть демо CMS с модулем инет магазина. прикручу-ка я в будущем этот модуль к учетной системе — тот же сайт и интегрировать ничего не надо. Тем более даже малый бизнес ща старается иметь если не магазит то какой то каталог с продуктами и услугами.
> чтобы быстро запустить — да. Вопрос сколько потом саппорт обойдется.
Так в том-то и дело, что это не вопрос. Стоимость поддержки 1С хорошо известна, и она в общем-то стоит сущую ерунду для любого бизнеса.
Вот стоимость вариантов А, Б и тем более Г — это реально «темная лошадка» и непонятные риски. Сэкономить сто долларов в месяц, чтобы рискнуть крупными штрафами, неустойками и потерей прибыли, например?
Так в том-то и дело, что это не вопрос. Стоимость поддержки 1С хорошо известна, и она в общем-то стоит сущую ерунду для любого бизнеса.
Вот стоимость вариантов А, Б и тем более Г — это реально «темная лошадка» и непонятные риски. Сэкономить сто долларов в месяц, чтобы рискнуть крупными штрафами, неустойками и потерей прибыли, например?
она в общем-то стоит сущую ерунду для любого бизнеса.
для мелкого далеко не ерунда. За ерунду програмер 1С даже задницу свою не подымет.
и то что многие ломаные версии используют тоже говорит о то что таки не ерунда.
Просто деватся некуда.
Вот стоимость вариантов А, Б и тем более Г — это реально «темная лошадка» и непонятные риски.
бизнес всегда риск. и не всегда наличие 1с спасет от штрафов — там тоже полно косяков и многие из них изза сложности системы не сразу увидишь.
DrPass: Абсолютно с вами согласен, добавлю еще немного: знаете сколько по статистике ИП закрывается в первые 3 года своего существования? Около 80%! Какая уж там поддержка, главное быстро стартовать, отбить вложенные деньги (зачастую взятые в кредит — ну по крайней мере до 2014-2015 так делали) и заработать сколько получится. Получилось — отлично, вот тут уже можно и подумать про поддержку, развитие и прочие штуки. Не получилось — ну что же, сумма вложений была небольшой, жалко и все такое.
Ни разу не встретил слов «сканер штрих-кодов», «ТСД», «кассовый аппарат», «весы» и т.д. Сабжевая система что — принципиально не работает с торговым оборудованием?
1С тоже не шибко работает с торговым оборудованием. Хотя бы потому что оно все разное. Как и разные протоколы клиент банка.
Сабжевая система предусматривает API черезх котрое можно легко подключить любое соременное оборудование имеющее на борту какую нибудь windows CE и может лихо ходить по сети и дергать любой вебсервис.
А вообще статья не про систему а про принципы разработки таких систем — это хабр а не бухгалтерский форум
Сабжевая система предусматривает API черезх котрое можно легко подключить любое соременное оборудование имеющее на борту какую нибудь windows CE и может лихо ходить по сети и дергать любой вебсервис.
А вообще статья не про систему а про принципы разработки таких систем — это хабр а не бухгалтерский форум
Не знаю насчет 1С, так как сам «работаю» очередную… нет, ни в коем случае не убийцу. Удобный для нас аналог с массой такого чего у 1С никогда не было и не будет, скажем так. Так вот, практически для всего встреченного оборудования есть драйвер/dll с инструкцией настройки под 1С и (иногда по отдельному запросу) описание протокола. Тоесть, либо набор инструкций для «1С-ника», либо писать самому. Мы — пишем сами.
Касаемо того, что сабжевая система предусматривает АРІ для подключения wince — это хорошо. Да вот только во-первых в сканерах штрих-кодов и весах wince нету, а есть только описание последовательностей байтиков да dll-ка. Ну и во-вторых как-то не очень сочетаются между собой слова «современное оборудование» и «wince».
И как раз потому, что хабр — технический форум, мне, как «борцуну с 1С» интересно, как мои соотечественники собираются подключать, например, фискальный регистратор к каждому торговому месту для обеспечения требований законодательства. А в регистраторах — на минуточку — тоже wince нету. А есть протокол и есть нюансы типа «регистратор ответил что чек №123 проведен, но в z-отчете этого чека почему-то нету». И без розруливания этих нюансов учетная система не нужна от слова «совсем».
И это еще не касаясь вопросов реальной многопользовательской работы с гигантским чудо-XML-ем.
Касаемо того, что сабжевая система предусматривает АРІ для подключения wince — это хорошо. Да вот только во-первых в сканерах штрих-кодов и весах wince нету, а есть только описание последовательностей байтиков да dll-ка. Ну и во-вторых как-то не очень сочетаются между собой слова «современное оборудование» и «wince».
И как раз потому, что хабр — технический форум, мне, как «борцуну с 1С» интересно, как мои соотечественники собираются подключать, например, фискальный регистратор к каждому торговому месту для обеспечения требований законодательства. А в регистраторах — на минуточку — тоже wince нету. А есть протокол и есть нюансы типа «регистратор ответил что чек №123 проведен, но в z-отчете этого чека почему-то нету». И без розруливания этих нюансов учетная система не нужна от слова «совсем».
И это еще не касаясь вопросов реальной многопользовательской работы с гигантским чудо-XML-ем.
Да вот только во-первых в сканерах штрих-кодов и весах wince нету, а есть только описание последовательностей байтиков да dll-ка.
в таком случае нужен драйвер для каждого типа оборудования. Новое оборудование и 1с уже беспомощна.
Но в любом случае у них может быть много готовых — они делают коробочный продукт в все такое.
В моем случае — берешь прогу с открытым кодом и допиливаешь особенности.
Вообще если речь о DLL и регистраторах без операционки. то тут по любому проблема хотя бы потому что сабж в виде вэб приложения.
Ну не бывает чтобы со всех сторон было хорошо. Я думаю один из вариантов — програмулька на делфи, к примеру, которая работает с dll и в другой стороны дергает API. все равно регистраор к компу подключается. А у которых на борту че посолиднее те работаю напрямую или через wifi (если речь штрих или rfid сканерах с котрыми по складу бегают)
И это еще не касаясь вопросов реальной многопользовательской работы с гигантским чудо-XML-ем.
нет там никаких проблем. опять же речь о малом бизнесе — не бувдет там тысяч запросов в секунду…
в таком случае нужен драйвер для каждого типа оборудования. Новое оборудование и 1с уже беспомощна.
Как я уже писал, с новым оборудованием все равно идет инструкция по подключению к 1С. А вам (и нам) надо самостоятельно писать драйвер. Без этого ваша (наша) супер-мега-учетная система никому не нужна.
Я думаю один из вариантов — програмулька на делфи, к примеру, которая работает с dll и в другой стороны дергает API.
А как же тогда заявленная кроссплатформенность и опенсорсность?
нет там никаких проблем. опять же речь о малом бизнесе — не бувдет там тысяч запросов в секунду
Зачем тысяч? Вот реальная ситуация. Бух делает отчет. Например, «взаиморасчеты с поставщиком». Менеджер забивает накладную от этого же поставщика. В торговом зале продается тот же товар, который есть в накладной менеджера. Мигает свет из-за коротнувшего холодильника. Фильтры/упсы есть не на каждом компе/свиче. Вопросс — что станется с чудо-XML-ем?
Как я уже писал, с новым оборудованием все равно идет инструкция по подключению к 1С. А вам (и нам) надо самостоятельно писать драйвер. Без этого ваша (наша) супер-мега-учетная система никому не нужна.
ну не всем нужно подключать торговое оборудование.
собственно я и не спорю что в 1с масса преимуществ.
но както существуют те немногое альтернативы для которых не выпускают драйвера.
А как же тогда заявленная кроссплатформенность и опенсорсность?так прога часть конкретного оборудования на конкретном месте.
А API оно универсальное.
Вопросс — что станется с чудо-XML-ем?
то же что и с чудо 1С. Либо успел сохранить документ либо нет.
Не понимаю проблемы.
Надеюсь вы не подумали что я храню документы в XML как файлы на на диске.
ни програмист ни тем более пользователь никак не касается XML.
ну не всем нужно подключать торговое оборудование.
Кому и зачем нужна учетная программа для малого бизнеса, которая не умеет работать с торговым оборудованием? В таких случаях ексель любому софту фору даст. Кроме того, как я уже говорил, через два месяца (или год и два месяца — в зависимости от большой политики) в нашей с вами стране любая учетная система должна будет работать как минимум с фискальным регистратором. И да — даже привел реальный сценарий работы с ним.
так прога часть конкретного оборудования на конкретном месте.
Тоесть если надо подключать торговое оборудование, «кросплатформенность» в пролете? Это уже не смешно.
то же что и с чудо 1С. Либо успел сохранить документ либо нет.
На всякий случай напоминаю, что я с 1С не работаю от слова «вообще» и в целом отношусь к этому поделию довольно прохладно. Мягко говоря.
Но интересовало другое — какова вероятность превращения в винигрет XML-хранилища в случае сбоев, в том числе аппаратных? И каким образом получена эта цифра (я о вероятности)? Какие тесты проводились?
Вы же не думаете, что у вас в малом бизнесе везде будут серверные стойки с двумя независимыми входными линями питания и УПС-ами?
Не понимаю проблемы.
Вот когда по вине вашего «либо сохранил либо нет» фирма понесет убытки, или хотя бы кто-то пару раз будет наново вносить накладную на сотню позиций (еще лучше — расходную), вот тут то понимание и придет.
Кому и зачем нужна учетная программа для малого бизнеса, которая не умеет работать с торговым оборудованием?
Мой склад или другие saas как работают? если работают конечно.
Для любого веб решеня стыковка с железом проблема — даже при наличии всех драйверов и описаний к ним.
На всякий случай напоминаю, что я с 1С не работаю
ну тематика статьи об 1с вот я и сравниваю.
Вот когда по вине вашего «либо сохранил либо нет» фирма понесет убытки, или хотя бы кто-то пару раз будет наново вносить накладную на сотню позиций (еще лучше — расходную), вот тут то понимание и придет.
не вижу разницы с 1С.
набивает накладную 99 позиций тут свет погас. И что?
Но интересовало другое — какова вероятность превращения в винигрет XML-хранилища в случае сбоев, в том числе аппаратных?
нулевая. Потому что нет никакого XML хранилища.
есть таблица документов в которой одна запись — один документ независимо от его структуры и сложности.
Либо записалось либо нет.
Мой склад или другие saas как работают? если работают конечно.
Тоесть все что вы умеете, это вручную вносить какие-то цифирки и генерировать отчеты? Тогда не называйте себя системой учета.
набивает накладную 99 позиций тут свет погас. И что?
Нормальная учетная система включается и продолжает работу с 99 позиции. Есть така весчь — ACID. Слыхали, нет?
нулевая. Потому что нет никакого XML хранилища.
Есть один большой XML в котором хранится много всего. Он не называется хранилищем поэтому он гарантированно всегда консистентен, я понял.
есть таблица документов в которой одна запись — один документ независимо от его структуры и сложности.
Либо записалось либо нет.
А, тоесть авария в процессе записи даже не рассматривалась. Вот все глупые — начиная от mysql и sqlite и заканчивая oracle и mssql — «они тупые», они че-то тестят, какие-то глупые аббревиатуры пишут, и только я один самый умный «либо записал либо нет вне зависимости от структуры». А заодно и от настроек ОСи, драйверов, винта и прочих обстоятельств.
В целом. Вы просили в начале вашей статьи критику и подсказки о промахах. Но критику вы не воспринимаете и подсказок не понимаете. Не только моих — об XML в этом топике не высказался только ленивый. Опять — все глупые, вы один самый умный? Тогда критику просили-то зачем?
Тогда не называйте себя системой учета.
ну да, в таком случае нет других систему учета кроме 1с — потому что к ним драйверов нет. Большинство ентерпрайз решений а не просто учетные системы — это веб решения. И там тоже нет встроеной стыковки с оборудованием. Это забота внедренца.
Встроеные возможности 1С кстати тоже весьма ограничены — без танцев с бубном там тоже не все запускается с полоборота…
А, тоесть авария в процессе записи даже не рассматривалась. Вот все глупые — начиная от mysql и sqlite и заканчивая oracle и mssql — «они тупые», они че-то тестят, какие-то глупые аббревиатуры пишут, и только я один самый умный «либо записал либо нет вне зависимости от структуры». А заодно и от настроек ОСи, драйверов, винта и прочих обстоятельств.
вообще не понимаю о чем вы. Я использую сервер БД для хранения данных. Он умеет обеспечить целостность данных при аварии. Замечательно. Я что должен делать кроме стартовать транзакцию перед внесением изменений в ИС и закомитить ее если все нормально.?
Нормальная учетная система включается и продолжает работу с 99 позиции. Есть така весчь — ACID. Слыхали, нет?
это не ACID а автосохранение. Не заметил такого в 1С.
ACID как раз не позволит ввести недоделаный документ в систему.
Зато может внести в систему проект документа.
Это было первой фичей, которую я по требованию заказчика в свою систему вносил еще в 90-х годах 8-)
Действительно, транзакция на документ — это клево, но вся предварительная работа тоже должна быть сохранена. Документ в статусе «набита гора данных, но сохранять рано» может жить неделями…
Кстати, насчет xml: консультировал недавно проект, в чем-то похожий. Сделали хранилище в постгре. Там есть поле в JSON, и постгре даже умеет внутри него практически реляционно искать. Да, еще, вы очень сильно заблуждаетесь, говоря про «экзотику» в запросах — это не экзотика, а ежедневная работа очень для многих… Я еще и не таких сценариев запроса могу накидать, поиск по паре полей в документе — это деццкий лепет.
Это было первой фичей, которую я по требованию заказчика в свою систему вносил еще в 90-х годах 8-)
Действительно, транзакция на документ — это клево, но вся предварительная работа тоже должна быть сохранена. Документ в статусе «набита гора данных, но сохранять рано» может жить неделями…
Кстати, насчет xml: консультировал недавно проект, в чем-то похожий. Сделали хранилище в постгре. Там есть поле в JSON, и постгре даже умеет внутри него практически реляционно искать. Да, еще, вы очень сильно заблуждаетесь, говоря про «экзотику» в запросах — это не экзотика, а ежедневная работа очень для многих… Я еще и не таких сценариев запроса могу накидать, поиск по паре полей в документе — это деццкий лепет.
вся предварительная работа тоже должна быть сохранена.
это сожно сдлеать но пока в учетных системах такой фичи не наблюдал. Не нак часто нынче вырубают свет чтобы усложнять сстему.
Там есть поле в JSON, и постгре даже умеет внутри него практически реляционно искать
реляция у меня в таблицах с аналитикой. XML — для подстраховки.
в запросах — это не экзотика, а ежедневная работа очень для многих
это в 1с так. Я об этом и писал. Там навернули много возможностей но теперь это так сложно что для простого бухгалтера бесполезно.
у меня есть опыт сопровождения учетных систем. Где нормально ведется работа никакие экзотические запросы не требуются.
как по вышему вообще могли вести раньше учет в бумажной форме если такие витиеватые запросы обьективно были бы нужны.
а если стоит задача бизнес-нализа, датамайинга и прочего — так для этого специальные инструменты олапы, многомерные запросы. пивот таблицы и тд.
Я еще и не таких сценариев запроса могу накидать,
и я могу. Но ни разу не видел чтобы мне это накидывали бухгалтера которых я сопровождал.
а если это какой аналитик так выгружу в ексель данные с хранилища и пусть крутит там многомерную диаграмму как хочет.
Это не задача УЧЕТНОЙ системы.
Менеджер забивает накладную от этого же поставщика. В торговом зале продается тот же товар, который есть в накладной менеджера.
Если не против, я смещу акцент с физической целостности данных на логическую. Пусть менеджер меняет цену в заказе, кладовщик делает подтверждение наличия на складе, а логист делает назначение на водителя. Все делают свои действия одновременно, так как это параллельные независимые процессы. Что в результате будет в базе? Не перезатрет ли последний из акторов действия предыдущих?
.В дангм случае бесплатная, кросплатформенная и простая. Что кстати не тносится ни к одному продукту названому вами вышеЗа БОСС не скажу, но исходники открыты. Nexus — бесплатная и простая, Compiere — бесплатная, не очень простая, но зато полная ERP.
.Предметную область понимает клиент — то есть бухгалтер. Зачем разрабу знать какие надо проводки — ему надо знать какой функцией их выполнить..
:) с таким видением предметной области увлечь других разработчиков, работать на новом движке будет проблематично. Их бы скорее увлекла идея пойти за человеком, который понял что-то важное про учёт, чего другие ещё не поняли. Все и так умеют написать функцию, которая делает проводки. Новый движок, единственным преимуществом которого является простота, но который надо изучать и с непонятными наперёд «особенностями» никому не нужен.
Nexus — бесплатная и простая, Compiere — бесплатная, не очень простая, но зато полная ERP.
Эти системы надо месяцами допилывать напильником под наш учет. Разве что удастся впихнуть as is убедивши клиента что
с таким видением предметной области увлечь других разработчиков, работать на новом движке будет проблематично
никто не запрещает изучать предметную область. например человек хочет быть на саппорте и зарабатывать на этом.
единственным преимуществом которого является простота, но который надо изучать и с непонятными наперёд «особенностями» никому не нужен.
и движок 1с в таком случае был бы никому не нужен. Потому то они и делают конфигурации которые уже модно пользовать.
чем я и занимаюсь.
Скажите, вы Odoo (бывшая OpenERP) смотрели? Что с ней не так?
То же, что и комментом выше — нужно допиливать? Но ведь это проще, чем с нуля? Или есть принципиальные претензии?
То же, что и комментом выше — нужно допиливать? Но ведь это проще, чем с нуля? Или есть принципиальные претензии?
В том то и дело что объем допиливания там больше чем с нуля.
Потому что нужно не только допилить а допиливать постоянно — а там это весьма трудоемко.
небесплатная судя по триалу.
питон -само по себе неплохо но прорамеров меньше и сложнее разворачивать.
не русифицированя не заточена а наших бухгалтеров (если сть русская версия — дайте ссылку)
это продукт для них.
код не могу посмотреть где но уверен что древний с проблемами с модульностью
то что я вижу — это есть законченая система для западного пользователя.
как то так.
Потому что нужно не только допилить а допиливать постоянно — а там это весьма трудоемко.
небесплатная судя по триалу.
питон -само по себе неплохо но прорамеров меньше и сложнее разворачивать.
не русифицированя не заточена а наших бухгалтеров (если сть русская версия — дайте ссылку)
это продукт для них.
код не могу посмотреть где но уверен что древний с проблемами с модульностью
то что я вижу — это есть законченая система для западного пользователя.
как то так.
Это система с открытым кодом. У них есть Enterprise версия с доп. функционалом и поддержкой, именно триал этой версии предлагают на главной. Сравнение здесь: www.odoo.com/editions — ссылка на скачивание там же (+ есть репозиторий на GitHub). Русификация встроена, заточки нет, это дорабатывается самостоятельно и есть наработки сообщества.
Проблем с модульностью быть не должно — там почти всё выделено в модули как раз. Ссылки на код выше, посмотрите и скажите, что думаете.
Я никак не связан с odoo, просто давненько наблюдаю (использовать пока не подвернулось возможности), поэтому интересны мнения других людей о ней.
Проблем с модульностью быть не должно — там почти всё выделено в модули как раз. Ссылки на код выше, посмотрите и скажите, что думаете.
В том то и дело что объем допиливания там больше чем с нуля.Учитывая, что вы пока не знакомы с системой (что странно для ищущего альтернативу 1С, ведь Odoo это крупнейшая ERP с открытым кодом, её сложно пропустить, если искать) и её кодом, как вы можете это знать?
Потому что нужно не только допилить а допиливать постоянно — а там это весьма трудоемко.
Я никак не связан с odoo, просто давненько наблюдаю (использовать пока не подвернулось возможности), поэтому интересны мнения других людей о ней.
Odoo это крупнейшая ERP с открытым кодом, её сложно пропустить, если искать) и её кодом, как вы можете это знать
я ее смотрел как многие другие. Все без исключения надо перепиливать.
Потому они у нас и не приживаются.
Все без исключения надо перепиливать.
Абсолютизация — один из признаков заблуждения :-)
В Odoo огромное количество самых разных модулей, которые можно использовать прямо из коробки.
Не стоит судить об Оду по состоянию модуля Accounting for Russia, это малая ее часть (и тут да, надо много чего делать и доводить).
код не могу посмотреть где но уверен что древний с проблемами с модульностью
Не знаю, но уверен. Очень смешно :-)
Odoo — самая гибкая и модульная система из всего что я видел лет за 15 работы в IT.
Архитектура выстрадана за много лет эволюции продукта.
В общем, не несите чепуху.
Отговаривать вас ввязываться в такой прожект, с учётом того, что вы свой движок уже сделали, думаю, поздно.
На данном этапе, можно только пожелать вам поскорее дойти до внедрений у реальных клиентов. С вашей энергией, есть вероятность, что вам удастся собрать единомышленников и даже что-то заработать на такой системе.
В любом случае, это будет интересный профессиональный опыт.
На данном этапе, можно только пожелать вам поскорее дойти до внедрений у реальных клиентов. С вашей энергией, есть вероятность, что вам удастся собрать единомышленников и даже что-то заработать на такой системе.
В любом случае, это будет интересный профессиональный опыт.
Ох. Даже не знаю с чего начать. Ну хорошо давайте с начала. Вы себе сложность системы явно не представляете. Я вот писал на хабр статью про типовую схему биллинга и там замечу учет весьма и весьма урезанный именно под задач биллинга и то таблиц не маленько. А вы тут на 1С замахнулись. Про отчеты посмеялся. Особенно мы будем печатать из браузера. Пробовали? Вы вообще в курсе что для нормальной печати из браузера для документа надо прописать отдельный css? И что сам по себе html не очень то хорошая вещь для отчетов. Он работает более менее для отчетов где одна две таблицы и все. Если что посложнее туши свет.
Выбор языка тоже не фонтан. У вас потом с проверками данных будет очень много заморочек. Как раз из-за слабой типизации. Будет «Ой мы случайно в деньги положили описание!»
Дополнительно прежде чем приступать сначала изучите предметную область. Хотя бы на уровне двойной записи.
Выбор языка тоже не фонтан. У вас потом с проверками данных будет очень много заморочек. Как раз из-за слабой типизации. Будет «Ой мы случайно в деньги положили описание!»
Дополнительно прежде чем приступать сначала изучите предметную область. Хотя бы на уровне двойной записи.
Ох. Даже не знаю с чего начать.
начните с перечитывания коментов — я уже на все вопросы ответил.
Вы себе сложность системы явно не представляете.
вы этого знать не можете. у меня многолетний опыт програмирования в том числе работы с учетными системами и 1С.
А вы тут на 1С замахнулись
я не замахнулся на 1С — я не идиот. Я делаю альтернативу а не аналог.
альтернативу для тех для кого 1С неоправдано хлопотное решщение.
Особенно мы будем печатать из браузера
там чернобелая табличная верстка с инлайн стилями. пока нормально — надо будет добавлю media атрибуты — проект в разработке не все сразу.
да и кому эта печать скоро будет нужна -все на электронку перейдут.
И что сам по себе html не очень то хорошая вещь для отчетов
да. Но зато не надо ничего другого. Тот же файл для печати, для просмотра на экране, для экспорта.
Он работает более менее для отчетов где одна две таблицы и все. Если что посложнее туши свет.
ну да. на навороченых сайтах HTML работает на на отчете нет.
цу меня там налоговая есть — довольно мудреный бланк и ничего.
да надо повозится — должна быть верстка одной таблицей со спанами чтобы не разьехалось в екселе.
но это HTML, а не спец построитель отчетов, — любой начинающий верстальщик сделает.
У вас потом с проверками данных будет очень много заморочек. Как раз из-за слабой типизации.
о тестировании слышали что нибудь?..
милионы сайтов, интернет магазинов и пр. работают на PHP и как то справляются с данными.
Дополнительно прежде чем приступать сначала изучите предметную область. Хотя бы на уровне двойной записи.
где вы увидели в этом проекте какие то проблемы с двойной записью?
о тестировании слышали что нибудь?..
О, кстати. А ваше решение покрыто автоматическими тестами? На каком уровне?
начните с перечитывания коментов — я уже на все вопросы ответил.
Кэп намекает, что все ответы должны были быть в статье, а не в комментариях :)
вы этого знать не можете. у меня многолетний опыт програмирования в том числе работы с учетными системами и 1С.
Извините, но по статье этого не видно.
я не замахнулся на 1С — я не идиот. Я делаю альтернативу а не аналог.
альтернативу для тех для кого 1С неоправдано хлопотное решщение.
Ну тогда неплохо бы указать в какие именно рамки будет укладываться это решение. Пока я к сожалению этого не вижу.
там чернобелая табличная верстка с инлайн стилями. пока нормально — надо будет добавлю media атрибуты — проект в разработке не все сразу.
да и кому эта печать скоро будет нужна -все на электронку перейдут.
На таком уровне работать будет. Дальше нет :)
ну да. на навороченых сайтах HTML работает на на отчете нет.
цу меня там налоговая есть — довольно мудреный бланк и ничего.
да надо повозится — должна быть верстка одной таблицей со спанами чтобы не разьехалось в екселе.
но это HTML, а не спец построитель отчетов, — любой начинающий верстальщик сделает.
Проблема в том что единственный формат который делает что на экране то на бумаге это PDF. Любой другой имеет свои нюансы. И вот html имеет их весьма много.
о тестировании слышали что нибудь?..
милионы сайтов, интернет магазинов и пр. работают на PHP и как то справляются с данными.
Покажите мне хоть одну систему учета на php и да так чтобы там бизнес-логику можно было писать на php да еще и не разработчикам.
Кэп намекает, что все ответы должны были быть в статье, а не в комментариях
все ответы в исходниках на гитхабе. статья описывает отдельные технологические идеи. Проект как таков тут несущественен.
Извините, но по статье этого не видно
это вопрос к вашему офтальмологу а не ко мне
На таком уровне работать будет.
на уровне достаточному обеспечить функциональность
Проблема в том что единственный формат который делает что на экране то на бумаге это PDF
не единственный. И с pdf не всегда все гладко.
И вот html имеет их весьма много.
пусть имеет его преимущества перевешивают. как минимум не надо на каждый документ писать код генерации PDF
и какая разница для накладной сколько пикселей будет высота наименования товара.
Покажите мне хоть одну систему учета на php и да так чтобы там бизнес-логику можно было писать на php да еще и не разработчикам.
не существует ни на каком языке учетных систем где бизнес логику пишут не разработчики. 1С тоже рассчитывали что бухгалтера будут строить отчеты и писать логику проводок.
где я писал что PHP это для того чтобы писал неразработчик?
все ответы в исходниках на гитхабе. статья описывает отдельные технологические идеи. Проект как таков тут несущественен.
Тогда не понятна цель статьи.
это вопрос к вашему офтальмологу а не ко мне
Ну-ну.
на уровне достаточному обеспечить функциональность
некий функционал (с) oldmann поищите кстати весьма занятная штука. Вот у вас сейчас тоже некий функционал
не единственный. И с pdf не всегда все гладко.
С ним меньше всего проблем.
как минимум не надо на каждый документ писать код генерации PDF
и какая разница для накладной сколько пикселей будет высота наименования товара.
Вообще все нормальные люди используют или системы отчетов или шаблонизаторы. К примеру для php весьма неплох TinyButStrong
не существует ни на каком языке учетных систем где бизнес логику пишут не разработчики.
Ну 1С жеж. Там пишут. Слова 1С у вас тут вполне есть.
где я писал что PHP это для того чтобы писал неразработчик?
А где вы писали противоположное? К примеру в 1С пригласить программиста, это не в 1С написать и пригласить их разработчика.
Тогда не понятна цель статьи.
цель стати (для девелоперов, коим вы похоже не являетесь)
описать варианты решения некоторых типичных технологических и архитектурных проблем возникающих при разработке учетных систем и им подобных.
Мой проект это просто место где то было опробовано.
Ну 1С жеж. Там пишут
там пишут разработчики. Или по вашему бухгалтер тетя Маша пишет логику документов и обработок в конфигурации? Последняя версия где что то писал бухгалтер была 2.0
А где вы писали противоположное? К примеру в 1С пригласить программиста, это не в 1С написать и пригласить их разработчика
Как говорил профессор Преображенский — «Кто на ком стоял? Голубчик, потрудитесь излагать ваши мысли яснее.»
цель стати (для девелоперов, коим вы похоже не являетесь)
описать варианты решения некоторых типичных технологических и архитектурных проблем возникающих при разработке учетных систем и им подобных.
В таком случае цель не достигнута. Я вот разработчик и прочитав вашу статью не почерпнул полезной информации, ни подходов ничего. Каких-то уникальных фишек тоже нет. А учитывая количество вопросов заданных в комментариях это явно не только мое мнение.
А теперь замечания по всему остальному. На вашем сайте и в этой статье нет ни одной ссылки на исходный код. Видимо тем кто хочет посмотреть надо искать по github. Скрипт заливки БД без указания кодировки, при этом кодировка не UTF-8 хотя таблицы в UTF-8. К примеру под linux это зальет фигню, так-как по умолчанию там mysql клиент считает что кодировка UTF-8. Ну и да на гихабе это тоже выглядит весьма весело. Нет описания схемы БД и функционала системы.
На вашем сайте и в этой статье нет ни одной ссылки на исходный код
на сайте есть. Здесь нельзя.
Скрипт заливки БД без указания кодировки, при этом кодировка не UTF-8 хотя таблицы в UTF-8. К примеру под linux это зальет фигню, так-как по умолчанию там mysql клиент считает что кодировка UTF-8
у меня демка на линуксовом хостинге. нет никаких проблем с заливкой.
Нет описания схемы БД и функционала системы.
функционал системы кратко описан на сайте.
Описания структуры БД нет в 99.99 процентах проектов на гитхабе.
кроме того структура БД нужна разработчику платформы которая уже готова и разрабатывать там особо пока ничего не надо.
А разработчикам «конфигурации» то есть документов отчетов и пр.
знать нужно разве что таблицу аналитики для нестандартных выборок.
И потом — проект в разработке — у меня не сотня рук. Когда появится кто то кому нужно знать структуру (для работы а не для любопытсва) я ее опишу.
на сайте есть. Здесь нельзя.
На какой странице? Я честно искал и нашел только ссылку на сборку с апачем под винду.
у меня демка на линуксовом хостинге. нет никаких проблем с заливкой.
А вы не на хостинге попробуйте, а на чистой виртуалке. Гарантирую что будут. Так-как у вас в файле нет указания кодировки. Посмотрите хотя бы файл mysqldump.
кроме того структура БД нужна разработчику платформы которая уже готова и разрабатывать там особо пока ничего не надо.
Да не только. Те же отчеты сделать, добавить свой функционал.
И потом — проект в разработке — у меня не сотня рук. Когда появится кто то кому нужно знать структуру (для работы а не для любопытсва) я ее опишу.
С выставлением ценника?
где вы увидели в этом проекте какие то проблемы с двойной записью?
А она у вас есть вообще? :)
не надо отвечать вопросом на вопрос. Итак — где проблемы с двойной записью? или признайте что пишете лишь бы ляпнуть.
У вас в вашем ПО есть двойная запись или нет? Конкретный и простой вопрос. Ну и да дополнительно, можно не общие фразы а все же про функционал поговорить. Что умеет и как.
Переходим на личности? Ну-ну. Давайте лучше больше подробностей технического характера.
или признайте что пишете лишь бы ляпнуть
Переходим на личности? Ну-ну. Давайте лучше больше подробностей технического характера.
У вас в вашем ПО есть двойная запись или нет?
есть но это не имеет отношения к аспектам обсуждаемой статьи.
Что умеет и как.
умеет выполнять функционал учетной системы.
Переходим на личности
вы сами перешли начав делать выводы о том что я знаю а чего нет
вы сами перешли начав делать выводы о том что я знаю а чего нет
О как здорово. Я думал мы приходим сюда в том числе и критиковать. А тут оказывается что автор у нас не погрешим, а если внезапно ему показывают, что не все так хорошо, он начинает нервно реагировать. Может иногда стоит думать, почему это спрашивают? И да вы тут тоже делаете выводы, что я знаю а чего нет.
критиковать конкретные решения а не ванговать что человек знает а что нет
Я вполне конкретно написал. И про отчеты и про все остальное.
на на это я конкретно ответил.
Да с HTML есть свои тонкие моменты — но главное преимущество — не нужны ни какие стороние продукты с которыми надо интегрироватся и все такое.
поэтому вполне сойдет — это бухгалтерия а не BI
тем более технически не проблема состыковать —
добавит API которое будет возвращать набор данных для внешнего генератора.
но тогдла проблема а как на странице показывать — значит нужна обратная взаимосвязь.
В данном случае бланк используется в первую очередь для просмотра документов в журнале (чтобы не открывать каждый раз страницу редактировангия)
а поскольку входящие в внутрение длокументы печати не требуют то тут можно вообще не заботится соответствию стандартным бланкам и тем более нерентабельно использовать специальные построители отчетов
Да с HTML есть свои тонкие моменты — но главное преимущество — не нужны ни какие стороние продукты с которыми надо интегрироватся и все такое.
поэтому вполне сойдет — это бухгалтерия а не BI
тем более технически не проблема состыковать —
добавит API которое будет возвращать набор данных для внешнего генератора.
но тогдла проблема а как на странице показывать — значит нужна обратная взаимосвязь.
В данном случае бланк используется в первую очередь для просмотра документов в журнале (чтобы не открывать каждый раз страницу редактировангия)
а поскольку входящие в внутрение длокументы печати не требуют то тут можно вообще не заботится соответствию стандартным бланкам и тем более нерентабельно использовать специальные построители отчетов
Мне, пожалуй, надоело обсуждать это в двух разных ветках, поэтому я вынесу это сюда в виде конкретного вопроса: предположим, мне, как разработчику на этой «платформе» надо добавить в документ (счет) еще одну сумму (по которой потом можно строить отчеты) и еще одну дату, по которой я должен мочь эти документы сортировать и фильтровать.
Какие конкретно действия для этого надо совершить?
Какие конкретно действия для этого надо совершить?
это учетная система — суммы и даты здесь либо относятся к хозяйственным операциям либо нет.
все что относится к хозяйственным операциям — это движения по синтетическим и аналитическим (субконто) счетам и хранится в таблице аналитики.
Как туда занести данные — это задача того кто разрабатывает документ.
Есть стандартный метод Excecute() которые вызывается во время проведения)в терминах 1С) документа. Есть встроеные функции как записать проводку и данные по субконто.
Все что не относится к учетным операциям а носит чисто информационных характер упаковывется в блоб. То есть так же как в 1С вы можете выполнять поиски сортировки и прочее только над учетными данными.
Если вы хотите сортировать документы по дням рождения заказчиков это к CRM и иже с ними.
все что относится к хозяйственным операциям — это движения по синтетическим и аналитическим (субконто) счетам и хранится в таблице аналитики.
Как туда занести данные — это задача того кто разрабатывает документ.
Есть стандартный метод Excecute() которые вызывается во время проведения)в терминах 1С) документа. Есть встроеные функции как записать проводку и данные по субконто.
Все что не относится к учетным операциям а носит чисто информационных характер упаковывется в блоб. То есть так же как в 1С вы можете выполнять поиски сортировки и прочее только над учетными данными.
Если вы хотите сортировать документы по дням рождения заказчиков это к CRM и иже с ними.
Проще говоря, на вашей платформе этого сделать нельзя. Либо движение по счетам, либо никак. Правильно?
Для платформы не ставилась задача делать что не входит в функционал системы бухгалтерского и складского учета.
Потому это и 1с не делает.
.
Потому это и 1с не делает.
.
(1С как платформа это позволяет, я это своими глазами видел.)
Итого, ваша платформа этого не позволяет. Собственно, на этом все обсуждения «расширяемости» можно закрывать — у вас она в тех узеньких рамочках, которые вам пришли в голову. Никакого «позволит избежать необходимости изменения структуры БД при внесении изменений в систему (например появление нового атрибута справочника)» у вас, на самом деле, нет.
Итого, ваша платформа этого не позволяет. Собственно, на этом все обсуждения «расширяемости» можно закрывать — у вас она в тех узеньких рамочках, которые вам пришли в голову. Никакого «позволит избежать необходимости изменения структуры БД при внесении изменений в систему (например появление нового атрибута справочника)» у вас, на самом деле, нет.
И моя позволят. Если написать соответсвующий код.
Нет проблем выбрать документы по какому то признаку и отсортировать.
Да это будет медленно, но для экзотики сойдет.
Я не собираюсь ради этого делать визуальный конфигуратор как в 1С чтобы генерить динамически структуру БД
и парсер запросов чтобы сортировать на уровне БД.
Нет проблем выбрать документы по какому то признаку и отсортировать.
Да это будет медленно, но для экзотики сойдет.
Я не собираюсь ради этого делать визуальный конфигуратор как в 1С чтобы генерить динамически структуру БД
и парсер запросов чтобы сортировать на уровне БД.
И моя позволят. Если написать соответсвующий код.
Прекрасно, возвращаемся к моему вопросу в комментарии: какие конкретно действия для этого надо совершить?
Да это будет медленно, но для экзотики сойдет.
Это не экзотика, это обычное требование пользователя в рамках той самой бизнес-задачи, которую, по вашим словам, ваша платформа позволяет легко решать.
Я не собираюсь ради этого делать визуальный конфигуратор как в 1С чтобы генерить динамически структуру БД
… а для этого не нужен визуальный конфигуратор.
и парсер запросов чтобы сортировать на уровне БД.
… а для этого не нужен парсер запросов
Это не экзотика, это обычное требование пользователя в рамках той самой бизнес-задачи, которую, по вашим словам, ваша платформа позволяет легко решать
моя задача решает складской и бухгалтерский учет
Когда я встречу хоть одного бухгалтера который такое потребует — я озабочусь этим вопросом.
за 15 лет пока имел дело с 1с не встретил ни одного.
а для этого не нужен визуальный конфигуратор.
а для этого не нужен парсер запросов
в 1с нужен.
в 1с нужен.
Так это личные проблемы 1С, почему вас это останавливает?
Кстати, на вопрос «что нужно сделать» вы так и не ответили.
Потому это и 1с не делает
Звоним в компанию, которая поставила вам 1С, просим добавить туда все что вы хотите, платим предоплату, получаем все что вы хотите прямо в 1С и, о боже, в бухгалтерской системе!
Заплатите мне и я добавлю.
Пока это опенсорс проект.
Бритва Оккама — не надо плодить сущности сверх необходимого
Пока это опенсорс проект.
Бритва Оккама — не надо плодить сущности сверх необходимого
Ну со временем вас начнет не хватать и нужны будут другие программисты. А другим программистам нужна простая система, которую легко расширять (как 1С), а не пытаться «Бухгалтерскую систему» превратить в «Не бухгалтерскую».
Поймите же, 1С позволяет настроить систему как угодно, при этом квалификация 1С программистов весьма низкая (да не побьют меня они), ваша же система этого не позволяет (судя по используемым вами решениям). Так вы либо пишите аналог 1С: бухгалтерии, которую нельзя менять, либо пишите аналог 1С, но со столь же гибкой архитектурой.
Поймите же, 1С позволяет настроить систему как угодно, при этом квалификация 1С программистов весьма низкая (да не побьют меня они), ваша же система этого не позволяет (судя по используемым вами решениям). Так вы либо пишите аналог 1С: бухгалтерии, которую нельзя менять, либо пишите аналог 1С, но со столь же гибкой архитектурой.
«Бухгалтерскую систему» превратить в «Не бухгалтерскую».
она именно бухгалтерская это вы пытаетесь прилепить рассылку и все что от лукавого
при этом квалификация 1С программистов весьма низкая
я б этого не сказал
тут как оаз был спор о знании предмеотной области
плюс с каждой версией 1с становится все монстрообразнее.
Так вы либо пишите аналог 1С: бухгалтерии, которую нельзя менять, либо пишите аналог 1С, но со столь же гибкой архитектурой.
я пишу не аналог а альтернативу. А если кому чешутся руки — платформа тоже открытый код. Какие проблемы.
А гибкая настройка противоречит самой идее. Я не собираюсь превращать проект в джумлу.
она именно бухгалтерская это вы пытаетесь прилепить рассылку и все что от лукавого
Именно что она у вас бухгалтерская, а вы предподносите ее так, как будто из нее можно склепать что то еще. Не надо сравнивать вашу систему с 1С. Бухгалтерия в 1С это всего лишь конфигурация, а у вас это полноценная система. Чуствуете разницу? У них можно на 1С систему учета в ресторане поднять, а у вас это все еще только Бухгалтерская система.
я б этого не сказал
Спорить не буду, это тоже не мое личное мнение.
я пишу не аналог а альтернативу
Одно другому не мешает.
А если кому чешутся руки — платформа тоже открытый код
Да вроде ни у кого не чешутся еще )
А гибкая настройка противоречит самой идее. Я не собираюсь превращать проект в джумлу
Да я не настаиваю, это вам предстоит с помощью вашей «не гибкой» системы конкурировать с 1С, в которой можно сделать все.
Именно что она у вас бухгалтерская, а вы предподносите ее так, как будто из нее можно склепать что то еще
ничего подобного не говорил
а у вас это все еще только Бухгалтерская система.
Вообще то у меня это веб приложение с открытым кодом. Тут можно что угодно дописать. И необязательно трогать функционал самой платформы.
могу модуль интернет магазина прикрутить. Будет жить на той же БД и никаких проблем с интеграцией.
ничего подобного не говорил
Веб приложение легко обновляется заменой отдельных файлов (привет конфигуратору 1С)
ну да
Тут можно что угодно дописать
ну вот опять
а где противоречие?
объекты конфигуратора деийствительно можно обновить заменой файлов. Например, новый бланк у накладной. Или просто баг какой, неправильная проводка там. Или новый регламентный отчет который по обыкновения обнародовали за день до конца месяца. Типичные бухгалтерские будни.
То что это просто сайт на PHP позволяет расширять не только платформу, а дописывать новый функционал. хотите рассылать приглашения контрагентам? Файлик с php на крон и вперед.
в этом и разница между аналогом и альтернативой.
Аналог 1С делать глупо. Но можно предложить альтернативные решения тех же задач другими способами.
я так понимаю вы тоже разраб 1с или некоей околоучетной документооборотной системы.
Никто другой не относится к альтернативным проектам с такой ревностью.
А у тебя есть такая фича как у меня? Ага! Нету!!!
А пофиг что у меня самого нет половины нужных фич. Главное что у тебя нет самого главного — сортировки по дням рождения тещи контрагента.
объекты конфигуратора деийствительно можно обновить заменой файлов. Например, новый бланк у накладной. Или просто баг какой, неправильная проводка там. Или новый регламентный отчет который по обыкновения обнародовали за день до конца месяца. Типичные бухгалтерские будни.
То что это просто сайт на PHP позволяет расширять не только платформу, а дописывать новый функционал. хотите рассылать приглашения контрагентам? Файлик с php на крон и вперед.
в этом и разница между аналогом и альтернативой.
Аналог 1С делать глупо. Но можно предложить альтернативные решения тех же задач другими способами.
я так понимаю вы тоже разраб 1с или некоей околоучетной документооборотной системы.
Никто другой не относится к альтернативным проектам с такой ревностью.
А у тебя есть такая фича как у меня? Ага! Нету!!!
А пофиг что у меня самого нет половины нужных фич. Главное что у тебя нет самого главного — сортировки по дням рождения тещи контрагента.
а где противоречие?
Ну то вы говорите что на ней можно пилить, потом говорите что это выходит за рамки учетной, потом опять что можно.
То что это просто сайт на PHP позволяет расширять не только платформу
Ну понятно, что угодно можно расширить положив рядом другую программу. Речь идет об удобстве расширения на базе именно вашего решения.
я так понимаю вы тоже разраб 1с или некоей околоучетной документооборотной системы.
Никто другой не относится к альтернативным проектам с такой ревностью.
Нет, я недолюбливаю 1С из за их маркетинговой политики и отношений к партнерами.
А пофиг что у меня самого нет половины нужных фич. Главное что у тебя нет самого главного — сортировки по дням рождения тещи контрагента
У меня то все есть, я учетными системами давненько заниматься перестал )
Ну то вы говорите что на ней можно пилить, потом говорите что это выходит за рамки учетной, потом опять что можно.
вы либо реально непонимаете либо делаете вид, что прискорбно.
Обьясняю последний раз.
Существуют учетные задачи. Они РЕГЛАМЕНТИРОВАНЫ. Первичные документы, отчеты, проводки и все такое. Там нет никаких экзотических поисков и сортировок.
Бухгалтеру важно подерживать в актуальном состоянии регламентную сторону потому что проверка с налоговой не впечатлится широкими возможностими сортировать контрагентов по дню рождения.
А значит нужно обеспечить легкую реконфигурацию. Поэтому очень важно иметь возможно легко заменить документ или отчет. или добавить новый. Чтобы это делать простой заменой файлов — платформа должна быть неизменной.
В 1С кстати нельзя перекопировать документ. Отчет или обработку еще можно выгрузить и подключить а новое поле документа (по котрому вы хотите лихо что то там сортировать) меняет структуру хранилища. как и новый атрибут справочника.
И поэтому несовместимы не только версии 8.0 — 8.3 а и релизы конфигураций с релизами той же версии.
Я уже не говорю про то что в 1с нельзя сделать того что не поддерживается платформой. Поэтому лепим битрикс. Поэтому делаем веб в точности похож на десктоп а потом чешем репу и пилим отдельно мобильного клиента. Через пару версий 1с действительно догонит SAP… По монстрообразности и дороговизне внедрения и саппорта.
Поэтому суть идеи — платформа должна быть неизменной в разрезе обеспечения РЕГЛАМЕНТИРОВАННОГО бухгалтерского учета для полной совместимости между объектами конфигураций где бы и в какое время бы они ни были бы написаны…
Точка.
Но поскольку всегда хочется что то добавить выбрана соответствующая технология — сайт на старом добром похапе.
например у меня в проекте есть еще управление проектами и задачами (и даже диаграму ганта рисует). Это просто рядом в ом же приложении. потом хочу попробовать сделать управление запасами в соответствии с ТОС, и т.д.
Но это может быть а может не быть. Но регламентированый законодательством и стандартами учета функционал будет обеспечен неизменной совместимой с любыми конфигурациями платформой и как следствие обеспечен возможностью «горячей» замены любого обьекта конфигуратора.
При этом разумеется можно расширять и функционал платформы но разраб должен понимать что это будет работать только у этого клиента. Ну уж если невтерпеж сортировать документы по длине фамилии контрагента — ну на тебе поле в таблицу документов.
В мире 1с тоже подпиливают конфы под клиента что их нельзя обновить потом. но это уже дело хозяйское.
Регламенты имеют свойство меняться. Вы за каждым таким изменением будете платформу допиливать?
настолько существенных изменений в регламентах не было за последние лет сто.
И есть опасение что за нашей жизни не будет. бухгалтерия консервативнее се религиозные фанатики
И есть опасение что за нашей жизни не будет. бухгалтерия консервативнее се религиозные фанатики
настолько существенных изменений в регламентах не было за последние лет сто.
Ну то есть вы надеетесь, что вам не понадобится менять платформу, потому что изменений не будет. Правильно?
их не будет. нет никаких причин чтобы они были.
будут технологические изменения типа перехода на электронку а в этом случае придется менять платформу всем и 1С в том числе.
разумеется здравый смысл подсказывает что при автоматическом компьютерном учете нафиг не нужна ни двойная запись ни соблюдение баланса.
Но пока не наблюдается чтобы хотя бы отказались от кореспонденции счетов.
Помню как мучался на внедрени Oracle Application где движения по счетам были построены на полупроводках.
будут технологические изменения типа перехода на электронку а в этом случае придется менять платформу всем и 1С в том числе.
разумеется здравый смысл подсказывает что при автоматическом компьютерном учете нафиг не нужна ни двойная запись ни соблюдение баланса.
Но пока не наблюдается чтобы хотя бы отказались от кореспонденции счетов.
Помню как мучался на внедрени Oracle Application где движения по счетам были построены на полупроводках.
их не будет. нет никаких причин чтобы они были.
Вы не представляете себе, сколько проектов было похоронено вот такими надеждами.
будут технологические изменения типа перехода на электронку а в этом случае придется менять платформу всем и 1С в том числе.
Странно, почему-то 1С удалось организовать электронный обмен с РосИмуществом безо всякой смены платформы.
Вы не представляете себе, сколько проектов было похоронено вот такими надеждами.
ну если проект лепили на делфи или winforms то конешно
потому то и скриптовый язык с открытым кодом
Странно, почему-то 1С удалось организовать электронный обмен с РосИмуществом безо всякой смены платформы
вы думаете этот обмен там был со времен версии 2.0?
введение поддержки вебсервисов и есть изменение платформы. До того никаким каком это сделать было нельзя
потому то и скриптовый язык с открытым кодом
А какая разница? Скриптовые языки не упрощают поддержку и модификацию. В итоге все равно все определяется расширяемостью базовой архитектуры.
вы думаете этот обмен там был со времен версии 2.0?
Я думаю, что эта функциональность уже есть, поэтому ваше «всем придется менять платформу» немножко неверно.
Скриптовые языки не упрощают поддержку и модификацию
упрощают
стандартная ситуация — делают прогу на делфи не отдавая исходники и садят клиента «на иглу»
хорошо если это солидная контора с саппортом и апдейтами а если нет.
что эта функциональность уже есть, поэтому ваше «всем придется менять платформу» немножко неверно.
«Эта» и у меня есть. И даже к платформе так таковой не относится.
преимущество веб приложения с открытым кодом что можно как изменить платформу так и дописать функционал рядом с ней чтобы не менять и не иметь проблем с совместимостью конфигураций…
Чего нельзя сделать в 1С или других компилируемых приложениях с закрытым кодом.
упрощают
Каким образом?
стандартная ситуация — делают прогу на делфи не отдавая исходники и садят клиента «на иглу»
Это, извините, не скриптовые языки, а открытые исходники.
преимущество веб приложения с открытым кодом что можно как изменить платформу так и дописать функционал рядом с ней чтобы не менять и не иметь проблем с совместимостью конфигураций…
Оптимистично.
Если вы измените платформу, то как вы избежите проблем с совместимостью?
Если вы допишите функционал «рядом», то при чем тут платформа?
Это, извините, не скриптовые языки, а открытые исходники.
да
но скриптовые языки по факту открытые (ну если специально не шифровать)
и потом они не требуют среды разработки.
Если вы измените платформу, то как вы избежите проблем с совместимостью?
никак потому и стараюсь ее спроектировать так чтобы менять не пришлось изза какой то несущественно фичи
Если вы допишите функционал «рядом», то при чем тут платформа?
ни при чем. В этом и преимущество.
я могу расширять возможности приложения не меняя платформу отвечающую за основной функционал.
и поэтому мне не надо наворачивать платформу чтобы обеспечить функционал на все случаи жизни.
тем более что специфичные фичи это как правило специфика конкретного клиента
то есть, чтобы мне как обсуждали добавить выборку по специальному полю документа не распарсивая блоб,
я добавляю это поле в таблицу документов.
результат — для фичи которая приспичила заказчику мне не пришлось ни изменять платформу ни усложнять платформу динамическими расширениями таблиц БД.
при этом конечно изменится документ или журнал в самой конфигурации. но тут та же проблема как и в 1с — изменил конфу — прощай совместимость и обновления от вендора.
но зато в отличие от 1С могут обновлятся другие документы и отчеты — поскольку платформа не изменилась а обновление -просто копирование файликов.
в 1С нужен програмер который вручную перенесет изменения или восстановит фичу после обновления
но скриптовые языки по факту открытые (ну если специально не шифровать)
Если кто хочет, чтобы код был закрытым — он зашифрует.
и потом они не требуют среды разработки.
Не только скриптовые языки не требуют среды разработки.
стараюсь ее спроектировать так чтобы менять не пришлось изза какой то несущественно фич
Ну, пока что-то не видно никаких способствующих этому проектных решений.
то есть, чтобы мне как обсуждали добавить выборку по специальному полю документа не распарсивая блоб, я добавляю это поле в таблицу документов.
… тем самым меняя структуру БД, что может повлечь проблемы дальше по цепочке. Ну и да, не только структуру БД — еще и в отображении надо будет поменять, ведь правда же?
поскольку платформа не изменилась а обновление -просто копирование файликов.
Угу, теперь представьте, что у вас один и тот же документ изменился по двум причинам: локальное требование заказчика и обновление, пришедшее в связи с изменением законодательства. Все еще обойдетесь простым копированием файликов?
еще и в отображении надо будет поменять, ведь правда же?
отображение — часть конфигурации а не платформы.
дополнительные поля на платформу не повлияють
Все еще обойдетесь простым копированием файликов?
в этом конкретном нет
в остальных да в чем и преимущество
в 1С обновление затрет все
отображение — часть конфигурации а не платформы.
А какая разница, менять-то все равно надо.
в этом конкретном нет
в остальных да в чем и преимущество
Вопрос соотношения «этого» и «остальных».
Системый управления версиями, как ни странно, не зря придумали.
В 1С кстати нельзя перекопировать документ. Отчет или обработку еще можно выгрузить и подключить а новое поле документа (по котрому вы хотите лихо что то там сортировать) меняет структуру хранилища. как и новый атрибут справочника.
И поэтому несовместимы не только версии 8.0 — 8.3 а и релизы конфигураций с релизами той же версии.
Я уже не говорю про то что в 1с нельзя сделать того что не поддерживается платформой. Поэтому лепим битрикс. Поэтому делаем веб в точности похож на десктоп а потом чешем репу и пилим отдельно мобильного клиента. Через пару версий 1с действительно догонит SAP… По монстрообразности и дороговизне внедрения и саппорта.
1) Совсем непонятно, что значит «нельзя перекопировать». Все объекты метаданных отлично копируется.
2) Добавление новых полей через стандартный механизм «Свойств и категорий» не требует присутствия программиста и изменений в программе. Пользователь сам решает какие дополнительные поля добавить, а далее заполняет их и в отчетах может по ним делать отборы и сортировки.
2*) Не понятна шпилька про изменение структуры хранения данных при добавлении реквизита в конфигураторе. В реляционных БД по другому никак нельзя сделать, а вменяемые версии document-oriented database появились только в последние года (во времена 8.0-8.1-8.2 их вообще не существовало). Но даже сейчас в разных сценариях применения релационки и NoSQL показывают различные показатели, что само по себе является аргументом не менять текущую архитектуру.
3) Про несовместимость версий платформ и конфигураций какая-то фигня. Все что написано для 8.0 запустится на всех релизах платформы вплоть до самой последней из 8.3. Для 8.1 нужно будет выполнить необратимое изменение, но зато начиная с 8.1 и далее все можно «проигрывать» в режимах совместимости. Так я локально на платформе 8.3 разрабатываю конфу, которой обновляю сервер с платформой 8.2 — и все отлично. В этом кардинальное различие от вашего любимого PHP, где никакой прямой и обратной совместимости нет (при переходе с PHP3 на PHP4 пришлось переписывать буквально все).
3) В 1С можно сделать все и не важно платформа поддерживает или не поддерживает. Если достаточно передать управление внешнему процессу — запускаем внешний процесс. Если нужен какой-то специфический объект, состояние которого должен изменять код в 1С и получать какие-то отклики, то в таких случаях пишется и подключается внешняя компонента.
4) Лепить Битрикс вообще не нужно — это другая тема. Битрикс был удобной известной отечественной «не OpenSource» CMS и потому идеально подошел компании 1С (если мне не изменяет память, то у них сделка прошла даже не поглощением, а путем обмена акциями). С помощью ручного CMS компания 1С сделала эталонную связку своих торговых решений с интернет-магазином. Но эта связка на базе открытого стандарта CommercML и потому её успешно используют так же в OpenCart, PrestaShop, Magenta и во многих других решениях интернет-торговли.
5) Веб-клиент и десктопная версия действительно на вид идентичны, но я бы поспорил на предмет «кто чей клон». Последние версии десктопного приложения (вариант интерфейса Такси) — это вообще полная калька с типовых приложений для iPad.
6) Про пилим отдельно мобильный клиент — это о чем? Платформа действительно имеет сборки отдельно для Android, iOs и Windows, но конфигурация как и раньше разрабатывается в конфигураторе и может быть запущена на любом из мобильных вариантов или вообще в десктопном исполнении.
7) Про SAP не нужно. Видел как это чудо техники работает. Нужно переключаться в один интерфейс и накладывать параметры, потом переключаться в другой интерфейс и формировать отчеты; если нужно изменить фильтр, то шаманство повторить; если нужно подправить данные по отчету, то лучше его сохранить, так как нас снова ждет увлекательная смена интерфейсов. То как в 1С в одном едином окошечке можно формировать отчеты по любым фильтрам, а в процессе открывать и править документы (тем самым меняя содержимое отчета) — выглядело как фантастика.
в этом конкретном нет
в остальных да в чем и преимущество
в 1С обновление затрет все
Т.е. вам можно мержить конфликтные правки, а 1Су вы это делать запрещаете? Для начала отметим, что в отличии от вашего варианта обновления пачки файлов «вслепую», в платформе предусмотрен предварительный анализ — если обновляемые элементы никем не менялись, то изменение пройдет «тихо», а иначе будет выдан список конфликтов с предложением их разрешить (нет, совсем не как в 7.7 — на 8-й платформе обновление было переработано).
А вы знаете, что в 1С для тех, кто не хочет использовать стандартную (как по мне очень удобную) систему мержа, прямо из коробки идет интеграция с Araxis Merge, DiffMerge, KDiff3, TortoiseMerge и Perforce P4Merge, а так же есть возможность подключения любой другой diff-утилиты?
Это общие положения, а теперь немного вглубь. У тех, кто сопровождает изменения в типовых, уже давно есть наработанные методики по минимизации рисков переписывания всего с нуля при обновлении — никому не нравится терять время на мержах. Далее в последних конфигурациях (которые используют БСП) пошли на встречу поддержки внедренцев — к примеру, в типовых есть общий модуль ОбщегоНазначения, который дорабатывается поставщиками конфигурации и изменения в котором внедренцам запрещены, но так же есть общий модуль ОбщегоНазначенияПереопределяемый, в котором продублированы все процедуры и функции из основного модуля в виде заглушек, которые никогда не меняются и отданы на откуп местным программистам (данные из основных процедур перед окончанием их работы скармливаются в пользовательские аналоги, где те могут быть дополнены).
Да и в самой платформе 1С тоже внедряют удобные фичи. Начали с подписки на события, которые позволяют, не изменяя документов (или прочих объектов), навешивать на стандартные события (запись, проведение и пр.) свои дополнительные обработчики. А недавно появился вообще новый многообещающий механизм — «расширения», который позволяет вообще не снимая с поддержки типовые конфигурации как угодно их дорабатывать — описание одного из первых применений можно посмотреть тут.
Пользователь сам решает какие дополнительные поля добавить, а далее заполняет их и в отчетах может по ним делать отборы и сортировки.
это в вашей паралельной вселенной. А в нашей вселенной бухгалтер тетя Маша даже понятия не имеет где там что редактируется и зачем. То же касается всех остальных крутых фич. — Это делают програмисты и делают небесплатно. И чем этих фич больше тем чаще надо звать програмиста.
Но статья не об этом. Статья для тех кто не считает что на 1с свет клином сошелся. такие люди были есть и будут, как бы вас одинэсников это не бесило.
это в вашей паралельной вселенной.
Зачем хамить, когда вам просто перечисляют факты, о которых вы не в курсе?
А в нашей вселенной бухгалтер тетя Маша даже понятия не имеет где там что редактируется и зачем.
Тогда зачем вообще поднимать этот вопрос? Если Маше нужны дополнительные реквизиты, то она спросит на курсах / у подружек / на форуме / в службе поддержки и начнет ими пользоваться. А нет — так у нее и голова не болит, они сами по себе на форме не появляются.
То же касается всех остальных крутых фич. — Это делают програмисты и делают небесплатно.
Вы упомянули конкретную «фичу», которую у вас должен делать программист. Я ответил, что в типовых 1С для такой мелочи вообще программист не нужен. А для более продвинутых вещей, как загрузка заказов с интернет-магазина, связка с клиент-банком и подключение торгового оборудования в любом случае понадобится программист (у вас в 100% случаев, а в случае 1С даже тут можно обойтись коробочным решением, которое админ просто должен правильно настроить — если связка с Битриксом, клиент-банк работает по протоколу от 1С, а торговое оборудование прошло сертификацию на «1С: Совместимо»).
Статья для тех кто не считает что на 1с свет клином сошелся. такие люди были есть и будут, как бы вас одинэсников это не бесило.
Ну у вас и юмор. Представляю вашу тетю Машу, которая открыла Хабр и читает технические статьи :)
А на самом деле вы написали статью именно для 1С-ников, что бы указать им на их недостатки и показать, что всего один человек может на коленке написать проект, который будет востребованным на фоне ихнего детища, которое они пилят уже третий десяток лет.
Не знаю, обратили ли вы внимание, но с те люди с которыми вы яростно дискутируете последние дни, вам явно пишут, что они не одинэсники и вообще 1С-ом не занимаются.
Я ответил, что в типовых 1С для такой мелочи вообще программист не нужен.
теоретически, по задумке фирмы 1С, для 1с програмист не нужен — даже язык програмирования на русском. Но практически никакой бухгалтер ни в какие атрибуты не полезет. Опуститесь на землю — никакие бухгалтера там ничего не редактируют и даже не открывают конфигуратор. Даже если им это рекомендуют на форумах.
Потому что там — полноценое програмирование, какие бы крутые мастера и построители там не были.
что они не одинэсники и вообще 1С-ом не занимаются.
тогда зачем спорят о том о чем понятия не имеют
тогда зачем спорят о том о чем понятия не имеют
Ну да, конечно, весь мир учетных систем состоит только и исключительно из 1С, а архитектура учетной системы строится по совершенно уникальным принципам, не имеющим ничего общего со всем остальным программированием.
теоретически, по задумке фирмы 1С, для 1с програмист не нужен — даже язык програмирования на русском.
Вы живете в реалиях 90-х. Когда я в начале нулевых еще писал программы для бухгалтерского учета на Foxpro (на базе такого нелюбимого вами формата dbf), у меня была знакомая бухгалтерша с Харькова, которая жаловалась, что в 6-ке она могла сама дописывать все, что ей было нужно, а теперь у них 7-ка и нужно каждый раз вызывать программиста (кстати, мы тоже думали, что с легкостью порвем и 1С, и Парус и всех остальных). Я веду к тому, что а) бухгалтера реально правили алгоритмы; б) начиная с версии 7.5 по официальным рекомендациям для бухгалтеров более не рекомендовано лазить в код и что-то менять.
Опуститесь на землю — никакие бухгалтера там ничего не редактируют и даже не открывают конфигуратор.
Я ничего не говорил про конфигуратор. Я говорил про типовой механизм «свойства и категории», который реализован у большинства справочников и документов в коробочном решении.
Даже скажу больше. Есть такой экзамен «1С: Специалист», на котором проверяют знания и навыки внедренцев типовых решений. Если внедренец делает то, что уже реализовано в конфигурациях, то ему снимают балы. За такие дополнительные реквизиты, как вы привели пример, как раз и штрафуют — они избыточны.
у меня была знакомая бухгалтерша с Харькова, которая жаловалась, что в 6-ке она могла сама дописывать все,
да мой бухгалтер тоже дописывал в версии 2.0
Я говорил про типовой механизм «свойства и категории», который реализован у большинства справочников и документов в коробочном решении.
о котором 9 из 10 бухгалтеров не подозревают. Даже если закончат курсы специалиста.
Существуют учетные задачи. Они РЕГЛАМЕНТИРОВАНЫ. Первичные документы, отчеты, проводки и все такое. Там нет никаких экзотических поисков и сортировок
Ответьте мне на простой вопрос, только искренне — у вас есть опыт продажи, внедрения и сопровождения бухгалтерского ПО?
>10k просмотров
>300 комментариев (40% ответов автора на вопросы)
и всего +4 за пост.
Да, автор местами гонит про XML в BLOB
Да, автор летает в альтернативной реальности про рынок и весь кошмар бухгалтерии, но посмотрите! Посмотрите — ему тыкают в неправильности, но он не сдается! Ему 100 раз указали на слабые места, но он видит в них возможности! За одно это стремление стоит приободрить автора кармой и плюсами!
Всем начинателям дается нелегко в первое время и их воспринимают как сумасшедших, но эта энергия и бодрость духа просто потрясают!
А вы посмотрите — он умудряется отвечать на АБСОЛЮТНО каждый вопрос, не оставляет их не отвеченными. В итоге даже мне стало интересно узнать о некоторых тонкостях работы 1с и бухгалтерии, что бывает вообще, и какие есть подводные камни))) как всегда — в комментариях скрыта самая интересная часть!
>300 комментариев (40% ответов автора на вопросы)
и всего +4 за пост.
Да, автор местами гонит про XML в BLOB
Да, автор летает в альтернативной реальности про рынок и весь кошмар бухгалтерии, но посмотрите! Посмотрите — ему тыкают в неправильности, но он не сдается! Ему 100 раз указали на слабые места, но он видит в них возможности! За одно это стремление стоит приободрить автора кармой и плюсами!
Всем начинателям дается нелегко в первое время и их воспринимают как сумасшедших, но эта энергия и бодрость духа просто потрясают!
А вы посмотрите — он умудряется отвечать на АБСОЛЮТНО каждый вопрос, не оставляет их не отвеченными. В итоге даже мне стало интересно узнать о некоторых тонкостях работы 1с и бухгалтерии, что бывает вообще, и какие есть подводные камни))) как всегда — в комментариях скрыта самая интересная часть!
Да, автор местами гонит про XML в BLOB
ну вобще я подумал таки да поменяю на сериализацию сэкономлю место.
на то и статья чтобы кто то на косяки укаал
Програмистам надо иногда по системе Станиславского представлять себя на месте пользака. Действительно бухгалтер не будет помнить имя xml тега чтобы выполнить точный поиск. А разраб найдет способ найти причину прямыми запросами к БД
вместе с уходом от XML в BLOB, отказаться от сериализации и выбрать JSON, поменять БД на PostgreSQL там есть тип данных JSON.
нет.
тип данных поля не имеет значения. Места уже много не сэкономишь.
а сериализация содержит длину строки. Что гарантирует от неприятностий с кавычками и прочими спецсимволами.
в xml для этого CDATA есть а в json ничего нет.
тип данных поля не имеет значения. Места уже много не сэкономишь.
а сериализация содержит длину строки. Что гарантирует от неприятностий с кавычками и прочими спецсимволами.
в xml для этого CDATA есть а в json ничего нет.
А зачем вам что-то для борьбы с кавычками и etc, если это уже заложено в сам json? Просто используйте стандартный компонент для работы с ним.
выгоды особо никакой а встроеная сериализация обьектов стопроцентно надежна.
да и наверняка быстрее.
да и наверняка быстрее.
Выгода в том, что json — (условно) универсальный переносимый формат, который можно прочитать даже если ваш «сайт на php» мертв и похоронен с почестями. В том числе — другой службой из другого приложений написанного на другом языке.
в 1с напрямую с БД прочитать ничего нельзя без танцев с бубном и как то живут.
Уж если кто то может выгрузить данные с Бд то уж точно он может перезапустить сайт или поцепить Бд на копию
это все таки PHP тут все намного пролще
как дополнительный бонус оно бы и не помешало но както я больше доверяю сериализации. там нет проблем ни с кавычками ни с кодировками вообще ни с чем.
Уж если кто то может выгрузить данные с Бд то уж точно он может перезапустить сайт или поцепить Бд на копию
это все таки PHP тут все намного пролще
как дополнительный бонус оно бы и не помешало но както я больше доверяю сериализации. там нет проблем ни с кавычками ни с кодировками вообще ни с чем.
в 1с напрямую с БД прочитать ничего нельзя без танцев с бубном и как то живут.
Да какая разница, как сделано в 1С? Вы же делаете альтернативу — так делайте сразу по-челочевески.
Уж если кто то может выгрузить данные с Бд то уж точно он может перезапустить сайт или поцепить Бд на копию
А если ему не нужен сайт, если он делает интеграцию?
Да какая разница, как сделано в 1С?
разница в существовании соответствующего функционала.
то есть сам по себе прямой доступ к Бд не есть жизненно необходимым как показывает широкое применение продуктов с отсутствием оного.
Хотя н самом деле те кто пытаются интегрировать 1с с инет магазинами были бы в восторге от возможности обмена напрямую.
но есть опасность — одно дело прочитал данные
другое дело засунул криво и конфа перестала работать.
поэтому лучше все таки доступатся к хранилищу через родное приложение
А если ему не нужен сайт, если он делает интеграцию?
а с чем он в таком случае ее делает? Нет сайта нет БД с его данными.
а с чем он в таком случае ее делает?
С БД, понятное дело.
Понимаете, когда вы используете для хранения в БД закрытый формат, вы усложняете жизнь всем — и разработчикам, которым надо его читать, и интеграторам, которые не могут с ним взаимодействовать, и поддержке, которая не может его прочитать без дополнительных инструментов. И еще и теряете поддержку на уровне БД.
С БД, понятное дело.
ну интеграцию обычно делают не с Бд а с неким продуктом
когда вы используете для хранения в БД закрытый формат,
я с этим не спорю — потому и был XML как одна из причин.
просто че то я не очень доверяю json вне сферы его естественного применения — взаимодействия с javascript.
и потом интеграция это как правило не просто обмен документами. Собственно первичные документы которые хранятся не особо кому то интересны.
интересно некие выборки — прайс например.
Поэтому если кому нужен документ лучше я отдам его в том же json через стандартный RESTful сервис. Тем более к Бд не всегда можно доступится напрямую внешней проге
.
И еще и теряете поддержку на уровне
БД.
ну этого в данном случае не нужно
ну интеграцию обычно делают не с Бд а с неким продуктом
Если у некоего продукта нет нормальной интеграции, то может выясниться что проще интегрироваться через БД.
просто че то я не очень доверяю json вне сферы его естественного применения
Вы можете сколько угодно ему не доверять, однако это де-факто стандарт.
Поэтому если кому нужен документ лучше я отдам его в том же json через стандартный RESTful сервис.
Угу, то есть у вас еще и REST-api будет…
Если у некоего продукта нет нормальной интеграции, то может выясниться что проще интегрироваться через БД.
21 век на дворе сервисы переезжают в облака — ПО должно уметь ходить у API по http
то есть у вас еще и REST-api будет
а че ему не быть — веб приложение однако
как раз пример функционала который платформу не меняет но легко добавляется
21 век на дворе сервисы переезжают в облака — ПО должно уметь ходить у API по http
Для начала ПО должно выставлять нормальный API по HTTP (в вашем случае — по HTTPS).
как раз пример функционала который платформу не меняет но легко добавляется
Ага, очень легко. Вот прямо начиная с авторизации и роутинга — очень легко.
За одно это стремление стоит приободрить автора кармой и плюсами
Не надо превращать хабру «форум wap-мастеров» конца 90х.
Ну да, а вы всегда писали только правильно и никогда не заблуждались. А всех, кто ошибается будем бросать со скалы!
Если я ошибаюсь, меня критикуют, а не плюсуют и поддерживают вне зависимости от количества комментариев, которые я наклепал.
А если вам кажется, что вас критикуют не обоснованно, вы будете молчать, получать минуса и кивать головой? Или попытаетесь оспорить?
Я просто имею ввиду, что если сейчас заминусовать автора, то мы так и не услышим продолжения. А вдруг взлетит?
Я просто имею ввиду, что если сейчас заминусовать автора, то мы так и не услышим продолжения. А вдруг взлетит?
А если вам кажется, что вас критикуют не обоснованно, вы будете молчать, получать минуса и кивать головой? Или попытаетесь оспорить?
А вы почитайте мои комменты, поймете )
Я просто имею ввиду, что если сейчас заминусовать автора, то мы так и не услышим продолжения. А вдруг взлетит?
Не взлетит. Многие здесь это прекрасно понимают.
Никто же не против попыток оспорить, только если они, в свою очередь, тоже выглядят необоснованно, какой смысл их поощрять?
Дочитал все комментарии и не увидел самого главного. Ни в статье, ни в комментариях, ни на гитхабе, ни на сайте zippy.com.ua я не увидел нишевого предназначения данного продукта. Очевидно, что сделать универсальное — это «сизифов труд», который никто не оценит и про который все благополучно забудут. Но конкретики никакой нет. Разве что на уровне отрицаний — это не для аптек, это не для общепита, это не будет WMS или MRP, это не для организаций с огромным документооборотом, это не для организаций с торговым оборудованием…
Я вижу просто очередной вебовский бухгалтерский калькулятор, которых уже десяток — ifin.ua, delovod.ua, webzvit.com.ua и другие. Кстати, пока дергал для вас ссылки, гугл мне заботливо предложил прочитать интересную тематическую статью на DOU — рекомендую и вам ознакомится — dou.ua/lenta/articles/oblachnyj-fenomen-onlajn-buhgalterii
От меня совет: найдите и займите узкую нишу. Когда начнете заниматься продвижением, ни в коем случае не противопоставляйте себя и продукты компании 1С. На вас будет играть уже тот факт, что у вас уже есть все готовенькое с коробки и это уже реально успешно работает у других, а продукты 1С и прочих еще нужно пилить, но хороший результат никто не гарантирует.
Я вижу просто очередной вебовский бухгалтерский калькулятор, которых уже десяток — ifin.ua, delovod.ua, webzvit.com.ua и другие. Кстати, пока дергал для вас ссылки, гугл мне заботливо предложил прочитать интересную тематическую статью на DOU — рекомендую и вам ознакомится — dou.ua/lenta/articles/oblachnyj-fenomen-onlajn-buhgalterii
От меня совет: найдите и займите узкую нишу. Когда начнете заниматься продвижением, ни в коем случае не противопоставляйте себя и продукты компании 1С. На вас будет играть уже тот факт, что у вас уже есть все готовенькое с коробки и это уже реально успешно работает у других, а продукты 1С и прочих еще нужно пилить, но хороший результат никто не гарантирует.
ниша — все те, кто на бухгалтерских форумах спрашивает что нибудь кроме 1С или которых 1с по тем или иным причинам не устраивает или не решает их задач за приемлемую цену.
Кроме того, есть еще одна вероятность. На хабре конечно такие темы трогать моветон, но реальность может привести скажем так, к определенному ограничению использования 1С в Украине мотивы которого не связанны с программированием и рыночной конкуренцией.
.
Кроме того, есть еще одна вероятность. На хабре конечно такие темы трогать моветон, но реальность может привести скажем так, к определенному ограничению использования 1С в Украине мотивы которого не связанны с программированием и рыночной конкуренцией.
.
Это не ниша. Те сайты которые я вам перечислил являются вашими прямыми конкурентами и они уже работают, дают рекламу, собирают фидбеки, на основании которых исправляют баги и пишут планы развития. Недовольных «сложностью» 1С, когда нужно сделать несколько примитивных движений, по результатам которых сдать отчеты и распечатать в архив первичку для проверки, становится все меньше и меньше. Если вы позиционируете себя как догоняющего догоняющих, то это путь в никуда.
Последний довод вообще из области фантастики. 1) Вадим Мазур ни за что не откажется от своего бизнеса в Украине и полюбовно решит все возникающие «претензии»; 2) украинские типовые решения пишутся в Украине в украинской компании «ABBYY Украина» украинскими программистами; 3) для особо «свидомых» платформа имеет украинскую локализацию, а последние типовые конфигурации уже практически полностью переведены на украинский язык; 4) 1С у всех ассоциируется не с Россией, а с Бухгалтерией, а вот с Россией ассоциируется в первую очередь Газпром, но его почему-то никто не запрещает и его платежки до сих пор оплачивают :)
Последний довод вообще из области фантастики. 1) Вадим Мазур ни за что не откажется от своего бизнеса в Украине и полюбовно решит все возникающие «претензии»; 2) украинские типовые решения пишутся в Украине в украинской компании «ABBYY Украина» украинскими программистами; 3) для особо «свидомых» платформа имеет украинскую локализацию, а последние типовые конфигурации уже практически полностью переведены на украинский язык; 4) 1С у всех ассоциируется не с Россией, а с Бухгалтерией, а вот с Россией ассоциируется в первую очередь Газпром, но его почему-то никто не запрещает и его платежки до сих пор оплачивают :)
все те, кто на бухгалтерских форумах спрашивает что нибудь кроме 1С или которых 1с по тем или иным причинам не устраивает или не решает их задач за приемлемую цену
Например тех, кто спрашивает «есть что-то побыстрее 1С», а то на она не справляется с обработкой 50 000 первичных документов за сутки"?
Производительность интерпретируемых скриптов php на порядок хуже, чем производительность скомпилированного приложения при прочих равных. Когда перепроводишь документы за месяц в 1с и это занимает на мощном серваке 1-2 часа, можно себе представить, сколько времени займет эта операция у приложения на php.
НДС, вычисляемый помесячно на основе оборотов, документы, проводимые задним числом, и отсутствие итогов на уровне платформы — это как? Промежуточные итоги и были придуманы в 1с для того, чтобы корректировать последующие итоги без их пересчета при проведении документов задним числом, а также, чтобы опираться на них при вычислении налогов, остатков итп для ускорения процесса. PHP +проведение задним числом документов в системе без итогов = вечность.
Даже, если представить, что автор создаст систему, которая будет идеалом в плане логики и реализации, все упрется в производительность выбранного стека технологий. На реальной базе с двумя десятками активных пользователей все будет висеть намертво.
НДС, вычисляемый помесячно на основе оборотов, документы, проводимые задним числом, и отсутствие итогов на уровне платформы — это как? Промежуточные итоги и были придуманы в 1с для того, чтобы корректировать последующие итоги без их пересчета при проведении документов задним числом, а также, чтобы опираться на них при вычислении налогов, остатков итп для ускорения процесса. PHP +проведение задним числом документов в системе без итогов = вечность.
Даже, если представить, что автор создаст систему, которая будет идеалом в плане логики и реализации, все упрется в производительность выбранного стека технологий. На реальной базе с двумя десятками активных пользователей все будет висеть намертво.
Вы наверно последние лет 12 были в коме. PHP давным давно уже не интерпретируемый язык. В отличие от 1С. И время перепроведения документов зависит от скорости СУБД и работы с ней а в 1С с этим более чем неоптимально.
Но в описываемой системе нет необходимости перепроводить все документы — вы невнимательно прочитали суть.
И в результате как вы сами написали считает два часа. Архитектура 1С строилась на dbf файлах — промежуточные итоги было вынужденной мерой. Почему оно так осталось — для меня загадка. Видимо не захотели все переписывать — поменяли только СУБД.
этим занимается СУБД и там простой UPDATE одной записи — то есть микросекунды.
Бездоказательное утверждение. Во первых два десятка активных пользователей это в лучшем случае несколько обращений в минуту — это работа с документами а не игра-стрелялка. Во вторых — вычисление итогов пересчетом уже неоднократно опробовано на больших данных в аналогичных моих проектах (например логистика складов). Нет никаких проблем просуммировать данные по одному столбцу целого типа хоть за пять лет.
И потом, система ориетироваана на малый бизнес а не на Сбербанк.
Уже создал. А насчет идеала — на то и PHP — бери и коректируй бизнес-логику под свои нужды в простом редакторе.
Но в описываемой системе нет необходимости перепроводить все документы — вы невнимательно прочитали суть.
Промежуточные итоги и были придуманы в 1с для того, чтобы корректировать последующие итоги без их пересчета при проведении документов задним числом
И в результате как вы сами написали считает два часа. Архитектура 1С строилась на dbf файлах — промежуточные итоги было вынужденной мерой. Почему оно так осталось — для меня загадка. Видимо не захотели все переписывать — поменяли только СУБД.
PHP +проведение задним числом документов в системе без итогов = вечность.
этим занимается СУБД и там простой UPDATE одной записи — то есть микросекунды.
На реальной базе с двумя десятками активных пользователей все будет висеть намертво.
Бездоказательное утверждение. Во первых два десятка активных пользователей это в лучшем случае несколько обращений в минуту — это работа с документами а не игра-стрелялка. Во вторых — вычисление итогов пересчетом уже неоднократно опробовано на больших данных в аналогичных моих проектах (например логистика складов). Нет никаких проблем просуммировать данные по одному столбцу целого типа хоть за пять лет.
И потом, система ориетироваана на малый бизнес а не на Сбербанк.
Даже, если представить, что автор создаст систему, которая будет идеалом в плане логики и реализации
Уже создал. А насчет идеала — на то и PHP — бери и коректируй бизнес-логику под свои нужды в простом редакторе.
Уже создал.
Забавно. Я не поленился, посмотрел вашу систему. Могу сказать, что с одной стороны ваше упорство похвально, с другой — у вас нет никакого морального права ругать программистов 1С. Ваш продукт написан на коленке, и с кучей говнокода. Зато в названии вашего калькулятора есть слово ERP, пафоса не занимать.
И скажите спасибо своему хостингу, что там есть автоматическая защита от SQL injection. Вашим потенциальным клиентам такое счастье может не перепасть, и эта штука похоронит их данные от первого же залётного дятла.
$sql = "select * from " . $table;
if (strlen($where) > 0) {
$sql .= " where " . $where;
}
if (strlen(trim($orderbyfield)) > 0) {
$sql .= " order by " . $orderbyfield;
}Причем все эти $where, судя по всему, топают прямо с полей формы.
у вас нет никакого морального права ругать программистов 1С
Я никого не ругаю а делаю сравнение с наиболее известной системой, как и принято
в подобных случаях.
что там есть автоматическая защита от SQL injection
Здесь невозможны никакие инъекции, просто злоумышленнику их негде воткнуть. А там где возможны, защита обеспечивается с помощью средств ADODB. И вообще это по определению внутрикорпоративная система — доступ будет только для сотрудников, никаких «залетных дятлов».
Причем все эти $where, судя по всему, топают прямо с полей формы.
нет. Не надо фантазировать.
Зато в названии вашего калькулятора есть слово ERP
Не придумал более подходящего но короткого термина для названия.
И этот «калькулятор» обеспечивает все основные первичные документы и отчеты. Примерно то же что и базовая конфигурация 1С.
Не надо быть таким ревнивым — на ваш век вашей любимой 1С вам хватит.
И этот «калькулятор» обеспечивает все основные первичные документы и отчеты
Но только в виде демо-версии потенциальных возможностей в каком-то далеком будущем. Т.к. сейчас с его помощью даже киоск автоматизировать нельзя. Потому что эта софтинка не позволит вам сигареты продавать одновременно пачками и блоками, а кока-колу продавать бутылками, а закупать ящиками.
Ещё она не позволит вам оплатить поставщику по выбранной приходной накладной, или получить от клиента оплату по конкретному счету.
В ней нет бухгалтерского учета. Там есть какие-то журналы проводок, но зачем они нужны, непонятно, т.к. проводки нигде не настраиваются. Есть группы товаров, но никакого отношения к счетам учета этих товаров они не имеют, просто для красоты служат.
В ней нет налогового учета, хотя налоги мы все платим.
В ней есть возможность указать НДС (какой, на что, по каким товарам?), но нет налоговых накладных.
В ней нет возможности интеграции с другими системами, вы не можете, например, выгрузить отчет по единому налогу или ЕСВ в какой-нибудь, я не побоюсь этого слова, Медок. Да вы, блин, даже посчитать их там не можете.
А вы ещё пишете «Примерно то же что и базовая конфигурация 1С» :)
Поэтому она ничего ещё не обеспечивает. В качестве портфолио как программиста-фуллстека она годится. Дескать, смотрите, сам спроектировал, написал. Но пользоваться как учетной системой ей нельзя, там ещё работы и работы. Причем работы не наколенной, а вдумчивой, с глубоким знанием предметной области, а не поверхностным.
разумеется это демка. Самый минимум. Жирно будет сделать бесплатно полную конфигурацию особенно витиеватые регламентрованые отчеты.
Сделана платформа (в терминах 1С) и минимальная конфа. Все на гитхабе.
Налоговые накладные есть. Есть экспорт в XML по стандарту ГНИ а дальше хоть в медок хоть в OPZ на подпись.
В киоске обычно суммовой учет — нет никаких проблем. А вообще при перемещении на розничную точку ящики спишутся а бутылки запишутся.
И вряд ли в приходной накладной будут ящики — ящик понятие нестанлартное — прописано будет бутылками. Програма для малого бизнеса а не для супермаркетов куда фурами завозят.
Позволит.
В банковской выписке указывается по какому документу.
А зачем их настраивать. Проводки прописаны в коде PHP коректируются если надо в простом редакторе. Все равно для этого нужен програмист — надеюсь не станете рассказывать что в 1С это делают бухгалтера (последний раз они это делали в версии 2.0 в середине 90х).
Просто здесь не выбираются счета на форме документа — пользователь работает с бизнес сущностями а не с номерами плана счетов как принято в 1С родом из 90х годов. На фига настраивать или каждый выбирать счет для НДС если он задается один раз при внедрении и менятся уже не будет.
Смыслом разработки не было скопировать 1С. А вы судя по всему не представляете как может быть по другому — не как в 1С.
Впрочем, народ часто пользуется поделками на Делфи где вообще ничего нельзя изменить и кода исходного нет, да еще и деньги за это платит. И ничё. Так что мой вариант не самый грустный.
Любое внедрение требует напильника. Разница в том что тут это гораздо проще чем в 1С.
И обновлять гораздо проще — скопировал пару файликов в каталог сайта и все — документ или репорт обновлен. И нет риска снести изменения в логике другого документа.
Сделана платформа (в терминах 1С) и минимальная конфа. Все на гитхабе.
но нет налоговых накладных.
Налоговые накладные есть. Есть экспорт в XML по стандарту ГНИ а дальше хоть в медок хоть в OPZ на подпись.
Потому что эта софтинка не позволит вам сигареты продавать одновременно пачками и блоками, а кока-колу продавать бутылками, а закупать ящиками.
В киоске обычно суммовой учет — нет никаких проблем. А вообще при перемещении на розничную точку ящики спишутся а бутылки запишутся.
И вряд ли в приходной накладной будут ящики — ящик понятие нестанлартное — прописано будет бутылками. Програма для малого бизнеса а не для супермаркетов куда фурами завозят.
Ещё она не позволит вам оплатить поставщику по выбранной приходной накладной,
Позволит.
В банковской выписке указывается по какому документу.
В ней нет бухгалтерского учета. Там есть какие-то журналы проводок, но зачем они нужны, непонятно, т.к. проводки нигде не настраиваются.
А зачем их настраивать. Проводки прописаны в коде PHP коректируются если надо в простом редакторе. Все равно для этого нужен програмист — надеюсь не станете рассказывать что в 1С это делают бухгалтера (последний раз они это делали в версии 2.0 в середине 90х).
Просто здесь не выбираются счета на форме документа — пользователь работает с бизнес сущностями а не с номерами плана счетов как принято в 1С родом из 90х годов. На фига настраивать или каждый выбирать счет для НДС если он задается один раз при внедрении и менятся уже не будет.
Смыслом разработки не было скопировать 1С. А вы судя по всему не представляете как может быть по другому — не как в 1С.
Впрочем, народ часто пользуется поделками на Делфи где вообще ничего нельзя изменить и кода исходного нет, да еще и деньги за это платит. И ничё. Так что мой вариант не самый грустный.
Но пользоваться как учетной системой ей нельзя, там ещё работы и работы
Любое внедрение требует напильника. Разница в том что тут это гораздо проще чем в 1С.
И обновлять гораздо проще — скопировал пару файликов в каталог сайта и все — документ или репорт обновлен. И нет риска снести изменения в логике другого документа.
разумеется это демка. Самый минимум. Жирно будет сделать бесплатно полную конфигурацию особенно витиеватые регламентрованые отчеты.
Ну отож
Налоговые накладные есть.
Входящие нашел, исходящие где-то, наверное, хорошо запрятаны. Но то такое.
В киоске обычно суммовой учет — нет никаких проблем. А вообще при перемещении на розничную точку ящики спишутся а бутылки запишутся.
Это как? Один товар пропал, другой появился?
А зачем их настраивать
Потому что они разные. Аналитические счета у половины предприятий свои собственные. Блокноты, фирменные кепки и бензин — это всё ТМЦ, но канцелярию мы учитываем на одном счету, одежду на другом, топливо на третьем.
А вы судя по всему не представляете как может быть по другому — не как в 1С.
Вы намекаете на то, что указать на отсутствующий (но нужный бизнесу) функционал в вашей системе — это узость мышления? Типа я задумку творца-художника не понял?
Вы сами слово 1С тут повторяли чаще, чем все остальные участники дискуссии, вместе взятые. И тут же пытаетесь оговариваться, что вы не повторяете 1С, не надо вас сравнивать с 1С.
Любое внедрение требует напильника.
Есть такая категория клиентов, как мелкий бизнес. Это как раз та категория, которая обычно не покупает «внедрение с напильником», а покупает готовый, работающий из коробки продукт. И это как раз потребители систем такого класса. Можно купить, поставить и сразу пользоваться и Акцент, и Инфобухгалтер, и 1С, и там не нужен будет ни программист, ни внедренец, это сделает любой мальчик-компьютерщик вместе с бухгалтером.
Разница в том что тут это гораздо проще чем в 1С.
С чего бы это вдруг? Никому не известная система, с кучей костылей, с необходимостью самостоятельно работать с СУБД через SQL, и вдруг стала гораздо проще?
Она проще лишь в том плане, что там ещё функциональность куцая.
удалить — (не пойму как удалять коментарии)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как нам обустроить альтернативу 1С