Как правильно выставить счет на аванс и акт на услуги?
Перехожу с МоеДело на 1С УНФ. Там все как то было понятно. А в 1С УНФ не понятно как услуги оформлять.
У меня 99% это услуги по ТЗ.
Каждая услуга звучит как "Выполнение работ по ТЗ №2343. В ТЗ всегда уникальные требования в свободной форме. Нет ни одного похожего требования в разных ТЗ.
Но УНФ не позволяет так писать. Надо выбрать номенклатуру. И получается что каждый раз на каждую услугу надо создавать новую номенклатуру? Правильно ли это? Или можно как то иначе решить?
Далее. Часто бывает так что надо выставить счет на аванс.
Как это правильно сделать? Опять же пишем как "Предоплата по ТЗ №2343". Снова каждый раз создавать уникальную номенклатуру?
Буду благодарен за подсказу по методологии такого учета.
Хочется не забивать номенклатуру каждый раз мусором. А завести одну позицию типа "Разработка" и по ней проводить все операции по разным суммам.
Да, дорабатывать 1С тоже очень не хочется. Она у нас облачная. И вообще в конфигуратор залазить это крайний вариант.
У меня 99% это услуги по ТЗ.
Каждая услуга звучит как "Выполнение работ по ТЗ №2343. В ТЗ всегда уникальные требования в свободной форме. Нет ни одного похожего требования в разных ТЗ.
Но УНФ не позволяет так писать. Надо выбрать номенклатуру. И получается что каждый раз на каждую услугу надо создавать новую номенклатуру? Правильно ли это? Или можно как то иначе решить?
Далее. Часто бывает так что надо выставить счет на аванс.
Как это правильно сделать? Опять же пишем как "Предоплата по ТЗ №2343". Снова каждый раз создавать уникальную номенклатуру?
Буду благодарен за подсказу по методологии такого учета.
Хочется не забивать номенклатуру каждый раз мусором. А завести одну позицию типа "Разработка" и по ней проводить все операции по разным суммам.
Да, дорабатывать 1С тоже очень не хочется. Она у нас облачная. И вообще в конфигуратор залазить это крайний вариант.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) PhoenixAOD, (5) s98, (4) _KaA,
У нас есть заказ и его номер формируется в ERP системе. Это самый обычный заказ. И услуга обычно одна - разработка по ТЗ.
У ТЗ всегда номер заказа. ТЗ по заказу №123
И акт на ТЗ всегда один - Выполнение работ по ТЗ №123, просто к нему прикладывается само ТЗ где расписаны все требования.
Платежей обычно два: предоплата 50% и доплата 50% по факту результата.
Соответственно и счета два: предоплата по ТЗ №123 и доплата по ТЗ№123.
И я чую что номенклатура должна быть одна. Потому что не гоже фигачить номенклатуру каждый раз.
Я и не против в примечании писать №ТЗ, но вот бед - в счет это никак не выводитя :)
Пример заказа покупателя
Как видите в комменте указал что за работы.
На печатной форме ничего нет.
И я залез в редактор печатных форм и написал что то типа так:
И ничего. И ладно бы без <Комментарий> выводилось. Я на абум атрибут указал, тк не знаю модель метаданных.
Но и слово Тест не выводится.
И тут мои навыки взлома 1С закончились :) В конфигуратор я зайти не могу тк у меня нет туда доступа и желания туда залазить.
Хочется найти решение, которое будет работать на уровне настроек пользователем.
Есть идеи как это решить?
У нас есть заказ и его номер формируется в ERP системе. Это самый обычный заказ. И услуга обычно одна - разработка по ТЗ.
У ТЗ всегда номер заказа. ТЗ по заказу №123
И акт на ТЗ всегда один - Выполнение работ по ТЗ №123, просто к нему прикладывается само ТЗ где расписаны все требования.
Платежей обычно два: предоплата 50% и доплата 50% по факту результата.
Соответственно и счета два: предоплата по ТЗ №123 и доплата по ТЗ№123.
И я чую что номенклатура должна быть одна. Потому что не гоже фигачить номенклатуру каждый раз.
Я и не против в примечании писать №ТЗ, но вот бед - в счет это никак не выводитя :)
Пример заказа покупателя
Как видите в комменте указал что за работы.
На печатной форме ничего нет.
И я залез в редактор печатных форм и написал что то типа так:
И ничего. И ладно бы без <Комментарий> выводилось. Я на абум атрибут указал, тк не знаю модель метаданных.
Но и слово Тест не выводится.
И тут мои навыки взлома 1С закончились :) В конфигуратор я зайти не могу тк у меня нет туда доступа и желания туда залазить.
Хочется найти решение, которое будет работать на уровне настроек пользователем.
Есть идеи как это решить?
(6) systemo,
Давайте еще раз. Я не настаиваю, но мне кажется, что номенклатуры должно быть несколько, так как это разные товары. Т.е. выполнение по ТЗ № 1 - это одна работа, а по ТЗ № 2 - это другая работа.
Если кратко, из увиденного (возможно я не правильно понял):
- есть потребность видеть аванс и оплату выполненных работ;
- есть потребность (ОПЕРАТИВНО ли?) формировать первичку;
- есть файлы-описания проектов, возможно захочется их хранить (присоединять к проектам!);
- и есть отчеты (какие?), как говорил s98. Или, проще говоря, какие-то должны быть результаты деятельности...
Отсюда я бы склонился к номенклатурной градации, а особенно если учесть п3, т.е. разные ТЗ - разный товар - разная номенклатура.
Думайте не с точки зрения как удобно доработать, а как вы с этим будете жить. А в печатную форму можно вывести любое название, для этого вообще не чего править не надо - используйте типовой механизм "Содержаний в таб. частях документов". Он уже есть и как раз для того и служит, что бы в ПФ выводить не то, что есть в названии номенклатуры.
Давайте еще раз. Я не настаиваю, но мне кажется, что номенклатуры должно быть несколько, так как это разные товары. Т.е. выполнение по ТЗ № 1 - это одна работа, а по ТЗ № 2 - это другая работа.
Если кратко, из увиденного (возможно я не правильно понял):
- есть потребность видеть аванс и оплату выполненных работ;
- есть потребность (ОПЕРАТИВНО ли?) формировать первичку;
- есть файлы-описания проектов, возможно захочется их хранить (присоединять к проектам!);
- и есть отчеты (какие?), как говорил s98. Или, проще говоря, какие-то должны быть результаты деятельности...
Отсюда я бы склонился к номенклатурной градации, а особенно если учесть п3, т.е. разные ТЗ - разный товар - разная номенклатура.
Думайте не с точки зрения как удобно доработать, а как вы с этим будете жить. А в печатную форму можно вывести любое название, для этого вообще не чего править не надо - используйте типовой механизм "Содержаний в таб. частях документов". Он уже есть и как раз для того и служит, что бы в ПФ выводить не то, что есть в названии номенклатуры.
(11) _KaA, методически это не верно.
Продукт один - услуга всегда одна.
Разные только опции этой услуги. Или операции процесса.
Если мне надо будет хранить какие либо данные об операции - то в 1С для этого есть сущность документ.
(12) s98, ERP у нас не на 1С, а на базе WordPress. Там смесь ERP/ECM и ACM. Это наша центральная система. 1С нам нужна только для выставления счетов и отчетов в налоговую. 1С тяжело дорабатывать, потому для основной деятельности она нам не подходит. ERP у нас четко заточена под наши процессы и постоянно дорабатывается. 1С как платформа плохо подходит для этих задач. Потому 1С это просто слой для отчетов и налогов.
Все управленческие данные у нас в CasePress (ERP/ECM/ACM на базе WordPress)
Продукт один - услуга всегда одна.
Разные только опции этой услуги. Или операции процесса.
Если мне надо будет хранить какие либо данные об операции - то в 1С для этого есть сущность документ.
(12) s98, ERP у нас не на 1С, а на базе WordPress. Там смесь ERP/ECM и ACM. Это наша центральная система. 1С нам нужна только для выставления счетов и отчетов в налоговую. 1С тяжело дорабатывать, потому для основной деятельности она нам не подходит. ERP у нас четко заточена под наши процессы и постоянно дорабатывается. 1С как платформа плохо подходит для этих задач. Потому 1С это просто слой для отчетов и налогов.
Все управленческие данные у нас в CasePress (ERP/ECM/ACM на базе WordPress)
(13)
Создание интернет портала "Опрятный малыш" - это услуга.
Продвижение и раскрутка сайта "Ремонт АКПП" - это тоже услуга, но совершено точно другая, потому что: затраты, взаиморасчеты и КТ задач будут отличатся. И не важно что выполнение пройдет по идентичному графику, и одним и тем же сотрудником.
Или "Стрижка газона для Петрова" - это не тоже самое, что "Стрижка газона на Сидорова". Разные затраты, взаиморасчеты, КТ (одна).
Возможно, у вас действительно методика другая, тогда я просто не подхожу вам как советчик :) В этом не чего страшного нет, просто вы бы написали в первом сообщении, что вам решение необходимо согласно методики такого-то автора, которая напечатана там и там то :)
Исходя из последнего вашего сообщения тем более вам рекомендую не трогать типовые вещи, так как потом каждое обновление станет в некоторые денушки или приведет к потере изменений.
Создание интернет портала "Опрятный малыш" - это услуга.
Продвижение и раскрутка сайта "Ремонт АКПП" - это тоже услуга, но совершено точно другая, потому что: затраты, взаиморасчеты и КТ задач будут отличатся. И не важно что выполнение пройдет по идентичному графику, и одним и тем же сотрудником.
Или "Стрижка газона для Петрова" - это не тоже самое, что "Стрижка газона на Сидорова". Разные затраты, взаиморасчеты, КТ (одна).
Возможно, у вас действительно методика другая, тогда я просто не подхожу вам как советчик :) В этом не чего страшного нет, просто вы бы написали в первом сообщении, что вам решение необходимо согласно методики такого-то автора, которая напечатана там и там то :)
Исходя из последнего вашего сообщения тем более вам рекомендую не трогать типовые вещи, так как потом каждое обновление станет в некоторые денушки или приведет к потере изменений.
(15) systemo,
Ну это же ваша система, так что я не в праве вас останавливать :)
По собственному опыту могу привести такой сценарий:
сдается отчетность и есть разница между итоговыми суммами в уч. системах. Как эту разницу оперативно выявить? Формировать отчеты и сверять.
А причин масса: либо серые оплаты выгрузились на белую фирму, либо опечатка при редактировании.
И вот берете вы отчет из одной учетной системы и сравниваете с отчетом из другой. И тут с ходу могу утверждать, что вывод комментов - это доп. настройка группировок в отчетах, потому что они по умолчанию не выводятся. Даже документы движений не всегда выводятся, да и какие движения то по заказам - их минимум.
Потом не понятно в каком виде будет показан отчет Продажи... Номенклатура то одна, все суммы и свернуться, наверное...
Не знаю, с другой стороны, вы говорите, что вам до фени отчеты, нужна только рег. отчетоность: может тогда вообще УНФ тут лишнее звено, т.к. есть конфигурации "Отчетность предпринимателя", "1с Отчетность"... они ровно на это и заточены.
Общим, вы меня извините, но я пожалуй откланяюсь из этой темы.
PS Не хотел вас огорчить - если что не так, не сердитесь строго :)
Ну это же ваша система, так что я не в праве вас останавливать :)
По собственному опыту могу привести такой сценарий:
сдается отчетность и есть разница между итоговыми суммами в уч. системах. Как эту разницу оперативно выявить? Формировать отчеты и сверять.
А причин масса: либо серые оплаты выгрузились на белую фирму, либо опечатка при редактировании.
И вот берете вы отчет из одной учетной системы и сравниваете с отчетом из другой. И тут с ходу могу утверждать, что вывод комментов - это доп. настройка группировок в отчетах, потому что они по умолчанию не выводятся. Даже документы движений не всегда выводятся, да и какие движения то по заказам - их минимум.
Потом не понятно в каком виде будет показан отчет Продажи... Номенклатура то одна, все суммы и свернуться, наверное...
Не знаю, с другой стороны, вы говорите, что вам до фени отчеты, нужна только рег. отчетоность: может тогда вообще УНФ тут лишнее звено, т.к. есть конфигурации "Отчетность предпринимателя", "1с Отчетность"... они ровно на это и заточены.
Общим, вы меня извините, но я пожалуй откланяюсь из этой темы.
PS Не хотел вас огорчить - если что не так, не сердитесь строго :)
(17) _KaA, (16) s98, (7) PhoenixAOD,
коллеги, я кажется понял идеальное решение для моих процессов и прошу вашей оценки:
1. Центральной сущность: Заказ покупателя, где номер не на автомате, а ставится руками из ERP системы
2. Далее на основании заказа создается счет на предоплату (вот что указывать в номенклатуре я пока не понимаю). Снимок
3. После исполнения заказа, мы на его основании создаем акт (в акте номенклатура звучит как "Работы по заказу"). Вот
и где то над таблицей акта надо выводить что это работы на основании Заказа №123 (данные подставлять из поля Заказ)
что скажете? :)
На мой взгляд это идеальная схема учета позаказного производства как в нашем случае.
коллеги, я кажется понял идеальное решение для моих процессов и прошу вашей оценки:
1. Центральной сущность: Заказ покупателя, где номер не на автомате, а ставится руками из ERP системы
2. Далее на основании заказа создается счет на предоплату (вот что указывать в номенклатуре я пока не понимаю). Снимок
3. После исполнения заказа, мы на его основании создаем акт (в акте номенклатура звучит как "Работы по заказу"). Вот
и где то над таблицей акта надо выводить что это работы на основании Заказа №123 (данные подставлять из поля Заказ)
что скажете? :)
На мой взгляд это идеальная схема учета позаказного производства как в нашем случае.
(20) systemo,
п. 1 - думаю, можно, но делать очень внимательно, как минимум не ошибиться с разрядностью.
п. 2 - не понимаю, зачем, номенклатура должна быть указана в Заказе покупателя и автоматически заполнятся на его основании. В Заказе ставите галку Запланировать оплату, заполняете платежный календарь, печатаете Счет на частичную оплату.
Номер Заказа наверняка можно выводить в печатную форму, но тут я не советчик.
То что Вы предлагаете с переключением номенклатуры возможно работать и будет. Но это противоречит логике УНФ.
п. 1 - думаю, можно, но делать очень внимательно, как минимум не ошибиться с разрядностью.
п. 2 - не понимаю, зачем, номенклатура должна быть указана в Заказе покупателя и автоматически заполнятся на его основании. В Заказе ставите галку Запланировать оплату, заполняете платежный календарь, печатаете Счет на частичную оплату.
Номер Заказа наверняка можно выводить в печатную форму, но тут я не советчик.
То что Вы предлагаете с переключением номенклатуры возможно работать и будет. Но это противоречит логике УНФ.
(21) s98,
по п1 не ошибемся. Все заказы всегда имеют уникальный номер.
по п2 проблема в том что у меня нет такой галочки :) а в счете надо указывать счет на предоплату или на доплату. И как это сделать не меняя номенклатуры я не понимаю. Тем более что какая номенклатура указана в счете - это не важно (но мб я ошибаюсь). А вот в акте и заказе - думаю что важно чтобы номенклатура совпадала.
Потому для счетов я завел две номенклатуры: Предоплата и Доплата (не придумал как еще это можно сделать) и завел их в группу "Типы платежей для счета". Мб я конечно ерунду сделал, но на сколько мне позволяют судить знания 1С и бухучета - все должно быть ок.
по п1 не ошибемся. Все заказы всегда имеют уникальный номер.
по п2 проблема в том что у меня нет такой галочки :) а в счете надо указывать счет на предоплату или на доплату. И как это сделать не меняя номенклатуры я не понимаю. Тем более что какая номенклатура указана в счете - это не важно (но мб я ошибаюсь). А вот в акте и заказе - думаю что важно чтобы номенклатура совпадала.
Потому для счетов я завел две номенклатуры: Предоплата и Доплата (не придумал как еще это можно сделать) и завел их в группу "Типы платежей для счета". Мб я конечно ерунду сделал, но на сколько мне позволяют судить знания 1С и бухучета - все должно быть ок.
(22) systemo,
по п.1 если будете вбивать номера ФФФФ-000111 - ОК, а если ФФФФ-111 - могут быть проблемы (в версии 1.3 были, как сейчас - не знаю). Точно в нулях не ошибетесь?
по п.2 - это тоже возможный источник ошибок.
У меня по УНФ опыт такой: если предусмотрена какая-то логика работы, то нужно ей и следовать. Даже если что-то кажется излишним и громоздким. Иначе потом все равно придется переделывать "как надо", потратив на это кучу сил и времени.
по п.1 если будете вбивать номера ФФФФ-000111 - ОК, а если ФФФФ-111 - могут быть проблемы (в версии 1.3 были, как сейчас - не знаю). Точно в нулях не ошибетесь?
по п.2 - это тоже возможный источник ошибок.
У меня по УНФ опыт такой: если предусмотрена какая-то логика работы, то нужно ей и следовать. Даже если что-то кажется излишним и громоздким. Иначе потом все равно придется переделывать "как надо", потратив на это кучу сил и времени.
(25) s98, у нас в заказах нет нулей. Сейчас номер заказа выглядит как: 31547
в ECM/ERP системе нумерация у нас сквозная для всех сущностей и начинается с 1.
Первая запись в базе знаний была как 1, потом мы создали первую организацию и она имеет номер 2, а потом первый заказ и он имеет номер 3, а потом добавили персону в базу и она имеет номер 4, а потом снова добавили заказ и он имеет номер 5, и так через 2 года заказ имеет номер из 5 знаков.
Нулей в нашей основной системе нет и не будет. А также исключена вероятность дублирования номера. Любая сущность в нашей систем имеет уникальный номер. Забив номер типа 23465 в поиск мы можем тут же найти организацию, договор, заказ, персону или инструкцию для сотрудника.
Потому и тут думаю что если мы просто будем копировать номер заказа как 32456 в номер заказа 1С УНФ то ничего не должно произойти страшного.
При этом если мы этот номер тут же забьем в основной системе, то сразу же найдем соответствующую запись заказа.
По п 2 я понял что вы это имелли ввиду, потому сильно обрадовался фишке с платежным календарем и счетом на 50%. По сути проблема с лишней номенклатурой типа платежа тут же сама собой устранилась :) За что вам большой респект!
в ECM/ERP системе нумерация у нас сквозная для всех сущностей и начинается с 1.
Первая запись в базе знаний была как 1, потом мы создали первую организацию и она имеет номер 2, а потом первый заказ и он имеет номер 3, а потом добавили персону в базу и она имеет номер 4, а потом снова добавили заказ и он имеет номер 5, и так через 2 года заказ имеет номер из 5 знаков.
Нулей в нашей основной системе нет и не будет. А также исключена вероятность дублирования номера. Любая сущность в нашей систем имеет уникальный номер. Забив номер типа 23465 в поиск мы можем тут же найти организацию, договор, заказ, персону или инструкцию для сотрудника.
Потому и тут думаю что если мы просто будем копировать номер заказа как 32456 в номер заказа 1С УНФ то ничего не должно произойти страшного.
При этом если мы этот номер тут же забьем в основной системе, то сразу же найдем соответствующую запись заказа.
По п 2 я понял что вы это имелли ввиду, потому сильно обрадовался фишке с платежным календарем и счетом на 50%. По сути проблема с лишней номенклатурой типа платежа тут же сама собой устранилась :) За что вам большой респект!
(27) systemo,
По нумерации. Возможно что-то поменялось, воспоминания времен УНФ версии 1.3 и платформы 8.2. Можете попробовать проверить, много времени не займет. Вбиваете без нулей документы с номером 1, 2, 3 ... 10, 11... Для 10 или 11 программа начинала ругаться на неуникальный номер и отказывалась сохранять документ. Аналогично для сотен и т.д. Не просто такт под номер отведено 6 знаков.
По нумерации. Возможно что-то поменялось, воспоминания времен УНФ версии 1.3 и платформы 8.2. Можете попробовать проверить, много времени не займет. Вбиваете без нулей документы с номером 1, 2, 3 ... 10, 11... Для 10 или 11 программа начинала ругаться на неуникальный номер и отказывалась сохранять документ. Аналогично для сотен и т.д. Не просто такт под номер отведено 6 знаков.
(13) systemo, для такого узкого применения предложенный вариант возможен. Но я бы все же подумал, чтобы использовать не комментарий, а другую сущность (характеристику, спецификацию, может быть что-то еще). Из-за того, что при создании какого-то документа "на основании" другого (Счета на основании Заказа, или Акта на основании Счета и т.п.) комментарий придется копировать "ручками", а это источник ошибок. А другие сущности будут автоматически копироваться.
(16) s98, если бы характеристика могла меняться в самом документа - например в счете, то я за. Но я не нашел как это делать.
Выше я писал, что когда то видел 1С где можно было прямо в таблице счета указать что за услуга и тут же дописать ее вариацию (комментарий).
И далее она выводилась в счет. Но такую опцию в 1С УНФ не нашел.
Вообще мне бы даже хватило понятия Заказ покупателя. Я бы номер заказа всегда подставлял их ERP. Автоматом или руками не так уж важно.
И далее учет спокойно велся бы в разрезе этого заказа. По заказу была бы серия счетов, платежей и он закрывался бы актом.
Это идеальное решение.
Но как в акте указать что акт по заказу №123? Реально ли это?
(17) _KaA, дорогой Каа :) Не стоит так близко принимать к сердцу тот факт что ваши комменты не подошли. Я очень благодарен за помощь. Возможно я что то не понима. А мб вы не понимаете меня. Это нормально. Я сам программист, и часто помогаю другим людям на форумах по моему профилю. Но никогда не обижаюсь если мое решение не подошло. Читаю все внимательно и учусь :) Ну или делаю выводы.
Выше я писал, что когда то видел 1С где можно было прямо в таблице счета указать что за услуга и тут же дописать ее вариацию (комментарий).
И далее она выводилась в счет. Но такую опцию в 1С УНФ не нашел.
Вообще мне бы даже хватило понятия Заказ покупателя. Я бы номер заказа всегда подставлял их ERP. Автоматом или руками не так уж важно.
И далее учет спокойно велся бы в разрезе этого заказа. По заказу была бы серия счетов, платежей и он закрывался бы актом.
Это идеальное решение.
Но как в акте указать что акт по заказу №123? Реально ли это?
(17) _KaA, дорогой Каа :) Не стоит так близко принимать к сердцу тот факт что ваши комменты не подошли. Я очень благодарен за помощь. Возможно я что то не понима. А мб вы не понимаете меня. Это нормально. Я сам программист, и часто помогаю другим людям на форумах по моему профилю. Но никогда не обижаюсь если мое решение не подошло. Читаю все внимательно и учусь :) Ну или делаю выводы.
(1) systemo,
Если же это не так (договор один, а ТЗ - несколько), то лучше воспользоваться советом из (2).
В любом случае можно разработать внешние печатные формы счета и акта, в которых к наименованию номенклатуры "Разработка" и "Предоплата" будет программно добавляться либо наименование договора, либо комментарий.
Правда, как обстоят дела с ВПФ в облаке - не в курсе.
Каждая услуга звучит как "Выполнение работ по ТЗ №2343. В ТЗ всегда уникальные требования в свободной форме. Нет ни одного похожего требования в разных ТЗ.
Возможно, есть смысл рассматривать каждое ТЗ как отдельный договор - можно будет анализировать, сколько по каждому ТЗ было реализовано и оплачено.
Если же это не так (договор один, а ТЗ - несколько), то лучше воспользоваться советом из (2).
В любом случае можно разработать внешние печатные формы счета и акта, в которых к наименованию номенклатуры "Разработка" и "Предоплата" будет программно добавляться либо наименование договора, либо комментарий.
Правда, как обстоят дела с ВПФ в облаке - не в курсе.
(1)
Мне кажется недостаточно информации для хорошего совета, поэтому подкину еще пару-тройку:
- а может номенклатура одна, а характеристики это номер тех задания?
- или партии (но тут надо быть аккуратным в разрезе партий не возможно хранить цены)?
- и я так и не понял, почему не подходит след. иерархия: Папка Разработка - номенклатура в ней ТЗ-00001, ТЗ-00002, ТЗ-00003, ТЗ-00004 и т.д. Чисто из эстетических соображений?
Мне кажется недостаточно информации для хорошего совета, поэтому подкину еще пару-тройку:
- а может номенклатура одна, а характеристики это номер тех задания?
- или партии (но тут надо быть аккуратным в разрезе партий не возможно хранить цены)?
- и я так и не понял, почему не подходит след. иерархия: Папка Разработка - номенклатура в ней ТЗ-00001, ТЗ-00002, ТЗ-00003, ТЗ-00004 и т.д. Чисто из эстетических соображений?
И еще коллеги, правильно ли я понял что номенклатура в 1С это такая универсальная сущность для всего на свете?
Поясню: понятие Предоплата и Доплата могут быть сущностями номенклатуры? Для того чтобы их вставлять в счета на предоплату и постоплату.
Чтобы понимать какой счет на предоплату по заказу, а какой на постоплату...
Поясню: понятие Предоплата и Доплата могут быть сущностями номенклатуры? Для того чтобы их вставлять в счета на предоплату и постоплату.
Чтобы понимать какой счет на предоплату по заказу, а какой на постоплату...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот