v7: Как отловить отказ от сохранения и отказ от проведения документа #799576

При записи документа, нужно выполнить некоторые действия с подчиненными документами. Использую процедуру ПриЗаписи. Она выполняется по кнопке "Записать". Если пользователь её нажимает, все отлично. Но есть еще кнопка "Провести". Если пользователь нажал сразу ее (без предварительной записи документа) и на вопрос программы о проведении - ответил НЕТ, то действия из процедуры ПриЗаписи уже отработали - подчиненные документы изменились, исходный документ внешне тоже изменился, но при закрытии выдает сообщение "Сохранить документ?", пользователь снова указывает "нет", тогда исходный документ возвращается к первоначальному состоянию, а при этом подчиненные документы уже были сохранены (перед попыткой проведения). Как отловить этот отказ от сохранения и вернуть подчиненные документы в первоначальный вид?

Очевидно, что подчинённые документы надо отрабатывать после успешного проведения и не надо ловить всякие отказы ???

Повесь на кнопку "провести" и "ОК" процедуру, которая сделает всё правильно.

Проводи по кнопке ок не интерактивно а впрямую, програмно и делай что хочешь

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

хотя будут глюки если впрямую через форму работать

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

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

заказчик может требовать что угодно. настоящий прог будет делать ПРАВИЛЬНО - чтобы обеспечить непротиворечивость данных. если заказчик настаивает на кривом решении которое потенциально не дает гарантии вменяемой нормального состояния связанных данных - тогда подробно обсуждать что именно в какой момент делается. иначе потом обвинят во всех смертных грехах

Изменяй подчиненные документы не ПриЗаписи, а ПриПроведении.

Заказчику нужно объяснить (желательно на русском литературном), что это неправильно. Сохранить док-т - ни о чем. Именно, при проведении док-т попадает в учет. (ну, как-то так)

> иными словами, если заказчик потребует изменения подчиненных именно при сохранении документа, а не при проведении. Проектирование поведения системы - не его епархия.

задай вопрос заказчику "Что делать при отказе от сохранения документа?" и по ответу узнаешь что делать: свою процедуру сохранения на обе кнопки "ОК" и "Записать" (как в 2) или переносить логику в проведение не факт, по разному бывает. Например, договор с фиксацией параметров, но без движений в учётной системе (проводок нет, а документ есть) другими словами - "Заказчик не знает что он хочет?" Тебе выдали задание, сделай "так и так", техника дела - твоя епархия, логика "что, где и когда" - дело заказчика. Предупреждение: "будут вот такие проблемы, можем решить так" снятие гемора с себя и отдача его заказчику для принятия решения

"Например, договор с фиксацией параметров, но без движений в учётной системе (проводок нет, а документ есть) " - расшифруй.

Будь проще. Проверяй значимые реквизиты документа в ПриЗакрытии, если оне изменились, задавай вопрос пользователю - "Изменились важные реквизиты дока, пересчитать подчиненные ? да/нет".. и усё. если ответит утвердительно - пересчет подчиненного.

Заказчик хочет документ "Договор" с некими параметрами и заковыристой печатной формой. Сии параметры используются далее в других документах. Используется документ (а не справочник) из-за автонумерации по определённым правилам и требованию заказчика (видишь бывают и такие, которые хотят именно "документ" и "при сохранении"). Документ не проводится, но в учёт попадает (как единица учётной системы). Так что, в учёт документ попадает не только при проведении, но и при сохранении

Я правильно поняла: договор - документ?

да, кроме нумерации непонятна логика использования объекта "документ", может планировались некие проводки, но следов не осталось, а документ есть и встроен в систему

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

И какие проводки может делать договор? По сути - документ. А по по-эсному - справочник. И в чем "не управляем"?

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

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

"Есть договор. У него срок действия. Срок закончился, договор нужно пролонгировать. " - и как это реализовано в док-ах?

Например, ограничение по сумме на забалансе. Договор имеет предел суммы, например, 2000$, в Дт ставим сумму, другие документы её гасят с контролем "Перелезли лимит - нет" собственно, по возможностям примерно равные решения, только документ имеет нумератор и может проводиться, а справочник нет. Для 8 мало критичные различия, для 7 возможно, что "документ" несколько предпочтительнее если нужна логика кроме хранения

То есть договор меняет сумму в проводках? Или как?

может иметь, зависит от типа. Договор на поставку, например, окон в кол-ве Н шт, на сумму МНОГО рублей лимит имеет, а договор связи нет, абонплата до расторжения

Не понял...

Контроль суммы договора редко встречающаяся задача? для 7 удобное решение на бух проводках

Почему редкое? Далеко не редкое. Только при чем тут документы? Бух проводки - далеко не удобное решение. Кроме, того, помимо суммы договора, прописана номенклатура (в договоре). Разная, по разным цене и количеству. И опять - при чем тут док-ты?

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

Есть договор. В нем прописана сумма "10 000 руб" и номенклатура: флешка1 = 10 шт по 200 руб, флешка2 = 10 шт по 300 руб, флешка3 = 10 шт по 500 руб. Договор подписан. Флешки 1 и 2 есть в наличии (сегодня), флешка 3 будет через 2 дня. Клиент хочет по данному договору забрать флешки 1 и 2 сегодня, а флешки 3 - по поступлению на склад (то бишь - через2 дня). Покажи схему "договор = документ".

29+ Суть разговора "Что лучше Справочник или Документ?" примерно соответствует "Что лучше Пирожное или Торт?" и ответ одинаков "смотря для чего". Если угостить много людей и нет ножа - пирожное, если кому-то в лицо запилить надо - торт побеждает с большим преимуществом (не разделится на составляющие в самый ответственный момент, хотя и пирожными можно обойтись и кидаться ими удобнее, поскольку имеется много в наличии)

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

Схема: документ Договор №1: должны нам товара на 10 000 документ накладная: По договору №1 получили на 5 000 (первые 2 флешки) сегодня документ накладная: По договору №1 получили на 5 000 (три оставшиеся флешки как придут на склад) Отчёт по договорам показывает недопоставку Оплата по накладным На вскидку, примерно так.

"документ Договор №1: должны нам товара на 10 000 " - чего? Смысл "Документ Договор" так и не ясен...

в любой типовой, т.к. не предполагает ни какой надстроенной логики. Для 90% организаций такой реализации достаточно, потому 1С не заморачивается. Зарегистрировали договор, максимум валюту учли и всё. К стати многовалютный договор, т.е. работа по которому может идти в USD, EUR и RUB в типовых представляется 3 записями. Вопрос "Зачем?" в такой ситуации пишется в несколько слов, особенно когда бухи их путают или хотят получить данные по договору в целом (во всех валютах, а записей 3). смысл реализации на базе объекта документ: в осуществлении дополнительного контроля, например, за суммой (нам всё поставили или нет), но есть и вторая сторона для договора поставки от нас клиенту (а чего это вдруг с нас требуют товара на сумму большую чем в договоре).

Я тебе говорила не только про 1С. Но видимо - зря. "смысл реализации на базе объекта документ" (как и прочее) - все спокойно реализуется без дописки нового док-та. Повторюсь - не надо изобретать велописед.

> Смысл "Документ Договор" так и не ясен... Для бухгалтера смысла нет. Ровно так же, как и нет смысла в сущности "документ реализация". Обходились же бухгалтера до 1С 7.7 совершенно естественными для них понятиями проводка и операция. Документ вообще в бухучете понятие необязательное. Бухгалтерии хватает записи о регистрации договора. Справочник их потребности покрывает с запасом. А вот если нам требуется учет договоров, если договора еще не дойдя до бухгалтерии проходят целый жизненный цикл подготовки, согласования, подписания, регистрации и всего прочего - без документа становится грустно.

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

да, не переживай, когда будешь реализовывать логику в 7 над договором (многовалютность, суммы, периоды, статусы и т.д.), тогда и вспомнишь про сей разговор и для себя примешь решение Справочник/Документ. Велосипед изобретать не надо, но и постоянно грызть кактус то же не стоит. Меньшая кровь в начале доработки (есть уже справочник и ладненько) часто оборачивается большим неудобством для пользователей в эксплуатации. Записали договор в справочник, потом поставили отдельным документом на учёт, потом провели накладную, потом провели погашение суммы договора, потом провели закрытие договора. Осталось наложить раздолбайство пользователей и ву-а-ля имеем замечательный бардак. В результате - юристы работают в своей конфигурации, бухгалтера в своей, продавцы в своей, руководство точит ножик всех порезать из-за такой автоматизации, поскольку не видит в своде почти ничего. Самый правильный принцип: "Автоматизация для удобства сотрудников, а не для удобства программеров". Бухгалтеру глубоко фиолетово выбирать договор из справочника или из журнала договоров и там и там запись, а для реализации системы со сложной логикой разница существенна.

39+ а если ещё кто-то внесёт этот договор без участия бухгалтера, например, юрист, то вообще счасце выше крыши.

Я и не думала переживать. Просто (м-м-м) забавно... По поводу конфигураций: отвлекись от 1с... Хотя, не, не надо.

хорошо, без 1С в какой области договор не документ?

42+ знаю только одну: в печи для растопки

Если для тебя модуль это отдельная конфигурация - я не смогу тебе объяснить.

Вона оно как Семёныч! "Если рассматривать отдельный модуль (для договоров) - да, документ, который на выходе становится записью справочника и грузится в бух учет" - вот это как, откуда грузится то? а ещё  тема про 7.7 и количество модулей ограничено. Тогда надо изложить свою мысль внятно, что за модуль имеется в виду? Договор - всюду документ, и только в типовых от 1С запись в справочнике.

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

> Договор - всюду документ, и только в типовых от 1С запись в справочнике. В 1С справочник договоров к договорам имеет очень отдалённое отношение. Фактически это журнал учета договоров, который в прошлом веке реализовывался линованной тетрадкой у секретаря. И не больше.

Мусье! Про "проводку" было сказано (впервые) в . Не надо наговаривать.

А мужики-то не знают! (С)