Как удалить или откорректировать разнесённый документ?

[Yuri Safronov]

Захожу в Главное меню \ Кассовые операции \ Приходные кассовые ордера

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

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

Что мне делать, как мне удалить или откорректировать разнесённый документ?

[mazzy]

Удалить/откорректировать уже разнесенный документ никак нельзя.
Можно создать новый сторно документ.

Почему?
Представь, что документы вводит не супер-Юрий, а простой оператор.
А теперь представь, что он может ввести, распечатать, получить деньги и без следов исправить документ в системе

[AHA-X34]

Логичнее, что бы документы могли вводить, как «супер-Юрий», так и «простой оператор» и каждый имел бы соответствующие права.
Обидно, что это не так.

[Yuri Safronov]

Согласен

[mazzy]

Права доступа есть.
А вот удалять нельзя.

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

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

[Yuri Safronov]

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

[AHA-X34]

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


Юра, вы чуток погорячились

[Yuri Safronov]

Согласен

[mazzy]

Цитата:

Изначально опубликовано AHA-X34
Их компетентность, мягко сказать, оставляет желать лучшего. В связи с этим появляется большое количество некорректных документов

Эта проблема решается не правкой, а механизмом одобрения.
Если у вас некомпетентный пользователь, то дайте ему возможность только вбивать информацию, и разносить только после одобрения. А квалифицированный пользователь пусть одобряет.

Если необходима дополнительная инфорация или дополнительный сервис для одобрения, то сделайте/дайте его.

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

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

Пожалуйста подумайте еще раз.

Подумайте также о том, что на западе бухгалтер - это далеко не суперпрофессионал, а обычный оператор. Как это ни обидно нашим бухгалтерам. То, что у нас делают главные бухгалтера там называется финансовый аналитик.

[mad_pilot]

вопрос не правильно понят.

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

советы "правильно надо было делать так...." не помогут.

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

[mad_pilot]

права и одобрения городить - не пройдет в условиях нашего бардака.
т-к начальство наше очень любит сваливать на теток совершенно
не свойственные им функции.

и одобрение приведет к тому что у тетки будут открыты 2 аксапты под разными login,

она вводит и она-же одобряет

сам видел много раз......

[mazzy]

ну тогда Аксапта вряд ли поможет
разруха она в головах, как правило.

[AHA-X34]

Уважаемый mazzy, я понимаю, что данный постинг теряет свою конструктивность, но и согласиться с Вами не могу. Да конечно разруха находится в головах, но как я думаю нельзя рассматривать Axapta только как средство обобщения и получения и … требуемой информации. Axapta, как и любой другой продукт (начиная от 1С) призваны не только считать, но и наводить порядок. Работа с такими системами требует определённой систематизации документооборота, выработки определённых правил и методологий учёта, да и много чего ещё. Большинство «автоматизаций предприятий» происходят не из-за того, что есть система, а хочется лучшего, а скорее из-за отсутствия какой либо приемлемой системы, попыток уйти от той самой разрухи, попыток проконтролировать бизнес и получать прибыль. (Хотя прибыль должна стоять на первом месте) Я думаю этот шаблон можно применить к большинству наших средних и крупных предприятий, это наследие союза. В процессе автоматизации участвуют те же самые люди, и именно система начинает дисциплинировать и учить их. Только тогда возникают у бухгалтеров вопросы: А почему так? Я всю жизнь делала вот так! Только тогда, в процессе разбора работы системы, они получают ответы о корректности или «красивости» их предыдущих действий, а со временем они начинают задумываться над своими действиями, а что ещё лучше о последствиях. Я всё это к тому, что разруха сама по себе не исчезнет, её надо помочь. Axapta и ей подобные программы это тот инструмент который на этапах внедрения и есть та помощь. Обычно проходит довольно длительное время, когда программа начинает выдавать ожидаемые результаты и работать на полную мощность.

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

[stranger]

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

Не буду продолжать:-)

И вы считаете что стоит давать "просто-оператору" такие права? тут и не каждому "супер-Юре" такие права дать можно :-))


вооот

[AHA-X34]

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

[mazzy]

AHA-X34, Вы на правильном пути.

Стоит только вспомнить, как конкретно решается откат в 1С - перепроведением с момента нарушения границы последовательности. И это всего лишь при десятке регистров.

А в Аксапте таблиц на порядки больше. Но это технические проблемы. Бог с ними. Они не так уж и важны.

Стоит подумать о том, что система сетевая. И если оператор ввел приходник, то финансовый директор может в этот момент запланировать эти деньги на платеж. Фин.дир ведь не знает, что сумма появилась минуту назад. Он просто запрашивает машину - есть деньги? Машина говорит - есть. Фин.дир принимает решение. Что будет если оператор "откатит" свое действие?

Разруху, ИХМО, надо лечить не с программы.
А как раз с анализа того, что было раньше и что хочется достичь после.
С анализа кто является генератором данных, кто потребителем.
И у кого какие права на те или иные действия.

Если уж очень хочется откатов, то почему бы и нет?
Но только распишите сначала на бумажке свои действия, действия исполнителя, действия ЛПР (лицо, принимающее решения). Представьте, что вместо проводок люди пишут на бумажке. Представьте, что эти бумажки быстро обрабатываются.

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

[Maxim Gorbunov]

Да ладно, что вы шум-то поднимаете. Почитайте вот здесь: http://www.axforum.info/forums/showt...id=792#post792

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

[glibs]

To AHA-X34

Я лично считаю, что думать, что «купим, мол, модную систему бухучета – и станем платить меньше налогов и штрафов, купим модную систему управления – и возрастут продажи и прибыль» и т.д. и т.п. есть великое заблуждение, характерное нашему, как вы заметили, постсоветскому менталитету. Михал Задорнов много говорил по поводу нашего желания верить в чудо.

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

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

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

Полностью согласен с Mazzy насчет того, что начинать надо с головы.

[mad_pilot]

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

критерии которым должна удволетворять "голова" и прочие органы чтобы внедрение было успешным?

ответы типа "готовность к внедрению", "общее понимание необъяснимого" и "продолжительное самадхи" не пронимаются.

[ldv]

Цитата:

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

Я вернусь к этому утверждению AHA-X34.
Дело в том, что описанная ситация - есть следствие неправильного бизнес -процесса. Бумажный и электронный документооборот должны выглядеть следующим образом.
1. Бухгалтер формирует ПКО в системе. Его распечатывает. Отдает на подпись.
2. Бумажный документ проходит все стадии согласования и т.п. и в итоге клиент его приносит кассиру. До этого момента документ можно изменять - и бумажный и в системе.
3. Кассир получает деньги.
4. Кассир сдает в бухгалтерию в конце дня кассовый отчет.
5. Бухгалтер проверяет кассовый отчет и в соотвествие с ним ПКО проводит.
При такой организации бизнес-процесса количество документов подлежащих в системе сторнированию удивительно снижается.

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