Статья: Сравнительный анализ ИНФИН-Бухгалтерии и 1С: Бухгалтерии

[Hakimroma]

вы че там, че так мало???????

[Аноним]

Очень далеко от действительности. С ИНФИН я работал и вспоминаю это как страшный сон... Нечего и сравнивать с 1С.
А практически все "минусы" 1С существуют только в воображении автора.

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

[tomvlad]

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

[Dracosha Andrew]

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

При этом антивирусы у них перестают обновляться, а почта доходить до адресата

[PiterBest]

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

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

[tomvlad]

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

[PiterBest]

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

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

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

[tomvlad]

PiterBest , Вы же не станете отрицать, что году так в 97-98 все отечественные конкурирующие производители программ для ведения бухгалтерского учета были примерно одного уровня. Например в нашем небольшом городишке с 700'000 жителями примерно половина фирм сидели на Инфине, остальные на 1С, БЕСТ, ПАРУС и пр.

Прошло 10 лет. Что же изменилось? Соотношение 1С к прочим производителям наверное по стране порядка 90% / 10%. И что бы Вы не говорили про первичные продажи, ситуацию в общем изменить будет сложно. Не случайно одним из самых востребованных продуктов являются утилиты для перевода на 1С или интеграции с 1С.

Честно говоря, про продажи я и сам не собирался писать, но сдается мне что Ваша желчность (пардон) вызвана скорее незнанием функционала и возможностей ПО конкурентов.

В нашем городишке с БЭСT'ом я встречался только 2 раза - использовала его средненькая торговая фирма и бюджетник. Бюджетник уже давно и прочно сидит на ЗИКе, а торговой конторе нужна была НОРМАЛЬНАЯ программа складского учета. Уж не знаю почему, но БЭСТ их не удовлетворил в части аналитики управленческого учета - используют ТиС. Видимо разработчики БЭСТа мозг в этом отношении недомучили (или мучить было нечего), причем давления со стороны франчайзи 1С на конкурента не оказывалось - это было его САМОСТОЯТЕЛЬНОЕ решение. Так что насчет кривых рук это вопрос спорный.

Теперь к вопросу о кислом. Вы постоянно муссируете вопрос терминологии. Оставьте терминологию в стороне. Субконто или аналитический разрез, или аналитический счет или еще что, какая по большому счету разница бухгалтеру, если продукт позволяет ему решать свои задачи. То, что не хватает специалистов, или им не хватает ума (желания, терпения, времени) изучить документацию - это уже вопрос другой. Как известно, за счет массовоого распространения 1С появилась и отрицательная сторона этого - нехватка грамотных специалистов. Зачастую программистами именуют себя люди, не знающие элементарных вещей. Вот сказать это я право имею - пытаюсь полгода найти программиста себе на замену. Из всех, кто приходил, а это было порядка 30 человек, тестовую задачку решил только один (и того не удалось переманить - повысили зарплату на прежней работе). Все остальные благополучно отсеялись на простейшей тестовой задаче. И ведь наверняка большинство из них осело именно на должность программиста 1С. Вот это я и имел в виду, а то, что Вы стараетесь увести разговор в сторону кривых рук или непродуманности интерфейса - это все вода. Кстати, о гибкости и доступности каждому - никто уже не кричит, Вы отстали на 5 лет. Никто например не позиционирует УПП как продукт для автоматизации ларька. Не должен сисадмин в НОРМАЛЬНОЙ конторе настраивать учетную политику или настраивать механизм партионного учета, ибо системное администрирование и должность бизнес-аналитика (внедренца, программиста, постановшика задачи, тестера) несовместимы. И опять мы возвращаемся к ларькам. А Вы вообще в курсе, что для ларьков есть другие решения, которые термин "субконто" не используют (видимо для понимания ларечников это недоступно). Но ведь нет, Вы говорите, что мозги не те или руки кривы. Посмотрите на себя со стороны, иногда помогает. За сим PiterBest разрешите откланяться, Вы мне уже неинтересны.

[ВикторП]

tomvlad, уж так получилось, что и я не работаю с 1с Уже давно, лет 15.
Основная причина - ну очень в ней трудно организовать учет среднего предприятия(сотрудников на 100-1000) в ЕДИНОЙ(!) базе. Причин много и, надеюсь, вы их хорошо знаете. Обязательно надо дробить бухучет на подсистемы. А при последующем объединении выплывает куча, в общем-то не разрешимых проблем. Вот поэтому и ходит шутка, что 1с может работать ТОЛЬКО в паре с xls. :

[tomvlad]

Ну ВикторП, знаю я одну контору, которая в Excell рассчитывает зарплату и уже потом результаты переносит в зарплатную программу. Неважно, что через ж..., главное расчетчик так привык. Пока справляется, начальство устраивает. И неважно какая у него программа, 1С не 1С. За 15 лет все довольно сильно изменилось. Большинство предприятий, кстати, умудряются не дробить учет на подсистемы (кроме пожалуй зарплаты, ну так специфика). Для торговых контор, да - сложнее, но уже почти год одинэсы пытаются сделать обмен с человеческим лицом, что в принципе уже работает (плюсов и минусов довольно много и перечислять их я не буду). Кстати, при грамотной настройке обмена (адаптации правил конвертации) неразрешимых проблем нет. Сейчас как раз занимаемся тем, что строим корпоративную информационную систему из нескольких распределенных баз. Несколько сегментов уже ввели в эксплуатацию, к зиме закончим остальное. Так что Ваши утверждения насчет Excell'я голословны.

[ВикторП]

Дело не в xls. Это сопутствующее.
Если дробить учет на любом предприятии по отдельным базам, то в принципе не возможно построить полный, достоверный, непрерывный учет! Это априори.
Пока вижу, что только в 1с8 что-то сдвигается в нужном направлении. А до этого все 1с....

[ВикторП]

Ну ВикторП, знаю я одну контору, которая в Excell рассчитывает зарплату и уже потом результаты переносит в зарплатную программу.

А вот мне не везет! Куда не прийду, всюду одно и то же - если стоит 1с, то все встают на дыбы, если начинаю удалять xls! Покупать-то лицензии не хотят, а руководство просит очистить от всего не лицензионного.
Правда городок у нас маленький, тыщ на 300

[tomvlad]

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

[ВикторП]

Согласен, построить будет трудно.

Главное знать как строить.

Кстати, достоверный учет и на базе одной программы построить сложно

Извиняюсь, но я не говорю про РАЗНЫЕ(!) программы, я говорю о разных базах. Разных, разрозненных массивах информации. Уж пусть лучше будут обслуживать ее разные программы, но база должна быть одна! Тогда еще можно с вами согласиться и про сложность, и про знания как строить. Но, скорее всего, вы согласитесь со мной, что тогда будет лучше все И описать в одной программе. Но это уже детали.

Но с тем, что построить нельзя в принципе, категорически несогласен.

Тут вы спорите не со мной, а с Лукой Пачолли. А его выводы подтверждаются 500 летней историей учета Извините, но я не доживу до торжества ваших выводов.

[tomvlad]

Извиняюсь, но я не говорю про РАЗНЫЕ(!) программы, я говорю о разных базах. Разных, разрозненных массивах информации. Уж пусть лучше будут обслуживать ее разные программы, но база должна быть одна! Тогда еще можно с вами согласиться и про сложность, и про знания как строить. Но, скорее всего, вы согласитесь со мной, что тогда будет лучше все И описать в одной программе. Но это уже детали.

Тут вы спорите не со мной, а с Лукой Пачолли. А его выводы подтверждаются 500 летней историей учета Извините, но я не доживу до торжества ваших выводов.

Были попытки описать все в одной программе. Поинтересуйтесь у внедрявших УПП, сколько стоила техника для нее, обучение персонала, да хоть просто трафик при связке нескольких филиалов. Допустим, есть база розничного магазина. Зачем оператору приемки товара информация о взаиморасчетах, зарплате, МСФО, бюджетировании и пр.? Конечно, при наличии хороших каналов связи можно организовать работу через выделенную линию. А если авария? Что, курить прикажете кассирам? Так что все споры об одной базе беспредметны в отрыве от конкретики.

Теперь предметно. В современных типовых НЕ МЕНЯЯ кода можно настроить On-Line обмен практически с любой периодичностью. Данные практически мгновенно могут попадать в бухгалтерскую программу. И нефиг приплетать Пачоли, и достоверность и полнота и непрерывность есть. Не умеете готовить - берите монстра.

[ВикторП]

Возможно я не точно выразился. Извините. Я не говорю про удаленное обслуживание баз данных. Я говорю про учет только на одном предприятии, без удаленного доступа, без обособленных подразделений. Все базы лежат на одном сервере, все рабочие места находятся в пределах локальной сети. Поэтому внешние каналы связи тут в принципе не важны. А локалка на 100мв/с всегда работает нормально(если нормально ее смонтировали). Не про то речь.
Учет должен быть непрерывным, сплошным, описываться методом двойной записи. На этих утверждениях Пачолли в основном и строится современный бухучет. Да, есть попытки применять другие методы, но, в конце- концов, они заканчиваются не удачей и про них я тоже не говорю.
Суть в другом. Если взглянуть на информационную базу учета с точки зрения Пачолли, то получается что для получения достоверного учета на предприятии, недопустимо ее разбивать ни на какие блоки, модули. Иначе появляются узлы неопределенности, неоднозначности учета, которые обязательно приведут к неточности, погрешности учета. Я думаю вы с этим согласитесь, но все же маленький пример.
Предположим в раздельных базах ведется учет МПЗ и авансовые отчеты. Если по авансовому отчету надо оприходовать какое-то МПЗ, то приходится это делать либо:

- в разных базах дублируя данные. Проводки скорее всего будут для базы "мпз"
Дт10/аналитика_мпз Кт71(скорее всего без аналитики!).
И для базы "АО"
Дт10(без аналитики!) Кт71/ФИО.

- только в одной, но это, априори, не очень достоверно(информации-то с другой базы нет).
Скажем для "АО" будет выглядеть примерно так:
Дт10/аналитика_мпз Кт71/ФИО.
Но тут, сами понимаете, аналитика_мпз будет всегда не достоверна.
Всякие объединения этих баз с любой периодичностью делу не помогут.
И это только для одного случая, а их по жизни очень много. Многовариантность задачи учета не дает ни какой возможности решить ее ни какими методами искусственного объединения разрозненных баз. И это мы рассматриваем еще без внешнего возмущения, без участия интересов "человека- ищущего" Вот поэтому-то иностранные компании и не хотят связываться с Российским учетным софтом.

[tomvlad]

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

[PiterBest]

Учет должен быть непрерывным, сплошным, описываться методом двойной записи.

Вот тут я возможно ошибаюсь но у буржуев учет идет по принципу стакана и нет понятий дебета-кредита Это все-равно метод двойной записи ?

Суть в другом. Если взглянуть на информационную базу учета с точки зрения Пачолли, то получается что для получения достоверного учета на предприятии, недопустимо ее разбивать ни на какие блоки, модули.

Могу согласиться если идет именно о бухучете.
Но есть контур оперативного учета и там несколько иные правила учета.
И совмещение таких учетов не есть гуд на мой взгляд
Вторая ситуация. Фирма построена по принципу мини-холдинга. Непотопляемый корабль из полусотни мелких. Закрыли одну и ладно. Откроем новую. Общий информационный оперативный учет нужен единым.
Но смысл нагружать его бухучетом каждого отдельного предприятия ?
Когда проще распределить на другие ресурсы:
- ресурсы локальных компов даже самых простых сейчас велики настолько, что для локальных задач почему бы их не задействовать
- зачем держать все яйца в одном лукошке при такой схеме
- нет необходимости заставлять сервер ворочать одной большой таблицей
И найдется много аргументов. Причем при такой схеме какое либо зеркалирование и он-лайн обмены тоже особо не нужны, если исходить из принципов необходимо и достаточно.

[Dracosha Andrew]

А я согласен с ВикторП двойная запись должна присутствовать всегда. Деньги не должны возникать из воздуха и уходить в никуда. Пусть план счетов не будет соответствовать ПБУ, скорее всего он будет много проще. Но двойная запись должна быть!!

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

Более того, скорее всего, что план счетов для оперативного учёта не будет совпадать с бухгалтерскими. И, более того, даже у разных юридических лиц в пределах одного холдинга может быть разный план счетов в бухгалтерии!! А консолидированная отчётность должна тем не менее не только составляться, но и быть прозрачной в рамках всего холдинга.

[PiterBest]

А я согласен с ВикторП
Двойная запись должна присутствовать всегда. Деньги не должны возникать из воздуха и уходить в никуда. Пусть план счетов не будет соответствовать ПБУ, скорее всего он будет много проще. Но двойная запись должна быть!!

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

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

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

Более того, скорее всего, что план счетов для оперативного учёта

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

[ВикторП]

Извините, никогда еще в моей практике никто из клиентов не вел отдельно материалы и авансовые отчеты.

А считать раздельно зарплату и всю прочую бухгалтерию вас устроит как очередной пример. А я и писал именно как о примере!

Пусть план счетов не будет соответствовать ПБУ, скорее всего он будет много проще.

А что-то мне подсказывает, что в ПБУ и НК нет упоминания о плане счетов.

Более того, скорее всего, что план счетов для оперативного учёта не будет совпадать с бухгалтерскими.

На сколько я знаю планы счетов если и разбегаются, то совсем не существенно. Куда сильнее разбегается БУ, НУ и УправленческийУчет. Но это, за малым исключением, совсем не страшно.

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

Извините, но что вы подразумеваете под "стаканом"? Может то, что в "ихних" программах практически нельзя править ранее сделанные операции?

[PiterBest]

Извините, но что вы подразумеваете под "стаканом"? Может то, что в "ихних" программах практически нельзя править ранее сделанные операции?

Стакан это когда я в один и тот же счет пишу с плюсом и с минусом и храню по нему сальдо не делая дебета-кредита в нашем понимании. Вообще наверно я неправильно написал у них все-таки двойная запись. Как только задумался как объяснить принцип стакана - почему-то сразу и сам понял А принцип в том, что они на один счет кладут с плюсом а на другой с минусом и есть строго положительные или строго отрицательные счета.
Наверно меня сбивает с толку вот что. Мы оперируем счетами например дебет 41 кредит 60 товар пришел и деб 60 кред. 51 заплатили.
А уних если (могу перепутать сестами но суть примерно такая) я сделаю источник 41 а целевой 60 то переводяв лоб на наше понимание в дебет 41 а кредит 60, а если счета местами поменяю то дебет-кредит не изменится, а изменится знак цифры, помещаемой на счет. А чтобы поменять дебет-кредит надо делать какую-то специализированную обратную проводку, которая по умолчанию не стоит (это когда их программу по российский учет пытаешься локализовать).
Т.е. как бы всегда по сальдо учет идет и это сальдо должно отражать реальную картину: остаток товара,остаток денег (если переводит на наше представление) и получается записи то двойные,только по другим принципам к их построению надо подходить: по другому строить.
Другой угол видения....метода бухучета.
Так что был неправ - запись имеет две стороны, значит таки двойная

[Dracosha Andrew]

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

[ВикторП]

Возвращаясь к структуре базы данных. Только наличие двойной записи позволяет построить достоверный учет на предприятии. Т.е. когда запись имеет вид "куда-откуда- сумма". Все прочие методы не гарантированы от ошибок учета. Точнее наоборот- ошибки гарантированы! Это с точки зрения учета.
А с точки зрения программистов(программ учета) базы дробятся не от хорошей жизни. То ресурсов вычислительных комплексов не хватает, то мозгов- как этого "долбанного Луку" обойти. А бывает и просто пишут только то, что требуется на данный момент данному заказчику.
Что же получается в остатке?
1. Для заказчика. Если хочешь построить надежную, достоверную систему учета на предприятии НЕЛЬЗЯ брать программу в которой заложен учет в раздельных базах по кускам, по модулям, по подсистемам и т.д. Чтобы там не говорили программисты, при этом они, даже самые умные(!!) не смогут обеспечить достоверность. Это доказывает и математика(теория графов).
2. Для программистов.

[PiterBest]

1. Для заказчика. Если хочешь построить надежную, достоверную систему учета на предприятии НЕЛЬЗЯ брать программу в которой заложен учет в раздельных базах по кускам, по модулям, по подсистемам и т.д. Чтобы там не говорили программисты, при этом они, даже самые умные(!!) не смогут обеспечить достоверность. Это доказывает и математика(теория графов).

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

Потому как, например в оптовой торговле объединение оперативного и бухгалтерского учета ведет к неминуемому конфликту:
- бухгалтеру надо накладную провести июнем, а менеджеру июлем и это уже разные записи в разных балансах (если можно так сказать)
Т.е. о графах и достоверности следует говорить относительного одного конкретного вида баланса и массива записей операций к нему.

[ВикторП]

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

Вот-вот и это надо учитывать. Но все же база должна быть одна! Просто в ней для оперативного, управленческого учетов могут использоваться дополнительные журналы аналитики, но они обязательно должны быть жестко увязаны с основным журналом бухгалтерского операций(ЖБО). Если это будут разные базы, т.е. не связанные тесным образом, не интегрированные, то опять гарантированно разбежится управленческий и бухгалтерский учет, а значит и весь учет предприятия. При этом необходимо наличие специфической ответственности по ведению этих журналов, ограничения прав доступа при определенных условиях, например, закрытие отчетного периода. Чтобы, закрыв отчетный период в ЖБО, не было возможности править связанные журналы, например, оптовой торговли в части влияющей на переданные данные в ЖБО. Тут, как писал уважаемый tomvlad, и «нужны мозги программиста».
Но я бы хотел закончить мысль о структуре баз данных. Если учетная информация хранится в разных базах, то получить достоверного учета на предприятии в принципе очень трудно, а с учетом человеческого фактора, не возможно. Это априори. Допустимо наличие различных вспомогательных журналов аналитики для управленческого учета, но они обязательно должны быть жестко интегрированы в единую базу. Всяческие отклонения от этого принципа гарантированно приведут к недостоверным результатам учета. Таково тут переплетение требований ХV века и возможностей XXI века, Луки Пачолли и Билла Гейтца.
Таков, по моему мнению, должен быть фундамент оценки при сравнении разных программ бухгалтерского учета. А уж потом надо рассматривать маркетинг, франчайзинг и прочую современную обвязку.
А вот теперь можно попытаться оценить состояние рынка бухгалтерских программ с такой точки зрения.
Посмотрите взвешенно, вдумчиво, оцените то с чем вы работаете. Возможно это поможет вам избежать конфликтов со «строптивыми» клиентами, когда будете сдавать несколько не то, что хотел видеть заказчик на этапе ТЗ. Возможно ваша программа изначально не способна выполнить все требования вашего клиента. И тогда ни какие самые умные программисты- прикладники тут уже не помогут.
Успехов всем!

[PiterBest]

Вот-вот и это надо учитывать. Но все же база должна быть одна! Просто в ней для оперативного, управленческого учетов могут использоваться дополнительные журналы аналитики, но они обязательно должны быть жестко увязаны с основным журналом бухгалтерского операций(ЖБО).

Виктор я понимаю о чем Вы, но мы в России живем. Вы предлагаете увязывать то, что в этом собственно не нуждается.
Вот Вам примеры:
- в управленческом учете есть документы, которых нет в бухгалтерском
Нет в принципе как класса
- в бухгалтерском учете есть документы, которых нет в управленческом тоже как класса
Зачем Вы их да еще в одну книгу увязывать собираетесь ?
Тут нужно понимать потребность в целостности каждого отдельного контура.
Например, я могу в системе вести учет предприятия состоящего из 50 на УСН, но при этом учет бухгалтерский каждого отдельно взятого из этих зачем он мне там нужен ? Пусть ведут его отдельно и это будет логично и правильно. Просто часто слышен подход что надо консолидировать, а почему бы не сделать задачу обратную ? И это гораздо проще.
Я пишу о технологиях, которые на практике живут и более того им мои клиенты продолжают придерживаться, а другим которые все в кучу собирали, после того как применили появился порядок и учет
Так что речь не о мое конфликте с клиентами а о конфликте различных структур пользователя между собой после того как их в кучу собирают и наши Российские особенности на это дело накладывают. Они устают от схемы Лебедь, рак и щука. И кто сказал что управленческому учету нужен бухгалтерский ? Не факт.
Мнение мое такое: нельзя придерживаться кранойстей ни при разделении ни при объединении. Надо уметь грамотно комбинировать оба метода и действовать в каждой конкретной ситуации.
Объединение всех видов балансов в одну книгу это крайность, собственно как и утверждение что их обязательно надо разделять.

[Dracosha Andrew]

ВикторП, Билл Гейц не занимался разработкой концепций учёта. Его Вы зря упомянули...

[ВикторП]

ВикторП, Билл Гейц не занимался разработкой концепций учёта. Его Вы зря упомянули...

Да, он то же мне вчера звонил об этом
Я писал о другом, о возможностях ХХI века, а их как раз и обеспечил Билл.
После отпуска продолжим.

[Dracosha Andrew]

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