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

[Гризликова]

Цитата:

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

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

Добрый день! Если есть список делитесь) у самой был такой же список, но вышла из декрета, всё в голове отформатипровано, записи потеряны(. К тому же новое место работы
А так я именно тоже специализировалась на бухучете, не все так плохо)

[Romaska]

Цитата:

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

Тема выделена отсюда
Кадровая ситуация на рынке ERP

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

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

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

Что то не припомню я таких ситуаций...
Максимум внедрений Navision приходится на складскую дистрибуцию и управленческий учет,есть примеры проектов с неплохо сделанным
бухгалтеским и налоговым учетом.
В любом случае структура любой ERP-системы подразумевает наличие процесса "учета" документа,а уж каковы настроенные правила такого учета определяется спецификой бизнес-процесса.
По поводу вечного противостояния 1С и MS в части фискального учета считаю даже спорить бессмысленно. По факту 1С занимает процентов 90 этого рынка и стремительно движется в направлении ERP.А вот MS в направлении исправления ошибок в учете движется медленнее,что подтверждалось не раз на проектах.
Насчет проблем в Наве думаю достаточно взять список доработок с нескольких однотипных проектов и его систематизировать,чтобы получить что то стоящее.

[Гризликова]

Цитата:

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

Что то не припомню я таких ситуаций...
Максимум внедрений Navision приходится на складскую дистрибуцию и управленческий учет,есть примеры проектов с неплохо сделанным
бухгалтеским и налоговым учетом.
В любом случае структура любой ERP-системы подразумевает наличие процесса "учета" документа,а уж каковы настроенные правила такого учета определяется спецификой бизнес-процесса.
По поводу вечного противостояния 1С и MS в части фискального учета считаю даже спорить бессмысленно. По факту 1С занимает процентов 90 этого рынка и стремительно движется в направлении ERP.А вот MS в направлении исправления ошибок в учете движется медленнее,что подтверждалось не раз на проектах.
Насчет проблем в Наве думаю достаточно взять список доработок с нескольких однотипных проектов и его систематизировать,чтобы получить что то стоящее.

самая типичная и необходимая доработка- отмена операций
если бухи пошли на работу без отмены, значит консультанты большие дипломаты)

[mazzy]

Цитата:

Сообщение от Гризликова

самая типичная и необходимая доработка- отмена операций

А подумайте немножко.

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

Пример:
1. Продавец создал заказ продажи
2. Заказ продажи обработан системой планирования и для него создан производственный заказ
3. Для производственного заказа создана закупка материалов и работы у субподрядчика
4. Созданы оплаты поставщикам и субподрядчику
5. Оплаты утверждены
6. Оплаты учтены
7. Закупка и работы учтены
8. Производственный заказ учтен
9. Заказ продажи учтен

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

Вы сейчас начнете говорить об ошибках ввода.
Об этом я уже писал здесь Должна ли многопользовательская ERP-система предоставлять возможность изменения уже проведенных операций?

[GalaM]

Цитата:

Сообщение от Гризликова

если бухи пошли на работу без отмены, значит консультанты большие дипломаты)

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

А что касается отмены, то может к 6 версии в НАВ и будет отменяться (сторнировкой, конечно же, все, что возможно)

[Corleone]

Цитата:

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

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

Из первого утверждение второе не следует.

Цитата:

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

Если бухи так хотят, то это в конце-концов их собственная ответственность и если что-то не сойдется после исправлений, то не моя это вина

Да, сделаем функционал как можем (через жопу) а последствия свалим на пользователей. Это в стиле майкрософт.

Цитата:

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

А что касается отмены, то может к 6 версии в НАВ и будет отменяться (сторнировкой, конечно же, все, что возможно)

Да так что мало не покажется.

[Гризликова]

не буду долго разлагольствовать:
1. Под отменой понимаю - отмену всей цепочки (отмена документа, расприменение и т.п.) Цепочки все проглядываютсяи их легко можно все расписать.
2. Отмена- это сторнирование кредит-нотой, отметка исправленных и исправляющих операций и создание новой операции (если речь идет о счетах продажи, то создание новой СЧФ со старым номером). Отмененные операции не должны попадать в Акты сверки, книги продаж и любую отчетность. В операциях покупки сложнее говорить об отменах, но возможно, да и покупные операции гораздо реже правятся (или вообще нет такой необходимости) чем продажные.
есть работающие проекты с отменой, базы намного чище и прозрачней, чем в БД, где существуют корректирующие операции, которые должны извратиться и сделать бухи. В фин. книге ни за что бы номера руками не стала править))
Но все имхо, но бухи руками правящие книги покупок и продаж - плачевно(((

[mazzy]

Цитата:

Сообщение от Гризликова

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

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

Пример:
1. Продавец1 создал заказ продажи 1 на 100 шт
2. Продавец2 создал заказ продажи 2 на 50 шт
3. Заказы продажи обработан системой планирования и для них создан один производственный заказ на 150 шт
... и так далее

После учета Заказ продажи 2 отменяется.
Что должно произойти?

Полностью согласен с gala "Если есть отмена операций, то скорее всего консультанты не очень хорошо представляют последствия этой отмены в длинных цепочках ERP."

Цитата:

Сообщение от Гризликова

2. Отмена- это сторнирование кредит-нотой,

Нет, нет, нет, нет.
Давайте не будем подменять понятия.
Отмена - это отмена.
Сторно - это сторно.

С вашим определением ни один бух не согласится.
В их понимании отмена совпадает с 1Совской отменой проведения - был документ и не стало документа.

Цитата:

Сообщение от Гризликова

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

А отметка то зачем?

А почему это СЧФ со СТАРЫМ НОМЕРОМ?
Вы похоже опять таки не понимаете последствий до конца.

Пример:
1. Продавец выставил комплект документов (включая СЧФ) на 100 рублей.
2. Склад отпустил товар клиенту на 100 рублей.
3. Продавец выполнил "создание новой СЧФ со старым номером" на 80 рублей.
4. Клиент оплатил 80 рублей.

Но со склада ушло товаров на 100 рублей.
Кто виноват? Как найти виноватого, если в системе никаких следов не осталось.

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

Предварительные - квота, invoice proforma. Эти документы могут быть изменены. Эти документы не сопровождаются движением ТМЦ.
Окончательные - invoice, СЧФ сопровождаются движением ТМЦ и не изменяются.

Цитата:

Сообщение от Гризликова

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

С какой это стати?

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

Что это значит?
Это значит, не мучайте себя и не мучайте клиентов. Просто научитесь пользоватся функционалом.

Цитата:

Сообщение от Гризликова

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

А подумайте почему они "реже правятся"?
Не потому ли что в систему попадают только окончательные документы?
Просто для покупок у вас не фиксируется весь ход переговоров. Покупки у вас - просто факт для бухгалтерии плюс приход на склад. А планирования не выполняется. Т.е. у вас закупки работают в режиме 1С:Бухгалтерии

Цитата:

Сообщение от Гризликова

есть работающие проекты с отменой,

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

Цитата:

Сообщение от Гризликова

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

Ну... Если цель внедрения - чистота базы и фискальные отчеты бухов...

[Гризликова]

ваше мнение единственно правильное ?
про 1с-ую отмену никто и не говорил, не надо мешать мух с чаем))
в наве отмена - это создание сторнирующей операции с отметкой и отметка корректирующей операции и корректируемой как раз для того., чтобы в отчетности не болтались исправления, которые иначе бы влияли на расчет зп менеджеров например и другие аналитические и бух. отчеты
а уж если Вы найдете клеинтов, которые согласятся видеть весь мусор в актах сверок....
Вы вообще по моему говорили, что бухгалтерию лучше в Наве не вести, о чем тогда спор)))?
единственное удаление которое мы допускали - это удаление первичной СЧФ продажи, она и в стандартном наве легко удаляется, а то что документ был откорркетирован видно в книгах операций, например в Клиентской
Оп1. СЧФ001 Отменена 100 р
Оп2. Кр0001 Отменена -100 р
Оп3. СЧФ001 230 р
Зато книгу продаж не приходится править руками, вот зачем отметка. Книгу продаж то у вас бухгалтер подтирает))?
У нас было предприятие, у которого в день 300 СЧФ
СЧФ приходится удалять, иначе пропуски в номерах счетов-фактур, а это обратит на вас внимание налоговой (что-то мутите значит)
знаю правда что есть предприятия, которые так и говорят налоговой, что типа программа глючная и платят штрафы....

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

да ещё забыла дописать, если к СЧФ0001 была применена оплата, то включаем расприменение, автоматическое и ручное.
Я так и представила себя, объясняющую буху, а вот вы знаете в международном функционале....))))))))))
некоторые я знаю вообще не применяют доки, но мы вот применяли, в конце года компрессировали и база не пухла
чем больше защита от дурака в системе, тем меньше проблем у руководства с текучкой кадров и т.п., если на пользователя возложить всё, то мы попадаем в зависимость от конкретного человека, правда это уже другая история

ещё ПЫ.СЫ. если предприятие отлично работает без автомтизации отмен, то ну и пусть) значит нет такой задачи и всё хорошо.
а вот если 300 счф в день и бух. система только нав)) и текучка (нет необходимости в квалиф. персонале и больших зп), то уж будьте добры включите макисмлаьную защиту от дурака

[rov_imported]

Я даже посмеялся

Цитата:

Сообщение от Гризликова

ваше мнение единственно правильное ?

Отвечу за Mazzy Нет, его мнение не единственно правильное. Но многие, например я, с его позицией согласны.

Цитата:

Сообщение от Гризликова

в наве отмена - это создание сторнирующей операции с отметкой и отметка корректирующей операции и корректируемой как раз для того.,

Вам опытные люди русским языком объяснили, а вы не верите.
В наве(стандартном) отмены - НЕТ! Уясните себе это четко. Создаются только сторнирующие документы и новые документы - и НИЧЕГО НИГДЕ не удаляется!

Цитата:

Сообщение от Гризликова

отметка .... корректируемой как раз для того...

Корректируемые операции в Наве НИКАК не отмечаются. Вы вообще про Навижн ведете речь - или может у вас какая-то другая система?

Цитата:

Сообщение от Гризликова

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

Нашли. Внедрили. Работают. И что? Вас это удивляет? Может надо сходить на курсы по готовке кошек?

Цитата:

Сообщение от Гризликова

единственное удаление которое мы допускали - это удаление первичной СЧФ продажи

А как же вторичной? А третичной?? А всех остальных?? Безобразие!!

Цитата:

Сообщение от Гризликова

удаление первичной СЧФ продажи, она и в стандартном наве легко удаляется

В мемориз! Однозначно!!
Что ещё в Наве стандартно удаляется - "огласите весь список пожалуйста"!

Цитата:

Сообщение от Гризликова

а то что документ был откорркетирован видно в книгах операций, например в Клиентской

Так-так... Отжигаем дальше!

Цитата:

Сообщение от Гризликова

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

Неа, не будем! Вы уже сами всё сказали.

Цитата:

Сообщение от Гризликова

да ещё забыла дописать, если к СЧФ0001 была применена оплата, то включаем расприменение, автоматическое и ручное.

Yes! Включаем и все расприменяем!!! Автоматически! Или вручную! Смотря, что курили утром!

ППЦ, не могу больше!

[Гризликова]

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

[rov_imported]

Цитата:

Сообщение от Гризликова

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

Это прекрасно!
Гризликова, мне очень нравится читать ваши посты, правда! Пишите ещё, ладно?

Mazzy, может эти цитаты собрать в кучу и вывесить где-нибудь на сайте ? Это же неиссякаемый анекдот!

[Гризликова]

у меня работы хватает, а вы балабольте, балабольте еще)
может по существу что скажете, хотя не стоит надеятся

[rmv]

Rov - поменьше эмоций.
Возможно Вам просто повезло и Вы ни разу не удаляли ручками записи в 17 таблице.
К сожалению у меня не было ни одного столь идеального проекта .

Повторю несколько утверждений Гризликовой, адресуя их к Вам:
1. Хотя бы у одного из Ваших клиентов в Навижне ведется бухгалтерский учет? Если да, то как бухгалтеры относятся к пропускам в серии номеров?
2. Ваши клиенты акты сверки с клиентами и поставщиками печатают? Как клиенты ваше клиента реагируют на сторнированные и сторнирующие документы?
3. Много ли модификаций приходилось делать для полноценного сторнирования? В частности во все документы протянули галку "Коррекция" для того чтобы не росли обороты по дебету, кредиту?


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

Цитата:

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

Пример:
1. Продавец создал заказ продажи
2. Заказ продажи обработан системой планирования и для него создан производственный заказ
3. Для производственного заказа создана закупка материалов и работы у субподрядчика
4. Созданы оплаты поставщикам и субподрядчику
5. Оплаты утверждены
6. Оплаты учтены
7. Закупка и работы учтены
8. Производственный заказ учтен
9. Заказ продажи учтен

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

Замечательный пример. Планирование в производстве штука безусловно нужная. И в данной ситуации (производство под конкретный заказ) удаление Заказа Продажи недопустимо.
Рассмотрим для полноты картины другой пример. Заменим п. 2 на "Производственный план на основе продаж за прошлый месяц обработан системой и создан производственный заказ". Что в этом случае мешает удалить Заказ Продажи когда вся цепочка завершена?

То же самое с дистрибуцией. Допускаю что порой закупка идет под конкретный заказ продажи, чаще всего правда встречался с
анализ продаж->товарный бюджет->закупка. Что в этом случае мешает отменить Заказ Продажи?

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

[Corleone]

Цитата:

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

Нашли. Внедрили. Работают. И что? Вас это удивляет? Может надо сходить на курсы по готовке кошек?

Тут стоит уточнить, бухучет работает?

[rov_imported]

Цитата:

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

Тут стоит уточнить, бухучет работает?

Ясен пень В смысле - работает.

[Eugeny_F]

Цитата:

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

Это прекрасно!
Гризликова, мне очень нравится читать ваши посты, правда! Пишите ещё, ладно?

Mazzy, может эти цитаты собрать в кучу и вывесить где-нибудь на сайте ? Это же неиссякаемый анекдот!

Кстати, учтенный счет-фактура вполне себе спокойно удаляется по кнопке F4. В стандартном Navision 4 SP3. Зачем он это дает делать, не понимаю.

[GRIZZLY_imported]

Не понимаю, почему так весело г-ну rov...
написали же, что отмена - это сторнирование. Давайте тогда введем другой термин, если отмена у вас ассоциируется с удалением проводок. Сказали же вам, что проводки не удаляются...
Про удаление документа Учт. Счет - его удаление в стандартном функционале разрешено (в 3.60), документ учтен, он оставил проводки, дальше его можно удалять, есть даже специальные пакетные задания по удалению Учтенных Документов. Показать как их найти?
В Нав 4.0 есть функции Аннулирования Фин. Регистров, в Нав 5.0 есть функция отмены применения клиентских/поставщиковских/товарных операций. Тоже будете спорить что нет отмены? И отменяемые операции метятся галкой Аннулирована, немного изучите стандартный функционал...
mazzy, в случае перевыставления менеджером нового счета - все было продумано, такой учет происходил с визой начальника склада (была спец. галка, которую мог ставить начальник склада), и недостачи или излишки учитывались в ячейке КОРР в модуле Управление Складом. Далее товары из ячейки КОРР перемещали на места хранения.
При аннулировании документа было сравнение документа Учт. Счет и документа Кредит-Нота. Если они в точности не совпадали, то аннулирование произвести было нельзя. Кроме того, документ Кредит-Нота применялся к Учт. Счету для точного возврата себестоимости.
Я думаю, что говорить о том, что консультант так сделал, так как не представлял последствий, нельзя. Может быть, он, наоборот, представлял что нужно сделать, чтобы с точки зрения бизнес-процесса и системы все было корректно?

[rov_imported]

Цитата:

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

Rov - поменьше эмоций.

Ну дак весело же! Смех, говорят, продлевает жизнь!

Цитата:

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

Возможно Вам просто повезло и Вы ни разу не удаляли ручками записи в 17 таблице.
К сожалению у меня не было ни одного столь идеального проекта .

Удалял. Кто ж их не удалял И тоже, практически во всех проектах.

Цитата:

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

Повторю несколько утверждений Гризликовой, адресуя их к Вам:
1. Хотя бы у одного из Ваших клиентов в Навижне ведется бухгалтерский учет? Если да, то как бухгалтеры относятся к пропускам в серии номеров?

Практически у всех - бухучет. Про пропуски- а они есть? Можно подробнее?

Цитата:

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

2. Ваши клиенты акты сверки с клиентами и поставщиками печатают? Как клиенты ваше клиента реагируют на сторнированные и сторнирующие документы?

Да, иногда, печатают. А у третьей стороны не остается выбора. Конечно, в акте сверки вылезает чушь: счет, стрнировка с минусом, новый счет. А что делать...

Цитата:

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

3. Много ли модификаций приходилось делать для полноценного сторнирования? В частности во все документы протянули галку "Коррекция" для того чтобы не росли обороты по дебету, кредиту?

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

Цитата:

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

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

С этим - согласен.

В общем, моя позиция простая. Я считаю, что отмена-это зло, и её быть не должно.
При этом действительно на начальном этапе без нее не обойтись. Где то можно почистить, где-то
написать процедуру.
Бояться её и правда не надо. Я считаю, что отмену должен делать только внедренец(ну или внутренний админ), и только тот, который знает всю "цепочку" и последствия. Ту самую цепочку, о которой говорит Mazzy.

Ну представьте вы себе ситуацию: пользователь учел счет-продажи, вместо 1000 USD, поставил 1 млн. USD.
Отчет о результатах продажи ушел в Европу, там топ-менеджеры посовещались и решили дозаказать товаров у поставщиков - на этот самы миллион.
Через день пользователь очнулся и понял, что счет неправильный и его надо отменить. Что сделает функция отмены? Сама позвонит по телефону в европейскую штаб-квартиру и объяснит, что данные в бумажном отчете на столе у вице-президента - неправильные? Или как?

[Гризликова]

Цитата:

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

Ну дак весело же! Смех, говорят, продлевает жизнь!


Удалял. Кто ж их не удалял И тоже, практически во всех проектах.



Практически у всех - бухучет. Про пропуски- а они есть? Можно подробнее?


Да, иногда, печатают. А у третьей стороны не остается выбора. Конечно, в акте сверки вылезает чушь: счет, стрнировка с минусом, новый счет. А что делать...


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


С этим - согласен.

В общем, моя позиция простая. Я считаю, что отмена-это зло, и её быть не должно.
При этом действительно на начальном этапе без нее не обойтись. Где то можно почистить, где-то
написать процедуру.
Бояться её и правда не надо. Я считаю, что отмену должен делать только внедренец(ну или внутренний админ), и только тот, который знает всю "цепочку" и последствия. Ту самую цепочку, о которой говорит Mazzy.

Ну представьте вы себе ситуацию: пользователь учел счет-продажи, вместо 1000 USD, поставил 1 млн. USD.
Отчет о результатах продажи ушел в Европу, там топ-менеджеры посовещались и решили дозаказать товаров у поставщиков - на этот самы миллион.
Через день пользователь очнулся и понял, что счет неправильный и его надо отменить. Что сделает функция отмены? Сама позвонит по телефону в европейскую штаб-квартиру и объяснит, что данные в бумажном отчете на столе у вице-президента - неправильные? Или как?

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