ПРоблема вот какая: системщик упёрся и хочет ставыить комплексную. Фирма занимается оптовой продажей продуктов питания. На данный момент такая ситуация: движение товара заносится в "Торговлю и склад", а оттуда всё переносится в бухгалтерию. Системщик хочет ставить комплексную, чтобы эту операцию переноса данных упростить... Я предлагаю всё движение товара заносить сразу в бухгалтерию. Подскажите: 1.что есть такого уникального в торговле и скаладе, чего нельзя сделать в бухгалтерии? 2. Чем плоха комплексная: чуем чую что ставить комплексную это смерть, а словами системщику объяснить не могу... Или комплексная не так плоха?

В комплексной куча доков, которые нафиг не нужны. Все зависит от задачи.

Нет, Комплексная не смерть. Она не так плоха.
Комплексная - это геморрой!

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

1.уникального - компонента опер.учет
2.комплексная вовсе не плоха -все зависит от колличества актиных пользователей,объемы базы, а так же от задачи.
Если все в пределах допустимых значений то комплексная вполне подходит.
И честно говоря не понимаю возражения по поводу комплексной - в небольшой фирме,с типовым бухучетом и приемлимым документооборотом и ленивым системщиком - комплексная то что надо.

Ну обясните мне тупому на кой нужна именно комплексная!!!?
Кому нужно это дублирование всяких телодвижений на бух. счетах и регистрах?

В принципе комплекснаю реализует 2 учета.
УПРАВЛЕНЧИСКИЙ - проведение по торговле. по факту.
БУХГАЛТЕРСКИЙ - проведение по документу.
*****
Торговля помнит все необходимые остатки и обороты на последний момент деятельности и соответственно нет необходимости использовать буххгалтерские запросы, что убыстряет работу если много оборотов, пользователей...

Я же не против оперативного учета как такового, я против объединения совершенно разных задач в одну.
Если объемы не большие, то достаточно одной бух. (кстати можно и на достаточно больших объемах обойтись одной бух :))
Если большие то все равно лучше разделить задачи (опер,расчет,бух).
Обмен можно через ОЛЮ организовать...
А комплексная это геморрой жуткий, еще ни разу не видел фирмы которая работает на комплексной не имеет проблем с синхронизацией оперативного и бух учета (разве что программер сидит под боком и всех правит).

:7 Согласен. Вывод: Снова вопрос денег для внедрения и сопровождения.
Лично я вля серъезных клиентов разделяю эти задачи.

4(0) По жизни не заставишь операторов правильно выставлять вид учета в доках. А выиискивать где чего должно быть и где чего стоит на самом деле это без матюков даже не объяснишь...

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

to 9 - решается (по крайней мере я так делал, правда не в комплексе, а в чистой торг) - кнопочка красного цвета (означает официальный док), если давишь на нее - становится зеленой (означает чисто управленческий вид учета). На нее нашита функция, которая и устанавливает тип учета (сам реквизит ТИП УЧЕТА с формы убран. НАЗЫВАЕТСЯ - СДЕЛАНО ДЛЯ ДУРАКОВ. Типа сено-солома. Кстати, заодно там и префикс номера в этой функции у дока меняется - потом по определенному префиксу доки выбиралсь для выгрузки в бух. Сделано было на 7.5

to 11
:)))
может и нам так внедрить :))
---
WBR,AVU.

попробуй. По крайней мере объяснять просто. Сначала сделал кнопочку черненькую/беленькую, ну уж очень гусей дразнить не хотелось

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

Зачем же так хаить комплексную. Не саму конкретную конфигураци, а возможную связку Бухгалтерия+торговля. Для чего нужна ? Риторический вопрос. Например, учет складских запасов. Т.е. бухгалтер в конце месяца может любые корректирующие проводки вручную делать, его дело, но эти проводки не должны касаться реального складского учета. В оперативном учете есть очень хорошая штука ТА. Очень нужная весчь, особенно когда нтенсивный документооборот. Если в 9.40 менеджер выписал товар со склада, то уже в 9.41 этого товара не должно быть !!!
Ну и на последок, когда у руководителя возникнет некая нестандартная задача, которую нужно будет решить,и которая изначально не проектировалась, гораздо быстрее и проще решить ее на опер. учете.

Вопрос почти в тему кто и как делал на бухе. авотматическое фомирование Книг: покупок и продаж

to Sheridan - ежели из комплекса выбросить зряплату, будет чудная конфа. Вот там реально можно работать. Руки вот не доходят смастерить такую - времени нет. Да и при моей специфике (упр учет, не торговля) проще ваять в данный момент на бух.
.
.
.
К народу - просьба не путать с ПУБ, ибо у нее изначально другое предназначение.

2(0) Можно все сделать на компоненте бухучет.
Пример - фирма в которой я до недавнего времени работал:
Мелкооптовая фирма (документооборот ~300 доков в день, в каждом доке ~ 15 строк). Число "пользователей" колеблется в течении дня от 3 до 7 чел.
Конфа - оригинальная на компоненте бухучет. Размер базы за год (2000)
4 Гб, в этом году планируется 2.5Гб. Сиквел не использую, крутится под "терминалом". Тормоза - очень редко (три менеджера запустили свои любимые обороты товара за квартал).

Почему вы думаете, что в бухгалтерии нет остатков на текущий момент?
Всегда есть! Давно делаю торговлю на бухгалтерии - никаких проблем!
В 9:40 товар выписали в 9:41:15 его уже на складе нет!

опечатка: нет уже в 9:40:15

Бухгалтерские счета отличаются от регистров ограничением на число измерений (до 5) и там только три ресурса - сумма, валютная сумма и количество. Кроме того в бухгалтерии встроенная система управления итогами. Поэтому нет ТА.
И все.

2 (0) Системщик прав, но при условии, что ему эксплуатировать!!! С комплексной проще, если вся контора в одном месте. Как мне кажется связка торг+бух в опте при постоянных корректировках менее мобильна, чем данный кусок в комплексной.
2 (7), а программер все равно нужен (вернее он уже есть...)
Если бы еще в комплексной можно было быстро и безпоследственно вычистить лишее (скажем убрать из нее зарплату или торговлю), то и глобальник полегчал бы и число файликов уменьшилось.

БОЛЬШОЙ ПРИВЕТ Tot-у, что то редко видно Вас?
.
.
а что, Би.Рассчитать( , ТекДок(), трали-вали
.
далее слабо катит? Ставишь указатель на нужный док и считаешь итоги. Некий аналог ТА в торговле. Можно даже остатки по часам на складе печатать (типа график наличия товара на 9-00, 10-00, ......)

Тогда подскажи вольный хлебопашец, как в Бухгалтерии реализовать продажу товара в розницу, чтобы наценка попадала на 42-й счет.

2(24)
Открываешь книгу: "Бухгалтерский учет для начинающих", ищешь тему - Бухгалтерский учет в условиях розничной торговли. Там очень хорошо все описано.
Не посчитай мои слова за наезд, но ИМХО многие проблемы исчезают, если внимательно и много времени уделить изучению литературы.
Меня както руководство озадачило: хотим считать отдельно наценку отгруженную и оплаченную. Долго общались с главбухом, книги почитали - сделали...

Нет, ты не понял(25). Знание бухгалтерии тут не причём. Можно ли это реализовать в Стандартной Бухгалтерии не переписывая её. Мне коллеги сказали, что нельзя. Суть вот в чём, получили товар по определённой цене. Надо его продать с 30-% наценкой. Эта наценка должна пойти на 42 счет. Вот и всё что хочет мой бух. Что делать - то . Это же не торговля и склад, где в расходке сразу ставить цена с наценкой, да что делать с 42-м, ручками забивать чтоли, мне кажеть что это всё решаеться просто, случай то типичный, но как...В Бухгалтерии и в бухгалтерии я пока ламер...:)(

2(26) Я когда уже запостил, подумал, что ты можешь имееть ввиду типовые конфигурации. Типовых уже тоже масса. Все не охватишь. Так-что по типовым - я не подсказчик. У меня лет 6 назад появилась своя "типовая", так я ее теперь и "дописываю, переделываю, и т.п.".
Могу только на вскитку совет дать - найти специалиста чтоб "поравил" как Вам хочется.

Спасибо, только эту проблему похоже прридётся решать именно мне

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

Да нет, В ЗиКе пишу, напишу и в Бухгалтерии

Изучать и внедрять - это самое то. Через годик посмотришь на свои произведения.. и поступишь как фирма 1С, а дальше нее (по типу MS)- бросишь на хрен свои произведения годичной давности и начнешь ваять новое,невиданное... Лучшее - враг хорошего...

В Бух можно организовать торговый учет, но такие были грабли: нет ТА,
если несколько менеджеров работают с клиентами и например резервируют,
товар, то не хватает метода ПроводитьПослеТА, дописывал а-ля 7.5 ГП и
проч. но вот именно при проведении не получается изменить время документа,
отчасти проблема решилась переходом на TSE, все рабочие места время с
сервака берут. Может чего-то я не догнал, не знаю. А еще итоги из регистров
быстрее получаются, при партионном учете удобнее, хотя и в бух тоже
неплохо. Очень понравилась "Синимекс-Гостиница" для Торговли, на бух такое
сделать проблематично, ИМХО.

Насчет изменения времени дока из самого дока - это да. Метода ПроводитьПослеТА не хватает в бух.
.
Насчет времени на рабочих станциях - пинай админа. Можно клиентов (и НТ/2К и новеловского) настроить так, чтобы при регистрации раб станции они брали время с сервака. Влом это, но можно. И проблем меньше. Но побегать по машинам админу придется.
.
Насчет утверждения "НА БУХ СДЕЛАТЬ ПРОБЛЕМАТИЧНО" - туфта. ВСЕ можно реализовать на ВСЕМ (всех компонентах) (с)Не помню чей, по моему слышал от Тот-а. Степень гемора только различается. Так что извини.

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

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

Аналитическими отчетами из типовой ТиС можно посоветовать пользоваться только врагу. Поскольку любой анализ в ней привязан к некорректной реализации учета себестоимости. Что касается работы нескольких менеджеров - что в ТиС, что в бухгалтерии - пока юзер не предпринял конкретных действий (типа проведения дока), ничего не зарезервируется. А точка актуальности -это, по моему скромному мнению, генеральная ошибка. Юзеры разные - а точка одна?! Засуньте ее куда поглубже... Если уж у кого возникает конфликт пользователей за товар, скажем, то отрабатывать это нужно на уровне транзакции при выборе товара прямо в строке дока, а не при проведении. При этом программер должен очень корректно сформулировать запрет для других пользователей ;-) Соответственно, ничего,кроме дополнительных головняков, ТА не дает.

Егор, спасибо за ценные мысли. Надо обмозговать...

Наверное есть смысл обсуждать не типовые конфы, а компоненты ...

(17) именно так и поступила - очень оказалось удобно :-)

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

(40) Именно в бухгалтерии это проще чем в ТиС. Т.к. бухгалтерский учет и есть та часть работы предприятия, предназначенная именно для решения поставленного вопроса. Для отнесения НДС на налоговые вычеты нужно выполнить три условия:
1. Оприходовать товар
2. Оплатить (включая НДС)
3. Получить правильно оформленный счет-фактуру.
Если товар только приходуется, то НДС для опта выделяется из цены и сумм и относится на счет 19 (в типовой субсчет 19.6) в аналитике контрагент-договор(договор по практике-документ поставки, отсюда и можно определить факт оплаты конкретного документа поставки, хотя этот механизм тупой, требует доработки, эта аналитика д.б. не текстом, а документом) , а суммы без НДС относятся на счет 41 (в типовой субсчет 41.1.- товары на складах) в аналитике номенклатура-место хранения. Партионный учет в разрезе партий по себестоимости на счете 41.1. (третья аналитика) реализован мной с напарником (неоднократно обсуждался на форуме, посмотри в архиве на "партионный"). В рознице выделять НДС нужно только если в субъекте федерации не введен единый налог на вмененный доход в розничной торговле. (А введен он, похоже, повсеместно).

1. По поводу точки ТА. Никак не пойму ваших проблем. Наверно, от того, что "торговлю" делал еще на Бухгалтерии 6.0 и потому появление Предприятия 7.0 практически проигнорировал. Считайте, что в Бухгалтерии ваша ТА установлена на конец текущего месяца (квартала) - т.е. вы всегда имеете "теперешние" остатки на конец текущего месяца (квартала). Заводите документы хоть вчерашним, хоть завтрашним днем - будете иметь остатки с учетом ВСЕХ документов, проведенных с датой ДО конца текущего месяца (квартала). Текущие остатки товара (на конец месяца) надо показывать прямо в справочнике товара при его выборе. И делать проверку при проведении документа на случай ошибки или конфликта за товар: при проведении проводки по конкретному товару делается проверка на наличие этого товара на данный момент (проведения). И в случае если товар пошел на "красноту" делается сообщение в окне сообщений.
2) (40)По поводу учета НДС. На мой взгляд не стоит слепо следовать тупости (хитроумности?) налоговиков (т.е. делать точно так, как они велят) - они такое наворотить могут, что один человек работать будет, а десять человек за ним учет вести. Да и закон они часто нарушают (прямо на уровне своих инструкций) в плане дозволенного ущемления налогоплательщиков. Хотя считаться с их присутствием приходится и надо оставаться в "правовом поле". Если конкретно, то можно, конечно, реализовать партионный учет в Бухгалтерии (лишнее субконто). Но если это требуется не Бизнесу, а только Учету - то стоит ли усложнять жизнь себе и людям? Что касается конкретно НДС, то я обычно советую поступать в "обход". На 19 счете (как обычно) учитываются суммы НДС по поступившим счетам-фактурам. В конце месяца смотрится кредитовое (из РАЗВЕРНУТОГО) сальдо по счету 60 (Поставщики) - это сумма наших долгов по поставкам. Считаем, что у всех наших кредиторов НДС по максимуму (20%). Вычисляем НДС (16.67 от суммы кредиторской задолженности) и оставляем эту сумму на 19 счете. Остальное ставим к возмещению. И все. Никакой мороки с учетом оплаты по счетам (для книги покупок). НДС платится не "больше", а несколько "раньше". Зато ошибок практически быть не может (и штрафов, соответственно). И налоговикам ловить нечего (на этом фронте). Стоит ему рассказать как ведется учет, и он понимает, что нет смысла смотреть в книге покупок когда и как был оплачен товар. На всякий случай сделать разъяснение в учетной политике предприятия о способе уплаты НДС (объяснить, что это не ошибка расчета, которую налоговики должны исправить, а сознательная уплата небольшой суммы НДС авансом для простоты учета)

Согласен Егор, что ТА - инструмент не верный (личное мнение), ну нет такого понятия на складе у кладовщика остатки на 10.40 и на 10.41 - только текущие остаки. Но ТА позволяет быстрей получать итоги на момент документа.
Если принудительно переводить ТА на конец месяца мы получим агналог БИ, со всеми вытекающими последствиями - замедлением получения итогов на документ (происходит тупой перебор всех движений от начала месяца до этого документа - на бух.компоненте иначе никак).

2(41,42)Смешно читать! Даже беглый взгляд на ваши излияния показывает стремление ситуацию упростить. Для (41): партия твоя - приходный документ (как третье субконто на 41 счете), а статус партии (в разрезе купленный-принятый, товар-услуга), а если еще возвраты учитывать? Для (42): а если у клиента разные ставки НДС и НП, ему что, переплачивать государству, лишь бы налоговая не смогла бы придраться? Буквально на днях с одним клиентом разговаривал. Он мне говорит: "Я один НП перчисляю 50 тыс.ежемесячно. Мне все имеет значение, какую ставку применять 5% или расчетную 4,76%!" У него разница между тем или другим в 500р. Ему не все равно, кому их отдавать! И это правильно! Всем вашим рассуждениям и допущениям - грош цена! Кстати, реализовывал автоматическое формирование книги продаж на бух. разными способами. Всегда клиент должен был платить довольно много (с налету не так просто решается и всегда требует некоторых допущений за счет особенностей учета в конкретной фирме, т.е. без универсальности), хотя всегда оставался доволен результатами.

(44) Птенец - ты и есть птенец! (шутка, без обид)
НДС платится не больше - он платится немного раньше (видимо, текст у меня слишком большой - весь в голову не влазит)
Насчет экономии на налогах - люди экономят, деля на черное и белое (тоже неудобно, но все же эффективнее)

2(45)Ты забываешь о раздельном учете по ставкам НДС. И голова тут не причем: большая или маленькая. А деление на ч/б - вчерашний день!

(43) Никак не пойму - зачем тебе ЗАДАВАТЬ РАСЧЕТ итогов на момент проведения документа: эти итоги у тебя уже есть на конец месяца (это тоже самое, если ты проводишь последний документ, а если он - не последний, то сделай его сначала непроведенным). А итоги на конец периода рассчитываются в Бухгалтерии сразу, автоматически, внутренними средствами в момент проведения документа. Ничего дополнительно считать не нужно.
(46) Птенцу. О раздельном учете по ставкам НДС я не забываю: все учитывается как надо (в справочнике товар у каждого наименования и ставка НДС и льгота по НП), а кроме того от кого принят товар от ЮрЛица или ФизЛица (это важно для некоторых продовольственных товаров). Так что ОТГРУЖАЕТСЯ НАМИ товар КАК ПОЛОЖЕНО с учетом всех возможных льгот и экономий. В (42) речь идет об учете поставок, точнее о том идиотском положении, когда можно ставить к возмещению НДС только в случае оплаты соответствующей счет-фактуры. При большом количестве входящих счет-фактур и "сложных" их оплатах это и трудоемко и велика вероятность ошибки (невнимательности) буха. Поэтому вот такой красивый способ решения проблемы (могу спокойно похвалить, поскольку не я его придумал).
А к простоте надо стремиться (это как принцип). Посмотри как ты сам проги пишешь - сначала наворотишь незнамо что, потом (когда получишь нужный результат) начинаешь упрощать текст. Простота и краткость - показатели таланта. Говорят, что у сложных проблем не бывает простых решений, но с чего ты взял, что это - сложная проблема?
Если у вас деление Ч/Б уже вчерашний день - это счастье! Может, и до нас когда-нибудь дойдет (насколько моя жизнь станет проще и осмысленнее - сильно утомляет двойная бухгалтерия)

2(45) Ввод задним числом документов. И с чего ты взял, что речь идет только об общем остатке? Кроме остатка общего необходимо знать 1)остаток по партиям 2) остаток консигнационного товара 3) остаток на складе на документ. Кстати если контролировать остаток только на конец месяца - интересно будет наблюдать отрицательные остатки в карточке склада в течении месяца.
А при групповом перепроведении как быть без расчета на документ?

(47) "Часто простое, кажется сложным
Черное белым, белое черным" (с) песня из фильма
Двойная бухгалтерия действительно омрачала жизнь. Но сейчас в единой бухгалтерии для законного уменьшения налогооблагаемой базы приходится применять такие схемы товароденежногооборота, такие конфигурации взаимоотношений между предприятиями холдинга с разным юридическим статусом и отношением к гражданству, что просто рассуждать о том, что может торговля того, что не может бух - становится просто неразумно. Зачем городить огород и лепить все на какой-то одной компоненте? В такой ситуации получится план счетов с 15-ю субконто (причем в реальной работе никогда никто не на одном месте не сможет заполнить все необходимые, в силу отсутствия информации к этому времени) или еще какой гемор.
Вся прелесть в том, что есть 3 компоненты - у каждой какая-то своя песенка. Надо наиболее полно пользоваться всеми тремя. бОльшая часть задач будет проще.
Понятно, что за годы работы возникают какие-то предпочтения и "всю физику можно свести к слову, похожему на душ" (с) Преподаватель Вовочки, но беспредельного упрощения не было и быть не может.
А если на компоненте Оперативный учет я пишу 100 строк текста модуля, зачем мне писать 1500 на бух компоненте и наоборот? (тоже самое касается расчета)

Резюме:
Все проще сделать на бухгалтерии?
Или те кто в форуме, делают все на бухгалтерии, потому что это наследуемые приложения со времен 6.0?

Правильно автоматически расчет производится вн. средствами,вот только как? - или сразу на ТА, конец месяца БИ, или расчитываются по движениям.

(49 и 50)Налоговое законодательство у нас действительно тяжелое и сложное. Соответственно, и способы уменьшения налогового бремени тяжелы и сложны - это касается, главным образом, крупных предприятий: большие деньги прятать сложнее %) - такого рода проблемы ПОКА не сильно касаются лично меня и моих клиентов (наша жизнь ПОКА проще).
Речь о другом. Принципы бухучета наиболее адекватны для отражения (записи) экономической деятельности. Вопрос в том - нужны ли еще и другие, дополнительные средства? Лично мне (по большому счету, "методологически") не хватает в Бухгалтерии лишь возможности использования дополнительных "ресурсов" (термин из Торговли) кроме количества, суммы и валютной суммы, по которым бы системой также поддерживались обороты и сальдо (я могу получить нужный результат и на проводках, но тогда из-за отсутствия всего одного дополнительного поля удвоится количество проводок...)
(51) Сальдо на конец периода и обороты за период рассчитываются системой сразу при проведении документа (прибавляются соответствующие суммы по документу к текущим остаткам сальдо и оборотов) - ты об этом спрашиваешь?
(47) Групповыми перепроведениями давно не занимаюсь. Учет всегда веду по средней себестоимости (ну люблю я и все нормальные люди простоту). Раньше, когда я в документах не фиксировал текущую себестоимость на момент отгрузки товара, а документы прихода менялись (вариант - их не было вовсе) - да приходилось делать групповое перепроведение. Но и тогда в 6-ке, да кажется и сейчас в 7.х итоги считались по уже проведенным документам - так что проблем нет.
Если ведешь аналитику в нужных тебе разрезах, используя СЧЕТА и СУБКОНТО (будь то партии, документы, консигнационный товар) - проблем нет: эти остатки по ним получишь.
А карточки товара мы распечатываем только в том случае, если фактический остаток на складе не соответствует "компьютерному" - начинаем поиск с распечатки карточки.
НУ НЕ МОГУ Я ПОНЯТЬ,ЗАЧЕМ НУЖНА ТОЧКА АКТУАЛЬНОСТИ.
И вот что еще хочу сказать, Гил. Гораздо большего эффекта можно добиться, если СНАЧАЛА продумать схему бизнеса и систему учета в целом (в интересах получения всех НУЖНЫХ цифр), организовать соответствующий документооборот и ПОТОМ все это автоматизировать, чем автоматизировать уже сложившийся "сам по себе" и постоянно непредсказуемо меняющийся "порядок дел" на предприятии.
Поскольку мы обычно - не начальники, то вариант - предложи заменить существующий "порядок" на продуманную тобой хорошую простую схему.
Примечание. Большая схема (система) должна состоять из упорядоченного числа малых простых схем (элементов)
ИЗВИНИТЕ ЗА МЕНТОРСКИЙ СТИЛЬ ИЗЛОЖЕНИЯ

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

(53) А ты сделай итоговое списание по средней цене - 1 раз в месяц или 1 раз в квартал и все эти проблемы будут по барабану.

2(53) Gil, а в чем, собственно, проблема рассчета остатков на компоненте БУ на _произвольный_ документ?
Относительно споров по реализуемости на БУ партионного учета + розницы + сроков годности + ГТД и прочего - могу выложить на ftp настройку, используемую у бывших моих клиентов (аптечные сети). Условие - никакого коммерческого применения в Москве и Уфе. Если интересно - предлагайте адрес.

(55) Посмотри pls в мыльницу.

Не, ребята, если нужно одному-двоим - мне нефиг задрачиваться и рассылать по почте. Есть кто с фтп?

2(49)Абсолютно согласен! Единственно, о чем приходится ностальгировать - невозможность сейчас (пару лет назад что-то подобное приходилось делать на бух.+ торг.) самому написать конфигурацию, приближающуюся по возможностям к комплексной, но, при этом, обязательно использующую все плюсы всех трех компонент. Причин несколько: нет реальной большой многоплановой задачи, уровень типовых значительно вырос и на базе типовых уже можно с мЕньшими затратами проводить внедрения для небольших фирм, в третьих, нужно быть самокритичным, - недостаточно собственных ресурсов, в т.ч. интеллектуальных. Что касается советов, если кто-то в таковых нуждается, например (0), то могу дать один - браться за работу на основе того, в чем чувствуешь себя абсолютно компетентным. Строго говоря, дело не в количестве строк кода. Если ты пишешь 1500 быстрее в одной компоненте, чем 1000 в другой, при этом лучше понимаешь происходящие процессы, да еще решаешь все свои задачи, то нет причин обязательно прыгать из компоненты в компоненту, утяжеляя конфигурацию. Было время, когда и на шестерке творили чудеса и долго удивлялись (и я в т.ч.) зачем нужна семерка!? С другой стороны, мне жаль тех, кто дальше бух. ничего не видит, да и видеть не желает, еще и нас жизни учат!

2(58) "Всем вашим рассуждениям и допущениям - грош цена!" ;)
При солидарности с (58) хочу чуть добавить.
Самый ценный ресурс - интеллект, know-how. Т.е. если не знаешь - учись, нет времени - откажись.
Интеллект/знания/опыт выплескиваются по разному. Нужно просто найти метод с наибольшей эффективностью.

to Gil. А как тебе при групповом перепроведении такая альтернатива "точке актуальности": в первый проход обработка делает все нужные документы непроведенными (до конца отчетного периода), во второй проход перепроводит их, используя остатки на конец периода.
Впрочем, понимаю, что не во всех случаях поможет. Сам я, действительно, групповое перепроведение делал один раз в жизни (изменили "на ходу" порядок налогообложения) и было это зимой прошлого года. Так что, я - не "спец", конечно. А то, что сначала приход, а потом расход - этого вполне можно добиться (говорю из собственного опыта). Ведь так и должно быть?
(58) Птенцу. Честное слово - не хотел тебя обидеть. Просто не удержался и "обыграл" твой ник.
По поводу твоего "жаления" тех, кто дальше бухгалтерии ничего не видит. Нельзя объять необъятное. Есть множество вещей, которые и хотел бы узнать, но понимаю, что в своей жизни я уже этого не успею. Так что нужно выбирать, на что лучше потратить свое время... Зачем без необходимости перепрыгивать на другую платформу (это я тебе о Торговле)? Что ты скажешь, если тебя кто-нибудь пожалеет, что ты дальше 1С ничего не видишь (Паруса там не попробовал, Галактики, Бэста...) Лично я переходил с 6-ки на Бухгалтерию 7,5 из-за того, что там более одного субконто (не устраивало меня, что один и тот же товар на разных складах приходилось забивать в справочник по новой и считался он разными товарами). Такая вот была на тот момент "производственная необходимость". Хотя, конечно, достоинств и полезностей у 7,5 гораздо больше. А вот на 7,7 так и не перешел. Хотя на ней работать гораздо приятней и возможностей больше. Но не вижу я _экономической_ целесообразности такого перехода. Было бы бесплатно - перешел бы. А использовать пиратские версии на основной работе - не рискую. Мало ли что. А Бухгалтерии мне вполне хватает (кроме одного момента, о котором я уже писал). Так что потребности в Торговле просто не испытываю. И не уверен, что писать в ней быстрее. Впрочем, язык Бухгалтерии мне тоже не очень нравится.

Ну вот, опять понеслась такая пьянка – что лучше, регистры или план счетов. Сколь раз мы уже спорили об этом.
.
Я выскажу свое ИМХО, и не более. Просьба особо сильно не пинать. Только виртуально.
.
План счетов – вещь, заточенная очень хорошо под определенный класс задач. ЕЕ ОГРОМНЫМ ПРЕИМУЩЕСТВОМ является ее интуитивная понятность и прозрачность для конечного пользователя (буха). За что лично я ее и уважаю. И что дает этой компоненте Большое преимущество в виде ясной и понятной опять же ручной операции, где все делает бух по любой нужной ему ситуации. А методы бух итогов специализированы и дают возможность порезвиться
.
Регистры – способ 1- быстро получить итоги на ТА, 2- прикрутить требуемую аналитику без теоретических ограничений (по крайней мере видимых). Но гладко на бумаге. Покажите мне контору, в которой нет доков задним числом. А заднее проведение – и где ТА? Это первая проблема. Вторая – как показала практика (в том числе обсуждение на Бурге), прикручивать много аналитики к регистру - сильные тормоза.
.
Но не это основная проблема. Основная проблема в том, что регистры, при всей их универсальности, обладают одним существенным недостатком (уж не сочтите за защиту/восхваление бух итогов). Движения регистров не прозрачны и они не могут быть двинуты вручную. Можно конечно, написать универсальный док. самое главное, У РЕГИСТРОВ НЕТ РУЧНОЙ ЯСНОЙ ОПЕРАЦИИ, доступной рядовому менеджеру/буху, и многомерный непрозрачный учет, давая теоретически возможность ручной операции, из- за своей усложненности этого НЕ ДАЕТ СДЕЛАТЬ. А это в свою очередь вызывает значительное усложнение алгоритмов доков, и как следствие, увеличение времени проведения. ВСЕ СИТУАЦИИ в торг должны обрабатываться программно, так, как задумает программист. ИМЕННО это в реальных условиях многовариантности нашего мира убивает.
.
Отсутствие в бух нужных механизмов (партионного учета, некоторых других вещей) позволяет некоторым говорить о ущербности БУХ. Есть и другое мнение противоположное первому (типа ТОРГ – отстой). Лично я так не считаю. Все таки нужны и бух итоги и регистры. Но если бы был гибрид (помесь бух. итогов и регистров) с лучшими методами от них – было бы проще.
.
А, ИМХО, регистры в чистом виде что? – то, что на любой среде программирования реализуется влобовую на любой СУБД, с добавлением неких методов. Всетаки должна быть ориентированность на среду применения/область применения и заточенность. С соответствующими этой области методами. Тогда и алгоритмы проще и адаптивность задачи (проги) лучше.
.
.
Я не поминал партионный учет, ГТД, …. на бух компоненте. Я не поминал бухгалтерии на регистрах. Это все реализуемо (с некоторым количеством гемора). И именно это, на мой взгляд и есть доказательство того, что все можно сделать на всем. ВОПРОС – С КАКИМИ ИЗДЕРЖКАМИ?. Соответствуют ли используемые методы поставленной цели и какова эффективность ее достижения. Наверное, это главный критерий.

Замечание 1: Некоторым нужен бухучет в конторе, некоторым - нет.
Замечание 2: Некоторые организации находятся в столицах, некоторые нет.
Замечание 3: Наверное, следует стремиться к тиражности решения.
Поэтому для предприятий, где все равно ведут бухучет на компьютерах (т.е. БУ покупается) имеет смысл потратить чуть больше времени на реализации на платформе БУ, что забрать себе те деньги, которые они должны были бы выложить за Торг.
Все индивидуально, но в случае тиражных решений, клиент платит не за часы, а решение проблем (т.е. например, он готов за это отдать 3000 USD). Поэтому, imho, в общем случае, маржа на решении, которое требует для себя только стандартную бухгалтерию больше, чем для решения на БУ+ТОРГ.

to 62 - между прочим, для небольших контор "имеет смысл потратить чуть больше времени на реализации на платформе БУ, что забрать себе те деньги, которые они должны были бы выложить за Торг." (с) Nomad - ЭТО ТОЖЕ ИМЕЕТ ДОСТАТОЧНО БОЛЬШОЙ СМЫСЛ, хотя есть и многие другие причины реализовывать полный учет только на одной компоненте или на двух в виде, похожем на комплекс.

Одно из главных преимуществ бухгалтерии перед торговлей - полный набор типовых отчетов, которыми бухи могут вытащить из базы любую информацию и
которые им понятны и доступны как 2х2!, а для любой операции описаной на регистрах нужен свой отчет и как правило не один... - для программера посадить все на регистры - и ты на фирме самый нужный человек. ;-)

2(64) Сие преимущество вырастает от того, что в бухгалтерии существует промежуточное звено - проводки в операции. В случае несостыковок финансов легче отследить - где что неправильно делается - при проведении документа или при формировании отчета.
А вообще Торг - это полуфабрикат Бух. И если проследить динамику их появления то видно - сперва была Торг. Бух появилась намного позже. А под 7.0 ее не было вообще...

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

2(66) Думаю, что все же не прав. Достаточно же для этого всего лишь взять Торг и Бух и сравнить. Можно, конечно, и по размерам dll соответствующих. Компонента Бух намного сложнее и универсальней. Впрочем, это не только достоинство...

Ну есс-но универсальней и сложнее, кто ж об этом спорит, и появилась
она, последней. Мнение было о причинах того почему она появилась последней.
Я думал не потому что не могли в 1с, а не хотели до времени, а уж потом поюзав 7.0 выпустили и бух. А по функционалу конечно она посерьезней будет.

Вольный хлебопашец - спасибо. Золотые слова. Целиком и полностью поддерживаю.
.
К 49: AlexWhite: "Вся прелесть в том, что есть 3 компоненты - у каждой какая-то своя песенка."
Нэ так все это было, нэ так. :-)

65: Тот: "А вообще Торг - это полуфабрикат Бух."
А вот это очнь даже точно.

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

(71)- Укажите точное место настройки. Завтра же Вас посетит налоговый инспектор и засадит по самое дно кошелька (просто за отсутствие количественного учета в бухгалтерии).
.
зы. Ну что сказать про Сахалин? На острове сезон сбора дятлов....

2(0) Mazzy+Вольный... против AlexWhite и Птенца - выбирай на вкус!

Налоговый инспектор, на кой чёрт нужен количественный учет в бухгалтерии налоговым? Все отчисления: НДС, еще в России есть какой-то НП,и без количества неплохо отчисляются!!!