как лучше реализовать фиктивную сумму документа
Добрый день.
У одного из заказчиков возникла задача. Конфигурация КА, ERP - не столь важно.
В документе "Заказ клиента" (и нескольких других) необходимо реализовать хранение фиктивных документов, которые будут нужны только для распечатки. При этом по реальным суммам будут происходить взаиморасчеты.
Например, позвонил клиент и попросил выписать документы на сумму 1000, при этом реальная стоимость заказанных товаров 900. Ну и далее с разницей в 100 нужно будет выполнять различные манипуляции - брать % и т.д.
Хочется реализовать с минимальными доработками типовой. Есть идея сделать фиктивный документ подчиненным основном, а в форму основного выводить выборочные реквизиты подчиненного.
Плюсы решения - минимальные доработки документа Заказ, минусы - документ нужно сохранить прежде чем можно будет вводить фиктивные данные.
Может у кого-то было что-то подобное. Поделитесь идеями.
У одного из заказчиков возникла задача. Конфигурация КА, ERP - не столь важно.
В документе "Заказ клиента" (и нескольких других) необходимо реализовать хранение фиктивных документов, которые будут нужны только для распечатки. При этом по реальным суммам будут происходить взаиморасчеты.
Например, позвонил клиент и попросил выписать документы на сумму 1000, при этом реальная стоимость заказанных товаров 900. Ну и далее с разницей в 100 нужно будет выполнять различные манипуляции - брать % и т.д.
Хочется реализовать с минимальными доработками типовой. Есть идея сделать фиктивный документ подчиненным основном, а в форму основного выводить выборочные реквизиты подчиненного.
Плюсы решения - минимальные доработки документа Заказ, минусы - документ нужно сохранить прежде чем можно будет вводить фиктивные данные.
Может у кого-то было что-то подобное. Поделитесь идеями.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Что-то вообще непонятная ситуация. Вам клиент просто аванс вносит? Или он сам выбрал товары, магическим образом посчитал стоимость и эту инфу сообщил вам? Я бы посмотрел в сторону функционала сделок с клиентами: в самой сделке указываете вашу "фиктивную" сумму, а дальше уже по сделке оформляете документы на реальную сумму
Например, позвонил клиент и попросил выписать документы на сумму 1000, при этом реальная стоимость заказанных товаров 900.
Что-то вообще непонятная ситуация. Вам клиент просто аванс вносит? Или он сам выбрал товары, магическим образом посчитал стоимость и эту инфу сообщил вам? Я бы посмотрел в сторону функционала сделок с клиентами: в самой сделке указываете вашу "фиктивную" сумму, а дальше уже по сделке оформляете документы на реальную сумму
(10) Вы не работали в 90-х? Сисадмин звонит в ИТ-контору и говорит - мне нужен комп и накиньте 10%. Приходит счет, работодатель оплачивает счет, потом сисадмин идет в ИТ-контору и делит эти 10% из черной кассы с менеджером по договоренности.
Это черные сделки, не пытайтесь их положить на белый учет )))
Это черные сделки, не пытайтесь их положить на белый учет )))
(11) Не, в 90х еще сидел за школьной партой)))
Тем не менее сделки хранятся в справочнике и позволяют:
1) указать сумму, которая в рег.учете не будет участвовать
2) объединить документы по сделке, что упростит создание необходимого отчета
Ну и, естественно, грозим пальцем и всячески осуждаем черную бухгалтерию!)
Тем не менее сделки хранятся в справочнике и позволяют:
1) указать сумму, которая в рег.учете не будет участвовать
2) объединить документы по сделке, что упростит создание необходимого отчета
Ну и, естественно, грозим пальцем и всячески осуждаем черную бухгалтерию!)
Алгоритм такой:
Вариант 1.
1) Заводят документ на фиктивную сумму
2) Сохраняют печатную форму.
3) Прикрепляют сохраненный файл к документу.
4) Меняют документ на реальную сумму.
Вариант 2.
1) Добавить реквизит, сумма фиктивной сделки.
2) При проведение в регистре взаиморасчетов вычесть данную сумму. Возможно в регистре продажи и еще каких то.
Молится, что ни где ни какой контроль с документом по сумме не происходит.
Печататься будут с фиктивной суммой, взаиморасчеты по реальным.
Вариант 1.
1) Заводят документ на фиктивную сумму
2) Сохраняют печатную форму.
3) Прикрепляют сохраненный файл к документу.
4) Меняют документ на реальную сумму.
Вариант 2.
1) Добавить реквизит, сумма фиктивной сделки.
2) При проведение в регистре взаиморасчетов вычесть данную сумму. Возможно в регистре продажи и еще каких то.
Молится, что ни где ни какой контроль с документом по сумме не происходит.
Печататься будут с фиктивной суммой, взаиморасчеты по реальным.
(5) Я бы за такое решение вообще не взялся, пусть бы заказчик искал другого исполнителя. Так как проблем не оберешься по доработке конфигурации. А если что то не так, обвинят исполнителя.
Дорабатывать конфигурацию это одно, а коверкать типовые механизмы, себе дороже.
Дорабатывать конфигурацию это одно, а коверкать типовые механизмы, себе дороже.
(6) Именно поэтому не стоит подсказывать, на мой взгляд. )) Надо подсказывать только правильные, добрые и приятные сердцу вещи ))) Ни в коем случае нельзя помогать убивать систему. Это же как наши пациенты, а мы как врачи - не надо помогать нерадивому врачу в убийстве. Профессиональная этика, так сказать.
Ну это сугубо мои принципы. Ибо "Лёха Дёмин говна не делает".
Ну это сугубо мои принципы. Ибо "Лёха Дёмин говна не делает".
(9) про эксель совет это шутка? Печатать документ тоже из экселя? вручную каждый раз заполняя все поля?)
Я знаю как отражать эти суммы в учёте. Вопрос исключительно в том, что менеджерам при такой схеме реализации придется работать с неудобным интерфейсом и количество действий возрастёт, что не подходит.
Конечно же менеджеры хотят чтобы общаясь с клиентом они в ОДНОЙ форме видели всю картину и %% начисления по сделке, а не создавали несколько документов и переключались между их формами с калькулятором в руках.
Кстати. Может вообще замутить какой=-нибудь АРМ менеджера где всё в интерфейсе будет прописано под их желания, а в результате будет создаваться пакет документов:
основной, который отражается в учёте
фиктивный - для печати и для фиксации разниц
на доп.услуги - сумма которого будет рассчитываться как разница между первым и вторым документом
А при редактировании выполнять обратную процедуру - подтягивать данные из пакета документов, а по окончании редактирования перезаписывать все документы.
По-моему мысль.
Я знаю как отражать эти суммы в учёте. Вопрос исключительно в том, что менеджерам при такой схеме реализации придется работать с неудобным интерфейсом и количество действий возрастёт, что не подходит.
Конечно же менеджеры хотят чтобы общаясь с клиентом они в ОДНОЙ форме видели всю картину и %% начисления по сделке, а не создавали несколько документов и переключались между их формами с калькулятором в руках.
Кстати. Может вообще замутить какой=-нибудь АРМ менеджера где всё в интерфейсе будет прописано под их желания, а в результате будет создаваться пакет документов:
основной, который отражается в учёте
фиктивный - для печати и для фиксации разниц
на доп.услуги - сумма которого будет рассчитываться как разница между первым и вторым документом
А при редактировании выполнять обратную процедуру - подтягивать данные из пакета документов, а по окончании редактирования перезаписывать все документы.
По-моему мысль.
Я разве где-то в сообщение просил дать оценку идее?) Или просил советы по организации учёта? ))
Как обычно - люди любят давать ответы, на вопросы, которые им не задавали.
Давайте попробую переформулировать более конкретно.
Обсуждаем только варианты архитектурной реализации с минимальным вмешательством в типовую конфигурацию. Не обсуждаем организацию учёта, не даём оценки принятым у клиента бизнес-процессам, не обсуждаем необходимость автоматизации в 1С.
У клиента очень давно есть сильно переписанная старая семерка. В которой десятки менеджеров работают в сильно переписанном документ "Заказ клиента" под их специфику работы. Заказчиком изначально озвучено принципиальное требование максимально сохранить удобство интерфейсных решений, с учётом возможностей и специфики внедряемой современной конфигурации.
Поэтому рассматриваются 2 альтернативных варианта архитектуры:
1 вариант Добавление реквизитов документа.
Добавляются нужные реквизиты и рисуется форма документа в которой реализуются все необходимые алгоритмы именно ТАК, как хочет и привык клиент. Разумеется с учетом реалий конфигурации ERP.
Плюсы: можно сделать почти идеально под хотелки клиента
Минусы: придется добавить много реквизитов документа и отдельную форму. Всё это будет делаться через расширение конфигурации.
2 Вариант - подчиненный фиктивный документ
Плюсы: можно не трогать типовой функционал
Минусы: придется сначала записать основной и фиктивный документы чтобы начать пользоваться функционалом
Все равно придется допилить форму документа, в которую будут подтягиваться данные из подчинённого (фиктивного не проведенного документа)
Как обычно - люди любят давать ответы, на вопросы, которые им не задавали.
Давайте попробую переформулировать более конкретно.
Обсуждаем только варианты архитектурной реализации с минимальным вмешательством в типовую конфигурацию. Не обсуждаем организацию учёта, не даём оценки принятым у клиента бизнес-процессам, не обсуждаем необходимость автоматизации в 1С.
У клиента очень давно есть сильно переписанная старая семерка. В которой десятки менеджеров работают в сильно переписанном документ "Заказ клиента" под их специфику работы. Заказчиком изначально озвучено принципиальное требование максимально сохранить удобство интерфейсных решений, с учётом возможностей и специфики внедряемой современной конфигурации.
Поэтому рассматриваются 2 альтернативных варианта архитектуры:
1 вариант Добавление реквизитов документа.
Добавляются нужные реквизиты и рисуется форма документа в которой реализуются все необходимые алгоритмы именно ТАК, как хочет и привык клиент. Разумеется с учетом реалий конфигурации ERP.
Плюсы: можно сделать почти идеально под хотелки клиента
Минусы: придется добавить много реквизитов документа и отдельную форму. Всё это будет делаться через расширение конфигурации.
2 Вариант - подчиненный фиктивный документ
Плюсы: можно не трогать типовой функционал
Минусы: придется сначала записать основной и фиктивный документы чтобы начать пользоваться функционалом
Все равно придется допилить форму документа, в которую будут подтягиваться данные из подчинённого (фиктивного не проведенного документа)
(13) вариант 1 правильный. Можно допреквизиты сделать и только печатную форму добавить внешнюю.
Мне правда так кажется, что это только начало истории, а на эти откаты потом надо будет что-то еще приделывать, их же надо будет от клиента получить, потом выплачивать кому-то, учитывать это дело, кого забыли, кого нет, налоги с них учесть и т.п. Но это будет следующая задача, наверное )
Мне правда так кажется, что это только начало истории, а на эти откаты потом надо будет что-то еще приделывать, их же надо будет от клиента получить, потом выплачивать кому-то, учитывать это дело, кого забыли, кого нет, налоги с них учесть и т.п. Но это будет следующая задача, наверное )
(13) Про эксель - шутка с большой долей истины.
про оценку идеи: Если организация ведет черную бухгалтерию - а в вашем случае, мне кажется, так оно и есть - было бы логичным скрыть необоснованное увеличение стоимости. Это ж и налоги, я так понял, тоже занижаются. Если вы реализуете тот механизм который планируете - вы окажете клиенту медвежью услугу. Любой эксперт, анализируюя базу данных увидит левые суммы.
По поводу реализации: если вы не сможете убедить клиента в необходимости изменения бизнес-процессов - любой вариант из предложенных подойдет. Выбирайте менее трудозатратный для конечного пользователя
про оценку идеи: Если организация ведет черную бухгалтерию - а в вашем случае, мне кажется, так оно и есть - было бы логичным скрыть необоснованное увеличение стоимости. Это ж и налоги, я так понял, тоже занижаются. Если вы реализуете тот механизм который планируете - вы окажете клиенту медвежью услугу. Любой эксперт, анализируюя базу данных увидит левые суммы.
По поводу реализации: если вы не сможете убедить клиента в необходимости изменения бизнес-процессов - любой вариант из предложенных подойдет. Выбирайте менее трудозатратный для конечного пользователя
(15) про организацию ведения управленческого учёта, информационную безопасность и порядок взаимодействия с проверяющими органами я проводил достаточно дорогие семинары для клиентов не один год, так что давайте не будем об этом.
И что значит "любой эксперт анализирующий базу данных"? Какой это еще эксперт посторонний?) К данным никто кроме как через СБ с NDA доступ не должен получать.
Что значит "не сможете убедить в необходимости изменения бизнес-процессов"? А где вы тут увидели "изменение бизнес-процессов"? Т.е. вы считаете что я должен убеждать клиента что менеджеры, которые продают должны открывать вместо одной формы 3-4 и тратить время на заполнение кучи полей и переключение между формами?) Серьезно?
Вы невнимательно читали - заказчик изначально поставил условие - сохранить удобный привычный интерфейс. и я не вижу смысла его ломать если он удобный. В конце концов от пользователя мне нужна информация, а дальше система сама разложит её по полочкам и создаст нужные документы и проведет их.
И что значит "любой эксперт анализирующий базу данных"? Какой это еще эксперт посторонний?) К данным никто кроме как через СБ с NDA доступ не должен получать.
Что значит "не сможете убедить в необходимости изменения бизнес-процессов"? А где вы тут увидели "изменение бизнес-процессов"? Т.е. вы считаете что я должен убеждать клиента что менеджеры, которые продают должны открывать вместо одной формы 3-4 и тратить время на заполнение кучи полей и переключение между формами?) Серьезно?
Вы невнимательно читали - заказчик изначально поставил условие - сохранить удобный привычный интерфейс. и я не вижу смысла его ломать если он удобный. В конце концов от пользователя мне нужна информация, а дальше система сама разложит её по полочкам и создаст нужные документы и проведет их.
(16) Под изменением бизнес-процессов имел ввиду рассмотреть возможность отказаться от ведения черной бухгалтерии.
Про переключение между формами и заполнение 3-4 форм вместо одной я не говорил ничего. Напротив, я сказал что решение должно быть максимально юзабельным, удобным и наименее трудозатратным для конечного пользователя. Вы упоминали АРМ - в идеале нужно сделать его.
Про переключение между формами и заполнение 3-4 форм вместо одной я не говорил ничего. Напротив, я сказал что решение должно быть максимально юзабельным, удобным и наименее трудозатратным для конечного пользователя. Вы упоминали АРМ - в идеале нужно сделать его.
(1) т.е. в учете документ хранится с суммой 900? клиент оплачивает 1000. вы ему печатаете документ на 1000.
если так, то проще всего наверно добавить в документ(или в таблицу с товарами) реквизит сумма наценки. и в отдельную печатную форму эту сумму раскидывать по позициям.
если так, то проще всего наверно добавить в документ(или в таблицу с товарами) реквизит сумма наценки. и в отдельную печатную форму эту сумму раскидывать по позициям.
(22) я описал только один из вариантов, а может так же отличаться и кол-во. Да и алгоритмы расчета вознаграждения могут быть разными. Понятно что можно всё это хозяйство зафигачить реквизитами документа "Заказ клиента", но всё-таки хочется с минимальным вмешательством в функционал типовой.
Зачем мне дублировать поля - сумма, кол-во и т.д. если можно просто создать отдельный документ для хранения всего этого, а в основном прописать ссылку на него. Ну и признак "Основной документ" с типом булево. Итого: добавляем всего 2 реквизита и отдельную обработку для создания/редактирования пакета документов.
Зачем мне дублировать поля - сумма, кол-во и т.д. если можно просто создать отдельный документ для хранения всего этого, а в основном прописать ссылку на него. Ну и признак "Основной документ" с типом булево. Итого: добавляем всего 2 реквизита и отдельную обработку для создания/редактирования пакета документов.
Вариант 3.
1. Создаётся обработка «АРМ менеджера» максимально повторяющая форму документа 1С7 «Заказ покупателя», но с учётом особенностей ERP.
2. После заполнения всех полей в форме и нажатии кнопки «Создать документы» создаётся пакет следующих документов:
2.1. Основной заказ клиента на сумму фактических операций (проведенный).
2.2. Фиктивный заказ клиента для печати фиктивных документов и отражения разницы между фактическими суммами и количеством и фиктивными (не проведенный).
3. При любом редактировании основного документа «Заказ клиента» автоматически открывается форма «АРМ менеджера» в которую загружаются данные пакета документов. При этом документы пакета блокируются от редактирования и другим пользователям выдается сообщение о блокировке редактирования, кем блокировано и когда.
4. При отгрузке на основании заказа автоматически создаётся два документа «Реализация товаров и услуг» - фактический и фиктивный, а на разницу создаётся документ «Поступление товаров и услуг» на служебную услугу (например, с названием «Вознаграждение») на контрагента выбранного в поле «Посредник» для отражения взаиморасчетов по мат. стимулированию с посредником(ами). Если посредников несколько, то автоматически создаётся отдельный документ на каждого посредника.
5. Сумма вознаграждения может отражаться в учёте либо в момент первой отгрузки (первой РН), либо пропорционально отгрузке по каждой РН. Это опционально можно вынести в настройку.
Какие недостатки могут быть у данной схемы?
1. Создаётся обработка «АРМ менеджера» максимально повторяющая форму документа 1С7 «Заказ покупателя», но с учётом особенностей ERP.
2. После заполнения всех полей в форме и нажатии кнопки «Создать документы» создаётся пакет следующих документов:
2.1. Основной заказ клиента на сумму фактических операций (проведенный).
2.2. Фиктивный заказ клиента для печати фиктивных документов и отражения разницы между фактическими суммами и количеством и фиктивными (не проведенный).
3. При любом редактировании основного документа «Заказ клиента» автоматически открывается форма «АРМ менеджера» в которую загружаются данные пакета документов. При этом документы пакета блокируются от редактирования и другим пользователям выдается сообщение о блокировке редактирования, кем блокировано и когда.
4. При отгрузке на основании заказа автоматически создаётся два документа «Реализация товаров и услуг» - фактический и фиктивный, а на разницу создаётся документ «Поступление товаров и услуг» на служебную услугу (например, с названием «Вознаграждение») на контрагента выбранного в поле «Посредник» для отражения взаиморасчетов по мат. стимулированию с посредником(ами). Если посредников несколько, то автоматически создаётся отдельный документ на каждого посредника.
5. Сумма вознаграждения может отражаться в учёте либо в момент первой отгрузки (первой РН), либо пропорционально отгрузке по каждой РН. Это опционально можно вынести в настройку.
Какие недостатки могут быть у данной схемы?
(23)
вынос мозга у следующего за вами программиста. ибо ОЧЕНЬ не прозрачная схема получается.
в последствии клиент тоже не обрадуется выставленному счету за доработку такой схемы программистом со стороны.
да вы и сами года через два не обрадуетесь обращению этого клиента.
Какие недостатки могут быть у данной схемы?
вынос мозга у следующего за вами программиста. ибо ОЧЕНЬ не прозрачная схема получается.
в последствии клиент тоже не обрадуется выставленному счету за доработку такой схемы программистом со стороны.
да вы и сами года через два не обрадуетесь обращению этого клиента.
(25) ну если программировать прямо из головы то да, но я всегда разрабатываю и утверждаю у заказчика документ с функциональными требованиями, в котором на понятном пользователю языке описывается работа системы после доработок и обязательно включены несколько сквозных числовых сценариев.
Плюс потом после доработок видео-инструкция.
Хотя с аргументом сложности частично согласен. Когда реквизиты в одном документе всё-таки проще
Плюс потом после доработок видео-инструкция.
Хотя с аргументом сложности частично согласен. Когда реквизиты в одном документе всё-таки проще
(29)Ваша задача звучит как 1 в 1 так называемая скидка мастеровому на СТО. У которого в магазине скидка 10% но сумму с клиента он берет без учета скидки. и ее же надо показать.
Опять же не понятно что за разница и куда вы ее потом будете девать. чья она должна быть, ваша или клиента.
Опять же не понятно что за разница и куда вы ее потом будете девать. чья она должна быть, ваша или клиента.
(30) в (23) всё очень подробно расписано.
В целом всё понятно. Вопрос заключается только в том, как в удобной форме, с минимальными дописками дать пользователю возможность работать с полной картиной по заказу. Чтобы видеть в одной форме и удобно:
1. Реальная сумма и кол-во.
2. Фиктивная сумма и кол-во.
3. Разница между 1 и 2.
4. Рассчитанный % от суммы разницы 1 и 2 как по цене, так и по кол-во (фактически купили 9шт., по документам 10 шт.).
А куда девать вопрос не стоит. Конечно же приходовать услугу от контрагента чтобы возник перед ним долг и дальше идут взаиморасчеты с ним как поставщиком услуги. Не знаю что такое "агентские", но если это в ERP типовой функционал, то подойдёт даже лучше чем поставщик услуг.
В целом всё понятно. Вопрос заключается только в том, как в удобной форме, с минимальными дописками дать пользователю возможность работать с полной картиной по заказу. Чтобы видеть в одной форме и удобно:
1. Реальная сумма и кол-во.
2. Фиктивная сумма и кол-во.
3. Разница между 1 и 2.
4. Рассчитанный % от суммы разницы 1 и 2 как по цене, так и по кол-во (фактически купили 9шт., по документам 10 шт.).
А куда девать вопрос не стоит. Конечно же приходовать услугу от контрагента чтобы возник перед ним долг и дальше идут взаиморасчеты с ним как поставщиком услуги. Не знаю что такое "агентские", но если это в ERP типовой функционал, то подойдёт даже лучше чем поставщик услуг.
(37)Да какая то странная и не понятная схема. зачем вам хранить количества и фиктивные суммы построчно? что вы с ними потом будите делать. в 99% ничего. работа ради работы.
Приходовать услугу от какого клиента? который посредник, вы можете ее делать и без всех этих манипуляций с заказом.
В общем как там есть правило, если можно сделать просто надо сделать просто.
Приходовать услугу от какого клиента? который посредник, вы можете ее делать и без всех этих манипуляций с заказом.
В общем как там есть правило, если можно сделать просто надо сделать просто.
(40) если она непонятна вам лично, то это еще не значит что она непонятная вообще.
Хранить их нужно затем, что от разницы берется % и начисляются агентские комиссионные посреднику, которых может быть несколько и как и алгоритмов расчета.
А вот на счет того, что при моей схеме решения сложно будет сравнивать строки в факт. и фикт. счетах я как раз и не подумал.
Тогда остаётся только один вариант дублирование всех нужных реквизитов как шапки, так и табличной части.
С другой стороны это упрощает общую логику работы с документом. Всю эту специфику можно вынести в отдельную группу и закладку и там всё сделать как сейчас в старой системе, а именно:
Факт: кол-во, цена, сумма
Фикт.: кол-во, цена, сумма
Разница: %, алгоритм расчета
Остаётся только вопрос каким документом и в какой момент создавать долг перед посредником чтобы минимизировать кол-во документов и форм для пользователя. По заказу покупателя нельзя - еще не было никаких взаиморасчетов. Думаю будет зависеть от бизнес-процесса. Обычно долг посреднику возникает в момент оплаты по заказу.
Надо будет еще подумать над этим вопросом. По-хорошему конечно нужно создавать на основании заказа покупателя документ отражающий оказание услуг поставщиком на посредника. И создавать его должен пользователь в момент получения оплаты.
Хранить их нужно затем, что от разницы берется % и начисляются агентские комиссионные посреднику, которых может быть несколько и как и алгоритмов расчета.
А вот на счет того, что при моей схеме решения сложно будет сравнивать строки в факт. и фикт. счетах я как раз и не подумал.
Тогда остаётся только один вариант дублирование всех нужных реквизитов как шапки, так и табличной части.
С другой стороны это упрощает общую логику работы с документом. Всю эту специфику можно вынести в отдельную группу и закладку и там всё сделать как сейчас в старой системе, а именно:
Факт: кол-во, цена, сумма
Фикт.: кол-во, цена, сумма
Разница: %, алгоритм расчета
Остаётся только вопрос каким документом и в какой момент создавать долг перед посредником чтобы минимизировать кол-во документов и форм для пользователя. По заказу покупателя нельзя - еще не было никаких взаиморасчетов. Думаю будет зависеть от бизнес-процесса. Обычно долг посреднику возникает в момент оплаты по заказу.
Надо будет еще подумать над этим вопросом. По-хорошему конечно нужно создавать на основании заказа покупателя документ отражающий оказание услуг поставщиком на посредника. И создавать его должен пользователь в момент получения оплаты.
может такой способ реализации....
1)Заказ на 1000 - полная стоимость (откуда печатаются все документы покупателю)
2)Поступление оплаты 1000.
3)Реализация 900
4)Поступление допрасхода на 100 от Контрагента = ваша организация
5)Проведение взаимозачета 100 Покупатель и Контрагент (ваш из допрасхода)
1)Заказ на 1000 - полная стоимость (откуда печатаются все документы покупателю)
2)Поступление оплаты 1000.
3)Реализация 900
4)Поступление допрасхода на 100 от Контрагента = ваша организация
5)Проведение взаимозачета 100 Покупатель и Контрагент (ваш из допрасхода)
(35) как раз это очень принципиальный момент, потому что отгрузка и возникновение взаиморасчетов должно происходить именно по факту и параллельно должна быть фиктивная отгрузка на увеличенную сумму.
Как раз в моём варианте 3 всё красиво складывается:
1. Фиктивная отгрузка подчинена фиктивному заказу покупателя. Причем если их будет много, то всё равно всё наглядно - все фиктивные документы отгрузки подчинены одному фиктивному заказу.
2. Реальный заказ и подчиненный ему реальные фактические отгрузки доступны по ссылке из фиктивного заказа и реальный заказ виден в отдельной колонке.
Самое узкое место на мой взгляд это необходимость постоянно перехватывать события создания заказа и редактирования заказа и необходимость в этом случае открывать специальную форму обработки.
Ну и необходимость всегда записывать заказ для работы с ним. Но это уже мелочи.
Как раз в моём варианте 3 всё красиво складывается:
1. Фиктивная отгрузка подчинена фиктивному заказу покупателя. Причем если их будет много, то всё равно всё наглядно - все фиктивные документы отгрузки подчинены одному фиктивному заказу.
2. Реальный заказ и подчиненный ему реальные фактические отгрузки доступны по ссылке из фиктивного заказа и реальный заказ виден в отдельной колонке.
Самое узкое место на мой взгляд это необходимость постоянно перехватывать события создания заказа и редактирования заказа и необходимость в этом случае открывать специальную форму обработки.
Ну и необходимость всегда записывать заказ для работы с ним. Но это уже мелочи.
(36) это как раз точно не принципиально
Посмотрел про агентские услуги - как-то сложно и мудрёно показалось.
Пока останавливаюсь на варианте 3. Основной фактический заказ покупателя содержит ссылку на фиктивный, который не проводится и используется для формирования печатных форм и хранения фиктивных данных: кол-во, сумма.
Далее в журнале заказов добавляем 2 колонки: признак "Основной / фиктивный" и "Фиктивный счет" в которой отображается ссылка на фиктивный счет. Для фиктивных счетов в этой колонке пусто.
При создании нового заказа или редактировании основного существующего открывается спец.форма результатом работы в которой является сформированный, записанный и проведенный пакет документов.
При попытке открыть фиктивный счет опять же открывается спец. форма и редактирутся весь пакет документов вместе.
Это вариант мне нравится тем что минимальные доработки документа "Заказ покупателя":
1. добавляем 2 реквизита шапки.
2. Добавляем новую форму списка.
3. Добавляем новую форму редактирования документа
Посмотрел про агентские услуги - как-то сложно и мудрёно показалось.
Пока останавливаюсь на варианте 3. Основной фактический заказ покупателя содержит ссылку на фиктивный, который не проводится и используется для формирования печатных форм и хранения фиктивных данных: кол-во, сумма.
Далее в журнале заказов добавляем 2 колонки: признак "Основной / фиктивный" и "Фиктивный счет" в которой отображается ссылка на фиктивный счет. Для фиктивных счетов в этой колонке пусто.
При создании нового заказа или редактировании основного существующего открывается спец.форма результатом работы в которой является сформированный, записанный и проведенный пакет документов.
При попытке открыть фиктивный счет опять же открывается спец. форма и редактирутся весь пакет документов вместе.
Это вариант мне нравится тем что минимальные доработки документа "Заказ покупателя":
1. добавляем 2 реквизита шапки.
2. Добавляем новую форму списка.
3. Добавляем новую форму редактирования документа
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот