×
×

Ваше сообщение

Для входа нажмите здесь

 
 

Вы можете выбрать иконку, характеризующую сообщение

Дополнительные опции

  • Преобразит www.example.com в [URL]http://www.example.com[/URL].

Просмотр темы (новые вначале)

  • 22.11.2013, 08:15
    Аноним
    Очень довольна


    Цитата Сообщение от Аноним Посмотреть сообщение
    Про ИНФИН под Windows!
    Программа сырая, глюков много. Инфиновцы, продавая программу, красочно описывают ее прелести, но когда уже в процессе работы возникают проблемы, то все за доп. плату. Пришел их человек, посмотрел все с умным видом, че-то понажимал на рабочих местах - за три часа, которые он у нас присутствовал мы заплатили денги и все осталось по старому. Просили кое-что настроить - настроили, но не так как нам надо было и не уложились в сроки. Конфликтик вышел ))
    Если в старой программе под DOS с базой можно было делать все, что угодно(в FoxPro вытащить, найти любые цифры), то здесь, если бухгалтер ошибся, или ящик завис - замучаешся баланс сводить. Аесли бухгалтер не один, если их >20 и все они обрабатывают болшие объемы информации? Работает по сети все медленно, иной раз непонятно завис он или "работает". Зависает кстати часто. Ключик электронный слетает стабильно раз или два в неделю.

    P.S. На одном немаленьком предприятии, я слышал, бухгалтера увольнятся начали после внедрения этой программы, потому - как начальству пофигу что там в программе не работает - все должно быть сделано и сделано вовремя. Не сделал - твои проблемы, ты виноиат, а из зарплаты минус! Вобщем, у автора статьи(Гайсина М.М.) мнение конечно предвзятое.
    А бухгалтера наши хают эту программу!!!
  • 25.09.2013, 12:26
    Аноним
    Тема старая, а вопросы остались. Читала, читала ничего не поняла. Сколько людей столько и мнений в защиту своей программы, а вот субьективного ответа так и не получила.
    У меня инфин и никогда не пользовалась 1с.
    Интересен был профессиональный анализ, а в теме одну и другую программу рвут как тузик грелку.
    Когда то пользовалась бэст, но это что-то с чем-то!
    Свести баланс или сверить расчеты?!!!! Это жесть! Приходилось распечатывать отчеты и практически вручную сверять и искать ошибки.
    В инфине можно методично просматривать месяц раньше или месяц позже одним нажатием клавиши и вплоть до 3-х летнего периода назад не выходя из оборотки! Очень удобно. Разноска тоже не сложная. Я сформировала стандартные проводки и за одно нажатие программа сама скидывает сумму в расход на ндс на расчеты с контрагентом в книгу покупок и может сразу же спрашивать типа тебе распечатать?
    Все это я сама вводила при составлении стандартной проводки. Но! Я один раз посидела над формированим этих проводок и потом уже комп только летал вводя данные. Я обслуживала две фирмы от и до- одна, с приличным оборотом данных и обходилась без помощников. Теперь вот мне в поисках новой работы все предлагают только знание 1с бух.
    Я хотела бы узнать на практике как работать с этой программой и ее нюансы, но в ютубе показывют общие знания, в демоверсии программа тормознутая и глючная. Так я и не поняла, как работает эта 1с.
    Кто бы ответил именно по удобствам, пусть даже хвалебным я не прочь послушать опытных пользователей.
  • 02.04.2011, 20:13
    Аноним
    Сравнительный анализ программ ведется по параметрам, слабо влияющим на производительность труда бухгалтеров и предприятия в целом.
    Почему?
    Крайне убогий уровень знания бухучета, местечковые интересы отделов, незнание и неумение руководить информационными подразделениями фирмы со стороны всех участников информационного обмена и всех руководителей и потребителей информации, а так-же производителей софта.
    Главные здесь МНС. ЕКХ, в т.ч. задним числом. Остальные не котируются.
    Как изменить что либо? Это невозможно.
    Мелкомягкие участвуют в мафии производителей железа, за измененный интерфейс и "более требовательные" к железу (а по русски - тормозные, неопимизированные, грязно писанные студаками 1 курсов проги) требуют немеренное бабло.
    В любом случае у меня вопрос - почему ексел на 386 проце файл с 100 000 записей считал за 1 секунду, а двухядерник 3,2 Ггц с 8 ОЗУ, супершиной и супервинтом тот же файл считает 8 секунд????????????????????????????????????????
    Почему 386 базу данных за предприятие считал в 1С 2.0 закрытие месяца за 5 минут, а 8 ядерник 64 разрядный ту же базу с рейдом 10 в 1С8.1 - 14 минут ???????????????????
  • 02.10.2008, 16:30
    Dracosha Andrew
    Ребята, по-моему у вас идёт терминологическая путаница. Просто в одном случае под базой данных понимается таблица баз данных, или набор таблиц, а в другом "набор данных и описание правил их обработки (ГОСТ так трактует)" По-моему вы говорите об одном и том же, но в разных терминах.
  • 01.10.2008, 15:41
    PiterBest
    Не знаю что там Вам может подсказывать, но:
    Во-первых, я не писал Вам что конкретную запись делаю в разных базах.
    Вы путаете работу в разных контурах и метод двойной записи.
    В каждом контуре каждая запись сделана по принципу двойной записи, но это не значит что бухгалтерский контур обладает наиболее полным набором этих записей и наиболее точно отражает реальную картину.
    Во-вторых я пишу Вам совершенно точно не как программист.
    Во-третьих реакция на события у нас в продуктах реализована давно и именно в dbf формате.

    Вы просто попробуйте посмотреть на решение не со своей колокольни.
  • 01.10.2008, 14:50
    ВикторП
    PiterBest, извините, но что-то мне подсказывает, что вы не очень хорошо усвоили принцип двойной записи. Иначе бы вы это не написали:
    В нашей программе может быть любое число книг и учетов в одной базе, но мы никогда не утверждаем категорично что все надо в одной базе держать. Надо уметь работать и с разными базами.
    Тогда добавлю чуток из программирования, что, несомненно, вам ближе.
    Метод транзакций в принципе можно реализовать и в dbf базах. Надо просто грамотно прописать все связи и правильную их реакцию на любые действия пользователя. Казалось бы, всего-то! Но не думаю, что вы возьметесь за сей труд. Вы лучше будете используете MS sql, FB и т.д. чтобы ваши данные полноценно обрабатывались с использованием транзакций.
    То же самое и в учете. Без метода двойной записи полноценный учет не построить. Как бы вы ни описывали. А двойную запись, априори, невозможно описать в разных базах. Точнее описать-то опишите, но работать не будет. Причина та же, что и с транзакцией в dbf -файлах
  • 30.09.2008, 11:14
    PiterBest
    Да простят нам возрождение темы )
    Я по крайней мере ее точно не пиарю......

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

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


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

    Если база будет разбита, то приходится привлекать некоторые дополнительные программы, перекачивать, сводить, проверять и только после этого как-то реагировать на ситуацию.
    А вот это уже зависит от способов организации конкретной программы. В нашей системе,например, разработчик дает инструмент для того, чтобы не надо было дополнительных программ и т.д. и т.п. и минимизирует потребность в программистах для этого и кстати организует поддержку решений, так что программист может увольняться
    Так что не умение работать с разными базами это проблемы конкретного решения. И подгонять жизнь под это неумение не надо.
  • 28.09.2008, 10:03
    ВикторП
    Цитата Сообщение от PiterBest Посмотреть сообщение
    Виктор я понимаю о чем Вы, но мы в России живем. Вы предлагаете увязывать то, что в этом собственно не нуждается.
    Вот Вам примеры:
    - в управленческом учете есть документы, которых нет в бухгалтерском
    Нет в принципе как класса
    - в бухгалтерском учете есть документы, которых нет в управленческом тоже как класса
    Тут вопрос не в форме, а в содержании. Согласен, в управленческом учете может существовать какая-то информация, которая не будет востребована в бухучете. Но наиболее достоверная информация на предприятии все же находится в бухгалтерии. А управленческий учет очень сильно опирается именно на бухгалтерский учет. Их трудно разделить. Так вот и надо постараться обеспечить достоверность, легкость ведения бухучета. Комплексно подойти к информации, а не делить ее. Увязать потребности и возможности управленческого учета с бухгалтерским. Не дублировать информацию. Предприятие от этого только выиграет.
    Зачем Вы их да еще в одну книгу увязывать собираетесь ?
    Заметь, я никогда не говорю "держать эту информацию в одной книге". Информация должна быть в одной БАЗЕ! Записи разные, в разных журналах аналитики, но они могут быть всегда увязаны с другими журналами или/и между собой. В том-то и суть.
    Например, я могу в системе вести учет предприятия состоящего из 50 на УСН, но при этом учет бухгалтерский каждого отдельно взятого из этих зачем он мне там нужен ? Пусть ведут его отдельно и это будет логично и правильно. Просто часто слышен подход что надо консолидировать, а почему бы не сделать задачу обратную ? И это гораздо проще.
    Согласен, для программиста да, это сделать легче. Но система-то строится не для него. А вот пользователю, хозяину предприятия как раз, чаще всего, и нужна возможность оперативно видеть в том числе и консолидированный учет всех его 50 предприятий! Иначе трудно оценить всю деятельность консорциума, выбрать правильную стратегию дальнейшего развития, оптимизировать затраты, перераспределять ресурсы и т.д. Если база будет разбита, то приходится привлекать некоторые дополнительные программы, перекачивать, сводить, проверять и только после этого как-то реагировать на ситуацию. А это потерянное время. А в случае появления ошибок при перекачке, а от этого ни кто не застрахован, последствия могут быть тяжкими. Ну выгоню я программиста, а кто мне вернет убытки?
    А в единой базе это можно решить в принципе -один раз и на долго.
  • 29.07.2008, 20:10
    Dracosha Andrew
    ВикторП, у вас культ личности, он этим тоже не занимался предлагаю не разводить бесполезную дискуссию.
  • 29.07.2008, 20:04
    ВикторП
    Цитата Сообщение от Dracosha Andrew Посмотреть сообщение
    ВикторП, Билл Гейц не занимался разработкой концепций учёта. Его Вы зря упомянули...
    Да, он то же мне вчера звонил об этом
    Я писал о другом, о возможностях ХХI века, а их как раз и обеспечил Билл.
    После отпуска продолжим.
  • 20.07.2008, 20:19
    Dracosha Andrew
    ВикторП, Билл Гейц не занимался разработкой концепций учёта. Его Вы зря упомянули...
  • 18.07.2008, 18:31
    PiterBest
    Цитата Сообщение от ВикторП Посмотреть сообщение
    Вот-вот и это надо учитывать. Но все же база должна быть одна! Просто в ней для оперативного, управленческого учетов могут использоваться дополнительные журналы аналитики, но они обязательно должны быть жестко увязаны с основным журналом бухгалтерского операций(ЖБО).
    Виктор я понимаю о чем Вы, но мы в России живем. Вы предлагаете увязывать то, что в этом собственно не нуждается.
    Вот Вам примеры:
    - в управленческом учете есть документы, которых нет в бухгалтерском
    Нет в принципе как класса
    - в бухгалтерском учете есть документы, которых нет в управленческом тоже как класса
    Зачем Вы их да еще в одну книгу увязывать собираетесь ?
    Тут нужно понимать потребность в целостности каждого отдельного контура.
    Например, я могу в системе вести учет предприятия состоящего из 50 на УСН, но при этом учет бухгалтерский каждого отдельно взятого из этих зачем он мне там нужен ? Пусть ведут его отдельно и это будет логично и правильно. Просто часто слышен подход что надо консолидировать, а почему бы не сделать задачу обратную ? И это гораздо проще.
    Я пишу о технологиях, которые на практике живут и более того им мои клиенты продолжают придерживаться, а другим которые все в кучу собирали, после того как применили появился порядок и учет
    Так что речь не о мое конфликте с клиентами а о конфликте различных структур пользователя между собой после того как их в кучу собирают и наши Российские особенности на это дело накладывают. Они устают от схемы Лебедь, рак и щука. И кто сказал что управленческому учету нужен бухгалтерский ? Не факт.
    Мнение мое такое: нельзя придерживаться кранойстей ни при разделении ни при объединении. Надо уметь грамотно комбинировать оба метода и действовать в каждой конкретной ситуации.
    Объединение всех видов балансов в одну книгу это крайность, собственно как и утверждение что их обязательно надо разделять.
  • 18.07.2008, 13:21
    ВикторП
    Цитата Сообщение от PiterBest Посмотреть сообщение
    Только в качестве дополнения Вашей мысли необходимо пояснять, что под учетом не учет всего предприятия в целом, а отдельно взятая его развновидность баланса (чтобы не путать со словом учет рискнул применить это слово), например бухгалтерский учет этого предприятия.
    Вот-вот и это надо учитывать. Но все же база должна быть одна! Просто в ней для оперативного, управленческого учетов могут использоваться дополнительные журналы аналитики, но они обязательно должны быть жестко увязаны с основным журналом бухгалтерского операций(ЖБО). Если это будут разные базы, т.е. не связанные тесным образом, не интегрированные, то опять гарантированно разбежится управленческий и бухгалтерский учет, а значит и весь учет предприятия. При этом необходимо наличие специфической ответственности по ведению этих журналов, ограничения прав доступа при определенных условиях, например, закрытие отчетного периода. Чтобы, закрыв отчетный период в ЖБО, не было возможности править связанные журналы, например, оптовой торговли в части влияющей на переданные данные в ЖБО. Тут, как писал уважаемый tomvlad, и «нужны мозги программиста».
    Но я бы хотел закончить мысль о структуре баз данных. Если учетная информация хранится в разных базах, то получить достоверного учета на предприятии в принципе очень трудно, а с учетом человеческого фактора, не возможно. Это априори. Допустимо наличие различных вспомогательных журналов аналитики для управленческого учета, но они обязательно должны быть жестко интегрированы в единую базу. Всяческие отклонения от этого принципа гарантированно приведут к недостоверным результатам учета. Таково тут переплетение требований ХV века и возможностей XXI века, Луки Пачолли и Билла Гейтца.
    Таков, по моему мнению, должен быть фундамент оценки при сравнении разных программ бухгалтерского учета. А уж потом надо рассматривать маркетинг, франчайзинг и прочую современную обвязку.
    А вот теперь можно попытаться оценить состояние рынка бухгалтерских программ с такой точки зрения.
    Посмотрите взвешенно, вдумчиво, оцените то с чем вы работаете. Возможно это поможет вам избежать конфликтов со «строптивыми» клиентами, когда будете сдавать несколько не то, что хотел видеть заказчик на этапе ТЗ. Возможно ваша программа изначально не способна выполнить все требования вашего клиента. И тогда ни какие самые умные программисты- прикладники тут уже не помогут.
    Успехов всем!
  • 17.07.2008, 15:17
    PiterBest
    Цитата Сообщение от ВикторП Посмотреть сообщение
    1. Для заказчика. Если хочешь построить надежную, достоверную систему учета на предприятии НЕЛЬЗЯ брать программу в которой заложен учет в раздельных базах по кускам, по модулям, по подсистемам и т.д. Чтобы там не говорили программисты, при этом они, даже самые умные(!!) не смогут обеспечить достоверность. Это доказывает и математика(теория графов).
    Только в качестве дополнения Вашей мысли необходимо пояснять, что под учетом не учет всего предприятия в целом, а отдельно взятая его развновидность баланса (чтобы не путать со словом учет рискнул применить это слово), например бухгалтерский учет этого предприятия.

    Потому как, например в оптовой торговле объединение оперативного и бухгалтерского учета ведет к неминуемому конфликту:
    - бухгалтеру надо накладную провести июнем, а менеджеру июлем и это уже разные записи в разных балансах (если можно так сказать)
    Т.е. о графах и достоверности следует говорить относительного одного конкретного вида баланса и массива записей операций к нему.
  • 17.07.2008, 11:12
    ВикторП
    Возвращаясь к структуре базы данных. Только наличие двойной записи позволяет построить достоверный учет на предприятии. Т.е. когда запись имеет вид "куда-откуда- сумма". Все прочие методы не гарантированы от ошибок учета. Точнее наоборот- ошибки гарантированы! Это с точки зрения учета.
    А с точки зрения программистов(программ учета) базы дробятся не от хорошей жизни. То ресурсов вычислительных комплексов не хватает, то мозгов- как этого "долбанного Луку" обойти. А бывает и просто пишут только то, что требуется на данный момент данному заказчику.
    Что же получается в остатке?
    1. Для заказчика. Если хочешь построить надежную, достоверную систему учета на предприятии НЕЛЬЗЯ брать программу в которой заложен учет в раздельных базах по кускам, по модулям, по подсистемам и т.д. Чтобы там не говорили программисты, при этом они, даже самые умные(!!) не смогут обеспечить достоверность. Это доказывает и математика(теория графов).
    2. Для программистов.
  • 16.07.2008, 21:14
    Dracosha Andrew
    Цитата Сообщение от PiterBest Посмотреть сообщение
    Так что был неправ - запись имеет две стороны, значит таки двойная
  • 16.07.2008, 17:28
    PiterBest
    Цитата Сообщение от ВикторП Посмотреть сообщение

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

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

    Цитата Сообщение от Dracosha Andrew Посмотреть сообщение
    Пусть план счетов не будет соответствовать ПБУ, скорее всего он будет много проще.
    А что-то мне подсказывает, что в ПБУ и НК нет упоминания о плане счетов.

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

    Цитата Сообщение от PiterBest Посмотреть сообщение
    Я не оспариваю эту точку зрения. Просто сам для себя хочу понять.
    Возможно принцип стакана это тоже самое. Но после нашего дебета-кредита вызывает полное отторжение при первичных попытках работы.
    Извините, но что вы подразумеваете под "стаканом"? Может то, что в "ихних" программах практически нельзя править ранее сделанные операции?
  • 16.07.2008, 13:12
    PiterBest
    Цитата Сообщение от Dracosha Andrew Посмотреть сообщение
    А я согласен с ВикторП
    Двойная запись должна присутствовать всегда. Деньги не должны возникать из воздуха и уходить в никуда. Пусть план счетов не будет соответствовать ПБУ, скорее всего он будет много проще. Но двойная запись должна быть!!
    Я не оспариваю эту точку зрения. Просто сам для себя хочу понять.
    Возможно принцип стакана это тоже самое. Но после нашего дебета-кредита вызывает полное отторжение при первичных попытках работы.

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

    Более того, скорее всего, что план счетов для оперативного учёта
    Могу понять все что угодно, но либо мы расходимся в представлениях оперативного учета, либо кто-то ошибается. В моем представлении план счетов в оперативном учете никому мягко говоря не нужен. Он на то и оперативный...... Возможно это опять таки особенности подхода в ПО к автоматизации.
  • 15.07.2008, 21:12
    Dracosha Andrew
    А я согласен с ВикторП двойная запись должна присутствовать всегда. Деньги не должны возникать из воздуха и уходить в никуда. Пусть план счетов не будет соответствовать ПБУ, скорее всего он будет много проще. Но двойная запись должна быть!!

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

    Более того, скорее всего, что план счетов для оперативного учёта не будет совпадать с бухгалтерскими. И, более того, даже у разных юридических лиц в пределах одного холдинга может быть разный план счетов в бухгалтерии!! А консолидированная отчётность должна тем не менее не только составляться, но и быть прозрачной в рамках всего холдинга.
  • 15.07.2008, 20:53
    PiterBest
    Цитата Сообщение от ВикторП Посмотреть сообщение
    Учет должен быть непрерывным, сплошным, описываться методом двойной записи.
    Вот тут я возможно ошибаюсь но у буржуев учет идет по принципу стакана и нет понятий дебета-кредита Это все-равно метод двойной записи ?

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

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

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

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

    Теперь предметно. В современных типовых НЕ МЕНЯЯ кода можно настроить On-Line обмен практически с любой периодичностью. Данные практически мгновенно могут попадать в бухгалтерскую программу. И нефиг приплетать Пачоли, и достоверность и полнота и непрерывность есть. Не умеете готовить - берите монстра.
  • 14.07.2008, 15:30
    ВикторП
    Цитата Сообщение от tomvlad Посмотреть сообщение
    Согласен, построить будет трудно.
    Главное знать как строить.
    Кстати, достоверный учет и на базе одной программы построить сложно
    Извиняюсь, но я не говорю про РАЗНЫЕ(!) программы, я говорю о разных базах. Разных, разрозненных массивах информации. Уж пусть лучше будут обслуживать ее разные программы, но база должна быть одна! Тогда еще можно с вами согласиться и про сложность, и про знания как строить. Но, скорее всего, вы согласитесь со мной, что тогда будет лучше все И описать в одной программе. Но это уже детали.
    Но с тем, что построить нельзя в принципе, категорически несогласен.
    Тут вы спорите не со мной, а с Лукой Пачолли. А его выводы подтверждаются 500 летней историей учета Извините, но я не доживу до торжества ваших выводов.
  • 14.07.2008, 12:50
    tomvlad
    Согласен, построить будет трудно. Главное знать как строить. Кстати, достоверный учет и на базе одной программы построить сложно, если бухи проводя что-то задним числом, не восстанавливают последовательности или, как в БП, не перепроводят более поздние документы. Тут уже чисто административные меры помогут. Но с тем, что построить нельзя в принципе, категорически несогласен.
  • 14.07.2008, 12:00
    ВикторП
    Цитата Сообщение от tomvlad Посмотреть сообщение
    Ну ВикторП, знаю я одну контору, которая в Excell рассчитывает зарплату и уже потом результаты переносит в зарплатную программу.
    А вот мне не везет! Куда не прийду, всюду одно и то же - если стоит 1с, то все встают на дыбы, если начинаю удалять xls! Покупать-то лицензии не хотят, а руководство просит очистить от всего не лицензионного.
    Правда городок у нас маленький, тыщ на 300
  • 14.07.2008, 11:54
    ВикторП
    Дело не в xls. Это сопутствующее.
    Если дробить учет на любом предприятии по отдельным базам, то в принципе не возможно построить полный, достоверный, непрерывный учет! Это априори.
    Пока вижу, что только в 1с8 что-то сдвигается в нужном направлении. А до этого все 1с....
  • 14.07.2008, 11:40
    tomvlad
    Ну ВикторП, знаю я одну контору, которая в Excell рассчитывает зарплату и уже потом результаты переносит в зарплатную программу. Неважно, что через ж..., главное расчетчик так привык. Пока справляется, начальство устраивает. И неважно какая у него программа, 1С не 1С. За 15 лет все довольно сильно изменилось. Большинство предприятий, кстати, умудряются не дробить учет на подсистемы (кроме пожалуй зарплаты, ну так специфика). Для торговых контор, да - сложнее, но уже почти год одинэсы пытаются сделать обмен с человеческим лицом, что в принципе уже работает (плюсов и минусов довольно много и перечислять их я не буду). Кстати, при грамотной настройке обмена (адаптации правил конвертации) неразрешимых проблем нет. Сейчас как раз занимаемся тем, что строим корпоративную информационную систему из нескольких распределенных баз. Несколько сегментов уже ввели в эксплуатацию, к зиме закончим остальное. Так что Ваши утверждения насчет Excell'я голословны.
  • 14.07.2008, 11:05
    ВикторП
    tomvlad, уж так получилось, что и я не работаю с 1с Уже давно, лет 15.
    Основная причина - ну очень в ней трудно организовать учет среднего предприятия(сотрудников на 100-1000) в ЕДИНОЙ(!) базе. Причин много и, надеюсь, вы их хорошо знаете. Обязательно надо дробить бухучет на подсистемы. А при последующем объединении выплывает куча, в общем-то не разрешимых проблем. Вот поэтому и ходит шутка, что 1с может работать ТОЛЬКО в паре с xls. :
В этой теме более 30 ответов(а). Нажмите здесь, чтобы перезагрузить эту тему.

Ваши права

  • Вы можете создавать новые темы
  • Вы можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •