Упр. учет. Оплаченные документы. Упр. учет. #230774

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

1С++, Табличное поле - типо так наверное

Поподробнее. Табличное поле никогда не использовал. Только запросы. Разные фирмы. Базы ДБФ и скуль. Причем в одной из фирм есть люди, которые работают только с копией. Копия ДБФ. В тех фирмах, где только ДБФ 1С++ не используется. Да и не знаю я, как под ДБФ юзать ++.

И самое забавное, что эта же проблема месяца через три возникнет у меня на 8-ке.

на 8-ке это не проблема

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

УстановитьОтбор, графа отбора, или общий реквизит документа, отвечающий за флажок оплаты документа... прописывать это флаг при проведении оплачивающих документов. Громоздко, конечно...

Работа задним числом.

объясни, что это значит.

насколько я понимаю, это же общее понятие, работа задним числом... что в твоем случае оно означает? Обрабатывать оплаты только текущим числом?

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

Править - не значит перепроводить

не придется. Реквизит, отвечающий за отбор в журнале, не влияет на регистры проведения оплачиваЕМого документа, поэтому в модуле проведения оплачиваЮЩего документа просто  Док.Найти(ОплачиваемыйДок); Док.ЭтотРек="ОплаченЮЛ"; или "ОплаченФЛ" и т.д., и Док.Записать; то же самое сделать в ОбработкаУдаленияПроведения

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

Знал бы ты, сколько у меня реквизитов отбора... Добавление еще одного отбора - это кошмар. Это еще несколько "лишних" реквизитов.

ну сделай справочник тогда... в виде журнала документов.

+ ИспользоватьСписокЭлементов; плюс, можно историю отслеживать

Конфигурация не указана, упомянут Оперативный учет. Исходим из того, чтосистема взаиморасчетов близкая к типовой ТиС. У zzzz - в голове бардак. > И появление в прошлом месяце нового непроплаченного документа откуда в ПРОШЛОМ месяце возьмется непроплаченный документ? вариантов всего три (исходим что сейчас в базе все ОК). 1. __Ввод__ нового документа в прошлый месяц (задним числом) - это ваши проблемы, если вы не поставили учет на фирме. к решению задачи отношения не имеет. 2. __Изменение_ данных задним числом - проблемы ваши, см. п.1 3. __СНЯТИЕ__ оплаты с документа прошлого месяца в текущем времени - для чего это может понадобиться - хз.. ну ладно, пусть будет. если делается п.3 - значит он делается легитимно. По существу задачи - показа "степени оплаты" документов - имхо изврат. как минимум три состояния документа - оплачен, неоплачен, оплачен частично. Изврат потому, что: ЧТО ИЗМЕНИТСЯ ОТ ТОГО ЧТО НА ЭКРАНЕ ПОСТОЯННО будет написано оплачен или неоплачен? что, бухов 60 раз в минуту интересует оплачен документ или нет? НЕ ИНТЕРЕСУЕТ!!! оплачен/неоплачен интересует в МОМЕНТ принятия какого-то решения по этому клиенту/документу. Для принятия решения ПО ДОКУМЕНТУ не надо показывать степень его оплаты 60 раз в минуту. Достаточно показать такую инфу в тот момент, когда бух/финик озаботился вопросом "какие документы оплачены/неоплачены в текущий момент? были неоплачены на 13 часов 10 ноября и т.д.". аналогично по клиенту. Есть убийственный аргумент, который валит таких бухов/автоматизаторов напрочь: - вопрос 1:сколько на экране вы увидите строк про оплаченных/неоплаченных документов? - ответ 1: (например) 30 документов. - вопрос 2: при этом вас не беспокоит, что вы не видите статуса "оплачен/неоплачен" В ДАННЫЙ МОМЕНТ ВРЕМЕНИ у остальных 2843 документов? - ответ2 :  а) не беспокоит (далее вопрос 3). при попытке ответа - я типа могу пролистать вперед-назад и посмотреть - возвращаемся к вопросу/ответу 1 и т.д. до бесконечности...  б) беспокоит. вопрос что вы делаете. ответ - листаю вперед/назад - возвращаемся к вопросу/ответу 1 и т.д. до бесконечности... - вопрос 3: что изменится от того ЧТО В ДАННЫЙ КОНКРЕТНЫЙ МОМЕНТ ВРЕМЕНИ наряду с 2843 доками которых вы не видите, вы не будете видеть текущие 30 доков? ВЫВОД: НИЧЕГО! итого сабж - имитация бухами бурной деятельности, вместо выполнения правильной работы, + потенциально широкие возможности накосячить с отображением статусов... .. если стоит вопрос ОПЕРАТИВНОГО получения статуса оплаты конкретного дока (набора доков) - такой вопрос не возникает 60 раз в минуту - то решается совсем по другому. автоматизаторы печатных машинок... блин... Если интересует момент "отлова" события оплаты документа (с целью выполнения каких либо действий, типа сразу стырить деньги и умотать в Гонолулу) - то это решается по другому. Автоматизаторы печатных машинок блин. Итак: в Прошлом месяце неоткуда (вдруг) взяться непроплаченному документу. > , что если сейчас бух согласен принять деньги, проплаченные авансом за прошлогодний документ, в оплату другого документа, то мне нужно будет внести изменения в прошлогодний документ. Бред. Если на одном документе висит "аванс", а другой документ неоплачен (неоплаченный документ может быть как раньше так и позже авансового документа) - это значит, что оплаты по данным документам и сами документы разнесены по РАЗНЫМ КРЕДИТНЫМ ЛИНИЯМ. при желании перекинуть аванс на неоплаченный документ следует сделать ТЕКУЩИМ ВРЕМЕНЕМ "взаимозачет". Никаких "неоплаченных" доков в прошлых периодах не появляется.

А если оплата "регистрируется" привязкой к документу документа-основания, или проставлением какого-либо реквизита в документа - то да... при попытке перекинуть оплату на другой документ в ПРОШЛОМ МЕСЯЦЕ ДЕЙСТВИТЕЛЬНО ВОЗНИКНУТ (вдруг) непроплаченные документы - кушайте, господа автоматизаторы, ;-) результаты своих автоматизаций... раньше надо думать было...

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

Похвально. Весьма. Вот только прежде чем что либо утверждать про меня, прочитай мои высказывания. Если непонятно, то разъясню. У меня база перепроводится каждую ночь. Мало ли по каким причинам в нее влезли. Если использовать реквизит, то в случае, если база не перепровелась до текущего числа за ночь, возможно неверное отображение. И именно об этом и говорилось в . Не думал, что так непонятно говорю. Вроде все все поняли 8) А то, что конфигурацию не упоминаю, наверно говорит о том что это не ТиС :) И не типовая. Как? Сумма оплаты и отгрузки сейчас выводится (внизу на экране все есть). Не бюджетники. Страховые и юрлица, которые забирают товар по договору. И им потом о долгах напоминать приходится.

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