По теме из базы знаний
- Различия в механизме оперативного проведения документов в версиях платформы 8.1 и 8.2
- Правила переноса данных из Бухгалтерия бюджетного учреждения, редакция 1.0 (ББУ 1.0.22.2) в Бухгалтерия государственного учреждения, редакция 1.0 (БГУ 1.0.8.2/1.0.7.2/1.0.6.3), исправленные и дополненные (BBU8_BGU8.xml) + обработки подготовки базы данных
- Проведение документа будущей датой для КА, УПП, УТ, УТ 11, КА 2, ЕРП 2 (неоперативное проведение) из формы самого документа.
- Проведение будущей датой (обычное приложение)
- Проблема производительности. Как может заблокировать работу в ERP один-единственный документ от 01.01.2099 года?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Есть ограничения логики работы платформы: регистр остатков без указания даты предполагает остатки на текущий момент (на этом построены все отчеты, а реально берет _последние_ остатки. Считается, что последние = текущие, но если разрешить проведение "будующем", то это будет уже не так - кто-то что-то спишет 2020 годом и все - правильная отчетность воссановится только через 8 лет. Самый простой способ: в нужные документы добавить свой реквизит (категорию), проводить их как есть, но с данным реквизитом, а при первом запуске в день у них всех изменять дату и перепроводить, а реквизит снимать. Или нужна только правильная дата в накладных? - тогда все еще проще - только подменять дату в печатной форме (хотя я бы все равно в сам документ добавил новое поле ДатаНакладной, которое бы и печатал - по крайней мере не получил бы неожиданностей с расчетом остатков, партиями и бухгалтерией.
8-ке документ будущей датой по умолчанию не проводится. Небольшая независимая от остального кода заплатка в форму документа решит эту проблему Автор статьи: Гений 1С | Редакторы: evGenius
Последняя редакция №5 от 28.05.07
Ключевые слова: будущая,дата,проведение,документ,оперативный,неоперативный
Суть метода - в том, чтобы при установке в форме будущей даты режим проведения документа менялся автоматически на неоперативный и возвращался обратно в автоматический при установке нормальной даты.
Вызов обработчика в режиме Данные="" происходит при открытии формы, при этом нужно также контролировать дату. Т.е. например пользователь сохранил документ будущей датой, потом его открыл и не меняя даты проводит.
В модуль формы документа добавляется процедура:
Код 1c:
Процедура п_ОбработчикИзмененияДаты(Данные)
Если Данные="ДокументОбъект.Дата" ИЛИ Данные="" Тогда
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
В самый конец модуля формы добавляется строчка:
Код 1c:
ПодключитьОбработчикИзмененияДанных("Дата","ОбработчикИзмененияДаты");
Вот и все.
Я было подумал, что если просто добавить в конец формы строку включения автоматического режима, то проведение будущей датой будет работать нормально, но ничего подобного, нужна именно моя схема, такая строка не дает ничего для проведения будущей датой:
Код 1c:
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Авто;
Некоторым ленивым программистам можно порекомендовать вставлять проверку в метод ПередЗаписью формы, чтобы не подключать лишние обработчики, видимо так оно проще:
Код 1c:
Процедура ПередЗаписью()
....
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
....
КонецПроцедуры
Последняя редакция №5 от 28.05.07
Ключевые слова: будущая,дата,проведение,документ,оперативный,неоперативный
Суть метода - в том, чтобы при установке в форме будущей даты режим проведения документа менялся автоматически на неоперативный и возвращался обратно в автоматический при установке нормальной даты.
Вызов обработчика в режиме Данные="" происходит при открытии формы, при этом нужно также контролировать дату. Т.е. например пользователь сохранил документ будущей датой, потом его открыл и не меняя даты проводит.
В модуль формы документа добавляется процедура:
Код 1c:
Процедура п_ОбработчикИзмененияДаты(Данные)
Если Данные="ДокументОбъект.Дата" ИЛИ Данные="" Тогда
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
КонецЕсли;
КонецПроцедуры
В самый конец модуля формы добавляется строчка:
Код 1c:
ПодключитьОбработчикИзмененияДанных("Дата","ОбработчикИзмененияДаты");
Вот и все.
Я было подумал, что если просто добавить в конец формы строку включения автоматического режима, то проведение будущей датой будет работать нормально, но ничего подобного, нужна именно моя схема, такая строка не дает ничего для проведения будущей датой:
Код 1c:
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Авто;
Некоторым ленивым программистам можно порекомендовать вставлять проверку в метод ПередЗаписью формы, чтобы не подключать лишние обработчики, видимо так оно проще:
Код 1c:
Процедура ПередЗаписью()
....
Если Дата>ТекущаяДата() Тогда
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.НеОперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения=ИспользованиеРежимаПроведения.Оперативный;
КонецЕсли;
....
КонецПроцедуры
В 1С для подобных вещей есть ордерная схема: Реализация по ордеру не меняет остатки товара, но уменьшает свободные остатки, а снятие товара делается расходным ордером. Вторая альтернатива - через заказы/резервирование.
Соответствующие отчеты покажут что есть, что "продано но не отгружено" и т.д.
Соответствующие отчеты покажут что есть, что "продано но не отгружено" и т.д.
Ордерная схема тоже не совсем подходит.
Я делал следующую схему.
Оператор проводит документ текущим числом времени. В проведенном документе меняет дату "на завтра" и с помощью метода описанном в посте №11 спец. обработкой проводил документ.
Правда еще дописал, чтобы корректировалась дата в с/ф
Я делал следующую схему.
Оператор проводит документ текущим числом времени. В проведенном документе меняет дату "на завтра" и с помощью метода описанном в посте №11 спец. обработкой проводил документ.
Правда еще дописал, чтобы корректировалась дата в с/ф
"А сегодня, в завтрашний день, не все могут проводить. Вернее проводить могут не только лишь все, мало кто может это сделать."
Бред какой-то. Причем здесь отгрузка и дата накладной ? Дата накладной это дата когда выписана накладная и ничего больше. В ТОРГ-12 если посмотреть внимательно. то можно увидеть, что есть отдельные поля для указания даты накладной, даты отгрузки и даты приемки покупателем, т.к. это все разные дат. Накладная выписана сегодня, товар по ней отгружен завтра, покупателю доставлен послезавтра. Именно так и делается. Для того, чтобы в базе были сведения о том, что отгружено, а что нет есть масса шататных средств - в УТ10 ордерная схема, в УТ11 или ордерная схема или более простой вариант - статусы документа реализация.
Собственно решение:
1. В свойствах документа запретите оперативное проведение (обновляется динамически)
2. Если проведение было завязано на оперативное/неоперативное, то поправить код...
Всё!
1. В свойствах документа запретите оперативное проведение (обновляется динамически)
2. Если проведение было завязано на оперативное/неоперативное, то поправить код...
Всё!
этой проблемой мучаются все хлебокомбинаты, молокозаводы и ежеси ... кто вечером готовит накладные а утром следующего дня развозят...
... сначало записывают потом печатают потом отпускают потом проводят ...
... воОоттАкиЕуВсЕхпрОблЕмы ...
... сначало записывают потом печатают потом отпускают потом проводят ...
... воОоттАкиЕуВсЕхпрОблЕмы ...
А если нужны реальные остатки, Пример
Мы делаем кучу документов и всех остатков на складе не помним, потом когда начнем проводить что то не будет хватать, по этому нужно проводить каждый документ что бы можно было получать постояно реальные остатки.
Мы делаем кучу документов и всех остатков на складе не помним, потом когда начнем проводить что то не будет хватать, по этому нужно проводить каждый документ что бы можно было получать постояно реальные остатки.
... тогда будет куча гемора... что взяли ... что-то не взяли кто-то опоздал у кого-то машина сломалась и т.д. и реальных остатков всЁ одно не увидишь...
ищите хорошего кладовщика...
это ВОООбще проблема...
вОт...
ищите хорошего кладовщика...
это ВОООбще проблема...
вОт...
Я вообще тогда не понимаю, как разработчики этой УТ делают так что бы он давал проводить товар которого нет на складе, стоит только дату поставить на день позже и все пошел минисуном, это что полочается, что бы программа сама контролировала остатки нужно обязательно проводить его сегоднейшей датой???
AVARY
Там проблема в другом.
Пример: Мы выписываем товар стоит сегодняйшая дата, при проведение он выдает сообщение не хватает 3 штук, все нормально так и должно быть, теперь ставим дату вчерашнюю, нажимаем провести и документ как ни в чем не бывало проводить его при этом товар падает в минус. Что с этим делать?
Там проблема в другом.
Пример: Мы выписываем товар стоит сегодняйшая дата, при проведение он выдает сообщение не хватает 3 штук, все нормально так и должно быть, теперь ставим дату вчерашнюю, нажимаем провести и документ как ни в чем не бывало проводить его при этом товар падает в минус. Что с этим делать?
(14) Илья, все очень просто: надо четко себе представлять, что МАШИНЫ ВРЕМЕНИ НЕ БЫВАЕТ! и назад во вчера вернуться не удастся. То, что такая возможность есть в 1Ске - это копромисс, для того чтобы тупые быдломанагеры и быдлобухгалтеры делали свою быдлоработу.
. рассмотрим 1 вариант.
проводим документ вчерашней датой, за период вчера-сегодня в базе наколотили туеву хучу доков, много разных движений, перемещений, инвентаризаций складов и прочее. ты хочешь, чтобы при проведении документа вчерашней датой это все обсчиталось в течение 10-15 минут и при этом вся организация нервно курила бамбук из-за того, что мудак не вовремя ВЧЕРА не сделал документ?
. рассмотрим 2 вариант.
совсем простой: КАК ТОВАР может уйти в минус? например: все ок, все пучком, приехали клиенты, забрали свой товар с накладными, колво штук товара = 2 шт НА СКЛАДЕ РЕАЛЬНО ОСТАЛОСЬ. Ни у кого никаких вопросов. причем эти 2 штуки РЕАЛЬНО УЧИТЫВАЮТ товар, на который документ не выписан (ну забыл быдломанагер), но товар со склада реально вчера ушел. Теперь спохватились и выписываем вчерашней датой док на 5 штук (которые ВЧЕРА клиент реально забрал). Товар "на сейчас" мгновенно превращается в -3 шт.
Вопрос: где косяк? -3 штуки быть не молжет.. ответ - косяк в расхождении между учетными данными и реальными... - это я привел еще самый упрощенный утрированный вариант.
вдогонку: в нормальной "конторе" если товар ушел, но доки не выписаны - товар БУДЕТ ВЕСЕТЬ В "РЕЗЕРВЕ" и не даст себя продать в другую реализацию...
..
все.. что неясного?
. рассмотрим 1 вариант.
проводим документ вчерашней датой, за период вчера-сегодня в базе наколотили туеву хучу доков, много разных движений, перемещений, инвентаризаций складов и прочее. ты хочешь, чтобы при проведении документа вчерашней датой это все обсчиталось в течение 10-15 минут и при этом вся организация нервно курила бамбук из-за того, что мудак не вовремя ВЧЕРА не сделал документ?
. рассмотрим 2 вариант.
совсем простой: КАК ТОВАР может уйти в минус? например: все ок, все пучком, приехали клиенты, забрали свой товар с накладными, колво штук товара = 2 шт НА СКЛАДЕ РЕАЛЬНО ОСТАЛОСЬ. Ни у кого никаких вопросов. причем эти 2 штуки РЕАЛЬНО УЧИТЫВАЮТ товар, на который документ не выписан (ну забыл быдломанагер), но товар со склада реально вчера ушел. Теперь спохватились и выписываем вчерашней датой док на 5 штук (которые ВЧЕРА клиент реально забрал). Товар "на сейчас" мгновенно превращается в -3 шт.
Вопрос: где косяк? -3 штуки быть не молжет.. ответ - косяк в расхождении между учетными данными и реальными... - это я привел еще самый упрощенный утрированный вариант.
вдогонку: в нормальной "конторе" если товар ушел, но доки не выписаны - товар БУДЕТ ВЕСЕТЬ В "РЕЗЕРВЕ" и не даст себя продать в другую реализацию...
..
все.. что неясного?
Добавляешь печатную формы с примерно таким кодом
Объект.Записать(РежимЗаписиДокумента.Проведения,РежимПроведенияДокумента.Неоперативный);
А насчет отсутствия контроля остатков при неоперативном учете в 1с тут много чего сказано и моя программерская часть личности с этим согласна... Ибо нельзя проводить товар на будущее, нельзя исправлять документы задним числом и т.д. Моя же бухгалтерская и финансовая сущность говорят о том, что не те основы были заложены в основу партионного учета в 1с... Всё-таки нужно было больше с практиками советоваться на начальных этапах разработки. Сейчас мы имеем систему, в которой нужно выбирать или-или. Или имеем четкий партионный учет и грамотных операторов, которые понимают что и зачем они делают, портативный терминал ввода данных у кладовщика, аккуратных сборщиков и упаковщиков и трезвых неслепых грузчиков. Или постоянные "отрицательные" партии, "плавующие" партии и стандартный персонал. Ну или просто ввести систему автоматизированого склада (:
Объект.Записать(РежимЗаписиДокумента.Проведения,РежимПроведенияДокумента.Неоперативный);
А насчет отсутствия контроля остатков при неоперативном учете в 1с тут много чего сказано и моя программерская часть личности с этим согласна... Ибо нельзя проводить товар на будущее, нельзя исправлять документы задним числом и т.д. Моя же бухгалтерская и финансовая сущность говорят о том, что не те основы были заложены в основу партионного учета в 1с... Всё-таки нужно было больше с практиками советоваться на начальных этапах разработки. Сейчас мы имеем систему, в которой нужно выбирать или-или. Или имеем четкий партионный учет и грамотных операторов, которые понимают что и зачем они делают, портативный терминал ввода данных у кладовщика, аккуратных сборщиков и упаковщиков и трезвых неслепых грузчиков. Или постоянные "отрицательные" партии, "плавующие" партии и стандартный персонал. Ну или просто ввести систему автоматизированого склада (:
(19)Как будто у наших операторов научились... Блин, как что-то нахимичить у операторов мозгов хватает, а сообщение прочитать, которое админ написал...всё, алес... kernel panic и BSOD в обоих глазах. Вообще, это работает по тому же принципу, что сказано в (17). При такой операции с документ проводиться в неоперативном режиме.
У нас услуги. Поэтому проверять товарные остатки не имеет смысла. Я вставляю такой код в форму документов.
Процедура ДатаПриИзменении(Элемент)
...
Если НачалоДня(Дата) <> НачалоДня(ТекущаяДата()) Тогда
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Неоперативный;
ИначеЕсли ЭтоНовый() Тогда
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Оперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Авто;
КонецЕсли;
КонецПроцедуры
Процедура ПриОткрытии()
...
Если НачалоДня(Дата) <> НачалоДня(ТекущаяДата()) Тогда
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Неоперативный;
ИначеЕсли ЭтоНовый() Тогда
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Оперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Авто;
КонецЕсли;
КонецПроцедуры
Показать
Тогда уж
Процедура ДатаПриИзменении(Элемент)
...
ОбновитьРежимПроведения();
КонецПроцедуры
Процедура ПриОткрытии()
...
ОбновитьРежимПроведения();
КонецПроцедуры
Процедура ОбновитьРежимПроведения()
Если НачалоДня(Дата) <> НачалоДня(ТекущаяДата()) Тогда
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Неоперативный;
ИначеЕсли ЭтоНовый() Тогда
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Оперативный;
Иначе
ЭтаФорма.ИспользоватьРежимПроведения = ИспользованиеРежимаПроведения.Авто;
КонецЕсли;
КонецПроцедуры
Показать
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот