23.04.2010, 11:02 | #41 |
Участник
|
Цитата:
В личной практике сталкивался с проектом, где от нескольких франчей работало более 20 специалистов одновременно. |
|
23.04.2010, 13:45 | #42 |
Участник
|
Не спорю, есть такие проекты (более того - сам на таких проектах работал))) поэтому и не написал 100%
__________________
Бей желтых пока не посинеют, бей синих пока не пожелтееют |
|
23.04.2010, 15:35 | #43 |
Сам.AX
|
Цитата:
Вот и на сайте 1С пишут оправдание: Цитата:
В частности, запрет внесения изменений задним числом, часто используемый в западных системах учета, может быть реализован на уровне прикладного решения. Политика учета, принятая на конкретном предприятии, может быть самой разнообразной. Например, может существовать не просто запрет на внесение изменений "задним числом", а ограничения на внесение изменений в определенных периодах. Кроме этого, существуют задачи, связанные с изменениями в процессе внедрения и отладки системы.
__________________
Возьми свет! |
|
23.04.2010, 15:43 | #44 |
Участник
|
Да причем тут права. У 1С на уровне платформы есть такое понятие, как режим проведения, он может быть оперативным и неоперативным. Я не видел ни одного решения, в котором бы была конструкция, отказывающая в неоперативном проведении в принципе. Хотя уже давно пора. Но и это не такая уж проблема. В типовых решениях нет механизмов внятной и удобной корректировки учетных данных. А без таких механизмов запрет работы задним числом гроша выеденного не стоит.
|
|
23.04.2010, 15:55 | #45 |
Сам.AX
|
В типовых нет. Любому юзеру можно запретить неоперативное проведение документов на уровне правки ролей пользователей. В былые времена так и делали. И это работает по сей день. С другой стороны бухгалтеров крайне смущает, что в системе есть документ - не правильная реалиизация, затем возврат, и ещё одна реализация (правильная). У некоторых по этому поводу волосы дыбом встают, поэтому считают, что править уже проведенные документы - это вполне нормально.
__________________
Возьми свет! |
|
23.04.2010, 16:15 | #46 |
Участник
|
ИМХО "корректировка" и "противоположная по сути хозяйственная операция" - вещи разные.
|
|
23.04.2010, 16:32 | #47 |
Участник
|
Цитата:
И правами доступа она не решается. Reaper уже говорил о корректировках. Кроме обычных корректировок есть данные, которые рассчитываются системой. Например, себестоимость. Например, курсовые и суммовые разницы, Например, НДС с авансовых платежей и т.п. В 1С при перепроведении рассчитанные проводки просто стираются и пересоздаются заново. Никого в 1С не волнует что там происходит с задолженностями, прибылью, бонусами от прибыли и т.п. Просто опять идет подмена понятий в "оправдании на сайте 1С". В 1С запрещают пользователю менять данные. Но в 1С это вовсе не значит, что данные будут неизменными (прежде всего из-за механизма перепроведения) Вот такой вот парадокс. =============== И! Уважаемые 1Сники, уважаемый Reaper. Обратите внимание, что в Аксапте не запрещено работать задним числом! (В Аксапте можно и нужно создавать документы прошлой датой. И Аксапта замечательно с такими данными работает. И помнит историю.) Обратите внимание! В Аксапте запрещено менять проведенные документы и проводки. Если система(!) или пользователь хочет поменять данные, то проводки не заменяются на новые, а к ним дописывается коррекция. А вот 1С - отвратительно работает задним числом. Попробуйте отказаться в 1С от перепроведения расходных накладных, если менеджер добавил накладной расход прошлой датой При перепроведении 1С просто забывает что было раньше и пересоздает проводки и движения. Из-за чего (даже при хваленой системе прав) в многопользовательской среде работать проблематично. |
|
23.04.2010, 16:35 | #48 |
северный Будда
|
Цитата:
Сообщение от Alexx7
С другой стороны бухгалтеров крайне смущает, что в системе есть документ - не правильная реалиизация, затем возврат, и ещё одна реализация (правильная). У некоторых по этому поводу волосы дыбом встают, поэтому считают, что править уже проведенные документы - это вполне нормально.
Так как автору топика нужно было чисто бухгалтерское решение - победа 1С в общем-то была предопределена. Другое дело, что тем самым он автоматически поставил перед собой задачу стыковки 1С и управленческой системы учёта. Всё как всегда получилось |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
23.04.2010, 16:39 | #49 |
Участник
|
Цитата:
а то что реализация означает, что у клиента возникает задолженность, а матответственные люди выдали со склада что-то материальное - их не волнует. действительно какая разница. Ну выдали сначала со склада на N рублей какой-то фигни. Потом взяли и по-нашему, С точки зрения склада: реализация - выдали возврат - склад принял обратно (и может отчитаться при инвентаризации) реализация - снова выдали (может быть что-то другое) С точки зрения продавца: реализация - он получит один бонус или комиссионное вознаграждение возврат - сторно бонуса или комиссионного реализация - возможно совсем другой бонус, а может быть и совсем другому продавцу и так далее. ...Бухгалтеров крайне смущает... Ну-ну... А остальных крайне смущает возможность исправления любого проведенного документа. |
|
23.04.2010, 17:10 | #50 |
Участник
|
Отказались от перепроведения. В УПП механизм учета без перепроведения включается опционально. В остальных конфигурациях со следующих редакций, кроме бухгалтерии, ужаса под названием "партионный учет от 1С" пока не предвидится.
|
|
23.04.2010, 23:36 | #51 |
Участник
|
|
|
24.04.2010, 11:52 | #52 |
Участник
|
Цитата:
Действительно, ну нет у нас машины времени, если какой-то документ (например, передача со склада хранения в цех) был проведен вчерашним днем, то значит вчера эти материалы были (ну не обманывают же сразу два кладовщика одновременно). Поэтому нет причин, по которым нужно проверять, приведет ли операция к отрицательным остаткам на дату операции. А вот смотреть к чему приведет такая операция текущие данные нужно (а Акса предполагает, что именно текущие данные нужны для принятия решений). И для того, чтобы не останавливать реальный процесс производства, часто приходится отражать сначала операции расхода, а потом (после получения документов), операции прихода. Может быть сумбурно написал, но это то, что от меня требует руководство (к сожалению, за исключением главбухов). И тут начинаются проблемы, если в связке с Аксой работает 1С. Акса смотрит на текущий результат, а 1С на результат на момент проведения документа. И они при экспорте часто расходятся. Хотя есть положительный момент, что в той же 1С в V8 разделили оперативное и не оперативное проведение. Правда нам это не помогает, так как в 1С данные импортируются из Аксы и в момент импорта в 1С как раз получатся оперативное проведение. |
|
24.04.2010, 12:01 | #53 |
Участник
|
В дополнение. Нужен или нет этот контроль в Аксе не зашито в приложении, а оставлено в настройках.
То есть, в одних случаях нужно, чтобы расход был только после прихода, в других, возможны отклонения. В одних случаях, можно отражать расход только если было подтверждение кладовщиков о физическом приходе, в других, если были документы, в третьих, можно отражать расходы и без подтверждения приходов. Все эти нюансы задаются настройками в складских моделях. При этом для одних номенклатур можно выбрать одни правила, для других - другие. |
|
Теги |
1c, olap, бизнес-анализ, сравнение, сравнение систем |
|
Похожие темы | ||||
Тема | Ответов | |||
OLAP и 1С: У 1С прежде всего похожий по задачам инструмент - компоновщик. (C) Demiurg | 63 | |||
Платформа «1С:Предприятие» как средство разработки бизнес-приложений | 1 |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|