как лучше реализовать фиктивную сумму документа

1. impextr 88 15.10.20 10:01 Сейчас в теме
Добрый день.
У одного из заказчиков возникла задача. Конфигурация КА, ERP - не столь важно.

В документе "Заказ клиента" (и нескольких других) необходимо реализовать хранение фиктивных документов, которые будут нужны только для распечатки. При этом по реальным суммам будут происходить взаиморасчеты.
Например, позвонил клиент и попросил выписать документы на сумму 1000, при этом реальная стоимость заказанных товаров 900. Ну и далее с разницей в 100 нужно будет выполнять различные манипуляции - брать % и т.д.
Хочется реализовать с минимальными доработками типовой. Есть идея сделать фиктивный документ подчиненным основном, а в форму основного выводить выборочные реквизиты подчиненного.
Плюсы решения - минимальные доработки документа Заказ, минусы - документ нужно сохранить прежде чем можно будет вводить фиктивные данные.

Может у кого-то было что-то подобное. Поделитесь идеями.
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
3. alex-l19041 8 15.10.20 10:11 Сейчас в теме
(1) каким образом эта разница будет учитываться в учете ? сколько еще документов и регистров это коснется ?
10. RocKeR_13 1345 15.10.20 11:06 Сейчас в теме
(1)
Например, позвонил клиент и попросил выписать документы на сумму 1000, при этом реальная стоимость заказанных товаров 900.

Что-то вообще непонятная ситуация. Вам клиент просто аванс вносит? Или он сам выбрал товары, магическим образом посчитал стоимость и эту инфу сообщил вам? Я бы посмотрел в сторону функционала сделок с клиентами: в самой сделке указываете вашу "фиктивную" сумму, а дальше уже по сделке оформляете документы на реальную сумму
11. FatPanzer 15.10.20 11:10 Сейчас в теме
(10) Вы не работали в 90-х? Сисадмин звонит в ИТ-контору и говорит - мне нужен комп и накиньте 10%. Приходит счет, работодатель оплачивает счет, потом сисадмин идет в ИТ-контору и делит эти 10% из черной кассы с менеджером по договоренности.
Это черные сделки, не пытайтесь их положить на белый учет )))
12. RocKeR_13 1345 15.10.20 11:31 Сейчас в теме
(11) Не, в 90х еще сидел за школьной партой)))

Тем не менее сделки хранятся в справочнике и позволяют:
1) указать сумму, которая в рег.учете не будет участвовать
2) объединить документы по сделке, что упростит создание необходимого отчета

Ну и, естественно, грозим пальцем и всячески осуждаем черную бухгалтерию!)
31. Азбука Морзе 106 16.10.20 10:24 Сейчас в теме
(1) Вот мое решение вообще без доработки типовой конфигурации:

1. Добавляем у документа доп.сведение по названием Разница.
2. Пишем доп.обработку для манипуляций с этими сведениями.
2. FatPanzer 15.10.20 10:05 Сейчас в теме
Тетрадочка в столбик, Excel.
dabu-dabu; +1 Ответить
4. oleg-x 27 15.10.20 10:45 Сейчас в теме
Алгоритм такой:
Вариант 1.
1) Заводят документ на фиктивную сумму
2) Сохраняют печатную форму.
3) Прикрепляют сохраненный файл к документу.
4) Меняют документ на реальную сумму.

Вариант 2.
1) Добавить реквизит, сумма фиктивной сделки.
2) При проведение в регистре взаиморасчетов вычесть данную сумму. Возможно в регистре продажи и еще каких то.
Молится, что ни где ни какой контроль с документом по сумме не происходит.
Печататься будут с фиктивной суммой, взаиморасчеты по реальным.
5. FatPanzer 15.10.20 10:48 Сейчас в теме
(4)
При проведение в регистре взаиморасчетов вычесть данную сумму. Возможно в регистре продажи и еще каких то.
Молится, что ни где ни какой контроль с документом по сумме не происходит.
Уволил бы за такое решение.
6. oleg-x 27 15.10.20 10:53 Сейчас в теме
(5) Я бы за такое решение вообще не взялся, пусть бы заказчик искал другого исполнителя. Так как проблем не оберешься по доработке конфигурации. А если что то не так, обвинят исполнителя.
Дорабатывать конфигурацию это одно, а коверкать типовые механизмы, себе дороже.
FatPanzer; +1 Ответить
7. FatPanzer 15.10.20 10:57 Сейчас в теме
(6) Именно поэтому не стоит подсказывать, на мой взгляд. )) Надо подсказывать только правильные, добрые и приятные сердцу вещи ))) Ни в коем случае нельзя помогать убивать систему. Это же как наши пациенты, а мы как врачи - не надо помогать нерадивому врачу в убийстве. Профессиональная этика, так сказать.

Ну это сугубо мои принципы. Ибо "Лёха Дёмин говна не делает".
8. m_nazar 15.10.20 10:58 Сейчас в теме
мой вариант:
1. Добавить реквизит для разницы сумм.
2. Добавить регистр накопления для учета этих сумм.
3. Добавить внешнюю печатную форму которая будет учитывать полную сумму
9. andy_zhav 197 15.10.20 11:00 Сейчас в теме
(1) Плохая идея в принципе. Если вы хотите отражать эти суммы в учете - отражайте их доп. услугами, к примеру. Если вы вообще не хотите их отражать в учете, то в (2) правильно подсказали
alex-l19041; +1 Ответить
14. impextr 88 15.10.20 13:41 Сейчас в теме
(9) про эксель совет это шутка? Печатать документ тоже из экселя? вручную каждый раз заполняя все поля?)
Я знаю как отражать эти суммы в учёте. Вопрос исключительно в том, что менеджерам при такой схеме реализации придется работать с неудобным интерфейсом и количество действий возрастёт, что не подходит.
Конечно же менеджеры хотят чтобы общаясь с клиентом они в ОДНОЙ форме видели всю картину и %% начисления по сделке, а не создавали несколько документов и переключались между их формами с калькулятором в руках.

Кстати. Может вообще замутить какой=-нибудь АРМ менеджера где всё в интерфейсе будет прописано под их желания, а в результате будет создаваться пакет документов:
основной, который отражается в учёте
фиктивный - для печати и для фиксации разниц
на доп.услуги - сумма которого будет рассчитываться как разница между первым и вторым документом

А при редактировании выполнять обратную процедуру - подтягивать данные из пакета документов, а по окончании редактирования перезаписывать все документы.
По-моему мысль.
13. impextr 88 15.10.20 13:24 Сейчас в теме
Я разве где-то в сообщение просил дать оценку идее?) Или просил советы по организации учёта? ))
Как обычно - люди любят давать ответы, на вопросы, которые им не задавали.

Давайте попробую переформулировать более конкретно.
Обсуждаем только варианты архитектурной реализации с минимальным вмешательством в типовую конфигурацию. Не обсуждаем организацию учёта, не даём оценки принятым у клиента бизнес-процессам, не обсуждаем необходимость автоматизации в 1С.

У клиента очень давно есть сильно переписанная старая семерка. В которой десятки менеджеров работают в сильно переписанном документ "Заказ клиента" под их специфику работы. Заказчиком изначально озвучено принципиальное требование максимально сохранить удобство интерфейсных решений, с учётом возможностей и специфики внедряемой современной конфигурации.

Поэтому рассматриваются 2 альтернативных варианта архитектуры:

1 вариант Добавление реквизитов документа.
Добавляются нужные реквизиты и рисуется форма документа в которой реализуются все необходимые алгоритмы именно ТАК, как хочет и привык клиент. Разумеется с учетом реалий конфигурации ERP.
Плюсы: можно сделать почти идеально под хотелки клиента
Минусы: придется добавить много реквизитов документа и отдельную форму. Всё это будет делаться через расширение конфигурации.

2 Вариант - подчиненный фиктивный документ
Плюсы: можно не трогать типовой функционал
Минусы: придется сначала записать основной и фиктивный документы чтобы начать пользоваться функционалом
Все равно придется допилить форму документа, в которую будут подтягиваться данные из подчинённого (фиктивного не проведенного документа)
19. starjevschik 15.10.20 14:40 Сейчас в теме
(13) вариант 1 правильный. Можно допреквизиты сделать и только печатную форму добавить внешнюю.
Мне правда так кажется, что это только начало истории, а на эти откаты потом надо будет что-то еще приделывать, их же надо будет от клиента получить, потом выплачивать кому-то, учитывать это дело, кого забыли, кого нет, налоги с них учесть и т.п. Но это будет следующая задача, наверное )
15. andy_zhav 197 15.10.20 13:58 Сейчас в теме
(13) Про эксель - шутка с большой долей истины.

про оценку идеи: Если организация ведет черную бухгалтерию - а в вашем случае, мне кажется, так оно и есть - было бы логичным скрыть необоснованное увеличение стоимости. Это ж и налоги, я так понял, тоже занижаются. Если вы реализуете тот механизм который планируете - вы окажете клиенту медвежью услугу. Любой эксперт, анализируюя базу данных увидит левые суммы.

По поводу реализации: если вы не сможете убедить клиента в необходимости изменения бизнес-процессов - любой вариант из предложенных подойдет. Выбирайте менее трудозатратный для конечного пользователя
16. impextr 88 15.10.20 14:06 Сейчас в теме
(15) про организацию ведения управленческого учёта, информационную безопасность и порядок взаимодействия с проверяющими органами я проводил достаточно дорогие семинары для клиентов не один год, так что давайте не будем об этом.
И что значит "любой эксперт анализирующий базу данных"? Какой это еще эксперт посторонний?) К данным никто кроме как через СБ с NDA доступ не должен получать.

Что значит "не сможете убедить в необходимости изменения бизнес-процессов"? А где вы тут увидели "изменение бизнес-процессов"? Т.е. вы считаете что я должен убеждать клиента что менеджеры, которые продают должны открывать вместо одной формы 3-4 и тратить время на заполнение кучи полей и переключение между формами?) Серьезно?
Вы невнимательно читали - заказчик изначально поставил условие - сохранить удобный привычный интерфейс. и я не вижу смысла его ломать если он удобный. В конце концов от пользователя мне нужна информация, а дальше система сама разложит её по полочкам и создаст нужные документы и проведет их.
17. andy_zhav 197 15.10.20 14:11 Сейчас в теме
(16) Под изменением бизнес-процессов имел ввиду рассмотреть возможность отказаться от ведения черной бухгалтерии.

Про переключение между формами и заполнение 3-4 форм вместо одной я не говорил ничего. Напротив, я сказал что решение должно быть максимально юзабельным, удобным и наименее трудозатратным для конечного пользователя. Вы упоминали АРМ - в идеале нужно сделать его.
18. impextr 88 15.10.20 14:35 Сейчас в теме
(17)
1) вопросы как вести деятельность находят в компетенции акционеров компании, а не моей
2) максимально удобным если я не смогу переубедить, а если смогу?) пусть клацают и бегают по формам?)
20. andy_zhav 197 15.10.20 15:50 Сейчас в теме
(18) Что-то обсуждение зашло в тупик...
21. impextr 88 15.10.20 16:01 Сейчас в теме
(20) Да нет, я бы не сказал что прямо в тупик. Просто во время подробного объяснения другим мне (как это часто бывает) пришло понимание что кроме двух вариантов есть третий, который мне на данный момент кажется оптимальным.
22. EVKash 16 15.10.20 16:02 Сейчас в теме
(1) т.е. в учете документ хранится с суммой 900? клиент оплачивает 1000. вы ему печатаете документ на 1000.
если так, то проще всего наверно добавить в документ(или в таблицу с товарами) реквизит сумма наценки. и в отдельную печатную форму эту сумму раскидывать по позициям.
24. impextr 88 15.10.20 16:08 Сейчас в теме
(22) я описал только один из вариантов, а может так же отличаться и кол-во. Да и алгоритмы расчета вознаграждения могут быть разными. Понятно что можно всё это хозяйство зафигачить реквизитами документа "Заказ клиента", но всё-таки хочется с минимальным вмешательством в функционал типовой.
Зачем мне дублировать поля - сумма, кол-во и т.д. если можно просто создать отдельный документ для хранения всего этого, а в основном прописать ссылку на него. Ну и признак "Основной документ" с типом булево. Итого: добавляем всего 2 реквизита и отдельную обработку для создания/редактирования пакета документов.
23. impextr 88 15.10.20 16:05 Сейчас в теме
Вариант 3.

1. Создаётся обработка «АРМ менеджера» максимально повторяющая форму документа 1С7 «Заказ покупателя», но с учётом особенностей ERP.
2. После заполнения всех полей в форме и нажатии кнопки «Создать документы» создаётся пакет следующих документов:
2.1. Основной заказ клиента на сумму фактических операций (проведенный).
2.2. Фиктивный заказ клиента для печати фиктивных документов и отражения разницы между фактическими суммами и количеством и фиктивными (не проведенный).
3. При любом редактировании основного документа «Заказ клиента» автоматически открывается форма «АРМ менеджера» в которую загружаются данные пакета документов. При этом документы пакета блокируются от редактирования и другим пользователям выдается сообщение о блокировке редактирования, кем блокировано и когда.
4. При отгрузке на основании заказа автоматически создаётся два документа «Реализация товаров и услуг» - фактический и фиктивный, а на разницу создаётся документ «Поступление товаров и услуг» на служебную услугу (например, с названием «Вознаграждение») на контрагента выбранного в поле «Посредник» для отражения взаиморасчетов по мат. стимулированию с посредником(ами). Если посредников несколько, то автоматически создаётся отдельный документ на каждого посредника.
5. Сумма вознаграждения может отражаться в учёте либо в момент первой отгрузки (первой РН), либо пропорционально отгрузке по каждой РН. Это опционально можно вынести в настройку.

Какие недостатки могут быть у данной схемы?
25. EVKash 16 15.10.20 16:15 Сейчас в теме
(23)
Какие недостатки могут быть у данной схемы?

вынос мозга у следующего за вами программиста. ибо ОЧЕНЬ не прозрачная схема получается.
в последствии клиент тоже не обрадуется выставленному счету за доработку такой схемы программистом со стороны.
да вы и сами года через два не обрадуетесь обращению этого клиента.
26. impextr 88 15.10.20 16:36 Сейчас в теме
(25) ну если программировать прямо из головы то да, но я всегда разрабатываю и утверждаю у заказчика документ с функциональными требованиями, в котором на понятном пользователю языке описывается работа системы после доработок и обязательно включены несколько сквозных числовых сценариев.
Плюс потом после доработок видео-инструкция.

Хотя с аргументом сложности частично согласен. Когда реквизиты в одном документе всё-таки проще
27. starjevschik 15.10.20 17:47 Сейчас в теме
(23) заказчику она обойдется дороже всех. Тут трудозатраты вырастают до пары недель.
Если клиент согласен это оплачивать, то почему бы и нет. Можно и еще более красочное что-нибудь сочинить.
28. muskul 16.10.20 05:49 Сейчас в теме
Какой то ерунды придумали честное слово. делается один реквизит "Сумма в печатной форме" и одна печатная форма. которая эту сумму раскидает как наценку или скидку на документ построчно. ВСЕ
Конфу вообще не трогаем.
29. impextr 88 16.10.20 09:47 Сейчас в теме
(28) спасибо конечно за ваше мнение, но ваш вариант вообще не походит. Вы видимо не внимательно читали тему и первоначальную задачу.
30. muskul 16.10.20 10:04 Сейчас в теме
(29)Ваша задача звучит как 1 в 1 так называемая скидка мастеровому на СТО. У которого в магазине скидка 10% но сумму с клиента он берет без учета скидки. и ее же надо показать.
Опять же не понятно что за разница и куда вы ее потом будете девать. чья она должна быть, ваша или клиента.
37. impextr 88 16.10.20 14:39 Сейчас в теме
(30) в (23) всё очень подробно расписано.
В целом всё понятно. Вопрос заключается только в том, как в удобной форме, с минимальными дописками дать пользователю возможность работать с полной картиной по заказу. Чтобы видеть в одной форме и удобно:
1. Реальная сумма и кол-во.
2. Фиктивная сумма и кол-во.
3. Разница между 1 и 2.
4. Рассчитанный % от суммы разницы 1 и 2 как по цене, так и по кол-во (фактически купили 9шт., по документам 10 шт.).

А куда девать вопрос не стоит. Конечно же приходовать услугу от контрагента чтобы возник перед ним долг и дальше идут взаиморасчеты с ним как поставщиком услуги. Не знаю что такое "агентские", но если это в ERP типовой функционал, то подойдёт даже лучше чем поставщик услуг.
40. muskul 17.10.20 05:33 Сейчас в теме
(37)Да какая то странная и не понятная схема. зачем вам хранить количества и фиктивные суммы построчно? что вы с ними потом будите делать. в 99% ничего. работа ради работы.
Приходовать услугу от какого клиента? который посредник, вы можете ее делать и без всех этих манипуляций с заказом.

В общем как там есть правило, если можно сделать просто надо сделать просто.
41. impextr 88 17.10.20 12:29 Сейчас в теме
(40) если она непонятна вам лично, то это еще не значит что она непонятная вообще.
Хранить их нужно затем, что от разницы берется % и начисляются агентские комиссионные посреднику, которых может быть несколько и как и алгоритмов расчета.

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

Тогда остаётся только один вариант дублирование всех нужных реквизитов как шапки, так и табличной части.
С другой стороны это упрощает общую логику работы с документом. Всю эту специфику можно вынести в отдельную группу и закладку и там всё сделать как сейчас в старой системе, а именно:
Факт: кол-во, цена, сумма
Фикт.: кол-во, цена, сумма
Разница: %, алгоритм расчета

Остаётся только вопрос каким документом и в какой момент создавать долг перед посредником чтобы минимизировать кол-во документов и форм для пользователя. По заказу покупателя нельзя - еще не было никаких взаиморасчетов. Думаю будет зависеть от бизнес-процесса. Обычно долг посреднику возникает в момент оплаты по заказу.
Надо будет еще подумать над этим вопросом. По-хорошему конечно нужно создавать на основании заказа покупателя документ отражающий оказание услуг поставщиком на посредника. И создавать его должен пользователь в момент получения оплаты.
32. 603692 3 16.10.20 10:38 Сейчас в теме
может такой способ реализации....
1)Заказ на 1000 - полная стоимость (откуда печатаются все документы покупателю)
2)Поступление оплаты 1000.
3)Реализация 900
4)Поступление допрасхода на 100 от Контрагента = ваша организация
5)Проведение взаимозачета 100 Покупатель и Контрагент (ваш из допрасхода)
33. 603692 3 16.10.20 10:40 Сейчас в теме
(32)и главное, ничего не дописывать, кроме распределения получеyных "допрасходов", но это уже можно и внешней обработкой.
34. FatPanzer 16.10.20 10:45 Сейчас в теме
(32)
1)Заказ на 1000 - полная стоимость (откуда печатаются все документы покупателю)
3)Реализация 900
Заказ не закроется.
35. 603692 3 16.10.20 10:48 Сейчас в теме
(34)это уже нюансы...если ведется по заказам, то двоить их не проводить на 1000 или нумерацию для таких по галочке отдельную, а если не по заказам, то вообще не связывать его с реализацией
38. impextr 88 16.10.20 14:44 Сейчас в теме
(35) как раз это очень принципиальный момент, потому что отгрузка и возникновение взаиморасчетов должно происходить именно по факту и параллельно должна быть фиктивная отгрузка на увеличенную сумму.

Как раз в моём варианте 3 всё красиво складывается:
1. Фиктивная отгрузка подчинена фиктивному заказу покупателя. Причем если их будет много, то всё равно всё наглядно - все фиктивные документы отгрузки подчинены одному фиктивному заказу.
2. Реальный заказ и подчиненный ему реальные фактические отгрузки доступны по ссылке из фиктивного заказа и реальный заказ виден в отдельной колонке.

Самое узкое место на мой взгляд это необходимость постоянно перехватывать события создания заказа и редактирования заказа и необходимость в этом случае открывать специальную форму обработки.
Ну и необходимость всегда записывать заказ для работы с ним. Но это уже мелочи.
36. 603692 3 16.10.20 10:55 Сейчас в теме
кстати, можно даже не допрасход делать, а поступление услуг Агентское вознаграждение за поиск покупателей, например, договор не с поставщиком, а агентский....опять же все в стандарте можно, без дописок конфы.
39. impextr 88 16.10.20 14:58 Сейчас в теме
(36) это как раз точно не принципиально
Посмотрел про агентские услуги - как-то сложно и мудрёно показалось.

Пока останавливаюсь на варианте 3. Основной фактический заказ покупателя содержит ссылку на фиктивный, который не проводится и используется для формирования печатных форм и хранения фиктивных данных: кол-во, сумма.
Далее в журнале заказов добавляем 2 колонки: признак "Основной / фиктивный" и "Фиктивный счет" в которой отображается ссылка на фиктивный счет. Для фиктивных счетов в этой колонке пусто.
При создании нового заказа или редактировании основного существующего открывается спец.форма результатом работы в которой является сформированный, записанный и проведенный пакет документов.
При попытке открыть фиктивный счет опять же открывается спец. форма и редактирутся весь пакет документов вместе.

Это вариант мне нравится тем что минимальные доработки документа "Заказ покупателя":
1. добавляем 2 реквизита шапки.
2. Добавляем новую форму списка.
3. Добавляем новую форму редактирования документа
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот