Кто программил удаление документов

[Andpil]

В общем в очередной раз на нашем предприятии поднялся вопрос об удалении (НЕ СТОРНО) документов с удалением (обновлением) проводок. Собственно решил создать опрос по этому поводу.

[Logger]

Вы бы лучше спросили, кто этого не делал

Думаю что таких бы не нашлось

[Logger]

Кстати, удаление фактур нечего программировать.
Оно штатно есть и даже выведено кнопкой на форму.

[Ivanhoe]

Кроме штатного удаления фактур ни на одном моем проекте не было подобной ереси Разве что полная очистка БД перед запуском.

[Andpil]

Цитата:

Сообщение от Logger

Кстати, удаление фактур нечего программировать.
Оно штатно есть и даже выведено кнопкой на форму.

Да кнопка такая есть, но нам не подходит, потому как мы из Украины, здесь с фактурами все гораздо сложнее, там и дополнительные проводки в ГК и первое событие, короче довольно сильно кастомизирован функционал по фактурам, в общем пользоваться этой кнопкой нельзя, поэтому она у нас она скрыта на уровне АОТ чтобы у пользователей не было и малейших порывов ее нажать.

[EVGL]

Цитата:

Сообщение от Logger

Вы бы лучше спросили, кто этого не делал

Я не делал. Делал только кнопку для быстрого сторно.

[MikeR]

Цитата:

Сообщение от Andpil

Да кнопка такая есть, но нам не подходит, потому как мы из Украины, здесь с фактурами все гораздо сложнее, там и дополнительные проводки в ГК и первое событие, короче довольно сильно кастомизирован функционал по фактурам, в общем пользоваться этой кнопкой нельзя, поэтому она у нас она скрыта на уровне АОТ чтобы у пользователей не было и малейших порывов ее нажать.

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


ЗЫ хочу добавить пунктик в голосование - Как это работает в данный момент (не работает, работает, лучше бы не работало )

[Logger]

Цитата:

Сообщение от Ivanhoe

Кроме штатного удаления фактур ни на одном моем проекте не было подобной ереси Разве что полная очистка БД перед запуском.

У меня полностью обратная ситуация.

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

[macklakov]

В опросе не хватает пункта "никогда этого не делал, ибо считаю это ересью"

[Andpil]

Цитата:

Сообщение от macklakov

В опросе не хватает пункта "никогда этого не делал, ибо считаю это ересью"

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

[ashu]

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

[sukhanchik]

Цитата:

Сообщение от macklakov

В опросе не хватает пункта "никогда этого не делал, ибо считаю это ересью"

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

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

[macklakov]

Цитата:

Сообщение от sukhanchik

Можно уточнить так: Кто делал удаление (фактически, откат) документов, которое применяется в бизнес-процессах?

Согласен.
Действительно, иногда приходится делать, для себя, джобики, чтобы система могла работать, пока нормальное сторно не написано. Но давать пользователям доступ к такой фиче, значит гарантированно порушить целостность данных. Либо это уже будет не AX, а что-то свое, написанное на X++. Т.е. ересь.

[kornix]

Цитата:

Сообщение от sukhanchik

Можно уточнить так: Кто делал удаление (фактически, откат) документов, которое применяется в бизнес-процессах?

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

[mazzy]

Цитата:

Сообщение от Andpil

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

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

Цитата:

Сообщение от MikeR

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

полностью согласен. особенно после слов "имейте в виду, что...".

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

по сути вопроса:
= делал под напором пользователей
= каждый раз жалел о том, что сделал

[lev]

Приходилось делать отмену разноски складских журналов (не только проводка и перенос, но ещё и прибыль\убыток), и отмену разноски накладной по заказу на продажу.
НО это были функции для отдела поддержки, и пользователям они были недоступны.

Более того, подобные откаты выполнялись только по служебным запискам, согласованным с руководителем того отдела, который запрашивает отмену документа (а иногда требовали согласование с ген директором, например для отмены накладной по заказу на продажу). Как правило такое согласование в 50% случаях отталкивает пользователя выполнять такое действие, и он лишний раз подумает делать или не делать.

[Ivanhoe]

Цитата:

Сообщение от Logger

У меня полностью обратная ситуация.

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

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

При этом я не отрицаю разовые правки данных в следствие ошибок стандарта / модификаций.

P.S. в последнее время всё чаще встречаюсь с компаниями, ИТ руководителями и директорами, которые именно за это и платят консалтингу - что консультанты не идут на поводу у пользователей и умею говорить "нет".

[ashu]

Цитата:

Сообщение от mazzy

полностью согласен. особенно после слов "имейте в виду, что...".

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

по сути вопроса:
= делал под напором пользователей
= каждый раз жалел о том, что сделал

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

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

[Raven Melancholic]

Работаю на клиенте.
Как и у большинства, есть джобики для очистки данных по некоторым документам, но они только для нашего отдела. Для остальных понаписано кучи "кнопок счастья" для удобного сторнирования.
Справедливости ради, стоить заметить, что регламентированный бухучет ведется в 1С с выгрузкой данных из Аксапты. При выгрузке учитываются сторнирования. Думаю, что если бы регламентированный учет вели в Аксе, то пришлось бы некоторые джобики разворачивать в полноценные механизмы, доступные некоторым пользователям.
PS: в опросе нет данных по разноскам, выполняемым производственными заказами и модулем Проекты.

[oip]

Пару раз приходилось писать соответствующие jobs для срочной корректировки определенных данных.

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