Если вы им скажете ровно то же, что описал ТС в стартовом сообщении, то конечно более вероятно, что вас пошлют лесом. Но если проявить немного сообразительности, то почему не выложат? Это же не какая-то секретная информация. У некоторых даже на сайте прямо указана стоимость часа за разные виды работ.
Дивіться процедуру в чеку, яка виконує друк на ФР (на ПРРО). Можливо, туди передається кількість і ціна і воно саме вираховує суму.
І я б не чіпав ніяких спільних модулів для цього, адже ви ризикуєте, що таке округлення почне робитися не лише для чека, а і для всіх/багатьох інших документів.
Нужно сделать запрос, который вернет остатки по дням. Берем остатки из виртуальной таблицы остатков на начало периода, добавляем туда движения, группируем по дню. А там просто сортируем и берем первое значение. Вот вроде тема, где похожий запрос обсуждали.
lals, а нахіба ви туди взагалі ходите? Років 15 назад, можливо, окрім місти і не було де щось почитати або спитати. Зараз же інформації в інтернеті достатньо, можна користуватися Гуглом відразу (якісь посилання будуть на ту же місту).
Xmdrug, я не впевнений чи можливо технічно (чи дозволить платформа/конфігурація) вести облік по групі рахунків (105 рахунок стане групою, якщо в нього з'явиться субрахунок), але якщо так, то цього б я точно не робив.
Тобто був рахунок 105, а ви хочете, щоб став 105/1? Я й досі не зрозумів навіщо це, але якщо вам сильно кортить, то створіть рахунок 105/1, перенесіть на нього всі залишки зі 105 рахунку і використовуйте далі його. Спочатку краще все зробити на копії та перевірити максимальну кількість сценаріїв роботи з ним, включаючь нарахування амортизації, закриття місяця і т.п.
Можливо, десь окрім бухгалтерського обліку також існують залишки по 105 рахунку (в якихось інших регістрах), але я не підкажу де саме (не знаю).
Та багато хто таке робив. Просто в деяких випадках буває таке, що рахунок прописаний прямо в коді або колись потім такий рахунок, що ви добавили, з'являється на рівні типової конфігурації. Навіщо вам саме субрахунок, вам точно не підійде варіант, щоб виділити це на якомусь субконто? Які субрахунки повинні з'явитись: 105/1 і 105/2?
Мне сейчас негде глянуть, посмотрите какой-то стандартный документ с табличной частью. Гляньте, например, как при изменении количества пересчитывается сумма. Там должно быть понятно, как обратиться к текущей строке.
Andry.Boris, [ hide ] без пробелов. Я с пробелами написал, потому что не отобразится иначе в тексте. Или слева под смайликами нажмите "Спрятать", оно за вас нужный тег вставит.
Заметил по отладчику, при заполнении картинок постоянно обновляется основной дин. списка "Список"
Предполагаю, что вот эти все заполнения вы начинаете выполнять в обработчике события ПриАктивацииСтроки. Если так, то в нем нельзя делать вызовов к процедурам/функциям с директивой НаСервере. "Нельзя" не означает, что это невозможно сделать, это означает, что могут быть какие-то неизвестные последствия. Возможно то, что вы наблюдаете, одно из таких последствий.
У меня вопрос как можно соединять таблицы по ИСТИНА
Любые соединения таблиц работают если условие соединения возвращает истину.
В этом случае
|ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ РАЗЛИЧНЫЕ | СоставГруппы.Ссылка КАК ГруппаПользователей | ИЗ | Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы | ГДЕ | СоставГруппы.Пользователь = &ТекущийПользователь) КАК ГруппыПользователей | ПО (&ИспользоватьОграниченияПравДоступаНаУровнеЗаписей)
К основной таблице добавятся записи из справочника ПользователиГруппы по текущему пользователю
| ГДЕ | СоставГруппы.Пользователь = &ТекущийПользователь
но ТОЛЬКО если ИспользоватьОграниченияПравДоступаНаУровнеЗаписей = ИСТИНА. Это значит, что к каждой строке из первой таблицы присоединятся все строки, которые получаются в результате этого запроса
|ВЫБРАТЬ РАЗЛИЧНЫЕ | СоставГруппы.Ссылка КАК ГруппаПользователей | ИЗ | Справочник.ГруппыПользователей.ПользователиГруппы КАК СоставГруппы | ГДЕ | СоставГруппы.Пользователь = &ТекущийПользователь
И вот проблема. Документ установка цен номенклатуры я могу вполне нормально заполнить, вот только как вызвать типовые функции по расчету цен, если они все не в общих модулях а в ФОРМЕ документа.
Мне кажется, что это проблема всех конфигураций 1С, в т.ч. современных. Не знаю почему, но почему-то разработчики не беспокоятся о возможности создания документов полностью программно. Либо на это есть какие-то причины. Вам придется поколупаться в вызовах с клиента, посмотреть что там вызывается при изменении разных полей и повставлять все эти вызовы в свою обработку, где-то покопировать серверные процедуры из формы.
1С Предприятие 8.3, 1С Предприятие 8.2, 1С Предприятие 8.1, 1С Предприятие 8.0, 1С Предприятие 7.7, Литература 1С, Общие вопросы по администрированию 1С, Методическая поддержка 1С - всё в одном месте: на Украинском 1С форуме!