Сергей Павличенко пишет:
На машине, где физически стоит ключ нужно запустить инсталлятор 7.4.0, выбрать режим CUSTOM и проинсталлировать драйвера LPT и USB, а также Sentinel Protection Server
Такое впечатление, что это ключевое... Только что добавил для локальной версии БЭСТ-4 на машине с Win 98 в установку драйвера Sentinel Protection Server - ключ обнаружился.
Румия Хусаинова пишет:
Кивают на 1С.Там это реализовали.
В группе, объединенной товарным знаком "1С", по разным оценкам, 2-3 тысячи разных программ. В некоторых из них это, действительно, сделано.
Сделано и в 30% БЭСТов, причем существенно удобнее.
Получается, что излишне начисленный соцналог за одного сотрудника компенсируется недоначислением налога за других сотрудников...
Оно, вроде бы, совершенно логично, однако, принимая во извращенные фантазии творцов российского налогового законодательства, не поставлена ли ими здесь какая-нибудь "растяжка"?
В общем, «губит людей не пиво, губит людей вода». А бухгалтерию – «простые решения». Ну, открыли на счете 62 дополнительные субсчета, ну, завели несколько аналитических счетов на одного партнера. А когда выясняется, что в результате, вместо фактов хозяйственной деятельности начинаем отражать в бухгалтерском учете чужие фантазии – говорим: «Плохая программа».
Вроде как на автомобиле прокололи колесо, и решили на будущее поставить вместо каждого колеса – пару. Это же совершенно очевидно, что теперь, даже проколов одно колесо, можно дальше ехать. А что повернуть в результате почти невозможно, так это «й автомобиль».
Но шутки – шутками, а получается, что выстраивание оптимальной системы взаиморасчетов в автоматизированном учете починяется неким общим закономерностям, которые в значительной степени не зависят от конкретной системы автоматизации. И которые надо внимательно анализировать и изучать.
Вот и в нашем случае сетей магазинов, наверное, могут существовать сети «квазинезависимых предприятий», каждое из которых имеет свой расчетный счет. Где критерий того, надо или не надо на каждый магазин заводить свой аналитический счет? На мой взгляд, критерием является, принято или нет в такой сети для ВСЕХ сумм оплаты указывать, к какому магазину они относятся. Иначе нам придется сумму оплаты, полученную от центрального офиса, как-то по магазинам «разносить» или «распределять» на основании собственных представлений о том, что имели в виду люди, которые переводили эту оплату. То есть отражать в учете не факты, а наши фантазии о намерениях наших покупателей.
Если же мы хотим видеть отдельно поставки в каждый магазин, использование счета взаиморасчетов для этих целей совершенно противопоказано. Как лучше решать такую задачу? Не знаю, данных мало приводится. Цель учета неясна. Если предположить простейший вариант, что целью является отслеживание соответствия заявок от магазинов и фактических поставок, то центр тяжести этого учета должен быть не на суммовой, а на количественной составляющей поставок. Поэтому, наверное, с помощью специализированного модуля «Планирование закупок» мог бы быть построен эффективнее, чем с помощью аналитических счетов.
Цитата
nordk пишет:
Я уже не вспоминаю еще такой момент что с магазином может быть 2 договора поставки и надо различать по какому из них оплата идет.
Константин Евгеньевич, мы редко совпадаем в конкретных методах решения. Тем не менее, я надеюсь, что с общим выводом Вы согласитесь.
Итак, наличие переплаты по одному договору и недоплаты по другому. Опять надо себя спросить, что мы отражаем в учете, факты или собственные фантазии? Есть письменный договор с покупателем, в котором он настаивает на таком специфическом способе ведения взаиморасчетов? И если начнем предметно отвечать на эти ы, выяснится, что в 99% случаев учет расчетов «по договорам», или, тем более «по документам» - это учет именно наших представлений о том, за что заплатил покупатель. А он просто гасит накопившуюся общую задолженность.
Казалось бы, что из того? Ну увеличим на порядок число проводок в системе, ну, в плане счетов будет по специальному счету для каждой проводки. Компьютер железный, справится. Однако ситуация не так безобидна, как кажется на первый взгляд.
Я уже как-то и на форуме, и в своей книжке, приводил пример с покупателем, которому мы отпустили без предоплаты на 500 руб. конфет и на 500 руб. пряников. Через три дня этот покупатель перевел нам 1000 руб., и написал в платежке, что это – оплата по счету-фактуре № … за конфеты. И больше этот покупатель у нас не появлялся.
Что мы должны сделать по логике учета «по договорам»? Мы должны считать, что из 1000 руб. платежа 500 руб. – это оплата за поставленные конфеты, а 500 руб. – это авансовый платеж за другие конфеты, которые покупатель собирается получить от нас в будущем. Соответственно, на 500 руб. нужно выписать авансовую счет-фактуру, и начислить с этой суммы НДС. Что мы имеем, скажем, в конце года, когда увидели, что покупатель был разовый и больше не появился?
Начислили мы НДС не с 1000 руб., а с 1500 руб. И перспектив сторнировать НДС, начисленный по авансовой счет-фактуре, у нас нет. Появилась дебиторская задолженность на 500 руб. и на 500 руб. – кредиторская. Короче говоря, плата за отражение в учете 1(одних) Сказок оказалась достаточно ощутимой.
Именно поэтому я утверждаю, что многоуровневая аналитика на счетах взаиморасчетов в 99% случаев – вещь не просто бесполезная, а попросту вредная. Реально она необходима только в очень немногочисленных случаях. Например, когда предприятие является провайдером интернет-услуг и одновременно оказывает услуги сотовой связи. Причем не предоставляет эти услуги в кредит.
Я прошу прощения, что влез с этими рассуждениями общего характера во вполне конкретный разговор, о том какими средствами можно решить конкретную проблему. Но именно потому и влез, что хочу подчеркнуть следующее обстоятельство. Прежде, чем проблему решать, «обсасывать» ее надо со всех сторон. Потому, что поспешно сделав «простое решение», можно достаточно серьезно подпортить хорошую учетную систему. Вот с этим, надеюсь, коллеги согласятся.
Саак Шахламджян пишет:
А то действительно все получается методом тыка... (получается, пожалуй, что в самом простом варианте предприятия я его все-таки методом тыка и изучил)
Категорически против недооценки этого метода!
Более того, считаю, что его надо назвать как-то более красиво. Самое подходящее было бы - "Имитационное моделирование компьютерных технологий управления производством". Одна беда, математики лет сорок назад назвали "имитационным моделированием" тупое многократное повторение алгоритма, с изменением параметров методом случайных чисел. При чем здесь имитация? Вот мы, действительно, имитируем документооборот некоего модельного предприятия, использую ту или иную систему автоматизации.
Лично для себя я вижу главную сложность в освоении производственных модулей БЭСТ-5 в том, что попросту слабо представляю себе планово-экономическую работу. Вот если бы кто-то подробно расписал, что и в какой последовательности нужно делать на простейшем предприятии, безотносительно к какой-либо программной системе, а потом - как это реализовать в БЭСТ-5, это был бы материал, которого нам всем очень не хватает.
Так что, если позволите, совет. Записывайте свои "тыки"...
Но оплата поступает из одного источника и безотносительно к магазинам. То, что учет поставок в разрезе магазинов и их соответствия заявкам вести надо, с этим никто не спорит. Но не решается эта задача ни многоуровневой аналитикой на счете 62, ни аналитическими счетами под каждый магазин...
Господа, вы все о программировании, а я опять про бухгалтерию...
Покупатель в описанной ситуации один, а грузополучателей много. Взаиморасчеты имеют экономический смысл только с одним покупателем - фирмой, владеющей сетью. Поэтому аналитические счета для грузополучателей на счете 62 - вещь ненужная и вредная.
Для грузополучателей имеет смысл только отслеживание соответствия их заявок и реальных поставок по накладным. А это совсем другая задача, не имеющая к взаиморасчетам никакого отношения. И если и применять к ее решению бухгалтерские проводки, то только на забалансовые счета.
Двухуровневой аналитики в БЭСТ-4 нет. Но думаю, если бы она и присутствовала, применять ее надо очень осторожно, и только после тщательного анализа бухгалтерской стороны дела.
В данном случае непонятно, почему на счете 62 фигурируют магазины, и тем более - плательщик? Если магазины входят в состав одного юридического лица, то это скорее складские подразделения. Если это разные юридические лица - в каждом магазине свой план счетов. Он может быть унифицированным, ы взаиморасчетов в холдинге как-то отрегулированы, но все равно учет - раздельный.
Короче говоря, явно не хватает бухгалтерских подробностей. А задача интересная, у меня тоже на обслуживании сеть магазинов...
Александр Мусинов пишет:
таким образом нарушать лицензионное соглашение и подвергну себя административной, либо уголовной отвественности?
По-моему, нарушением лицензионного соглашения с компанией БЭСТ это уж точно быть не может. Более того, думаю, что компания такие попытки будет приветствовать.
Алексей Новиков пишет:
Как разработчик может однозначно определить, что из Ваших начислений относится к больничным, что к отпускам?
Это определять, конечно, не нужно, а вот коды доходов определяются законодательно. Так что список кодов может быть стандартным, к каждому коду - своя колонка начислений, а состав колонки определяется индивидуально.
С другой стороны, добавить 3-4 новых кода, завести новые колонки, убрать начисления из старых колонок... Стоит ли по этому поводу напрягать разработчика?
Если сформировать "Сводную оборотную ведомость", вид ведомости "сверочная", в последней колонке будет разность начальный остаток + приход - расход - конечный остаток. Ведомость большая, но просмотреть эту колонку можно.
Скорее всего, там, все-таки, заметные расхождения по небольшому количеству номенклатурных номеров. бы выписать 2-3-4 позиции с максимальным отклонением, и внимательно проанализировать, что произошло со складским ценами для этих номенклатурных номеров, напрмер, с помощью "Детальной ведомости движения".
Возможно, что в на какую-то дату по этим позициям были отрицательные остатки, и себестоимость по этой причине было невозможно корректно рассчитать.
Но чудес здесь обычно не бывает. Если есть отклонение, значит, неправильно рассчитаны либо цены списания, либо стоимость конечных остатков.
Алексей Новиков пишет:
А какое наказание предусмотрено за нарушение установленного порядка предоставления сведений (например, невыделение отпускных отдельным кодом)?
Скорее всего, просто могут не принять данные. А вот на 2008 год надо непременно перенастроить. Кстати, там еще доходы от использования в служебных целях личного транспорта 2400, доходы по договорам гражданско-правового характера 2010, мат.помощь теперь может быть от работодателя и иная, что-то еще...
Александр Павлющик пишет:
Увы, не попались мне в свое время некоторые программисты. Не видать бы им зачета по информатике!
По-моему, тот факт, что авторы налогового кодеса - бывшие двоечники, причем не только по информатике, но и по бухучету, совершенно очевиден.
Представьте себе счет-фактуру на 30 строк. В каждой строке НДС округляется до копейки. Подсчитываем итог, делая сначала округление, потом суммирование. Итоговая сумма НДС не равна 18% от итоговой суммы счета-фактуры. Что налоговый инспектор отмечает. Подсчитываем итог, делая сначала суммирование, потом округление. Итоговая сумма НДС не равна итогу, полученному на калькуляторе. Что налоговый инспектор тоже отмечает. Да еще при этом говорит про программистов и "1С".
Но Яков Александрович прав, скорее всего, проблема не в этом. Так что ждем подробности.
К сожалению, разработчики в августе 2007 года отошли от принципа, когда при снятии ключа рабочая версия превращается в демо, т.е. продолжает работать, но с принятыми для демоверсии ограничениями.
Теперь она не работает вообще, а для установки демоверсии используются специальные установочные файлы.
За это я разработчиков критиковал и продолжаю это делать. Можете присоединить к этой критике и свой голос.
Насколько я понимаю, о том, куда девать ошибки округления, в теории бухгалтерского учета решен. Они относятся на счета прибылей и убытков. Так что, если, например, в конце квартала образовалась разница между суммарными остатками по картотеке, учитываемыми на счете 106, и дебетовым сальдо на этом счете в 15 коп., последним днем квартала делается проводка ДТ106 КТ99 на эту сумму. С текстом, скажем, "Списание ошибок округления". И некоторе знакомые главные бухгалтеры такие проводки с удовольствием делают. Для них это своеобразный "бухгалтерский шик".
Но, конечно, 1500 руб. - это очень много. И, насколько я понимаю, речь идет не столько о разнице между проводками и остатками, сколько о "несхождении" оборотной ведомости движения ТМЦ. Поясните, пожалуйста, ведомость делается по отдельному складскому подразделению или по предприятию в целом? Учет, судя по всему, по фактическим ценам? Ведомость формируете после расчета себестоимости?
Илья Аниканов пишет:
Сформировали файл через Групповые справки - 2-ндфл в электронном виде(ХML 2006),пытались сдать через электронную отчетность.
Запаздывает КБ, и это всех нас не красит... Но экспорт данных за 2007г. в программу "Налогоплательщик" сделали. Сегодня поставил трем клиентам пакет 1-43, везде экспорт прошел без проблем. Так что в Вашем случае, пожалуй, самым простым выходом было бы следующее.
1. Поставить "Налогоплательщик" версии 11, полученный в ИМНС или с их сайта.
2. Сделать экспорт из БЭСТ-4+ в "Налогоплательщик".
3. В "Налогоплательщике" в п."Сервис" запустить "Лечение баз", затем сформировать XML-файл формата 2007г.
4. Загрузить этот файл в программу передачи отчетности.
Кажется, после большой раскачки, минимальная команда все же сформировалась. Через пару дней начнем работать вплотную. Если есть еще желающие, милости просим.
Господа, я имею слабость развлекаться преподаванием. Учу компьютерным технологиям бухгалтерского учета в Российском государственном торгово-экономическом университете. Собственно говоря, учу практической бухгалтерии. Программы БЭСТ при этом, конечно, тоже осваивается, но главная цель - подготовить спецалиста с навыками главного бухгалтера. Судя по тому, что среди выпускников главных много, вроде, получается. Хотя, конечно, всегда помню, что делаю это не один.
Подготовка по практическому учету у нас двухуровневая. На первом уровне студент в одиночку моделирует работу малого предприятия. Это дело я изложил в недавно вышедшей книге. А центральным звеном обучения на втором уровне является деловая игра, в процессе которой студенты моделируют работу разных специалистов среднего предприятия с оптовой и розничной торговлей. Действия всех участников "наполняют" одну базу, команда работает в сетевом режиме, в конце получаем квартальный баланс и другую отчетность. Очень предметно рассматриваем процесс диагностики бухгалтерской системы и поиск ошибок в учете.
На сайте Компании БЭСТ появилась возможность организовать такую игру без необходимости собирать всех ее участников в одном месте. Для этого только нужно, чтобы у каждого был в распоряжении интернет со скоростью не менее 128 Кбит/сек. Там для этих целей открыли специальную базу, с которой можно работать в терминальном режиме. Работу мы с К.Е.Горбуновым из Санкт-Петербурга опробовали, вроде, получается. Однако, если в такой игре участвуют меньше, чем 5-7 человек, она становится неинтересной.
А вот собрать команду мне никак не удается. Поднял этот только среди дилеров БЭСТ. Вроде, все "за", а кандидатур нет, хотя предложил более месяца назад. Я, конечно, понимаю, что праздники, каникулы, отчетность. Но хочется все же опробовать технологии, посмотреть, какие появятся проблемы, и вообще, как все это будет выглядеть.
По этой причине обращаюсь теперь не только к дилерам, но и ко всем посетителям сайта по БЭСТ-5. Если в Вашем окружении есть молодой бухгалтер, который хочет стать главным, но пока им не стал, студент, желающий плотно "въехать" в практическую бухгалтерию, сотрудник, который что-то о теории бухучета знает, но хочет освоить практическую сторону, приглашаю всех их принять участие в упомянутой деловой игре. Обязательное условие одно - доступ к быстрому интрнету, чтобы можно было зайти на demo.bestnet.ru (там еще поставить комоненты Java придется). А в остальном детали уточним, исходя из состава участников. Рассчитываю это мероприятие месяца на два.
Если желающие принять участие есть, прошу их написать мне по адресу bt@freeline.ru, Иванов Николай Николаевич. Детали обсудим.
В принципе, не исключено, что на такого рода образовательных услугах начнем зарабатывать деньги. Но пока все бесплатно.
Zoha пишет:
Т.е. у Вас в ключе не прописано приложение Товары.Продукция. Попробуйте через FoxBro изменить начальную дату этого приложения (...\SCLAD\User.dbf в строке с идентификатором SCL_BEG). Для выполнения штатного режима, отправил разработчику.
А у мня такая ситуация в пяти модулях, которых нет у клиента. Везде другая дата начала периода. Это "Товары", "Продажи", "Закупки", Касса" и "Основные средства". Не подскажете, где в каких файлах нужно исправлять эту дату?