Новая бета-версия 4.5.113

[Григорий]

Предлагаем опробовать новую бета-версию 4.5.113:

http://www.infop.ru/b2/beta/upgrade.pak

4.5 (113) от 29.11.2010

Изменения

• Добавлена возможность переноса данных из ДЦУ в ЖТО (меню Сервис | Специальные функции | Импорт из ДЦУ в ЖТО).
• Пункт "Перенос данных ЖТО в ДЦУ" (меню Сервис | Импорт/экспорт данных) переименован в "Импорт из ЖТО в ДЦУ" и перенесен в меню Сервис | Специальные функции.
• Добавлена возможность переноса данных по зарплате из версии Стандарт в ПРОФ (меню Сервис | Специальные функции | Импорт данных по зарплате: cо Стандарт на ПРОФ).
• Пункт "Перенос зарплаты с ПРОФ на Стандарт" (меню Сервис | Импорт/экспорт данных) переименован в "Импорт данных по зарплате: c ПРОФ на Стандарт" и перенесен в меню Сервис | Специальные функции.

Изменения в Зарплате и кадрах

• Улучшен отчет "Список сотрудников с параметрами" (контекстное меню справочника сотрудников, пункт Отчеты | Печать списка сотрудников). Добавлен вызов карточки сотрудника из отчета.
• В Справочнике видов приказов (меню Зарплата | Справочники) добавлены новые поля, отвечающие за доступ и видимость для полей в Журнале приказов:
  • Доступ к основным параметрам - принимает значения: "Доступно", "Видимо", "Нет". Настраивает доступ и видимость для полей "Подразделение", "Штатность", "Должность", "График рабочего времени" и "Счет затрат".
  • Доступ к основной должности - принимает значения: "Доступно", "Видимо", "Нет". Настраивает доступ и видимость для поля "Основная должность".
  • Доступ к дате конца - настраивает доступ для поля "Дата конца".
  • Доступ к коэффициенту рабочего времени - настраивает доступ для поля "Коэффициент рабочего времени".
  • Доступ к авансу - настраивает доступ для поля "Сумма (процент) аванса".
  • Доступ к информации по договору - настраивает доступ для полей "Испытательный срок", "№ договора", "Дата договора", "Шаблон договора".
  • Доступ к периоду работы - настраивает доступ для полей "Дата начала периода работы", "Дата окончания периода работы".
• В зависимости от настроек Справочника видов приказов, в Журнале приказов теперь скрываются лишние поля.

Изменения в Бухгалтерии

• Бланк "Расчет по начисленным и уплаченным страховым взносам РСВ-1 2010" перемещен на закладку "НДФЛ, ПФ, ФСС" (ранее он находился на закладке "ГНИ")
• Добавлен пункт контекстного меню "Отчеты | Движение средств" в контекстно меню справочника сотрудников.
• Добавлен пункт контекстного меню "Движение средств" в контекстно меню справочника основных средств.
• Добавлен пункт контекстного меню "Движение средств" в контекстно меню справочника клиентов.
• Добавлен пункт контекстного меню "Движение средств" в контекстно меню справочника ТМЦ и услуг.

Изменения в Складе

• Добавлен пункт меню "Отчеты | Признание расходов при УСН" (В комплексной версии используется отчет "Признание расходов при УСН" на вкладе "Склад", пункт меню "Отчеты | Прочие отчеты"). Он используется при упрощенной системе налогообложения с учетом доходов "доходы за вычетом расходов". Порядок работы следующий:
  1. Вносятся поступления в журнал товарных операций (ЖТО).
  2. Заносятся оплаты поставщику в журнал Платежные документы (Касса, Банк исходящий). Оплаты поставщику не обязательно связывать с конкретными поставками.
  3. Вносятся операции реализации в журнал товарных операций (ЖТО).
  4. Заносятся оплаты от покупателей в журнал Платежные документы (Касса, Банк исходящий) и обязательно связываются с конкретными реализациями.
  5. Запускается отчет, он формирует проводки и выводит обоснование расчета.
  Отчет работает при методе расчета учетной цены "По средней".

Далее тут:

http://www.infop.ru/forum/showthread.php?t=7019

[Писарев Петр]

Добавил МОЛ на склад, перешел в другую фирму, а там МОЛ болтается из предыдущей. Как бы его выгнать со склада?

P.S. проверял на демке

[Писарев Петр]

Почему бы все таки не добавить еще одну переменную ПАРАМ(по аналогии с зарплатой, во вложении), чтобы пользователь мог в частности бороться с двумя единицами измерения? Зачем добавлять детали, если можно воспользоваться коэффициентом при вводе операции.
http://www.infop.ru/forum/showthread.php?t=5858

[Виктор]

Сообщение от Писарев Петр

Почему бы все таки не добавить еще одну переменную ПАРАМ(по аналогии с зарплатой, во вложении), чтобы пользователь мог в частности бороться с двумя единицами измерения? Зачем добавлять детали, если можно воспользоваться коэффициентом при вводе операции.

Ты думаешь что хорошо будет пользователю вводить этот к-нт при каждом вводе? СЫмневаюсь я оНако!
Уж если решать вопрос со второй единицей, то решать принципиально и на долго. И ПАРАМ тут не поможет- это простая подпорка.
Лично я уже добавил в комплексе журнал коэффициентов, как детальку с_товары. Теперь со второй единицей не должно быть проблем.

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

[Писарев Петр]

Сообщение от Виктор

Ты думаешь что хорошо будет пользователю вводить этот к-нт при каждом вводе? СЫмневаюсь я оНако!

Дак пользователь не всегда это вводит, как и в зарплате переменную ПАРАМ не всегда используют.

Сообщение от Виктор

Уж если решать вопрос со второй единицей, то решать принципиально и на долго.

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

Сообщение от Виктор

И ПАРАМ тут не поможет- это простая подпорка.

Из двух зол на данном этапе - ПАРАМ - это меньшее.

Я "за" табличку деталей к с_товары. Где задаем коэффициенты преобразования из одной единицы в другую. Просто и понятно всем будет.

PS правда у нас тут мелкий вопрос и только с одним тмц: "яйцо", из штук в граммы. Но необходимость в подобных преобразованиях наблюдается вроде.

[Григорий]

Сообщение от Писарев Петр

Добавил МОЛ на склад, перешел в другую фирму, а там МОЛ болтается из предыдущей. Как бы его выгнать со склада?

P.S. проверял на демке

Скрипт где-то выкладывал по сотрудникам, он этот вопрос тоже решает.

[Игорь]

Сообщение от Crusaider

Я "за" табличку деталей к с_товары. Где задаем коэффициенты преобразования из одной единицы в другую. Просто и понятно всем будет.

PS правда у нас тут мелкий вопрос и только с одним тмц: "яйцо", из штук в граммы. Но необходимость в подобных преобразованиях наблюдается вроде.

Коэффициент перевода л-тонны,тонны-л зависит от температуры...
П.П.Насчет "яйцо" тут вы не правы.в граммах яичный порошок и меланж...для рецептов используется яйцо...а проблема в неправильной структуре рецепта
Николаю Бойченко я показывал как это делается и не надо переводных таблиц...

[nppinteh]

Добрый день!

А планируется ли через механизм импорта / экспорта через XML перебрасывать строчки Журнала начислений со всеми деталями и поддеталями?

[Григорий]

Сообщение от nppinteh

Добрый день!

А планируется ли через механизм импорта / экспорта через XML перебрасывать строчки Журнала начислений со всеми деталями и поддеталями?

Файловый обмен для склада в первую очередь переделаем на работу через XML а потом до журнала начислений думаю доберемся.

[Писарев Петр]

Сообщение от Виктор

Лично я уже добавил в комплексе журнал коэффициентов, как детальку с_товары.

А структура это детальки какова?

[Виктор]

Сообщение от Писарев Петр

А структура это детальки какова?

Самая простая: ид(ПК), идлинк(на с_товары), дата,коэффициент,единица

[nppinteh]

Сообщение от Григорий

Файловый обмен для склада в первую очередь переделаем на работу через XML а потом до журнала начислений думаю доберемся.

Классно!!!!

[nppinteh]

Добрый день!

Импорт/Экспорт (для склада) полезен в случае если первичные ключи совпадают.
К примеру, имеется 2 базы А и Б. Из базы Б нужно перекидывать накладные в А. В этом случае правильное копирование будет, если первичный ключ совпадает (для контрагентов, тмц и другие). Получается, что поле "код" для "с_клиенты" может не совпадать в базах А и Б, а поля "код_стр" совпадают. Это не проследить. (В ИП 1 такой проблемы не было, поскольку было только поле "код" текстовое)
Веду к тому, чтобы при импорте/экспорте из Б в А находился контрагент по полю "код_стр", то есть в базе А контрагент с полем код=126 , код_стр="0126" и наименование="ыва", в базе Б контрагент с полем код=127 , код_стр="0126" и наименование="ыва", а программма нашла бы именно код=126 для наименования "ыва" для импортируемой накладной. В настоящее время, если контрагент с полем код=127 отсутствует в базе А, то контрагент становится пустым; а если контрагент с полем код=127 присутствует в базе А с наименованием <>"ыва", то подставится неправильный контрагент в базу А
Понятное дело, что видимые код_стр для бухов должны быть ключевым моментом пр синхронизации клиентов (товаров, ....)

[Писарев Петр]

Сообщение от Crusaider

Я "за" табличку деталей к с_товары. Где задаем коэффициенты преобразования из одной единицы в другую. Просто и понятно всем будет.

PS правда у нас тут мелкий вопрос и только с одним тмц: "яйцо", из штук в граммы. Но необходимость в подобных преобразованиях наблюдается вроде.

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

Так что детальку прикрутить с коэффициентами - это можно. Вопрос все равно - каким образом можно для формирования проводок ПЕРЕДАВАТЬ в функцию формирования последних какой либо ПАРАМетр?

[Виктор]

Сообщение от Писарев Петр

Вопрос все равно - каким образом можно для формирования проводок ПЕРЕДАВАТЬ в функцию формирования последних какой либо ПАРАМетр?

Посмотри ПЕРЕМ или ПЕРЕМ_ВРЕМ. Может устроит. Хотя я их стараюсь избегать, но иногда устраивает.

PS Позднее исправление!!! Следует читать: ПРОФИЛЬ и ПРОФИЛЬ_ВРЕМ
Прошу прощения- поздно обратил внимание, что написал фигню.

[Писарев Петр]

Сообщение от Виктор

Посмотри ПЕРЕМ или ПЕРЕМ_ВРЕМ. Может устроит. Хотя я их стараюсь избегать, но иногда устраивает.

Это понятно, но это сопряжено с переделкой СТАНДАРТНЫХ функций. А этого бы не хотелдось. Но если добавить эту переменну.ю ПАРАМ в настройки склада и ДЦУ (по аналогии с зарплатой), то вопрос и двух единиц и дополнительных переменных РЕШИТСЯ.

Так что деталька, детальной, а доп переменная ПАРАМ нужна.

[Григорий]

Сообщение от nppinteh

Понятное дело, что видимые код_стр для бухов должны быть ключевым моментом пр синхронизации клиентов (товаров, ....)

Да, надо от ид-шников отходить, выигрыш в производительности от них не велик, а проблем вот таких вот прибавляют.

[Виктор]

Сообщение от Григорий

Да, надо от ид-шников отходить, выигрыш в производительности от них не велик, а проблем вот таких вот прибавляют.

Хорошо бы и все остальные справочники привести в такое же соответствие. Например, ос_ос....

[nppinteh]

Сообщение от Григорий

Да, надо от ид-шников отходить, выигрыш в производительности от них не велик, а проблем вот таких вот прибавляют.

Значит добавляем в проекты далекого будущего?