Что вы делаете, когда не хватает 41 учетного кода?

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

А мне, вот, пришлось пойти на "святотатство".
Достало, собственно говоря, не то, что учетных кодов не хватает, а непредсказуемость процесса.
У нас имеются несколько групп материалов (в российском учете это счета 10.01, 10.02, 10.03 и т.д.) и группа аналогичныз затратных счетов (например, 25.01, 25.02, 25.03 и 26.01, 26.02, 26.03 и так далее).
Для списания этих материалов на соответствующие им счета могут использоваться всего 2 внутренних покупателя (один для списания на 25 счета, другой — на 26-е). Параметр "Отображение учета из позиции запаса" у нас = "Да".
Но бывают случаи, когда те же материалы могут быть списаны в какой-то один счет, например, в брак, тогда приходится создавать 3 разных внутренних покупателя: для списания 10.01 в брак, для списания 10.02 в брак, для списания 10.03 в брак, либо занимать под списание в брак не один учетный код, а 3.
Самое главное, что при таких разных правилах нет уверенности, что пользователи не перепутают внутреннего покупателя и не выберут покупателя для списания 10.02 в брак при списании материала, учитываемого на счете 10.01 или 10.03. В этом случае произойдет совсем не то, что ожидается.
И самое печальное, что процесс очень непрозрачный, и, чтобы добавить возможность списания на какой-нибудь новый счет бухгалтер вынужден обращаться к эксперту по Скале, он должен ухитриться найти неиспользуемую "дырку" в автоучете и занять ее.
При этом, в настоящий момент количество свободных "дырок" приближается к нулю, а уверенности, что не понадобится списывать на какой-нибудь новый счет, нет.
Пришлось пойти на некие внешние доработки:
Всем внутренним покупателям установили учетный код 40 (при этом, что бы мы ни списывали, суммарный учетный код будет равен 40).
Позицию 365 в таблице автоучета модуля "Управление Запасами" очистили. При создании проводки получаем вместо бухгалтерского счета (365).
После создания проводок ГК модуля УЗ запускаем запрос, который обнаружив "(365)", "идет" в таблицу складских проводок (SC07), "смотрит" код покупателя, по коду покупателя "идет" в таблицу покупателей (SL01) и "смотрит" в поле "Счет предоплаты". А в этом поле у нас для внутренних покупателей подставлен тот самый счет, на который надо выполнить списание. "Взяв" этот счет, запрос заменяет на него цифры в скобочках (365).
Все счастливы.
Теперь мы можем не заботиться, что мы списываем, важно только "наклепать" нужное количество внутренних покупателей, которых может быть сколько угодно, хоть 100, хоть 1000. И процедура их ввода очень проста и прозрачна, надо правильно заполнить всего 5 полей и рядовой бухгалтер может это сделать.
Если кто-то заинтересуется, могу опубликовать текст запроса и инструкцию по вводу внутренних покупателей.
Запускаем новую процедуру в марте, но сама методика была мной придумана и опробована еще в мою бытность консультантом, единственное отличие, что тогда, когда я впервые использовал похожий вариант, длина бухгалтерского счета была 6 символов и их можно было "запихать" в код внутреннего покупателя, что позволяло, не "идти" в таблицу покупателей, а просто откинуть "INTR" и тем самым получить требуемый счет

Очень неплохо Правда, чем больше таких штуковин, тем большую тоску вызывает переход на очередной сервис-пак или версию

Juri писал(а):

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

Слава Богу, используемые мной в данной процедуре поля, вряд ли будут изменены в следующем сервис паке (если только не расширят учетную строку до 100 символов )