Имя: Пароль:
1C
1C 7.7
v7: Как отловить отказ от сохранения и отказ от проведения документа
0 LisaAlisa
 
20.06.17
19:19
При записи документа, нужно выполнить некоторые действия с подчиненными документами. Использую процедуру ПриЗаписи(). Она выполняется по кнопке "Записать". Если пользователь её нажимает, все отлично.
Но есть еще кнопка "Провести". Если пользователь нажал сразу ее (без предварительной записи документа) и на вопрос программы о проведении - ответил НЕТ, то действия из процедуры ПриЗаписи() уже отработали - подчиненные документы изменились, исходный документ внешне тоже изменился, но при закрытии выдает сообщение "Сохранить документ?", пользователь снова указывает "нет", тогда исходный документ возвращается к первоначальному состоянию, а при этом подчиненные документы уже были сохранены (перед попыткой проведения). Как отловить этот отказ от сохранения и вернуть подчиненные документы в первоначальный вид?
1 Злопчинский
 
20.06.17
19:37
Очевидно, что подчинённые документы надо отрабатывать после успешного проведения и не надо ловить всякие отказы
???
2 GreyK
 
20.06.17
19:41
(0) Повесь на кнопку "провести" и "ОК" процедуру, которая сделает всё правильно.
3 Злопчинский
 
20.06.17
19:44
Проводи по кнопке ок не интерактивно а впрямую, програмно и делай что хочешь
4 LisaAlisa
 
20.06.17
19:45
а если пользователь Сохранил, но не провел документ, тогда подчиненные не изменятся... Не знаю, насколько это правильно, но теоретически заказчик может это потребовать
5 Злопчинский
 
20.06.17
19:45
хотя будут глюки если впрямую через форму работать
6 LisaAlisa
 
20.06.17
19:45
иными словами, если заказчик потребует изменения подчиненных именно при сохранении документа, а не при проведении
7 GreyK
 
20.06.17
20:10
(6) Тут два варианта, первый просто при сохранении документа, а второй при сохранении проведенного документа, научитесь разбирать эти разные события.
8 Злопчинский
 
20.06.17
22:27
(6) заказчик может требовать что угодно. настоящий прог будет делать ПРАВИЛЬНО - чтобы обеспечить непротиворечивость данных. если заказчик настаивает на кривом решении которое потенциально не дает гарантии вменяемой нормального состояния связанных данных - тогда подробно обсуждать что именно в какой момент делается. иначе потом обвинят во всех смертных грехах
9 ndv76
 
21.06.17
06:13
Изменяй подчиненные документы не ПриЗаписи, а ПриПроведении.
10 Масянька
 
21.06.17
08:37
(6) Заказчику нужно объяснить (желательно на русском литературном), что это неправильно.
Сохранить док-т - ни о чем. Именно, при проведении док-т попадает в учет. (ну, как-то так)
11 trdm
 
21.06.17
08:43
(6) > иными словами, если заказчик потребует изменения подчиненных именно при сохранении документа, а не при проведении.
Проектирование поведения системы - не его епархия.
12 Fedor-1971
 
21.06.17
09:47
(6) задай вопрос заказчику "Что делать при отказе от сохранения документа?" и по ответу узнаешь что делать: свою процедуру сохранения на обе кнопки "ОК" и "Записать" (как в 2) или переносить логику в проведение

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

(11) другими словами - "Заказчик не знает что он хочет?" Тебе выдали задание, сделай "так и так", техника дела - твоя епархия, логика "что, где и когда" - дело заказчика. Предупреждение: "будут вот такие проблемы, можем решить так" снятие гемора с себя и отдача его заказчику для принятия решения
13 Масянька
 
21.06.17
09:51
(12) "Например, договор с фиксацией параметров, но без движений в учётной системе (проводок нет, а документ есть) " - расшифруй.
14 Ёпрст
 
21.06.17
09:56
(0)Будь проще. Проверяй значимые реквизиты документа в ПриЗакрытии, если оне изменились, задавай вопрос пользователю - "Изменились важные реквизиты дока, пересчитать подчиненные ? да/нет".. и усё. если ответит утвердительно - пересчет подчиненного.
15 Fedor-1971
 
21.06.17
10:08
(13) Заказчик хочет документ "Договор" с некими параметрами и заковыристой печатной формой. Сии параметры используются далее в других документах. Используется документ (а не справочник) из-за автонумерации по определённым правилам и требованию заказчика (видишь бывают и такие, которые хотят именно "документ" и "при сохранении").
Документ не проводится, но в учёт попадает (как единица учётной системы).
Так что, в учёт документ попадает не только при проведении, но и при сохранении
16 Масянька
 
21.06.17
10:34
(15) Я правильно поняла: договор - документ?
17 Fedor-1971
 
21.06.17
10:36
(16) да, кроме нумерации непонятна логика использования объекта "документ", может планировались некие проводки, но следов не осталось, а документ есть и встроен в систему
18 vcv
 
21.06.17
10:38
(16) А что, договор - это не документ?
По хорошему, договор создаваться, редактироваться, пролонгироваться документами в учетной системе. Справочник устроен для простоты. При более-менее сложной работе с договорами справочник неуправляем совершенно.
19 Масянька
 
21.06.17
10:40
(17) И какие проводки может делать договор?
(16) По сути - документ. А по по-эсному - справочник. И в чем "не управляем"?
20 vcv
 
21.06.17
10:55
А как им управлять? Как на справочнике строить учет жизни договоров? Есть договор. У него срок действия. Срок закончился, договор нужно пролонгировать.
- Сформировать доп.соглашение с указанием даты, до которой будет действовать договор
- Отправить доп.соглашение клиенту
- Получить скан по почте и изменить фактический срок действия договора
- Не забыть вытрясти с клиента доп.соглашение с синей печатью
- Получить отчетность, какие договора истекают, какие пролонгировались, всё ли нормально с предоставлением оригиналов и так далее...
Всё это хорошо строить на документах. Справочник даёт нам только одно - факт наличия договора с такими-то реквизитами для печати на документах. На большее он слабо способен.
21 vcv
 
21.06.17
10:58
+(20) Можно, конечно, стоить на справочнике учет объектов, которые являются документами по своей сути. Но ограниченное по своим возможностям решение.
22 Масянька
 
21.06.17
11:01
(20) "Есть договор. У него срок действия. Срок закончился, договор нужно пролонгировать. " - и как это реализовано в док-ах?
23 Fedor-1971
 
21.06.17
11:29
(19) Например, ограничение по сумме на забалансе. Договор имеет предел суммы, например, 2000$, в Дт ставим сумму, другие документы её гасят с контролем "Перелезли лимит - нет"

(20) собственно, по возможностям примерно равные решения, только документ имеет нумератор и может проводиться, а справочник нет. Для 8 мало критичные различия, для 7 возможно, что "документ" несколько предпочтительнее если нужна логика кроме хранения
24 Масянька
 
21.06.17
11:31
(23) То есть договор меняет сумму в проводках? Или как?
25 Fedor-1971
 
21.06.17
11:34
(24) может иметь, зависит от типа.
Договор на поставку, например, окон в кол-ве Н шт, на сумму МНОГО рублей лимит имеет, а договор связи нет, абонплата до расторжения
26 Масянька
 
21.06.17
11:36
(25) Не понял...
27 Fedor-1971
 
21.06.17
11:38
(26) Контроль суммы договора редко встречающаяся задача? для 7 удобное решение на бух проводках
28 Масянька
 
21.06.17
11:41
(27) Почему редкое? Далеко не редкое. Только при чем тут документы? Бух проводки - далеко не удобное решение.
Кроме, того, помимо суммы договора, прописана номенклатура (в договоре). Разная, по разным цене и количеству. И опять - при чем тут док-ты?
29 Fedor-1971
 
21.06.17
12:00
(28) при том, что в 7 "объект Документ" это единственное что может создать программируемые движения и если необходимо реализовать логику учёта, то собственно делаем вид документа с названием "Договор" и прописываем логику его движения.

Справочник с периодическими реквизитами не обеспечит гибкости движений документа

Бух проводки - одно из возможных решений по фиксации движений "Договора" (может и не слишком оптимальное, за то очень понятное бухгалтеру)
30 Масянька
 
21.06.17
12:05
(29) Есть договор. В нем прописана сумма "10 000 руб" и номенклатура: флешка1 = 10 шт по 200 руб, флешка2 = 10 шт по 300 руб, флешка3 = 10 шт по 500 руб.
Договор подписан.
Флешки 1 и 2 есть в наличии (сегодня), флешка 3 будет через 2 дня. Клиент хочет по данному договору забрать флешки 1 и 2 сегодня, а флешки 3 - по поступлению на склад (то бишь - через2 дня).
Покажи схему "договор = документ".
31 Fedor-1971
 
21.06.17
12:06
29+ Суть разговора "Что лучше Справочник или Документ?" примерно соответствует "Что лучше Пирожное или Торт?" и ответ одинаков "смотря для чего". Если угостить много людей и нет ножа - пирожное, если кому-то в лицо запилить надо - торт побеждает с большим преимуществом (не разделится на составляющие в самый ответственный момент, хотя и пирожными можно обойтись и кидаться ими удобнее, поскольку имеется много в наличии)
32 Масянька
 
21.06.17
12:11
(31) Суть разговора в том, что не нужно изобретать велописед.
В любой учетной программе (даже не 1С) - договор = справочник. Не зря, видимо, так сделали.
33 Fedor-1971
 
21.06.17
12:11
(30)Схема:
документ Договор №1: должны нам товара на 10 000
документ накладная: По договору №1 получили на 5 000 (первые 2 флешки) сегодня
документ накладная: По договору №1 получили на 5 000 (три оставшиеся флешки как придут на склад)

Отчёт по договорам показывает недопоставку
Оплата по накладным

На вскидку, примерно так.
34 Масянька
 
21.06.17
12:15
(33) "документ Договор №1: должны нам товара на 10 000 " - чего?
Смысл "Документ Договор" так и не ясен...
35 Fedor-1971
 
21.06.17
12:24
(32) в любой типовой, т.к. не предполагает ни какой надстроенной логики. Для 90% организаций такой реализации достаточно, потому 1С не заморачивается.
Зарегистрировали договор, максимум валюту учли и всё. К стати многовалютный договор, т.е. работа по которому может идти в USD, EUR и RUB в типовых представляется 3 записями. Вопрос "Зачем?" в такой ситуации пишется в несколько слов, особенно когда бухи их путают или хотят получить данные по договору в целом (во всех валютах, а записей 3).

(34) смысл реализации на базе объекта документ: в осуществлении дополнительного контроля, например, за суммой (нам всё поставили или нет), но есть и вторая сторона для договора поставки от нас клиенту (а чего это вдруг с нас требуют товара на сумму большую чем в договоре).
36 Масянька
 
21.06.17
12:30
(35) Я тебе говорила не только про 1С. Но видимо - зря.
"смысл реализации на базе объекта документ" (как и прочее) - все спокойно реализуется без дописки нового док-та.
Повторюсь - не надо изобретать велописед.
37 vcv
 
21.06.17
12:36
(34) > Смысл "Документ Договор" так и не ясен...
Для бухгалтера смысла нет. Ровно так же, как и нет смысла в сущности "документ реализация". Обходились же бухгалтера до 1С 7.7 совершенно естественными для них понятиями проводка и операция. Документ вообще в бухучете понятие необязательное.
Бухгалтерии хватает записи о регистрации договора. Справочник их потребности покрывает с запасом.
А вот если нам требуется учет договоров, если договора еще не дойдя до бухгалтерии проходят целый жизненный цикл подготовки, согласования, подписания, регистрации и всего прочего - без документа становится грустно.
38 Масянька
 
21.06.17
12:44
(37) "А вот если нам требуется учет договоров, если договора еще не дойдя до бухгалтерии проходят целый жизненный цикл подготовки, согласования, подписания, регистрации и всего прочего - без документа становится грустно." - это отдельный модуль, который, кстати, для бух учета абсолютно не важен, поскольку в бух учет договор попадает после "целого жизненного цикла" в качестве записи справочника :)
Если рассматривать отдельный модуль (для договоров) - да, документ, который на выходе становится записью справочника и грузится в бух учет.
39 Fedor-1971
 
21.06.17
12:54
(36) да, не переживай, когда будешь реализовывать логику в 7 над договором (многовалютность, суммы, периоды, статусы и т.д.), тогда и вспомнишь про сей разговор и для себя примешь решение Справочник/Документ.

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

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

(38) В результате - юристы работают в своей конфигурации, бухгалтера в своей, продавцы в своей, руководство точит ножик всех порезать из-за такой автоматизации, поскольку не видит в своде почти ничего.
Самый правильный принцип: "Автоматизация для удобства сотрудников, а не для удобства программеров". Бухгалтеру глубоко фиолетово выбирать договор из справочника или из журнала договоров и там и там запись, а для реализации системы со сложной логикой разница существенна.
40 Fedor-1971
 
21.06.17
12:57
39+ а если ещё кто-то внесёт этот договор без участия бухгалтера, например, юрист, то вообще счасце выше крыши.
41 Масянька
 
21.06.17
12:57
(39) Я и не думала переживать.
Просто (м-м-м) забавно...
По поводу конфигураций: отвлекись от 1с... Хотя, не, не надо.
42 Fedor-1971
 
21.06.17
12:59
(41) хорошо, без 1С в какой области договор не документ?
43 Fedor-1971
 
21.06.17
13:01
42+ знаю только одну: в печи для растопки
44 Масянька
 
21.06.17
13:05
(42) Если для тебя модуль это отдельная конфигурация - я не смогу тебе объяснить.
Пилите, Шура, пилите (С)
45 Fedor-1971
 
21.06.17
13:20
(44) Вона оно как Семёныч!
"Если рассматривать отдельный модуль (для договоров) - да, документ, который на выходе становится записью справочника и грузится в бух учет" - вот это как, откуда грузится то? а ещё  тема про 7.7 и количество модулей ограничено. Тогда надо изложить свою мысль внятно, что за модуль имеется в виду?

Договор - всюду документ, и только в типовых от 1С запись в справочнике.
46 vcv
 
21.06.17
13:21
(38) > это отдельный модуль, который, кстати, для бух учета абсолютно не важен

Про бухучет вы, леди, первой заговорили, если я ничегоь не пропустил. Автор об этом и не заикался. А вдруг у него бухучета и нет там вовсе...
47 vcv
 
21.06.17
13:24
(45) > Договор - всюду документ, и только в типовых от 1С запись в справочнике.

В 1С справочник договоров к договорам имеет очень отдалённое отношение. Фактически это журнал учета договоров, который в прошлом веке реализовывался линованной тетрадкой у секретаря. И не больше.
48 Масянька
 
21.06.17
13:29
(46) Мусье! Про "проводку" было сказано (впервые) в (12).
Не надо наговаривать.
49 Масянька
 
21.06.17
13:29
(45) А мужики-то не знают! (С)
Программист всегда исправляет последнюю ошибку.