Дилемма бухгалтера: Как отказаться от 1С? (2 часть)

[mazzy]

ух ты, сколько сообщений!
Привет, всем.

2 dmit2604

Цитата:

Я смогу поставить международную версию с русским интерфейсом и удачненько видеть свое финансовой состояние? (при учете, что имеется "шлюз" для налогового махлевания в 1С). Тогда давайте все вместе "бумажки" человеческие сделаем! Счета там, платежки и прочее!

Да. Можно видеть свое финансовое состояние на межуднародной версии с русским интерфейсом.
Нет. Вместе делать бумажки не стоит. Это и будут "Свои" локализации. Прежде чем этим заниматься нужно 100 раз подумать. Пока ситуация не настолько безнадежна, по-моему


2 Falcon

Цитата:

Принудить считать используемую систему (будь то Аксапта или что-то иное) - верхом совершенства...

Действительно экстремизм.
Хотя в каждой шутке есть доля шутки.

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

2 ef

Цитата:

хотелось бы высказать моё...

Согласен. Мне тоже кажется, что это правильный путь.
Вот только это еще должно быть единым, стандартным и поддерживаться поставщиком.
Тогда будет совсем идеально.

2 Stiw

Цитата:

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

А это вообще идеальный случай. По роду деятельности, общаюсь со специалистом по международному учету - с Игорем Аверчевым. Он с этого варианта НАЧИНАЕТ рассматривать подходы к автоматизации цветного учета. Этот вариант дает самый точный результат. В этом я с ним согласен.

У этого варианта есть два недостатка:
1. он очень дорог (два комплекта бухгалтеров... им же зарплату платить надо)
2. на практике такая точность в общем то и не нужна.

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

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

[Stiw]

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

[SA]

критика Павла в-общем уместна. Только полемика сверху меня утомила своим размером.

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

Я вижу простейший выход в наличии отдельных бух. баз рядом с основной системой, в которой крутятся все ресурсы, планирование и финансы. XML поможет организовывать и настраивать выгрузку (преобразовывать значения) не влезая в программу. Это ОЧЕНЬ важно - не меняя бух. программу, иначе потеряется возможность постоянных обновлений.

С другой стороны мне нравится идея с модулем ЛПБ. Очень приятно и технически корректно. НО!
1.Требутся возможность размножения и закрытия юр.лиц
2. требуются идеи по обеспечению безопасности. Правда ведь глупо иметь в программе пометки "для налоговой", "для себя", "сокрытая прибыль" и т.д.

[Stiw]

Думаю что главный вывод данной ветки состоит в том что:
1. Любимая программа бухгалтера была есть и будет и Аксапта её не устранит
(по крайтей мере еще долго).
2. Методологии "зачернения", "отбеливания" и "зеленения разницы" бывают разными,
но единой быть не может иначе она станет всем известна и "зеленить " будет нечего.
Поэтому и не будет единого решения.
3.На рынок выходит SAP http://www.cnews.ru/topnews/2002/05/22/content6.shtml если повар нам не врёт , так что времени у Navision для раздумий какой сегмент рынка занять остаётся весьма немного. Думаю что нужно теснить 1С.
4. А написать ЛПБ на Аксапте можно и нужно, но средствами Navision (другой вопрос как им это довести и какова будет цена решения).
5. Наш мир не стабилен и Аксапта может недожить до совершеннолетия.
6. Хитрый Microsoft может купить 1С с потрохами и объединив с Navision единолично править на Российском софтверном рынке.

Остаётся только подождать...

[SA]

Не согласен с п.2 Мой опыт следующий:
Большинство предприятий и финансистов считают что придумали свой метод и часто всерьез предлагают его продавать в качестве методики или ноу-хау. однако всем некогда почитать, например, Голубкова "Оффшорные методы в российском бизнесе" или еще кое-что по-хлесче.
Универсальная техническая идея в том, что для каждой новой валюты и пакета отчетности ( управленческий + по одному на юрлицо) необходимо заводить свой план счетов со своими оборотами.

С остальными пунктами согласен на 100%. Думаю M$ попытается купить 1С. Вполне по майрософтовски будет подкладывать комплект 1С с подпиской на обновления во все инсталляции Навижен. Дешево и сердито. Надо только лейблы переписать. И наша дисскуссия исчерпается.

[mazzy]

В целом, согласен с выводами Stiw и утверждениями SA.

Небольшая добавка.

Цитата:

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

В общем случае так делать нелья.
Еще раз повторюсь, далеко НЕ ВСЯ информация попадает в бухгалтерию. Вполне возможна ситуация, когда разные операторы ДОЛЖНЫ видеть только часть документа. Вполне возможна ситуация, когда операторы и не должны подозревать о существовании альтернативных данных.

Например, авансовый по командировке. Гостиница реально стоила, например, 1000 баксов. Управленческий менедежер знает только это. За эти знания с него и спрос. Белый бухгалтер знает то, что гостиница стоила 500 рублей, из них 400 сверхнормативные.

И т.п.

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

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

[dmit2604]

Предлагаю открыть новую тему по двум причинам:
1) сообщений накопилось столько, что приходится ждать по 15 минут на моем Инете, чтоб прочесть свежее.
2) дискуссия приобрела несколько более определенное русло (на мой взгляд) и поэтому требует продолжения в новом топике.

Исходя из этого прошу:
Администратора: перенести сюда все сообщения начиная с сообщения Mazzy от 22-05-2002 23:25, начинающееся со слов "Ух ты, сколько сообщений...".
Всех остальных: Постить свежие сообщения сюда...
Всем спасибо! Надеюсь на взаимопонимание и поддержку!

Продолжаем!
PS: к Админу. А нельзя как-то в персональных настройках поменять порядок сообщений, чтоб свежие - вверху?

[Nikolson]

Дмитрий!
Я сделал то, о чем вы просили.
Насчёт новых сообщений вверху - посмотрим.

P.S. Давайте относится к друг другу с уважением.

[Stiw]

Думаю что подход разделения управленческого и бухгалтерского учета во многом зависит от рода деятельности организации, при появлении на компании производства многие из предыдущих ("торговых") подходов перестают работать.
С точки зрения авансового отчета на 1000 $ который не отражается в бухучете могу сказать что и сумма которая была на него выдана тоже там не отразилась, и поэтому ни то не другое в бухучет не попадет. А вот "белые" суммы и отчеты проведенные в бухучете должны попасть в упручет в пересчете к его валюте. Вопрос когда? Или в реальном времени или по концу месяца трансляцией.В реальном времени интереснее.Ну наверное мы несколько отклонились от темы

[komar]

Есть такой принцип бухучета, который гласит, что затраты на этот самый учет должны окупаться. То есть нужно не гоняться за идеальной точностью (которой все равно НЕТ НИ В ОДНОЙ МЕТОДИКЕ УЧЕТА), а принять решение оптимальное по соотношению затрат и результатов. В нашем случае это - периодическая трансляция.
Что касается реализации механизма в AXAPTA - то он вполне реализуем. Ну будут некоторые доделки, но ведь системы Navision тем и сильны, что их можно переделывать.
И не нужно бояться "своей" локализации - вся локализация того же Attain ,была в свое время "своей", а теперь стала "общей", да и 1С переписывают все кому не лень.
AXAPTA - это не SAP , чтобы растопытив пальцы кричать, что в нее заложены идеальные процессы - нет нигде идеальных процессов. И если партнеры будут сотрудничать с Navision в создании локализации, или создавать свои модули, то все от этого только выиграют.
Ведь тот же Attain в российском исполнении работает!!! А чем отличается его бухгалтерская функциональность в международной версии от Axapta? Да ничем не отличается!

[dmit2604]

Цитата:

Изначально опубликовано komar
И не нужно бояться "своей" локализации

Бояться вроде нечего, но это не выход. Я уже говорил, что во-первых будет "сколько людей, столько и мнений", во вторых все сразу же упрется в поддержку этих доработок. Собственно, зачем тогда нам "Navision CIS", если они не состоянии это сделать? Почему это этим должны заниматься партнеры? Другое дело, когда представительство отказывается поддерживать/локализовывать версию (как понимаю это случилось с XAL). Тогда, конечно без энтузиастов не обойтись!

Кстати, партнеры! Вопрос о стратегии локализации ТРЕТЬЕЙ версии поднимался уже в присутствии Navision? Или они такую же линию будут гнуть и дальше? Может, если у кого вызрели хорошие идеи, стоило бы вместе это обсудить? Так вот побубним тут "кажный о своем" и "воз и ныне там" останется. И будем ждать глюкавую третью версию
Тем, кто в первый раз читает: Прошу прощения, я сознательно утрирую!
К Stiw:

Цитата:

Изначально опубликовано Stiw
А вот "белые" суммы и отчеты проведенные в бухучете должны попасть в упручет в пересчете к его валюте. Вопрос когда? Или в реальном времени или по концу месяца трансляцией.В реальном времени интереснее.Ну наверное мы несколько отклонились от темы

Ты хотел сказать, что суммы налогов должны попасть в "управленческую базу" оперативненько? Это - да. Или я тебя не понял?
А от темы мы не отклонились, а как раз и обсуждаем как обустроить двойной учет в Аксапта.

[komar]

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

[Stiw]

Цитата:

Изначально опубликовано dmit2604
Ты хотел сказать, что суммы налогов должны попасть в "управленческую базу" оперативненько?
[/B]

Желательно и не только налоги

[dmit2604]

Попробую обобщить дискуссию. Предпосылки идей появились, когда Mazzy сказал: "большинство операций должно учитываться и там, и там автоматически. Однако, существуют операции, которые НЕЛЬЗЯ конвертировать автоматически. Такие операции лучше вводить вручную" (Обойдусь без цитат, слишом много места занимают)

Потом выделились 2 основных точки зрения:

Одну из них начал SA, сказав "Теперь идеи. Кормим Аксапту реальными данными - по покупкам, настоящей стоимостью ОС и т.д. Рядом ставим 1С на ОДНО рабочее место и сажаем туда ГлавБуха. Теперь надо
1. настроить выгрузку движений ТМЦ из Аксапта в 1С раз месяц
2. настроить перенос начисленных налогов и отчислений из 1С в Аксапта
3. решить проблему с дублированием ввода банковских и кассовых операций и печати нормальных форм платежек, ордеров,накладных,фактур.
Естественно, баз 1С имеем по количеству юридических лиц. и получаем обновления программы от фирмы 1С ДВА РАЗА в МЕСЯЦ. И голова не болит.....
"Управленческая" и "бухгалтерская" базы пересекаются на банковских, кассовых , налоговых операциях и счетах фактурах. Проблема в желании иметь оперативную информацию по денежным средствам и отгрузкам в "управленческой" базе.

Mazzy предложил альтернативу: "Структура бухгалтерской базы данных в 1С простейшая. Это должен быть отдельный модуль. В нем можно творить что душе бухгалтера угодно: вводить задним числом, удалять, вставлять. В него должны копироваться проводки из стандартного финансового блока. Таким образом, не будет проблем с сылками и связями. а SA добавил: "1.Требутся возможность размножения и закрытия юр.лиц 2.Требуются идеи по обеспечению безопасности."

Промелькнула также несколько идеализированная идея Stiw'a:"Думаю что решить разногласия можно только одновременной двойной разноской документов по разным планам счетов (например GAAP и Российский), естественно на один в валюте управленческого учета, а на другой в валюте бухгалтерского учета."на что Mazzy тут же возразил: "далеко НЕ ВСЯ информация попадает в бухгалтерию. Вполне возможна ситуация, когда операторы и не должны подозревать о существовании альтернативных данных"

Все сошлись во мнении, что лучше НЕ делать локализацию самостоятельно.

Уф! Вроде все! Теперь дальше.
Выделилось направление дискуссии по идее "1С-рядом" о том, как и какие данные передавать туда и обратно. Причем оперативно или периодически.

А также по-моему наметилось обсуждение организации отдельного модуля (по идее "1С-внутри") в разрезе безопасности и размножения юр.лиц.

Других перспективных направлений дискусии я вроде не заметил. Что не так - поправляйте! Я подредактирую. Всем спасибо за внимание. Предлагаю продолжать!

ЗЫ: Может это никому и не надо было, по крайней мере я разобрался

[komar]

А может не стоит вообще строить систему "черного" учета?
Ведь покупающие импортную систему - это в основном ориентированные на запад крупные компании. То есть система будет использоваться не для того, чтобы дурить налоговую, а для реального учета.
Но в принципе, никто ведь не мешает держать в той же аксапте компанию с другим планом счетов, другой разноской, создать интерфейс выборочного копирования данных, и вперед. Таким образом, имеем разные варианты данных в одной системе.
Что касается преимуществ аксапты перед одним эсом, пожалуйста:
1.параметризация, то есть отсутствие необходимости переписывать систему каждый год, когда меняется план счетов
2. возможность отследить, откуда у операции ноги растут, что в 1С весьма проблематично
3.соответствие данных различных модулей, то есть таки интегрированность
4. и кто сказал что в аксапте нельзя удалять проводки???

[mazzy]

Кхм... Мдя... Вот оно как...

Оффтопик, извиние

2 Nikolson:
Спасибо, что создали и поддерживаете такое замечательное место. Этот форум был первым ОТКРЫТЫМ. После того, как появились вы остальные тоже стали открывать свою информацию. Этот форум предоставляет богатую информацию всем заинтересованным посетителям. Это замечательно.

Однако, информация это не только текст и картинки. Это еще и контекст, в котором находятся топики. Если топики переносить, то контекст необратимо изменяется.

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

Кроме того, в открытых дисскусиях часто возникают споры. Это нормально. Наверняка, будут желающие стереть или перенести что-то. Наверное, вряд ли стоит делать это регулярно. Мнений много. Уверен, что жизнь со времене расставит все по местам. (конечно, бывают случаи патологического хулиганства, но здесь явно не тот случай)

Хочется поблагодарить за ваше терпение и за действительно хороший форум. А если будет свой фильтр для каждого участника - будет вообще замечательно.

2 dmit2604:
Полностью согласен, что та ветка очень объемна. Дома я тоже сижу на диалапе и отлично тебя понимаю. Но. Может не стоит удалять что либо? Зачем лишать себя выбора? Наверное, можно было бы просто создать новый топик, процитировать нужные места, сделать ссылку в старом на новый. Если народу это будет интересно, то, убежден, обсуждение перейдет в новый топик.

Т.е. давайте будем создавать, а не удалять.

Теперь к делу
2 dmit2604:
согласен с выводами.

Что хотелось бы сказать. Сама поставнока вопроса неверна. Зачем отказываться от чего либо? Отказ означает уменьшение свободы выбора, а следовательно может привести к менее эффективному решению. Вряд ли стоит огульно отказываться от рассмотрения любого варианта (не стоит отказываться даже от варианта "своей" локализации). Надо понимать плюсы и минусы любого решения.

Использование ЛПБ приводит к меньшим затратам на бухучет. Но увеличивает затраты на сопряжение данных (целостность)

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

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

Нужно принять управленческое решение: достичь заданного результата в заданные сроки, используя заданные (реальные, а не идеальные) ресурсы.

[mazzy]

Цитата:

Изначально опубликовано komar
А может не стоит вообще строить систему "черного" учета?

К сожалению, вопрос стоит не так.

Всем нужен реальный учет - без него невозможно жить.
А фискальный учет все вести обязаны.

Поэтому и приходится мучаьтся с двумя учетами.

[Pavel]

Цитата:

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

Согласен. Приводил ранее пример простого с технической точки зрения варианта

Цитата:

Изначально опубликовано Pavel
копирование рабочей БД со всей информацией и работа с ней в режиме редактирования/оптимизации.
...понятна ответственность и реализована необходимая свобода действий.

Рабочая база системы с полной и актуальной информацией сохраняется. На ее основании делается "оптимизация".

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

С уважением

[dmit2604]

К Mazzy: Простите за огульные переносы. И Nikolson'a подставил. Больше не буду. Сознаю свою ошибку. Простите. "Давайте будем создавать, а не удалять!"

Теперь по делу:

Цитата:

Первоначально опубликовано Mazzy
Вряд ли стоит огульно отказываться от рассмотрения любого варианта (не стоит отказываться даже от варианта "своей" локализации).

Полностью согласен. Но прошу также учесть:
1.Вариант "ЛПБ" - затраты на этапе разработки средства согласования приложений. Один раз для каждого из приложений (1С, Галактика, БЭСТ и т.д.)
2. Вариант "Использовавание только стандартной Аксапты" - снижение эффективности и борьба с локализацией "всю жизнь!" .
3. Вариант "Использование отдельного модуля" - затраты на программирование. Один раз на версию (или даже раз на каждое изменеие законодательства).

Философия про идеальные ресурсы (Mazzy прости!) хороша, но тут, на мой взгляд, чистая математика. На глаз можно оценить расходы... Умножьте на частоту - получите сумму. (Кто-то умный вставит 5 копеек про дисконтирование

Задача простая. Получить нормальное решение. Причем такое, которое, придя к заказчику не стыдно будет предложить. Лучше, если несколько вариантов решений.
Что я имею сейчас? Международную версию где ни слова по русски(я про отчеты), "Русскую" версию, с которой не знаю, что делать, и которая, кстати тоже ничего не дает нашему бухгалтеру. Имею 1С, которая уже стоит у Заказчика, в которой он работает, но я понятия не имею как к ней подступиться... ОК! Заказчик говорит: "как мы все это обустроим?"ЧТО Я ОТВЕЧУ?
Вариант 3 сразу отпадает. У меня нет времени на пол-года разработку модуля. Вариант 2 не устраивает их бухгалтера. Смысла в такой автоматизации они тоже не видят. Вариант 1 - тоже сопряжен с затратами, но пока для меня это - единственное решение!

Народ! Я тут не в прятки играю и не оттгого пишу, что мне нечем заняться! Я пытаюсь выяснить пойдет ли (заставят ли) Navision пойти по пути 1. Если этого не случится, то начнется "частная локализация" и тогда мне интересно, поддержит ли меня кто-то на пути 3. Если и тут "не судьба", то обсуждение заканчивается, потому что начинается ожесточенный труд.

[Nikolson]

Цитата:

Изначально опубликовано mazzy
Кхм... Мдя... Вот оно как...

Оффтопик, извиние

2 Nikolson:
Спасибо, что создали и поддерживаете такое замечательное место. Этот форум был первым ОТКРЫТЫМ. После того, как появились вы остальные тоже стали открывать свою информацию. Этот форум предоставляет богатую информацию всем заинтересованным посетителям. Это замечательно.

Однако, информация это не только текст и картинки. Это еще и контекст, в котором находятся топики. Если топики переносить, то контекст необратимо изменяется.

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

Кроме того, в открытых дисскусиях часто возникают споры. Это нормально. Наверняка, будут желающие стереть или перенести что-то. Наверное, вряд ли стоит делать это регулярно. Мнений много. Уверен, что жизнь со времене расставит все по местам. (конечно, бывают случаи патологического хулиганства, но здесь явно не тот случай)

Хочется поблагодарить за ваше терпение и за действительно хороший форум. А если будет свой фильтр для каждого участника - будет вообще замечательно.

Сергей, я правильно вас понял, что Вам бы хотелось уидеть на нашем форуме некое подобие игнор листа + возможность сортировки сообщений?