gifts2017

"Удобная торговля" по мотивам 7.7 на платформе 8.3

Опубликовал Дмитрий Краснопольский (Deda) в раздел Отраслевые решения - Торговля

Основываясь на логике и удобстве работы с конфигурацией 1С: 7.7 Торговля и Склад 9.2, а также по многочисленным отзывам пользователей конфигурации 1С: 8.3 "Управление торговлей 11", я начал написание этой конфигурации. Это удобство и принципы той далеко не забытой 1С: 7.7 Торговля и склад 9.2 на новой платформе 1С: 8.3.

Реализован партионный учет по методу FIFO. Восстановление последовательности. Контроль остатков.

2 регистра накопления:

  • ДолгиКонтрагентов и ПартииТоваров обеспечивают отражение взаиморасчетов и учета Себестоимости, которую очень удобно подстроить (доработать) под нужды любого предприятия, потому что код расчета себестоимости находится в модулях документов (это удобно), в отличие от Управления Торговлей 11, в которой используется "РАУЗ" расширенная аналитика учета запасов.
Остатки
Взаиморасчеты

Маловесная конфигурация (350кб.) на данный момент имеет 5 документов:

  • ПоступлениеТМЦ
    РеализацияТМЦ
    ПеремещениеТМЦ
    Возврат от клиента
    ИнвентаризацияТМЦ
  • ОприходованиеТМЦ
  • СписаниеТМЦ

и необходимые справочники:

  • Номенклатура
  • ВидыЦен
    В 
  • Партии
  • ЕдиницыИзмерения
    ВидыНоменклатуры
    Контрагенты
    ДоговорыКонтрагентов
    Организации
    Склады
    ГТД
    СтраныМира

РегистрыСведений:- ЦеныНоменклатуры (позволяют установить цены примо из карточки товара)
Цель разработки данной конфигурации: 

  1. Удобство (практичность) для конечного пользователя
  2. Бесплатно
  3. Легковесность конфигурации
  4. Простота кода для доработки под любую организацию

19.03.16 - Обновлено СпрНоменклатура, СпрПартии. - Разионализован код в документах.- Заведены ЦеныНоменклатуры.

25.03.16 - Добавлены цены номенклатуры в карточке Товара.- Подбор партий в документах.- Добавлен ВводОстатков, ГТД, СтраныМира.

30.03.16 - Исправлены множественные ошибки.- Рационализированы формы, добавлены реквизиты.- Добавлены спец обработки в раздел Настройки и Администрирование.- Переделаны отчеты.- Обновлен интерфейс. 

14.04.16 - Добавлен модуль ценообразования. Цены можно формировать как вручную так и на основании документов Поступления. Изменен интерфейс.

01.08.16 - Исправлен модуль ценообразования. Убран документ "Ввод остатков" (Ввод остатков осуществляется докумнетами Поступление и Оприходование). Исправлено модуль документа Поступления. Изменен интерфейс.

07.09.16 - Благодаря пользователю CnupT (Алексею) добавлены документы: ИнвентаризацияТМЦ, ОприходованиеТМЦ, СписаниеТМЦ

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

Скачать файлы

Наименование Файл Версия Размер
Конфигурация 35
.dt 376,61Kb
01.08.16
35
.dt 1.1 376,61Kb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Павел Павел (modestry) 10.03.16 14:48
Не плохо, до сих пор куча фирм 1с 9.2
2. Алексей Роза (DoctorRoza) 10.03.16 15:26
Конечно, воля Ваша, но я бы делал ТиС 8.3 на толстом клиенте и без всяких Такси, ИМХО!
Sup4ik; CaSH_2004; Oleg1708; Deda; +4 Ответить 1
3. Dmitry Vidmanov (etmarket) 10.03.16 15:37
Вот это заявка на успех! Автору удачи!
4. Дмитрий Краснопольский (Deda) 11.03.16 03:07
(2) DoctorRoza, Хорошо! Я буду иметь ввиду ваше пожелание при дальнейшей доработке конфигурации.
5. Сергей (Che) Коцюра (CheBurator) 11.03.16 03:36
Занятно.
Полезно.
Но уже плохо.
Нет системы.
Для начала - месяц - нарисовать "архитектуру", предполагаемый функционал.
Потом делать.
Иначе получится лоскутно-костыльковая вещь.
ТиС можно содрать практически 1-в-1
Обычно допилы в части ценовой политики.
И ОЧЕНЬ ВОСТРЕБОВАНО разделение прав/доступов - вплоть до видимости и/или доступности для редактирования реквизитов.
новую УТ11 писать я думаю смысла нет, а вот улучшенный вариант ТиС (хрен с ним, пусть даже не улучшенный, а 1-в-1) немножко подсмотреть полезного в СКАТ и Элементарной торговле (https://sites.google.com/site/elementarytrade/home) - можно.

Если подходить по серьезному - может получиться вполне нормальный "фриварный/опенсорсный" продукт, пользующийся спросом. Но только если подходить серьезно. Пока - замах есть, но несерьезный ;-) так что если серьезно - я бы поучастовал. Программить на 8-ке мне влом, да и не умею, но вот потестить, попинать в нужных направлениях (типовую ТиС 9.2 знаю, думаю, очень неплохо) - я бы поучаствовал (даже подарил бы в конфигу вариант решения мгновенного контроля исправлений задним числом по неуходу в минуса от исправления до сейчас).

А если еще прилепить сюда вменяемый блок адресного учета (могу поучастовать, опыт/наработки есть) - то вообще может получиться хорошо.
я - на связи.
nikaleks; the1; baracuda; Deda; +4 Ответить 1
6. Дмитрий Краснопольский (Deda) 11.03.16 03:44
(5) CheBurator, Благодарю, за советы! Действительно конструктивные, принял во внимание! Месяц нарисую, как оформлю документ ввода остатков. Тестирование в нашем случае необходимая вещь! Будем дружить :-)
7. Сергей (Che) Коцюра (CheBurator) 11.03.16 03:47
насчет толстый/такси - я б сильно подумал.
скольо наблюдаю - 99% времени персонал сидит в одном окне: либо пялится на "журнал", либо работает в документе, либо смотрит на какое-нит сводное "рабочее место".
8. Сергей (Che) Коцюра (CheBurator) 11.03.16 05:27
Могу предложить достаточно легкую настройку и методику использования факторинга
Допиливаются два документа всего
Акт передачи на факторинг
Отчет по факторингу
Типовая схема регистров для тис остается без изменений
Если надо будет - стучись, плкажу как сделано
9. Сергей (Che) Коцюра (CheBurator) 11.03.16 05:39
В рамках типовой тис хоть и можно реализовать - но для менеджеров получается трудоемко, надо подумать как это сделать красиво:
Описываю все на примере типовой тис
- реализованная в тис схема фиксации долгов/взаиморасчетов по договорам с фиксацией кредитного документа - вполне себе устраивает всех
- предлагается немного расширить в части (рулить настройкой для клиента)
1. Веден евзаиморасчетов кучей - то есть не фиксировать кредитный док в измерении, оставлять его пустым (типа как партионка по среднему в куче) - реализуется тривиально в полпинка
2. Штатный вариант договор-кредитный документ
3. Вариант ведения взаиморасчетов посделочно (одна реализация=одна сделка) - востребовано при отношениях с сетями - если по первым двум вариантам в основном важно должны мы или нам - то в этом варианте очень строго по какому конкретно - а так как в рамках одного договора по сетям могут грузиться разные магазины - которые по ряду причин нельзя выделить как отдельных клиентов и даже как отдельных грузополучателей - то оплаты идут не по порядку отгрузок а по конкретным реализациМ. Этот вариант реализуется по сути выделением сделки в отдельный договор с единственным документом отгрузки - то есть по сути это вариант 2 с ограничением - но как это сделать удобно - чтобы менеджерам не маяться с введением очередного Договора по шаблону основного договора - надо думать, наметки есть но надо думать

Возможно надо посмотреть как реализовано в ут11 аналогичные схемы
10. Сергей (Che) Коцюра (CheBurator) 11.03.16 05:43
ВАЖНО
Принципиально отказаться от порочной практики несоответствия ввода на основании и зафиксированным движениям по регистрам, обыденная ситуация: м енеджер-лавочник уверен что раз пко или выписка введены на основании реализации - значит они закрывают эту реализацию по оплате. В типовой тис это не так - закрываются долги не по структуре подчиненности а по фифо, подробнее можно посмотреть у меня пояснения злесь http://infostart.ru/public/175550/
11. Сергей (Che) Коцюра (CheBurator) 11.03.16 05:47
..то есть должен по максимуму использоваться вариант вививиг - что вижу то и есть
При этом сразу и жестко блокировать попытки ввода неверных ситуаций по типу: аыписка в 100 руб вешается на реализацию в 100 руб - но при этом внезапно реализация на 20 руб оплачена - хдесь должен быть запрет ибо нарушается принцип визивиг - привязано 100 рублей оплаты, а по факту привязалось всего 80, остаток 20 повис фиг его знает где.

Подумать как правильно разрулить иакую ситуацию - возможная часть вариантов в моей счылке в предпосте
12. Сергей (Che) Коцюра (CheBurator) 11.03.16 05:53
В регистрах взаиморасчетов - по покупателям/поставщикам - отказаться от измерения "вид долга" (за товары/за услуги) - это разруливать на уровне договоров

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

Думать
Вполне возможно что не так или совсем не так
13. Сергей (Che) Коцюра (CheBurator) 11.03.16 05:57
Документ "корректировка долга"
Типовая тисовская формулировка причем разная по отношению к покупателем/поставщикам - вводит юзверя в ступор. Формулировать просто - указывать корретируем по покупателю или поставщику и просто уменьшение нашего долга/увеличение нашего долга - прога сама перелопатит в нужном направлении покупатель или поставщик

Возможен вариант как в типовом тис - но пояснения тогда расписать чуть подробнее сразу на форме
14. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:03
Корректировка долга два режима:
Авторазноска корректируемого долга или с явным указанием корректируемых документов
Тогда в корректировке должна быть табличная часть в которой при авторазноске автоматом в табличную часть заносится корректируемые документы по общему правилу подбора (по фифо например) на требуемую сумму общей корректировки. Такое заполнение делается только один раз, далее при проведении дока отрабатывает вариант с указанием погашаемых документов, см ниже (автоподбор документов может быть перезаполнен принудительно по кнопке)

С выбором корретируемых документов вручную - совершенно аналогично как выше, только доки набираются не автоматом, а пользователе с использование например галочек в таблице-запросе непогашенных доков

Учесть также что возможно надо указать и вид долга для каждого погашаемого документа..?
15. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:06
Наряду с типовым корретировкой долга сделать типовой документ взаимозачета
Между долгами покупатель-покупатель, покупатель-поставщик, поставщик-поставщик
С учетом договоров?
Заполнение аналогично корректировке долга - обязательно должно быть видно в табличной части какие документы погашаются
16. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:14
Тщательно подумать
Сделать по подобию типовых конфиг - их всетаки не дураки разрабатывают, со многими решениями в типовых конфигах я вынужден согласиться
Например
Припервом проведении документа в тч дока фиксировать получившееся авторраспределение какоелибо - например, что оплата легла конкретно на такието отгрузки. Эти отгрузки погашенные оплаатой - фиксируем гдето - например в тч дока
Все последующие проведения в первую очередь стараются сделать так, чтобы припроведении получилось точно то что зафиксировано в тч дока. Если не получилось - тогда уже пытаемся заново распределить. Отклонения текущего распределения припроведении от предыдущего либо сразу стопорим или - возможно регулируется глобальной настройкой - проводим как получилось, все отклонения от предыдущего проведения гдето фиксируем

Самый простой пример: в типовой тис - напечатали клиентту счф, все ок
Спустя какое о время клиент просит напечатать счф заново или выставить ту же самую но с учетом вычерка - то нсть переделать документ. Печатаем - получаем совершенно другие гтд по куче позиций.

Реализация такого варианта есть, успешно работает, позволяет спокойно спать
17. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:22
Есть особо упоротые клиенты
Например сети
И не только они
Для них не подходят стандартные формы например счф
Пример: клиент хочет чтобы в торг12 были одни инн/кпп указаны, а в счф - инн/кпп другие при совпадении всех остальных реквизитов.
И таких хотелок вагон
Вменяемых вариантов программного заполнения по таким хотелкам реализовать не удалось. Самая простая, логичная и легко прослеживаемая и контролируемая система при которой к одноэсника не болит голова - подткаждый первичный документ есть тупаф форма со всеми реквизитами которые ДОЛЖНЫ БЫТЬ В Этой ПЕЧАТНОЙ ФОРМЕ - вот что туда ответственное лицо - менеджер/бухгалтер - впишет - то и будет печататься 1-в-1
Запилил такую систему у себя - стал спать спокойно. Как реализовать - форма с полями или регистр сведений или вообще готовый макет со стационарновбитыми данными - вопрос технический. Суть: всякие значения для заполнения документов берем не из карточек клиентов а из значений соответсвующих полей сооттветствующих печформ.
18. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:24
Сильно подумать о реализации учета в разрезах характеристик цвета/размеры/сернумы и прочее
19. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:29
Возврат от клиента
Тупо запретить/ не реализовывать вариант без указания документ-основания
Возврат - только на основании реализации

При возврате обязательно проверять непревышение возврата над реализацией

Типовая тис тупо пропустит вариант
Реализация 100 шт
Возврат1 70шт
Возврат2 50шт

Возвраты - мегаболезненное место практически у всех
Предусмотреть вариант некой загрузки возвратов - мастер возвратов типа - когда подсасываем количество возврата требуемое и автоматически вычисляем - с учетом уде ранее сделанных возвратов - по каким документам какие возвраты надо сделать и тупо сами их генерим
20. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:32
Гтд для импорта и для отечественных товаров
Гораздо проще все свести к одному
Гтд должна указываться всегда, даже для отечественных товаров
Для отечественных товаров тупо юзер подмтавляет болванку "отечествееной гтд" - где номер гтд 4 прочерка как обычно указывается для отечественных гтд
21. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:36
Ряд клиентов- обычно сети - требуют в отгрузке соблюдения оригинального порядка строк исходной заявки

Сделал тупо
Во всех тч всех доков есть скрытая служебная колонка ОПС - оригинальный порядок строк - там где надо просто проставляется нумератор строк, сортировка которую может делать юзер всегда идет как ОПС+реквизитсортировки. Для незаполненных опс жквивалентно сортировке по реквизиту.

Необходимость заполнения опс регулируется соответсвующей предопределенной зарактеристикой клиента
22. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:40
В типовой тис если реализация по товарному составу меньше заявки - часть заявки оставалась непогашенной. Для большинства клиентов длинные заявки по которым возможны несколько отгрузок - непрозрачны, трудноконтролируемы.

ПОЭТОМУ проще когда даже неполная реализация ЗАКРЫВАЕТ ЗАЯВКУ ПОЛНОСТЬЮ
И клиент если е у надо выставляет новую заявку
Вариант длинных или коротких отгрузок регулируется предопределенной зарактеристикой клиента/договора

У меня все заявки - корткие
В типовой тис это реализуется вставкой одного оператора присвоения в нужное место глобальной процедуры
23. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:46
Типовая тис никак не защищена от кривыз минусовых резервов
Например по регистру остатков = 100, в резерве = -40, по факту на свободных остатках действительно 100
Приходит заявка на 130шт
Тис считала тупо
доступно = остаток - резерв = 100 - (-40) = 140
Заявка в полном составе принимается на обслуживание, потом начнается (_._)
В тисе правится тривиально, но так до сих пор эта дырка в типовой есть

Учесть это в восьмерочной конфигурации!!!
24. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:47
.. Вот накидал малость по мелочам
25. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:50
В типовой тис есть дырка, которая приводит к труднообнаруживаемым нарушениям в учете которые получаются пересортами, хотя их не должно быть - связано с указанием свойства партии
26. Сергей (Che) Коцюра (CheBurator) 11.03.16 06:56
Отгрузки с отложенным переходом права собственности
Допилил такое, реализуется достаточно просто
Надо будет - стучись
27. Владислав Чинючин (vcv) 11.03.16 07:01
Подписываюсь. Я б тоже поучаствовал в серьёзном проекте.
28. Сергей (Che) Коцюра (CheBurator) 11.03.16 07:03
В разрабатываемом решении следует сделать обязательно какойнить простой вариант, готовые шаблоны оперативной загрузки данных - заявок, например
То есть некий механизм плугинов для каждого вида документа для каждого клиента
1-2 готовых варианта загрузки - типа из плоского экселя по столбцам артикул-количество, из плоского текста с разделителями
29. Сергей (Che) Коцюра (CheBurator) 11.03.16 07:05
(27) категорически приветствую!!!

Есть соображения
Самое первое - кто в мск - очная встреча.
Прошу обдумать данное предложение.
30. Сергей (Che) Коцюра (CheBurator) 11.03.16 07:06
Маня декларировал что он тупой ковертицие 77 на 8ку типовыми инструментами - получил практически работающее приложение, ручной доводки надо было мало
31. Сергей (Che) Коцюра (CheBurator) 11.03.16 07:09
В команде хорошо бы иметь спеца по ут11 - там есть ряд интереснополезных моментов.
Он бы пинал нас в нужном направлении или хотя бы критиковал.
Но боюсь таким спецам по ут наша возня будет неинтересна
32. Денис Новосёлов (binex) 11.03.16 07:19
(26) CheBurator, не хилая такая заявка на доработку. Похвально.
33. Дмитрий Краснопольский (Deda) 11.03.16 07:23
(19) CheBurator, А как же быть с возвратом от клиента если были вводы остатков и реализации остались в прошлой базе? В ТиСе есть возможность указания себестоимости в ВозвратеОтПокупателя и соответственно создается новаПартия с ПриходнымДокументов - ВозврОтПокуп...
34. Дмитрий Краснопольский (Deda) 11.03.16 07:25
(29) CheBurator, Очная встреча правда необходима, но я в Иркутске :( Поэтому можно групповой SKYPE организовать)
35. Владислав Чинючин (vcv) 11.03.16 11:39
(34) Deda, С очной ставкой не выйдет. Магнитогорск. Как раз посерёдке между вами :)
36. Oleg karp (Oleg1708) 11.03.16 11:59
Адресное хранение и ценообразование очень нужно в такой конфигурации.
37. Сергей (Che) Коцюра (CheBurator) 11.03.16 12:08
(33) Забить на возвраты в начале ведения учета. такие возвраты - возможность делать только через ПоступлениеТМЦ - смирится с этим. Потом такое поступление Взаимозачетом зачесть в отгрузки.

" В ТиСе есть возможность указания себестоимости в ВозвратеОтПокупателя" - скольок ни смотрел - никто из типа ведущих учет в ТиСе - нихрена там не забивает. Поэтому все возвращаемые себестоимости - спрятать нафиг от пользователя, все автоматом. ТОЛЬКО НА ОСНОВАНИИ РЕАЛИЗАЦИИ.
38. Сергей (Che) Коцюра (CheBurator) 11.03.16 12:10
(32) "фигня какая-то" ;-)
Это не заявка на доработку, это то, что тупо всплыло в голове в мутном состоянии ночью глубокой...
39. Сергей (Che) Коцюра (CheBurator) 11.03.16 12:13
(36) Про ценообразование - черкани пару строк, что хочется.
Про адресное хранение - тут надо сильно подумать, чтобы не свалиться в излишества.
40. Владислав Чинючин (vcv) 11.03.16 14:01
(39) CheBurator, Думаю, большое количество потребностей в "адресном хранении" закроет иерархический справочник складов с возможностью указывать в документах/отчетах склад-группу. И склад в табличной части документа.
41. Роман Озеряный (rozer) 11.03.16 16:24
(6) Deda, в 2009 году в нашей компании было принято решение переписать ТиС9.2 на платформу 1с 8.1 мы потратили 1 год и около 7 лимонов рублей (60% кода было написано франчем) и работаем на ней до сих пор (около 250 пользователей) . Мы сравнивали а не писать ли под УФ и решили не писать... ну вод такая история. А вам - удачи !
42. Евгений Плешивцев (infosoft-v) 11.03.16 16:33
(29) CheBurator, я то же за скайп, т.к. Волгоград. Готов принять участие. Знаю немного Ут11 (есть два внедрения)
CheBurator; Deda; +2 Ответить
43. Роман Озеряный (rozer) 11.03.16 16:37
+ (41) продолжим )

(31) CheBurator,

 Но боюсь таким спецам по ут наша возня будет неинтересна 


это точно, за 6 лет мы так обкостылили нашу поделку на 8.1 что теперь переводим весь этот ужос на УТ11. Короче бросайте эту затею - архитектура УТ11 хорошо придумана + с партионкой намучаетесь - вспомните что ГП надо восстанавливать тогда уж лучше УТ10.3. А такое пилить или по заказу за бабло - просто коробку не продать будет. Для кого хотите делать для "стариков" которые любят ТиС9.2 (сам с ней работал 5 лет) ?
44. Дмитрий Краснопольский (Deda) 11.03.16 18:45
(43) rozer, Добрый день! О границе последовательности уже подумано и она прекрассно восстанавливается в данном конфиге. Проверяйте! И еще как вы думаете за сколько минут в маловесном данном конфиге восстанавливается ГП? На то и упор - на скорость. К примеру восстановить 4000 документов сейчас занимает меньше минуты...Партионный учет уже есть, но немного подкорректировать осталось... опять же проверяйте и увидите... :) Благодарю за конструктивную критику!
45. Дмитрий Краснопольский (Deda) 11.03.16 18:48
(43) rozer, И еще главный момент, - работаем не на коробку, но ради удобства и простоты большинства пользователей, принципиально бесплатный фриварный продукт, для людей которые ищут альтернативные маловесные конфиги под конкретные задачи. :-)
46. Роман Озеряный (rozer) 11.03.16 20:13
(45) Deda, оставьте в ут два регистра и там будет шикарная скорость восстановления ГП особенно если не очищать движения автоматом и не трогать не измененные данные как в ут11 а для инфо может не в курсе - магазька уже бесплатна а функционала там немного поболее... А так просто завидую по хорошему людям которые в учебных целях могут тратить время на такое бесплатно (сам давно когда-то таким был) а когда у тебя большая семья и работаешь один это как-то понять и мотивировать на такое сложно. Ну ладненько - удачи!
www2000; Deda; +2 Ответить
47. Сергей (Che) Коцюра (CheBurator) 11.03.16 20:43
(43) rozer,
много думал/думаю на эту тему.
вообщем да - мне УТ11 вполне показалась.
48. Сергей (Che) Коцюра (CheBurator) 11.03.16 20:46
(44) Deda,
если писать чисто УУ-конфу, то вполне можно обойтись без процесса восстановления ГП. просто исключив исправления и внос документов задним числом. Все вносим/исправлеям в "сейчас". но, боюсь, что такое не найдет понимания в широких кругах лавочников.
49. Сергей (Che) Коцюра (CheBurator) 11.03.16 20:49
На размышление/обсуждение.
отказаться от типового механизма фиксации "основной единиц измерения" - за все время ни разу не видел, чтобы народ работал в основных единицах. Все работают в базовых. То есть карточка клиента в которой указана базовая единица и все. При этом остальных единиц измерения - может быть неограниченное количество. Они используются в основной работе. Их же допускается использовать - ручным выбором юзверем и в документах.
50. Сергей (Che) Коцюра (CheBurator) 11.03.16 21:56
В подавляющем количестве случаев выписка счф производится по кнопке из документа реализации тупым техническим методом - нажать кнопкк - в открывшейся новой форме документа счф жмем ок (записать-провести-закрыть). Все. То есть тупые технические действия которые по большей части менеджеры врспринимают как тупую лишнюю работу
У себя сделал подписку на проведение реализации и автосоздание счф. Все довольны. Имеет смысл сделать аналогично, тем более что подписки на события штатно в восьмерке. Или иным способом но суть - автогенерация счф при проведении реализации у которой нет счф
51. Сергей (Che) Коцюра (CheBurator) 11.03.16 22:21
Концепция корректировки заявок как она есть в тис
В целом вполне работоспособно
За исключением полной невозможности работать с заявками в терминах журнала документов, так как с точки зрения менеджера заявка одна - по состоянию на сейчас - а в программе это целая цепочка корректировочных заявок. Менеджеры тупо выпадают в осадок, а все что надо - показывать для оперативной работы только текущее состояние заявок - то есть некий псевдожурнал-список, который показывает только незакрытые активные заявки, с выделение просроченных цаетом или както иначе. У меня так сделано и все менеджеры практически постоянно сидят в этом псевдожурнале где основные действия ввести новую заявку, закрыть заявку, скорректировать заявку. Корректировка заявки в виде новой заявки с автозаполненными показателями всеми у менеджеров не вызывает вопросов - менеджер правит нужные данные и проводит заявку и ее текущее состояние отражается в обновленном псевдожурнале. Внимание: ненужная заявка закрывается штатным образом, а не удаляется - это непрвильно!
В обычный журнал менеджер заходит изредка, больше для служебных целей. Основное правило: проведенная заявка не может быть изменена - только вводом корректировочной. Это автоматом снимает проблемы с гп и проблемы с любителями увеличивать например резерв путем изменения заявки в прошлой неделе - и получается жпс.

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

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

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

По снеговику не спец
52. Сергей (Che) Коцюра (CheBurator) 12.03.16 04:47
Deda, сделай партионку еще "по-среднему" - реализуется просто (галка/список в настройках организации по выбору вида партионки - как есть в ТИС) по типу "по среднему= ФИФО при одной партии" - в измерении пустая партия, все кладешь на нее. Штатный алгоритм, который отрабатывает ФИФО - штатно такой вариант будет давать такой же результат как по-среднему.
53. Владислав Чинючин (vcv) 12.03.16 05:17
(49) CheBurator,
Про единицы измерения.
По моему, достаточно регулярно востребован учет одновременно в нескольких единицах. Продаём во всяких разных единицах, а общая управленческая отчетность в тоннах, литрах, метрах...
(50) CheBurator,
Не знаю, как у вас, а у меня по причине требований налоговой приходится выписывать по нескольку счетов фактур к одной реализации. Одну для собственного товара, и, отдельно, по одной для каждого комитента. Поэтому автовыписка с/ф сделана явно и с обязательной печатью. Потому что, бывает, при банальном выборе другой партии в документе приходится отдавать покупателю новые счета-фактуры.
(51) CheBurator,
Про корректировки.
В ТиС довольно легко допиливается возможность корректировки практически любого документа. Заявок, поступлений, реализаций... С соответствующим формированием проводок. У меня активно используется по причине особенностей работы с поставщиками.

К заявкам, по моему, важней корректная цепочка - заявка (с корректировками) - приказ на отгрузку - реализация.
У тебя такое реализовано? Я никак не соберусь :)
54. Сергей (Che) Коцюра (CheBurator) 12.03.16 05:33
(53)
Про единицы измерения.
"По моему, достаточно регулярно востребован учет одновременно в нескольких единицах. Продаём во всяких разных единицах, а общая управленческая отчетность в тоннах, литрах, метрах... " - учет одновременно в нескольких единицах - это несколько из другой оперы. И в ТИС он не реализован никак. Пересчет погонные метров в тонны и тому подобное - это скорее варианты вывода отчетов. когда одна единица пересчитывается в другую по правилам, определяемым либо коэффициентами либо "плугинами"
55. Сергей (Che) Коцюра (CheBurator) 12.03.16 05:35
(53)
"Не знаю, как у вас, а у меня по причине требований налоговой приходится выписывать по нескольку счетов фактур к одной реализации."
это всетаки достаточно экзотический вариант, как и одна СЧФ на нескольо накладных. просто в настройках отрубаем автогенерацию СЧФ 1-в-1 и выписвааем как надо.

"Потому что, бывает, при банальном выборе другой партии в документе приходится отдавать покупателю новые счета-фактуры." - если ручной учет партий - то да, это понятно. если автовыбор партиф (гтд) в счф - выше я описал как это можно будет реализовать ПРИ НЕОБХОДИМОСТи.
56. Сергей (Che) Коцюра (CheBurator) 12.03.16 05:46
(53)
Про корректировки.
"В ТиС довольно легко допиливается возможность корректировки практически любого документа. Заявок, поступлений, реализаций... С соответствующим формированием проводок. У меня активно используется по причине особенностей работы с поставщиками. "
- в типовой ТИС джля этого не надо ничего дописывать побольшому счету:
.корректировка заявок поддерживается штатно (обсосано мной от и до)
.корректировка поступлений - нет такой фигни (если привязываться к бухпроводкам): любая корректировка поступления ведет либо к корректировочной счф В ЧАСТИ УЧЕТА НАЛОГОВ, ТО ЕСТЬ ОТНОШЕНИЙ С ГОСУДАРСТОВМ. а как докинуть или снять часть суммы с поступления поставщика - ту вагон возможностей даже штатно - "возврат поставщику" и новое поступление (что автоматом приведет к правильным суммам в учете, обороты - отдельная история) или документ "корректировки" - который тупо докидывает разницу (по типу доп.расходов в типовой ТИС). если речь идет о бонусах и премиях - то они вообщем тоже реализуются шттано как пример - поступление (прочее) услуга, с взаимозачетом на взаимрасчеты по товару. или иным способом.
.корректировка продаж - аналогично поступлениям.

я бы не стал типовой ТиС в части клона что-то переделывать в этой части (ПОКА). все таки конфа универсальнйо должна получиться. Кого не устроит - допил отдельный (или развитие функционала) - нет смысла писать НОВУЮ УТ11

А вот отложенный переход права собственности (на складе покупателя) - это уже чуть ли не стандарт. его было бы смысл впилить нормально (реализуется просто), а не притянутыми за хвост складами "товар в пути"... где под каждую отгрузку свой склад придется делать...
57. Сергей (Che) Коцюра (CheBurator) 12.03.16 05:54
(53)
"К заявкам, по моему, важней корректная цепочка - заявка (с корректировками) - приказ на отгрузку - реализация.
У тебя такое реализовано? Я никак не соберусь :)"

- цепоряка заявок в ТИС - реализована штатно (описывал выше, требуется мелкая дорабтка для номера "сделки" да и то в рамках8-ки это может штатно получится - надо советоваться, писал выше)

- приказ на отгрузку смысла нет в клоне ТИС писать. - мы же не хотим писать новую УТ11 или полностью ордерную схему (пока)?
приказ на отгрузку реализуется в полпинка - перведом заявки со склада "основной склад" на виртуальный (или вполне реальный) склад "зона готовых к отгрузке" (готовые может сразу пониматься как и разрешенные, а разрешенные = приказ - может отдельно - то есть "основной склад" - "готовые к отгрзке" - "разрешенные к отгрузке". Реализуется в полпинка (простая обвеска не трогая глобальный код даже можно сделать). Операторами/юзерами авыполняется по нажатию кнопки.

Все что на складе "разрешено к отгрузке" - по нему выписывается реализации. на остальных - заблокировано.
у меня это реализовано статусами заявок (но делалось это давно и сейчсас бы чуть по другому сделал)

Рез.ме: в рамках создания КЛОНА - я бы не морочился (пока) реализацией этого функционалда как стандартного. На штатный функционал клона mnfrfz пришлепка реализуется в полпинка при необходимости - затраты на клюшках - пару часов если красиво и аккуратно.
58. Сергей (Che) Коцюра (CheBurator) 12.03.16 05:56
"приказ на отгрузку реализуется в полпинка - перведом заявки со склада "основной склад" на виртуальный (или вполне реальный) склад "зона готовых к отгрузке" (готовые может сразу пониматься как и разрешенные, а разрешенные = приказ - может отдельно - то есть "основной склад" - "готовые к отгрзке" - "разрешенные к отгрузке". "

- причем состав заявок - !!!все штатным функционалом!!! - готовых к отгрузке и/или разрешенных - тривиально и содержательно (даже со всей истрией движений) смотрится типовыми отчетами ОтстакиТМЦ и Ведомость по остаткам ТМЦ
59. Владислав Чинючин (vcv) 12.03.16 13:19
(55) CheBurator,
это всетаки достаточно экзотический вариант, как и одна СЧФ на нескольо накладных

Всего лишь комиссионная торговля. И мы обязаны отражать в книжках и журнале с/ф отдельно свой товар/услуги, отдельно комиссионные по каждому комитенту. Притом налоговая хочет, что бы легче проводить перекрёстную проверку, не только отдельными строками в книжках и журнале отражать, но и выдавать отдельные с/ф.
(56) CheBurator,
Про корректировки.
- в типовой ТИС джля этого не надо ничего дописывать побольшому счету:

Тут я о своём геморрое радею. В металлоторговле есть такая засада. Вот ты взял металл у производителя, отгрузил его покупателю, успешно закрыл месяц. И где-нибудь в середине следующего месяца от производителя сваливается исправление чуть ли не половины всего месячного поступления с новыми ценами. И это безобразие нужно текущим периодом отразить, да так, что бы себестоимость не зависла. Еще и части покупателей, согласно условиям договоров, выставить по новым ценам.
(57) CheBurator,
приказ на отгрузку смысла нет в клоне ТИС писать

Я опять о своём. У меня часто случается подписывание договора и спецификации на поставку (это заявка), который будет вывозиться не весь и не сразу. Особенно с тендерами. Подписали спецификацию, а вывозить металл по ней будут полгода чуть ли не каждый день. А склад, вдобавок, зачастую арендованный и хранитель хочет бумажку на конкретно сегодняшнюю отгрузку в конкретный сегодняшний камаз. Как-то без отдельного документа грустно.
Но, вроде, и касательно других возможных пользователей. Иметь отдельной бумагой приказ кладовщику от менеджера полезно для наведения порядка.
60. Сергей (Che) Коцюра (CheBurator) 12.03.16 14:46
Подписали спецификацию, а вывозить металл по ней будут полгода чуть ли не каждый день. А склад, вдобавок, зачастую арендованный и хранитель хочет бумажку на конкретно сегодняшнюю отгрузку в конкретный сегодняшний камаз. Как-то без отдельного документа грустно.


ээээ! вы не смешивайте спецификацию, то есть, грубо говоря, товарную матрицу договора. с заявками, которые отражают РЕАЛЬНО происходящие физические процессы. Я очень сомневаюсь, что по спецификации СОБИРАЕТСЯ СРАЗУ ВЕСЬ ТОВАР в одну большую кучу, и потом постепенно происходит типа "вот из этой большой кучи надо отгрузить вот такую кучку поменьше вот такого-то числа". Для склада заявкой на исполнение будет являться как раз "вот такая кучка поменьше на отгрузку вот такого-то числа". Все операции с такой кучкой и будут являть собой собственно складскую работу и складские документы. и вполне реализуется стандартной схемой работы заявок в типовой тис. Да, может быть несколько неудобно, но реализуемо (например, приказом на отгрузку может быть появление НЕПРОВЕДЕННОЙ РАСХОДНОЙ НАКЛАДНОЙ с пустой табличной частью. Новые накладные склад не имеет права создавать (тупо отобрано правами шттано), может только оперировать с уже существующими). А вот "спецификация" - как раз попадает под классификацию заявки как "длинной" - практически один-в-один такая схема работы как ты написал по металлопрокату у меня была в фармопте при отгрузках на бюбджетный фармации. Одна большая заявка (которая даже еще в большей части своей и на складе нет) - которая потом месяц-полтора отгружалась кучей накладных. И ничего - справились типовыми объектами метаданных.
61. Сергей (Che) Коцюра (CheBurator) 12.03.16 14:50
Что и как делать - презумпция автора разработки.
Имхо, делать клон, заточенный на какую-то специфику именно автора - имеет место быть такая парадигма.
Но тис 9.2 получила такое широкое распространение именно ввиду свойе относительной простоты, и при этом вполне достаточной функциональности ДЛЯ БОЛЬШИНСТВА. Специфику точил каждый сам (тем более что дотачивается достаточно легко).

Такая концепция представляется мне обоснованной. Я бы и придерживался ее. Вплоть до "соглашения" не вводить новых объектов метаданных, предназначенных для отражения частных специфик. Свои предложения я автору высказал в этом отношении - я думаю, мы их обсудим на конференции.
62. Сергей (Che) Коцюра (CheBurator) 12.03.16 14:55
еще раз: писать новую УТ11 - смысла нет. Надо где-то остановиться. остановить СЕБЯ.
Имеет смысл делать легкие улучшения, которые реализуются только добавками в код типовой (например, деление, заявок на длинные и короткие). новые метаданные/виды документов - имеет смысл делать (да и то надо думать/принимать решение), если это представляет из себя некий новый отдельный блок, которого не было в типовой, которые не встраивается в уже существующие цепочки документов (например, реализация факторинговых операций - где просто появляются два новых вида документа типа акт о передаче на факторинг и отчет по факторингу в конце месяца).

Как-то вот так я представляю себе доработки НОВОГО функционала.
63. Владислав Чинючин (vcv) 12.03.16 19:36
(60) CheBurator,
ээээ! вы не смешивайте спецификацию, то есть, грубо говоря, товарную матрицу договора. с заявками, которые отражают РЕАЛЬНО происходящие физические процессы.

У меня они в предметной области смешаны. Спецификация от обычного счета отличаются де юре, а не по факту отработки. Когда клиент подписывает спецификацию или берёт счет, ни кто не может сказать, за сколько дней и сколькими машинами он это будет вывозить. Разве что спецификация обычно имеет больший тоннаж и чаще выводится не за раз.
(62) CheBurator,
еще раз: писать новую УТ11 - смысла нет. Надо где-то остановиться. остановить СЕБЯ.

Это да. Но всё же предлагаю:
- Возможность ведения взаиморасчетов с разрезе счетов, множественное указание кред.документов в документах банка и кассы.
- Человеческий взаимозачет/переуступка долга.
- Приём на хранение, передача на хранение (расширение стандартной комиссии)
- Нормальное распределение доп.расходов на себестоимость при поступлении и прочих операциях, возможность указания доп.расходов сразу при поступлении
- Может быть векселя?
- Учет на складе по качеству и доп.характеристикам поставки, складская пересортица
64. Сергей (Che) Коцюра (CheBurator) 12.03.16 21:43
- Возможность ведения взаиморасчетов с разрезе счетов, множественное указание кред.документов в документах банка и кассы.

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

Про кред.доки в доках банка и кссы - тоде писал выше, поддерживаю

- Человеческий взаимозачет/переуступка долга

Писал выше, поддерживаю

- Приём на хранение, передача на хранение (расширение стандартной комиссии)

У себя сделал тупым доп регистром переданные на ох по образу комиссии и два дока передача и возврат по ох. Работает ок. Проблем нет. Достаточно будет акты мх1,3 - они есть - журнал актов, и ведомость инвентаризации ох - там есть некоторые мелкие засады. Стоит ли заводить отдельный регистр под ох или можно обойтись регистром комиссионеров - с довидом операции комиссия или ох - надо смотреть. Есть засады спартионкой при учете комиссии и ох - разная логика, надо совещаться

- Нормальное распределение доп.расходов на себестоимость при поступлении и прочих операциях, возможность указания доп.расходов сразу при поступлении

Согласен.
Но надо подумать.
Вполне возможно что отдельной табличной часть допрасходы класть как и в поступлени, так и в реализации - надо посовещаться по мотивам ветки на мисте. Отдельный документ допрасходов также останется скорее всего как и в тис, вводится на основании. Есть засада - надо думать - акты допрасходов могут быть в апреле, а сами поступления/отгрузки в марте - будет нестыковка. Даже движения апрельского допрасхода вроде нсть возможность сделать движения в регистры мартом (?) - но это может повлечь неоднозначности, особенно при использовании таких допрасходов. Гденить в бухии. В целом надо сделать, но надо подумать.
Вариант указания допрасходов в одном документе возможен только если допрасходы идут от того же поставщика по тому же договору - иначе в одном документе надо будет вводить еще допклиентапоставщика услуг и договор - будет некрасиво. А ввод допрасходов в реализации аналогично в документе если мы сами создаем эти допрасходы, если сторонний поставщик кслуг то документом отдельным. Получается сильно выморочено - много альтернатив. Лучше оставить допрасходы только одним документом (с табличной частью перечнем документов поступления и реализации) - такое у меня вообщем тоде реализовано - в фуре идет сразу несколько поставок и доставка раскидывается на несколько поставок - пришлось всего лишь чуток подправить код допрасходо в по поставке. Короче надо делать но посовещаться.

Тут я считаю что: в связи с целевым назначением конфиги она должна быть проще. В том числе именьше альтернатив сделать нужное движение. Иначе это затруднит реализацию.

Итого я практически присоединяюсь

- Может быть векселя?
В рамках типовой тис это прекрасно реализуется без всяких допсущностей вроде. Надо посовещаться

- Учет на складе по качеству и доп.характеристикам поставки,
Складу и менеджерам вообщем допхарактеристики поставки пофиг. Учет по допхарактеристикам товаров (сюда же попадает и качество) - да, надо делать

складская пересортица
- нет такого варианта. Есть списание недостачи и оприходование излишка (что в соответствующих инвентарных ведомостях замыкается дркг на друга и показывается как пересорт). Имеет смысл сделать допскладской документ Пересорт, в котором в одной строке номенклатура-характеристики-количество-сумма недостачи и аналогично напротив излишек. Проведение будет практически полностью идентично проведению списания + проведению излишка. Привводе на основании инвентаризации включить пересорт в вычитание отклонений для ввода нового документа списания/оприходования/пересорта - как это сейчас слелано штатно в тис. То есть пересорт реализуется вполпинка.

Во всем этом лично для меня сложность в учете по допхарактеристикам
65. Владислав Чинючин (vcv) 13.03.16 10:47
(64) CheBurator,
Под измерение счет нет необходимости выделять отдельное измерение, прекрасно реализуется штатным функционалом, достаточно сделать быстрое человеческое превращение "счета" в отдельный элемент справочника договоров по шаблону группы договора.

Я тоже делал на штатном функционале, но только не на справочнике договоров, а использовал измерение КредДокумент. Там, где расчеты по договору указано вести по счетам, обязательно указание креддокумента вида ЗаявкаПокупателя и обязательно распределение долгов/оплат по креддокументам.
Приём на хранение, передача на хранение (расширение стандартной комиссии)
У себя сделал тупым доп регистром переданные на ох по образу комиссии и два дока передача и возврат по ох. Работает ок. Проблем нет.

У меня доработана штатная комиссия. Новый статус партии, несколько новых кодов операций. Тоже работает :)
Нормальное распределение доп.расходов на себестоимость при поступлении и прочих операциях

У меня, в связи с вышеупомянутой массовой корректировкой приходов от поставщиков и, естественно, доп.расходами от каких-нибудь транспортников, которые приходят хорошо если в первой половине следующего месяца, доп.расходы приходуются в виде корректировки движений. То есть, когда приходуются доп.расходы отдельным документом, анализируются все движения партий, на которые списываются доп.расходы (имею жесткий партионный учет), и датой документа доп.расходов делаются движения на разницу себестоимости.
Если например, был документ реализации с движениями
ПартииНаличие расход количество=1шт с/с=1000руб
Продажи приход количество=1шт с/с=1000руб ПродСтоимость=1200руб
Приходую доп.расход по этой партии на 100 руб когда-нибудь позже реализации. Документ доп.расходов делает движения с такими же измерениями и реквизитами, что делал документ реализации, но на сумму 100руб.
В результате, если смотрю, например, продажи за большой период, захватывающий и реадизацию и доп.расходы, вижу себестоимость 1100 руб и выручку 1200 руб.
Получается всё корректно и с аналитикой. И даже если партия не просто продалась, а еще и перемещалась, доприходовалась, возвращалась от покупателя - везде вижу нормально закрытые регистры, нормальные обороты по проводкам и нормальную упр.аналитику по себестоимости.
Складу и менеджерам вообщем допхарактеристики поставки пофиг. Учет по допхарактеристикам товаров (сюда же попадает и качество) - да, надо делать

Позвольте не согласиться. В доп.характеристиках поставки хорошо выглядит, например, к "Пальто женское" характеристика "красное с перламутровыми пуговицами". Что бы не раздувать бесконечно номенклатуру.
складская пересортица
- нет такого варианта. Есть списание недостачи и оприходование излишка (что в соответствующих инвентарных ведомостях замыкается дркг на друга и показывается как пересорт)

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

Ну если уж говорить про штатный функционал, свойство партии и есть доп.характеристика поставки.
Только штатный функционал требует жесткого партионного учета для использования этих "доп.характеристик". Потому что автосписание партий о них ни сном ни духом.
66. Дмитрий Краснопольский (Deda) 13.03.16 11:57
Друзья! Есть ли у кого возможность или желание дописать к этому конфигу небольшой модуль установки цен номенклатуры? Либо как в ТиС7.7 либо как в УТ11 или скрещением? Либо по-нашему попроще :)
67. Il Il (Il) 13.03.16 12:20
И итоге со всеми хотелками - получаем УТ10.3...
думаю идея автора самая верная - базовый функционал, а остальное кто как хочет допилит.
sys1c; CheBurator; Deda; +3 Ответить 1
68. Владислав Чинючин (vcv) 13.03.16 14:06
(67) Il,
И итоге со всеми хотелками - получаем УТ10.3...
думаю идея автора самая верная - базовый функционал, а остальное кто как хочет допилит.

Если так подходить, лучше просто брать УТ. Гораздо проще по трудозатратам "отпилить" ненужный функционал (хотя бы скрыть ролями), чем допиливать ненужный. Бонусом получишь еще и развиваемую конфигурацию на поддержке, что бы не париться с вопросом с/ф и разновсяческой регламентированной отчетности и форм документов.

Наверное, если пилить что-то альтернативное, нужен альтернативный подход. Может быть смена документарной идеологии на другую. Например, процесс согласования заказов клиентов может породить длинную цепочку документов корректировки, которая только замыливает взгляд менеджера в журнале. Аналогично для процесса утверждения заказа поставщику. Работа со складом тоже далеко не всегда хороши ложится на документ (про склад Чебуратор лучше меня скажет, у него этот вопрос навороченней).

Было в прошлом тысячелетии такое понятие - АРМ. Автоматизированное Рабочее Место. Притом под ним обычно подразумевалась не настройка ролей при том же самом принципе работы "журнал-документ-отчет", а интерфейс, адаптированный под потребности и особенности.
69. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:13
(65)
Я тоже делал на штатном функционале, но только не на справочнике договоров, а использовал измерение КредДокумент. Там, где расчеты по договору указано вести по счетам, обязательно указание креддокумента вида ЗаявкаПокупателя и обязательно распределение долгов/оплат по креддокументам.

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

Например:
- выставили счет на 100 руб - во взаиморасчеты надо отражать? - вообщем-то нет, так как счет/заявка - это всего лишь некое ПРЕДЛОЖЕНИЕ клиенту. если отразили заявку во взаимлорасчетах - сразу поис долг. а клиент забил на эту заявку - вместе с закрытием заявки (которую забил клиент) - надо закрывать и взаиморасчет.
- если при проведении документов по взаиморасчетам (платежи/отгрузки) в кред.документе указывать счет/заявку, по которому идут эти взаиморасчеты - это уже как-то ближе к действительности и мне больше нравится. Но это приводит к тому, что нельзя выписать платежи/отгрузки без указания документа/основания (по которому можно вытащить заявку). А с учетом того,что в Типовой ТИС корректировка заявок выполняется не в смой исходной заявке, а корректировочными заявками (а как это в 8-ке делать? - ВОПРОС!) - то идентификация "корневой" заявки, которую надо указывать в документах взаиморасчетов - нетривиальная задача, если только во все документы не вводить дополнительный реквизит "сделка" (счет/заявка) - чтобы пропускать документы по этой сделке и она автоматом попадала в кред.документ - в итоге - это тоже самое, что элемент справочника "договоры" в группе какого-то договора.

Не мог бы ты более развернуто пояснить как у тебя работает/построена схема когда в кред.документе указывается заявкаПокупателя?
70. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:16
"У меня доработана штатная комиссия. Новый статус партии, несколько новых кодов операций. Тоже работает :) "
- тоже можно, но мне кажется что более правильно концептуально - новый/отдельный участок учета/работы - новый/отдельный регистр. Это проще и прозрачнее.
надо подумать/посовещаться.
71. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:23
(65) по доп.расходам

"Документ доп.расходов делает движения с такими же измерениями и реквизитами, что делал документ реализации, но на сумму 100руб."
- расход себестоимости увеличиваешь? а приход себестоимости? Можно подробнее покахать/посмотреть? (можно в личку или скайп Zlopun - на живых примерах посмотреть движения по регистрам - чтобы понять лучше? спсб.)
72. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:29
(65) " доп.характеристиках поставки хорошо выглядит, например, к "Пальто женское" характеристика "красное с перламутровыми пуговицами". Что бы не раздувать бесконечно номенклатуру. "
- мы об одном, но в разных терминах. - Это не доп.характеристка ПОСТАВКИ. это доп.характеристика НОМЕНКЛАТУРЫ (а где она - в поставке, остатках, реализации - это уже другое дело.). так что, таки да, учет по доп.характеристикам НОМЕНКЛАТУРЫ надо однозначно делать (и мне кажется что это будет самое большое дополнение в клон).

"Ну если уж говорить про штатный функционал, свойство партии и есть доп.характеристика поставки." - а тут уже непонятно немного.. в ТИС этим пытались делать деление по характеристикам номенклатуры за неимением оных используя свойства партии, и учет остатков велся полностью на регистре партий (был у меня такой опыт). При наличии характеристик номенклатуры - такая потребность скорее всего отпадет. Я бы вообще подумал бы на тему отказа в клоне от свойств партии.
73. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:33
(65)
"Оприходование стандартно создаёт новую партию с нулевой себестоимостью. А это не всегда надо.
С управленческой точки зрения, я не нашел на складе излишек в свой карман, а балбесы-кладовшики перепутали два ящика. И если сделаю оприходование, просто завышу себе маржу по какой-то позиции."

- если можно, то тоже посмотреть на живом примере. Примерно я представляю, но лучше глянуть. Предлагаемый документ "Пересортица" - может оприходовать списывать нужные "себестоимости" и количества. например запросто может быть пересорт 1 коробки Термосы1 и термосы2 - ну одинаоквые коробки по внешнему виду и где-то рядом. Только Термос1 - 12 шт на 12000 рублей, а Термос2 - 6штук на 6000 рублей. Как тут в "ноль" пересортить?
74. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:35
(68) угу, про АРМы - самое оно. по сути у меня в ТИС менеджеры и склад работают именно с АРМами - псевдожурналами текущнего состояния.
75. Сергей (Che) Коцюра (CheBurator) 13.03.16 14:36
ну, до Ут10.3 - даже с обсуждавшимися ВОЗМОЖНЫМИ доработками - еще достаточно далеко (как мне кажется) ;-)
76. Il Il (Il) 13.03.16 17:05
(68) vcv, согласен - был похожий случай еще на клюшках, урезаная до мин. тис92 по точкам + допиленый уриб, в центре полновесная 9.2, которую впоследствии заменили на 10.3,
но если 77 урезать по времени вполне реально, то урезать 10.3 - это жуть

что касается задумки автора - очень хорошая тема для "ларьков" - кому "розницы" мало, а УТ уже много.
77. Владислав Чинючин (vcv) 13.03.16 18:10
(69) CheBurator,
Использовать КредДокумент я решил потому, что по этому измерению был бардак, порождаемый редактированием документов задним числом. Пользователи не особо понимали, что такое КредДокумент. А теперь все знают - в рамках договора есть выставленные счета/спецификации, взаиморасчеты мы ведём раздельно по счетам.
Не мог бы ты более развернуто пояснить как у тебя работает/построена схема когда в кред.документе указывается заявкаПокупателя?

В банковских и кассовых документах добавлена табличная часть с указанием кред.документов (заявок) и суммы, которая на них распределяется (есть вариант <авто>). Если сумма по документу больше, чем долгов по указанным заявкам, превышение считается "нераспределенным авансом" (пустой КредДокумент в регистре). Если в качестве кред.документа указана не заявка, определяется заявка по структуре подчинённости.
В реализации добавлен реквизит табличной части ПоЗаявке, что бы можно было выписывать реализацию по нескольким заявкам. Реализация, при проведении, формирует таблицу долгов по каждой заявке покупателя, указанной в табличной части.
Процедура в глобальнике глДвижениеДолгов проверяет переданный КредДокумент, если он не заявка, ищет корневую заявку сделки по структуре подчинённости (ДокОснование в шапке, ПоЗаявке в табличной части). Для заявки определяется корневая заявка по структуре подчинённости. То есть какая заявка начала сделку с учетом цепочки корр.заявок, выписанных на основании корневой (первичной) заявки.
Документ ОтменаЗаявок закрывает авансы по заявке (если есть) перенося их на неуказанный кредитный документ, превращая в нераспределенные авансы. Долги, естественно, остаются на своих заявках.
Сделан документ распределения долгов, который позволяет в рамках договора перебрасывать аванс с одной заявки на другую и закрывать долг на одной заявке авансом на другой.
Реализация без указания заявки или со значительным превышением объёма заявки запрещается полномочиями пользователя.
В реализации так же есть настройка, позволяющая указать, что какие-то заявки (или все) нужно полностью закрывать при реализации. При закрытии заявки авансы, числящиеся на ней переносятся на "нераспределенные авансы".
Введено понятие "планового долга" по заявке. Он состоит из фактического долга по заявке (остатки по КредДокумент в регистре покупателей) и неотгруженного остатка заявки.
По каждой заявке можно указать график платежей, но этот кусок у меня реализован дурно, поэтому отмолчусь.
Расширен штатный отчет ОплатаЗаявок, которые показывает не только остатки заявок, но и, по каждой заявке, фактический и плановый долг. График платежей (отдельный отчет по анализу долгов покупателей, сроков задолженности и всего прочего) тоже показывает как фактический, так и плановый долг. Отчет по взаиморасчетам фактически штатный.
78. Владислав Чинючин (vcv) 13.03.16 19:35
(71) CheBurator,
Документ доп.расходов делает движения с такими же измерениями и реквизитами, что делал документ реализации, но на сумму 100руб."
- расход себестоимости увеличиваешь? а приход себестоимости? Можно подробнее покахать/посмотреть?

Смотри скриншот отчета по партиям наличным и партиям отданным (у меня с филиалами по комиссии работа). И в экселе служебный отчет об движении партии по наличным.
Прикрепленные файлы:
93056965.XLS
79. Владислав Чинючин (vcv) 13.03.16 19:44
(73) CheBurator,
- если можно, то тоже посмотреть на живом примере. Примерно я представляю, но лучше глянуть. Предлагаемый документ "Пересортица" - может оприходовать списывать нужные "себестоимости" и количества. например запросто может быть пересорт 1 коробки Термосы1 и термосы2 - ну одинаоквые коробки по внешнему виду и где-то рядом. Только Термос1 - 12 шт на 12000 рублей, а Термос2 - 6штук на 6000 рублей. Как тут в "ноль" пересортить?

У меня жесткий партионный учет. Поэтому пересортица в первую очередь используется, когда на складе/офисе попутали и по факту отгрузили одну пачку металлопроката, а по учету - другую.
Оприходование/списание используется, в основном, не классически, а в виде доприходования/списания тоннажа в пачке металла при провеске. Принял металл по договору по теоретическому весу, но потом, по какой-либо причине потребовалось взвесить и доприходовать излишки веса или списать недостачу веса.

И в других областях торговли возможно аналогичное. Стоит две коробки с пуговицами. Аналогичные. По одной цене. Только одни черные, другие красные. Продавцы перепутали в тетрадке какие продажи. На инвентаризации выяснилось что по учету 40 черных и 60 красных, по факту 50 и тех и других. Тут бы просто "перекинуть" учетный излишек вместе с себестоимостью на другую номенклатуру/партию/характеристику, а не списывать и приходовать.
Прикрепленные файлы:
80. Сергей (Che) Коцюра (CheBurator) 13.03.16 20:00
(77) Все нормально, примерно так представлял. Плохо одно - извращена суть "кред.документа". Которым может быть только то, что порождает взаиморасчеты - платежи или отгрузки. Ни счета, ни заявки не являются доками, порождающими обязательства перед друг другом. По сути ты конкретный ДОГОВОР (которым является выставленный счет/заявка при условии принятия его клиентом - то есть оплатой этого счета) опустил на уровень кредитного.документа.

В принципе, норм.решение. Введено понятие "сделки" по сути.
Немного непонятно, но вопросы уже в личке задам
81. Владислав Чинючин (vcv) 13.03.16 21:14
(80) CheBurator,
Плохо одно - извращена суть "кред.документа"

Суть его какая-то неустойчивая к перипетиям жизни. Бухгалтер была в налоговой и банк разносила позднее обычного, склад накосячил и сегодняшнюю непроведенную накладную получится провести только завтра, менеджер обнаружил ошибку в позавчерашнем документе... В результате в кред.документе непонятным для пользователя образом то банк, то накладная, то вообще какая-то невнятная корректировка долга...
Более-менее это работает либо при жестком регламенте работы, или постоянном восстановлении последовательности. Первое мешает пользователям работу работать, второе замедляет работу с отчетами. А при достаточно регулярных ошибках восстановления последовательности велик риск, что на это вовсе забьют и взаиморасчеты в разрезе кредитных документов превращаются в седой замшелый "пересорт" с отсутствием малейшего смысла в движениях по новым документам.
В результате ни кто не смотрит на этот кред.документ в отчетах, а бухгалтера жалуются "у меня долга по договору нет, а реализация почему-то сделала проводку на 62.2".
82. Сергей (Che) Коцюра (CheBurator) 13.03.16 23:01
(81) все правильно
То сто ты предложил выше - ты по сути превратил кредитный док в "кучу"
При таком варианте кредитный док совершенно излишняя сущность и его можно вообще убрать, потому что "куча" реализуется измерением договор.
Поэтому все что ты написал по работе с заявками в качестве креддокумента - спокойно и красиво - без всяких лазаний по структурам подчиненности - которые весьма неоднозначны могут быть для правильного определения главной заявки - спокойно и красиво реализуются на уровне договора, что и следует сделать без кредитного документа. То есть договору придается смсл сделка - в рамках договора может быть несколько заявок и вообщем такая же схема как ты нарисовал выше.
83. Сергей (Che) Коцюра (CheBurator) 13.03.16 23:29
(79) "тут бы просто "перекинуть" учетный излишек вместе с себестоимостью на другую номенклатуру/партию/характеристику, а не списывать и приходовать." - ага. волшебное слово "перекинуть".. ;-) - это и будет одновременное списание колва стоимости с одного товара, и повесить это колов и стоимост (или скорректированную стоимость) на другой товар. Ясен пень, что удобнее это делать одни документом. Трабла только в том, что пересорта как самостоятельного факта нет - это даже по инвентариным ведомостям отнесение излишков и недостач друг на друга.
84. MAXXL (MAXXL) 16.03.16 09:38
(17) CheBurator,
Я такие хотелки решал просто - в договоре добавлял нужные поля (обычно разные реквизиты идут под разные торговые точки), договор обзывается по имени торговой точки. И делал печатные формы в которых нужные варианты реквизитов брались из договора. В восьмерке был еще вариант (для упрощения обновления) с использованием доп. реквизитов
85. Александр Красильников (kao_andi) 16.03.16 11:26
Вопрос, а почему не посмотреть в строну УНФ конфигурация по простоте напоминает как раз ТиС (и даже еще проще) плюс еще много положительных плюшек, которые как раз отключаемы и в коробке уже синхронизация с сайтом и БП?
86. Александр (nikaleks) 16.03.16 13:39
Спасибо автору за разработку, скажу за себя, как и многие на форуме, давно хотел сделать какую-то конфигурацию простенькую, для мелких магазинов и прочих участников мелкой розничной сети, но всё руки как-то не доходили.

Может действительно, если мы объедением силы, то получится СУПЕР ТИС))) в любом случае все мы люди не глупые, опыт есть, есть и багаж с внедрением, а такого рода программных продуктов нет, и скорее всего не будет.

Так что давайте граждане, на баррикады!

P.S. Готов поучаствовать в разработке!
87. Виктор Левченко (lvictor58) 16.03.16 17:56
Уж как-то забористо все получается!
Тут уж или наиболее простой вариант делать с минимумом документов и регистров для мелких ООО работающих по упрощенки по схеме "Доходы" или патент. С возможностью подключения кассового оборудования, и расчетом себестоимости продаж. Либо, не изобретая заново велосипед, использовать типовую УТ,
На мой взгляд используемый метод учета партий в разрезе документов поставки как в УТ 10 и выше, наиболее рационален, чем по создаваемым бесконечное количество раз элементам справочника "Партии". По крайней мере данные по продажам можно выгружать в какую-либо типовую типа БП и уже там шаманить глубже.
Кстати аналогом для партионного учета, реализованного в УТ10, была давно уже позабытая конфигурация ТиС 8.7. Но она была выпущена более 15 лет тому назад, и очень тормозила. Возможно алгоритмы проведения документов были коряво написаны, либо какие-то недочеты в самой платформе 1С; да и "железо" тогда слабенькое было. Вот и появилась на смену ей ТиС 9.2.
А с восьмого релиза платформы 1С опять вернулись к методу учета по поставкам как к более рациональному.
88. Сергей (Che) Коцюра (CheBurator) 17.03.16 00:09
(87) те оесть партией является ссылка на документ поставки?
89. Сергей (Che) Коцюра (CheBurator) 17.03.16 00:10
(87) все-таки (пока) мне кажется более удобной организация партий - именно как в ТИС 9.2 - спр.партии (в котором есть ссылка на документ) - при необходимости в спр.партии добавляются нужные реквизиты. если партия - ссылка на документ - то будет проблематично...
???
90. aspirator 23 (aspirator23) 19.03.16 15:39
Уважаю, приятно, что не вымирает племя альтруистов.
Грустно что все это довольно быстро погибнет, а кто-то потратит на разработку этого свое время.
- для разработки нечто своего, нужна сильная методическая поддержка. Чего скорее всего нет.
Следствие - в лучшем случае получится повтор ТиС или Ут10, о чем автор сразу заявил.
Стоит ли тогда делать дубль два? Может проще взять УТ10 и расширить функционал тем чего нет в УТ11?
Но тут опять все упрется в отсутствие опытных методистов.
- разработка требует денег. Ладно опустим это - можно на энтузиазме вывезти.
- самое важное - разработку нужно уметь продать. А в среде участников похоже только программисты.

Конечно коммерчески удачные опыты самостоятельной разработки есть
1.Снегопат. Но у Орефкова за плечами был телепат и колоссальное уважение общества 1с.
2.Татиту со своим магазином. Его удача в его незаурядной коммерческой жилке.
....
91. Дмитрий Краснопольский (Deda) 19.03.16 17:46
(85) kao_andi, Добрый день! УНФ уважаю, работа в ней радует, но как и в остальных продуктах 1с - смущает громоздкий интерфейс и сложность кода в расчете себестоимости. Тут принципиально важно создать продукт маловесный с основными функциями. А там дальше пользователи пускай БСП прикручивают к ней или скрещивают с другими модулями. :-)
92. Сергей (Che) Коцюра (CheBurator) 22.03.16 12:00
(90) ну так основнавя идея и есть практически 1-в-1 ТИС повторить. К ней методическая поддержка практически не нужна. Ввиду простоты, обсосанности и сохранившихся мамонтов по 77
93. Вадим Латышев (pro1c@inbox.ru) 23.03.16 01:39
100% надо!
Многие спрашивали: "А есть 8-ка, как ТиС 7.7?"
94. Виктор Левченко (lvictor58) 29.03.16 17:51
при необходимости в спр.партии добавляются нужные реквизиты. если партия - ссылка на документ - то будет проблематично


(89) Партиеобразующих документов не очень много:
- ввод остатков ТМЦ
- приходная накладная (и не обязательно еще делать отдельно для розницы и по импорту)
- оприходование излишков
Возврат от покупателя можно возвращать на партии отгрузки
Сделайте их с одинаковыми реквизитами и храните в них всю нужную вам информацию.
В конце концов в регистре учета партий можно завести реквизиты.

Что мне больше всего не нравилось в ТиС 9.2 так это учет партий в разрезе розничных цен и перемещение их со склада на склад. Что в принципе методологически не верно! Партии должны учитываться в целом по организации, а не по отдельному складу в рамках этой организации. Фирма 1С пошла на компромиис, чтобы обеспечить функциональность системы в режиме распределенной базы данных, хотя не видно какой в этом смысл: все равно потом надо перепроводить БД для восстановления ГП.
95. Сергей (Che) Коцюра (CheBurator) 29.03.16 19:00
(94) в типовой тис партии учитываются как раз по организации, по складам не учитывают. Пиплы партии привязывают к складам через мол в партионном учете в первую очередь не для расчета себестоимости, а для учета матответсвенности и исчисления прибыли по фактически самостоятельным (с точки зрения собственника-управленца) магазинам-точкам. Обеспечение таких хотелок в рамках тис реализуется другим образом, а не через выкручивание партионного учета как это обычно делают эмулируя склады в партиях через мол - но тут да, может быть не сильно удобно и замудрено по мнению типапродавановведущихтипаучет - потому как обычно хочется чтобы было и просто и так как нужно и потом оказывается чтобы это было максимально близко к белой бухгалтерии
96. Сергей (Che) Коцюра (CheBurator) 06.04.16 01:50
конкурентами для данной разработки на данный момент являются из известных мне
СКАТ-ПРОФЕССИОНАЛ http://infostart.ru/public/199013/
ЭЛЕМЕНТАРНАЯ ТОРГОВЛЯ http://infostart.ru/public/415422/
97. Максим Олексенко (BooMSys) 22.04.16 20:52
И как ее заполучить? Для ознакомления и тестирования.
98. Дмитрий Краснопольский (Deda) 25.04.16 08:33
(97) BooMSys, Здравствуйте! Напишите свой е-мэйл, я Вам вышлю...
99. Максим Радченко (coolseo) 05.06.16 09:15
Deda, Здравствуйте. Я готов поучаствовать в тестировании. Скиньте пожалуйста на почту.
biznesdv@yandex.ru
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа