svarog

8
Рейтинг

svarog



  •   Регистрация: 02.04.2007 (17 лет назад)

  •   Был(а) на сайте: 22.10.2021

Подписчики 2
Группы

Рейтинг 8

Обработка заполнения итоговой накладной для 1С77 Украина
+8 –

Инструменты и обработки Для всех Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 1С:Производство+Услуги+Бухгалтерия 1С:Бухгалтерия для бюджетных учреждений 7.7 Украина Абонемент ($m) Внешняя обработка (ert,epf) Мастера заполнения

В связи с вводом в Украине закона о разрешении формирования итоговой налоговой накладной для постоянных покупателей, появилась необходимость заполнять итоговую налоговую накладную реализациями за предыдущий месяц. Обработка решает эту проблему.

1 стартмани

27.01.2012    13723    16    svarog    5       

8
Смотреть все

Комментарии

БУ › Опыт внедрения 1С-УНФ 8.2 › #103 15.02.13 18:23
Эх, классно, когда все делать через заказы. В УПП и УТ, чтобы красиво учитывать продажи, во всех доках обязательно указывать Заказ покупателя.
Здесь же производство идет на склад, и в течении недели продается клиентам или перерабатывается дальше.
БУ › Опыт внедрения 1С-УНФ 8.2 › #101 15.02.13 17:37
Та же хрень, что и в Beagle. У клиента низкомаржинальный товар (производство), и ему прям после каждого Производственного документа надо точно знать, сколько продукт на выходе стоит (ОПЗ почти нет, все затраты вводятся 1 раз в день на всю продукцию, выпущенную в этот день).
Чтобы не городить огород с полнеценным партионным учетом, думаю автоматически создавать партию товара (создавать элемент справочника Партии) при поступлении товара на склад, и автоматически заполнять свободную партию в расходных документах. Как еще можно сделать, чтобы потом можно было бы с горем пополам обновиться?
Dev › Обработка заполнения итоговой накладной для 1С77 Украина › #6 21.02.12 17:46
У меня "Дата виникнення податкового зобов’язання" = Дата реализации (соответственно, в документе заполняются). В документе "Налоговая накладная" в типовой конфигурации, когда устанавливается пометка "Итоговая" в табличной части видны эти даты. Автоматически суммы НДС по дате первого события не рассчитывается.
Dev › Обработка заполнения итоговой накладной для 1С77 Украина › #2 31.01.12 10:10
Да не за что
Dev › Обработка заполнения итоговой накладной для 1С77 Украина › #0 30.01.12 20:45
В связи с вводом в Украине закона о разрешении формирования итоговой налоговой накладной для постоянных покупателей, появилась необходимость заполнять итоговую налоговую накладную реализациями за предыдущий месяц. Обработка решает эту проблему.
Admin › Журнал регистрации изменений › #9 19.03.09 16:41
(7) Где то на инфостарте были измерены скорость работы с регистрами и справочником. Так в регистры сведений проигрывают по скорости записи/чтения справочникам. В регистрах идут проверки на уникальность записи, кажись так.
Admin › Журнал регистрации изменений › #8 19.03.09 16:38
странно отрабатывается обновление (при нажатии кнопки "Обновить") в обработке "Журнал изменений". С самом журнали запись есть, а в обработке показывает с запозданием минут на 15.
Admin › Журнал регистрации изменений › #1 18.03.09 11:21
Отличная обработка.
Есть пожелание:
1) при внесении изменений в табличной части (например, изменил колич. товара с 8 на 10), старое и новое значение количества в разных строках находятся. Т.е. выводит все реквизиты таб. части со старыми значениями и ниже все реквизиты таб. части с новыми значениями. Неудобно искать, что же изменилось. С реквизитами шапки документа синхронизация старых и новых значений происходит на ура (например, сумма документа).
2) Для более быстрого поиска измененных реквизитов можно было бы добавить галочку "Изменен" в таблице изменений.
Dev › Последовательность …и как "я" её понимаю … › #17 04.03.09 9:49
Очень актуальная тема, особенно для УПП с рабочей производственной частью....
частенько перепроводится период от недели до месяца для рассчета себестоимости...
Admin › Подсистема "Дополнительный журнал регистрации" (для любой конфигурации платформы 8.1) › #39 03.10.08 9:26
(38) С выгрузкой через план обмена - плохо. Ты ж каждую сек не будешь грузить, не получится. А если через каждую минуту (допустим), то один и тот же реквизит документа может изменить два пользователя. А запишется только последнее изменение, что есть неправильно.
По поводу XML. У меня распределенка на десяток подразделений. Что, с каждого тащить дополн. файл XML и сливать потом в один?? То же самое относится и к дампу. Это хорошо для БД одной, но не для распределенки.