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

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

не буду долго разлагольствовать:
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С:Бухгалтерию и вводить туда факт руками

Цитата:

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

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

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

[rmv]

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

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


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

Цитата:

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

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

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

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

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

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

[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.
Отчет о результатах продажи ушел в Европу, там топ-менеджеры посовещались и решили дозаказать товаров у поставщиков - на этот самы миллион.
Через день пользователь очнулся и понял, что счет неправильный и его надо отменить. Что сделает функция отмены? Сама позвонит по телефону в европейскую штаб-квартиру и объяснит, что данные в бумажном отчете на столе у вице-президента - неправильные? Или как?

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

[rov_imported]

Цитата:

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

отмену визирует только уполномоченный пользователь (нач. отдела, нач. склада и т.п.),

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

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

Цитата:

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

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

не будем говорить про абстракицию, есть конкретный проект, где расписаны все бизнес-процессы и всё предусмотрено)) уж доказыать ничего не буду, ладно?)
всё уберу подписку на эту тему, а то отвлекаюсь от работы))

[rmv]

Цитата:

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

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

Ну например про несчастный миллион вместо ста тысяц.
Учли Вы СФ-0001 на 1 000 000.
Беда - нужно на 100 000 была.
Учли КР-Н-0001 на 1 000 000 применили, замечательно.
Учли красивый СФ-0002 на 100 000. Все довольны, даже клиента уговорили что номерок СФ-0002 он то бедняга уже его к учету принял...
ибо ему тоже товар грузить нужно, принял естествнно с правильной суммой 100 000 и Вас конечную цифру попросил переделать.
(ситуация имхо бредовая. Обычно Заказ Продажи как счет до подписания клиентом СФ не учитывают - ну если у ROV'a так - пусть будет так).

Итого по НДСу:

Вариант 1
Книга Продаж
СФ-0001
СФ-0002
Книга покупок
КР-Н-0001

Вариант 2
Книга Продаж
СФ-0001
СФ-0002
КР-Н-0001

Вариант 3
СФ-0002 ?

Какой у вас?
Варианты 1 и 2 - ждите проверки .
Варианты 3 - дырки в нумерации.

Цитата:

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

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

Ну например как излишнее списание/приход сторнировать по 17 табличке?

[rov_imported]

Цитата:

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

Какой у вас?

У нас (ну то есть у клиентов) - вариант 1.
Что у них бывает при проверке -отписал честно - не знаю.

Цитата:

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

Ну например как излишнее списание/приход сторнировать по 17 табличке?

В стандартном функционале - никак, так как нет сторнировочных документов, аналогичных кредит-ноте.
Либо делать обратным документом - с завышением оборотов. Это не очень правильно -но если нет другого выхода,
то что остается...
Но! Как раз этот завышенный оборот можно уже тупо по фин. книге отсторнировать.
Итак: лежала на складе 1 штука по 100 руб. - скажем тетрадь. Сальдо на 10-ке - 100.
Оформляем Акт списания (допустим на 25).
Получаем Дт 25 - Кт 10 100 руб.
Понимаем, что ошиблись. Делаем обратный документ: Акт Оприходования того же артикула на те же деньги обратно на тот же склад.
Получаем Дт 10 - Кт 25 100 руб.. Нам бы хотелось, чтобы это пошло как сторно, но будет увы обычная обратная проводка.
Тогда тупо по фин. книге (ну то есть в фин. журнале) делаем 2 проводки:
1-я: Дт 10 - Кт 25 -100 руб. - то есть сторнируем нашу "неправильную" обратную проводку.
2-я: Дт 25 - Кт 10 -100 руб. - а это мы уже сторнинуем наше "неправильное" списание.
В результате по товарной книге мы имеем 1 штуку по 100 руб на складе. А по фин. книге: сальдо на 10-ке - 100,
на 25-м - 0. И нет двойных оборотов.

[rmv]

Цитата:

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

У нас (ну то есть у клиентов) - вариант 1.
Что у них бывает при проверке -отписал честно - не знаю.

Думаю все таки руками книги покупок и продаж чистят .

Цитата:

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

В стандартном функционале - никак, так как нет сторнировочных документов, аналогичных кредит-ноте.
Либо делать обратным документом - с завышением оборотов. Это не очень правильно -но если нет другого выхода,
то что остается...
Но! Как раз этот завышенный оборот можно уже тупо по фин. книге отсторнировать.
Итак: лежала на складе 1 штука по 100 руб. - скажем тетрадь. Сальдо на 10-ке - 100.
Оформляем Акт списания (допустим на 25).
Получаем Дт 25 - Кт 10 100 руб.
Понимаем, что ошиблись. Делаем обратный документ: Акт Оприходования того же артикула на те же деньги обратно на тот же склад.
Получаем Дт 10 - Кт 25 100 руб.. Нам бы хотелось, чтобы это пошло как сторно, но будет увы обычная обратная проводка.
Тогда тупо по фин. книге (ну то есть в фин. журнале) делаем 2 проводки:
1-я: Дт 10 - Кт 25 -100 руб. - то есть сторнируем нашу "неправильную" обратную проводку.
2-я: Дт 25 - Кт 10 -100 руб. - а это мы уже сторнинуем наше "неправильное" списание.
В результате по товарной книге мы имеем 1 штуку по 100 руб на складе. А по фин. книге: сальдо на 10-ке - 100,
на 25-м - 0. И нет двойных оборотов.

С учетом измерений сторнирование фин. операцией руками представляется достаточно трудоемким.

Rov - спасибо, вопросов больше нет.