Спасибо за вариант технологии принятия решения..Я думаю,что постановка ТЗ - это работа ,и что вменяемый Заказчик зто понимает и принимает...Еще раз огромное спасибо за Вашу работу!!
Добрый день. Я начал позже и еще только нагоняю, поэтому не в курсе всей дискуссии по данному вопросу. Однако мне сразу приходит в голову такой вариант решения без дополнительный уточнений: 1. Перемещения делать с признаком, который при проведении отключает проводки. 2. Проводки перемещения формирует в таких случаях только документ Реализации. 3. При перепроведении/изменении Реализации проводки в ней же и меняются. 4. Документы перемещения нужны только для работников склада, что бы они смогли в них проставить отметку какую-то... (товар получен/не получен и т.п.) 5. В перемещении строки с товарами отображать динамически при открытии формы и брать их из связанной реализации. 6. В реализации реализовать всю логику движения со ссылками на "непроводные" документы перемещения. Таким образом перемещения будут некими аналогами счетов фактур при реализации.
Думал об этом. Не красиво, ну вот что-то внутри не дает так сделать. Если бы писал для клиента и были бы сроки - точно так бы и сделал. Но не нравится мне так.
@@chistovpavel Душа не лежит? Согласен. А вот такой вариант? 1. Перемещения создаются обычные с проводками. Но у них так же ставится признак несамостоятельности. 2. Реализация при проведении взводит вспомогательный регистр накопления 3. Перемещения этот регистр минусуют 4. Пользователь руками редактирует перемещение. При проведении количество остатка при указанном наборе аналитик (дата, реализация, номенклатура, склад, количество) начинает отличаться от нуля и проходит отказ на запись/редактирование. 5. Редактируется реализация - меняются данные регистра, в форме документа выводится сообщение, что есть перечень подчиненных перемещений (исправить и их в соответствии? ) Пользователь соглашается и тогда мы пробегаем по ним и правим в соответствии с новыми реалиями. редактирование автоматом не хорошо. Вдруг пользователь реализацию изменил ошибочно?
Предложить отказаться от создания документа перемещения, а в табличной части РТУ указывать склад списания. Можно и автоматом по остаткам подбирать склад и количество.
1. Сделать блокировку на изменения документов перемещения связанные с реализацией остальные не блокировать. 2. При изменений документа реализации мы уже знаем связанные документы и меняем их так как они меняются в зависимости от реализации. 3. Написать логику для проверки таб части реализации и перемещения.
Формировать перемещения обработкой пост фактум, перед закрытием месяца, когда все документы внесены. С возможностью переформировать при изменении ситуации.
Логика решения должна быть изменена. Если кратко то наиболее оптимальное решение это формирование движения перемещения товаров в рамках движения проводок реализации. Формирование печатной формы документа перемещения из документа реализации путём добавления печатной формы. Таким образом в случае автоматического перемещения товаров документ перемещения является виртуальным. По таким случаям необходимо предусмотреть отдельную нумерацию виртуального перемещения или префикс документов и печать после закрытия периода.
А почему бы не сделать контроль остатков при изменении реализации, проверяя остатки на момент перемещения (ДатаРеализации-1сек для раздельных доков/ либо просто ДатаРеализации)? Тогда при изменении задним числом реализации 1с будет проверять - не уйдет ли в минус товар при перемещении ->запрет перепроведения - есть ли изменения в ТЧ товаров, если есть - > сообщать юзеру "В перемещении №хх изменено кол-во товара А, выполните действия ХХХ". Плюс если неужен контроль - выдавать окошко "Подтверждаю ДА/НЕТ" с фиксацией юзера и времени в лог - чтобы потом был крайний, кто поменял документ, а перемещение не перепечатал например и осознанно нажал "ПОДТВЕРЖДАЮ". Т.е. юзер будет видеть все что происходит в 1с наглядно, будет оповещен о изменениях в важных документах, у него будет выбор и история его действий. Плюс запрет минусования остатков.
Почему нельзя сторнировать операции по "начальному" документу, а потом попробовать перепровести "новый" документ, если это возможно (может же не быть остатков нужного товара, например)?
Соглашусь с предыдущим оратором наполовину. Запретить перепроводить документы. Даже я бы сказал запретить редактировать проведенные документы, запретить редактировать и перемещения , все запретить , оставить только возможность удалять
Ну доп. свойство сделать, в котором связать с документом источником. Далее просто проверять, есть ли ссылки на источник, если есть, то менять связанные документы.
Спасибо за вариант технологии принятия решения..Я думаю,что постановка ТЗ - это работа ,и что вменяемый Заказчик зто понимает и принимает...Еще раз огромное спасибо за Вашу работу!!
Добрый день. Я начал позже и еще только нагоняю, поэтому не в курсе всей дискуссии по данному вопросу. Однако мне сразу приходит в голову такой вариант решения без дополнительный уточнений:
1. Перемещения делать с признаком, который при проведении отключает проводки.
2. Проводки перемещения формирует в таких случаях только документ Реализации.
3. При перепроведении/изменении Реализации проводки в ней же и меняются.
4. Документы перемещения нужны только для работников склада, что бы они смогли в них проставить отметку какую-то... (товар получен/не получен и т.п.)
5. В перемещении строки с товарами отображать динамически при открытии формы и брать их из связанной реализации.
6. В реализации реализовать всю логику движения со ссылками на "непроводные" документы перемещения.
Таким образом перемещения будут некими аналогами счетов фактур при реализации.
Думал об этом. Не красиво, ну вот что-то внутри не дает так сделать. Если бы писал для клиента и были бы сроки - точно так бы и сделал. Но не нравится мне так.
@@chistovpavel Душа не лежит? Согласен. А вот такой вариант?
1. Перемещения создаются обычные с проводками. Но у них так же ставится признак несамостоятельности.
2. Реализация при проведении взводит вспомогательный регистр накопления
3. Перемещения этот регистр минусуют
4. Пользователь руками редактирует перемещение. При проведении количество остатка при указанном наборе аналитик (дата, реализация, номенклатура, склад, количество) начинает отличаться от нуля и проходит отказ на запись/редактирование.
5. Редактируется реализация - меняются данные регистра, в форме документа выводится сообщение, что есть перечень подчиненных перемещений (исправить и их в соответствии? )
Пользователь соглашается и тогда мы пробегаем по ним и правим в соответствии с новыми реалиями.
редактирование автоматом не хорошо. Вдруг пользователь реализацию изменил ошибочно?
Запретить перепроводить документы. Оставить возможность только создавать новые, а исправлять возвратом.
Предложить отказаться от создания документа перемещения, а в табличной части РТУ указывать склад списания. Можно и автоматом по остаткам подбирать склад и количество.
1. Сделать блокировку на изменения документов перемещения связанные с реализацией остальные не блокировать.
2. При изменений документа реализации мы уже знаем связанные документы и меняем их так как они меняются в зависимости от реализации.
3. Написать логику для проверки таб части реализации и перемещения.
Формировать перемещения обработкой пост фактум, перед закрытием месяца, когда все документы внесены. С возможностью переформировать при изменении ситуации.
Большое спасибо за видео.
Логика решения должна быть изменена. Если кратко то наиболее оптимальное решение это формирование движения перемещения товаров в рамках движения проводок реализации. Формирование печатной формы документа перемещения из документа реализации путём добавления печатной формы. Таким образом в случае автоматического перемещения товаров документ перемещения является виртуальным. По таким случаям необходимо предусмотреть отдельную нумерацию виртуального перемещения или префикс документов и печать после закрытия периода.
А почему бы не сделать контроль остатков при изменении реализации, проверяя остатки на момент перемещения (ДатаРеализации-1сек для раздельных доков/ либо просто ДатаРеализации)?
Тогда при изменении задним числом реализации 1с будет проверять
- не уйдет ли в минус товар при перемещении ->запрет перепроведения
- есть ли изменения в ТЧ товаров, если есть - > сообщать юзеру "В перемещении №хх изменено кол-во товара А, выполните действия ХХХ". Плюс если неужен контроль - выдавать окошко "Подтверждаю ДА/НЕТ" с фиксацией юзера и времени в лог - чтобы потом был крайний, кто поменял документ, а перемещение не перепечатал например и осознанно нажал "ПОДТВЕРЖДАЮ".
Т.е. юзер будет видеть все что происходит в 1с наглядно, будет оповещен о изменениях в важных документах, у него будет выбор и история его действий. Плюс запрет минусования остатков.
Почему нельзя сторнировать операции по "начальному" документу, а потом попробовать перепровести "новый" документ, если это возможно (может же не быть остатков нужного товара, например)?
Соглашусь с предыдущим оратором наполовину. Запретить перепроводить документы. Даже я бы сказал запретить редактировать проведенные документы, запретить редактировать и перемещения , все запретить , оставить только возможность удалять
Если в задаче есть условие программного формирования перемещений, тогда просто включаем Скайнет + запись в текстовый файл протокола изменений.
Ну доп. свойство сделать, в котором связать с документом источником. Далее просто проверять, есть ли ссылки на источник, если есть, то менять связанные документы.
Вообще конечно перемещениями должны заниматься кладовщики, а реализациями - бухгалтера.
да, действительно не решаемая задача