В чем проблема с удалением документов в Аксапте

[AXcons]

По мотивам предыдущей темы насчет БУ.

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

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

[fed]

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

[sukhanchik]

Удаление документов, как механизм - нужен. Кому и как - это уже второе дело. Но нужен.
Чтобы ответить на Ваш вопрос - нужно сначала ответить вопрос - для каких целей используется АХ на предприятии?
Я встречался со следующими целями:
1. Расчет с/с товара
2. Складской учет (в т.ч. WMS)
3. Планирование (расчет плана поставок; сводное планирование)
4. Ведение БУ / НУ с интеграцией или без с 1С.

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

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

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

В общем... Если цифры из АХ используются бизнесом, то бизнес будет стремиться к тому, чтобы они были правдивые. Если не используются - то бизнесу будет параллельно и все упрется в удобство пользователей, которым удобнее всего Excel

[GBH]

Абсолютно согласен с fed.
Аудиторский след аудиторам и не нужен, он в первую очередь нужен руководству, чтобы понимать, что происходит. А то получается как в анекдоте: сколько символов в минуту печатаете? - 800. Правда такая фигня получается.
Вот также и с пользователям - провел документ, удалил, провел, удалил. Чем занимался весь день? А он тебе факт - во, создал 10 проводок, очень неудобный интерфейс и система DAX говно. А ты ему, подожди, ты 10 создал проводок, но 40 отсторнировал. Ты вообще понимаешь, что творишь?

Конечно, я всё утрирую, но смысл примерно такой.

Если запускали DAX там где это новая система, то аудит для решения проблем вида "Я ничего не делала - это система сама всё сделала" очень помогает. Также, видя невозможность перепроведения документа люди начинают думать - "А что я, собственно говоря, творю?".

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

[AXcons]

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

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

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

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

[AXcons]

Цитата:

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

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

Да, у нас доступ тоже не у всех, конечно. Специальная функция под специальными правами.

[AXcons]

Цитата:

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

Сторнирование проводки по поставщику для какого-нить финансового контроллера легче и быстрее найти чем заниматься поисками непонятно чего в каком-то логе (причем еще не очень понятно в каком периоде и по каким признакам искать надо).

А можете на примере объяснить зачем вообще финансовому аналитику искать сторнирование проводки?
То есть если он сверяет первичку с системой, и не нашел какого-то документа, то значит его нет. Чего искать-то? Надо сделать и дать втык тому, кто накосячил. Ну если уж хочется выяснить какая там была история, кто и что, ну обратятся в ИТ отдел, там посмотрят ЖБД.
А если документ был отсторнирован и сделан заново, то он есть, опять же нет смысла смотреть сторно проводку, наоборот, она будет мешать, т.к. под нее нет первички.

[fed]

Цитата:

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

То есть если он сверяет первичку с системой, и не нашел какого-то документа, то значит его нет. Чего искать-то? Надо сделать и дать втык тому, кто накосячил. Ну если уж хочется выяснить какая там была история, кто и что, ну обратятся в ИТ отдел, там посмотрят ЖБД.
А если документ был отсторнирован и сделан заново, то он есть, опять же нет смысла смотреть сторно проводку, наоборот, она будет мешать, т.к. под нее нет первички.

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

[Fillin]

Согласен с авторами. В удалении ничего страшного. Если это делается осознанно и не приводит к проблемам у других пользователей. Cons правильно написала. Консалтинг с ужасом в глазах говорят, что удалять нельзя. Отчасти их так научили. Отчасти справедливо боятся, что это повлечет претензии в будущем от Заказчика. Сам сталкивался. Сначала просят сделать удалении документов. Смотришь - вроде ничего критичного. Сделаешь. А они потом еще функционал допишут. И как понаудаляют - так просят разобраться "что ваша аксапта не правильно считает".
Консалтинг боится таких доработок. И не потому что не умеет. У них уровень ответственности в другой плоскости

[Fillin]

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

[AXcons]

Цитата:

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

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

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

[Fillin]

ice. поясните. почему "детские". пишите сюда. не стесняйтесь. а то на уровне "сам дурак"

[AXcons]

Цитата:

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

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

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

[Владимир Максимов]

Вас интересуют технические проблемы или организационные? Я могу озвучить только чисто технические проблемы

Технические проблемы

1. Не все операции Axapta можно корректно откатить в том смысле, что можно корректно "вырезать" сумму по удаленному документу. Чтобы это организовать приходится вводить дополнительные ограничения как технического, так и организационного характера в ведении учета

Ну, про ОСВ Вы в курсе. Тот факт, что там можно что-то отфильтровать по счету ГК - это иллюзия. Работает, но при очень определенных условиях. Реально связь между проводками контрагента и проводками ГК не однозначная. В общем случае, Вы просто не можете сказать, какая проводка контрагента какую проводку ГК породила

Ну, простой пример, в общем случае, ваучер поставщика может совпасть с ваучером клиента. Вы удаляете документ поставщика и "случайно" цепляете документ клиента (ваучеры-то одинаковые). Чтобы это обойти, Вам придется заняться очень жестким разграничением операций по клиентам и по поставщикам. Как программно, так и организационно.

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

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


2. Проблемы установки новых модификаций

Стандартный функционал не предполагает удаления документов. При написании стандартного кода об этом никто не задумывается. Это значит, что после выхода нового Hotfix, Service Pack или каких-нибудь покупных Add-on, Вам придется заново изучать и тестировать уже казалось бы отлаженный функционал


3. Удаление - очень "тяжелая" операция для SQL

Удаление, во-первых, одна из самых медленных операций SQL. Как следствие, во-вторых, серьезно возрастает риск блокировок. В целом, система становится более "задумчивая"


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

[AXcons]

Цитата:

Сообщение от Владимир Максимов

Вас интересуют технические проблемы или организационные? Я могу озвучить только чисто технические проблемы

Технические проблемы

1. Не все операции Axapta можно корректно откатить в том смысле, что можно корректно "вырезать" сумму по удаленному документу. Чтобы это организовать приходится вводить дополнительные ограничения как технического, так и организационного характера в ведении учета
...

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

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

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

Цитата:

2. Проблемы установки новых модификаций

Стандартный функционал не предполагает удаления документов. При написании стандартного кода об этом никто не задумывается. Это значит, что после выхода нового Hotfix, Service Pack или каких-нибудь покупных Add-on, Вам придется заново изучать и тестировать уже казалось бы отлаженный функционал

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

Цитата:

3. Удаление - очень "тяжелая" операция для SQL

Удаление, во-первых, одна из самых медленных операций SQL. Как следствие, во-вторых, серьезно возрастает риск блокировок. В целом, система становится более "задумчивая"

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

[Владимир Максимов]

Цитата:

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

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

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

Цитата:

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

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

Предположим, Вы создали (купили, установили) новую функциональность, где на основании созданного документа формируют другой документ. Естественно, что в момент установки никто не вспомнит, что у Вас есть еще функционал по удалению документов. И вот день настал, документ удалили, и новый функционал стал показывать полную ерунду!

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

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

Цитата:

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

Да и вообще давно не ставили никаких обновлений, честно говоря. Не вижу особого смысла.

Вот! Это Ваше счастье! В самом прямом и незамутненном смысле этого слова. Безо всяких шуток и подколок.

Хотя, это прямо указывает на то, что у Вашей компании проблемы. Она прекратила развитие. Ее все устраивает. Но к вопросу поддержания системы это отношения не имеет.

Цитата:

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

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

Удаление "славится" тем, что зачастую блокирует вообще всю таблицу целиком. А операции обновления - только отдельные части. В общем, Вам пока просто везло...

[Ivanhoe]

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

Удобного исправления документов в рамках правил (права, открытый период и т.п.) реально не хватает в Аксе.

[mazzy]

Цитата:

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

как правило никто про это не думает - бюджет в договоре на это не выделяется.

ну и зря ) я в свое время даже в устав проекта этот пункт добавлял.
это типично холиваный пункт даже внутри предприятия-заказчика.

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

[grib_nat]

Написала в другой теме и продублирую здесь:
На производственных предприятиях (Ах4.0) в 2015г. руководители поняли, что неверно или не вовремя предоставленная информация может дорого стоить компании.
Был сделан Оперативный отчет по показателям производственной деятельности, который отражал все важные показатели производства и реализации: добыча, показатели по производственным переделам (планы и факты), реализация, движение основного сырья, простои основного технологического оборудования, производительность каждого оборудования...Все данные собирались их АХ4.0.
Отчет ежедневно в автоматическом режиме попадал топ-менеджменту компании.
После запуска отчета возникла необходимость в отчете, который показывал, какие данные отражаются не оперативно или вносятся изменения. Это очень дисциплинировало всех участников.
НЕЛЬЗЯ удалять проводки и истории изменений, если вы считаете, что у Вас ERP-система

[AXcons]

Цитата:

Сообщение от Владимир Максимов

В общем, Вам пока просто везло...

C 2003 года все везет. На всех проектах делали.

Цитата:

Сообщение от Владимир Максимов

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

У нас все учтено.

Цитата:

Сообщение от Владимир Максимов

Ну, например, если Вы оплатили одной платежкой 2 накладных, а потом одну накладную удалили, то что делать с платежкой? Понятно, что технически уменьшить сумму можно. А что на это скажет казначейство?

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

Цитата:

Сообщение от Владимир Максимов

Понятно в чем проблема? Новый функционал был "не в курсе" возможности удаления. Вам придется заново модифицировать процедуру удаления, чтобы учесть новый функционал

Ну да, за это программисты зарплату и получают, вообще то. Не вижу тут проблемы.

Цитата:

Сообщение от Владимир Максимов

Хотя, это прямо указывает на то, что у Вашей компании проблемы. Она прекратила развитие. Ее все устраивает.

Не поняла логики. Как связано развитие и сервис паки? Мы программируем новый функционал сами, как раз потому что бизнес у нас все время развивается. И мы его запрограммируем лучше и быстрее чем Майкрософт, и как нам надо. Поэтому и не ставим обновления, потому что там ничего интересного для нас нет. Разве что если там какие-то системные баги исправлены, но это такая редкость.