Статья называется "Как руководить интровертами без вреда для здоровья". Типа это актуальная проблема.
Интроверт продуктивен в тиши и одиночестве.
Интроверт работает один и отвечает за всё сам.
Продуктивен, ответственен, другим не мешает.
И в чем проблема руководить таким человеком?
Может им просто не руководить надо, а помогать ему?
Экстраверт умеет и любит работать в команде. На раз-два налаживает контакты и генерирует идеи на лету.
Экстраверт привык делить и работу, и ответственность.
Я один здесь вижу безответственного чувака, балабола и бездельника?
Может вести крупный проект, где за коммуникацию будут отвечать экстраверты.
Но что при этом думает РП-интроверт об продажнике-экстраверте, наобещавшем заказчику золотые горы, интроверт вслух не произносит, дабы не нарушать деловую этику и тонкую психику экстраверта.
Честно говоря, я не в курсе, как сейчас по законодательству.
Исходя из общих рассуждений — это теоретически возможно, но при условии отсутствия других обязательств у предприятий, особенно перед бюджетом, судом и т.п.
Во время кризиса неплатежей в 90-х взаиморасчеты делались все равно через банки — предприятия приносили реестры своих должников, те — своих и так далее. Если цепочка замыкалась, то расчеты по всем счетам проводились одним днем.
Есть еще третья категория б/у. Бюджетники. Эти звери по моему вообще проводки не разносят никогда.
У меня пока обошлось, не встречался.
Ведь в реальной жизни красным ничего не бывает. Ведь фактически описанный вами овердрафт внутри дня это отдельный счет с кредитом, который работает только в рамках дня.
Я не очень понял про отдельный счет с кредитом. Когда оформляется овердрафт по расчетному счету, то ссудный счет к нему либо открывается сразу, либо при первой выдаче (погашения красного сальдо на расчетном счете). Или вы про что?
Просто мы скрываем часть проводок, для простоты.
Нет, мы их реально не делаем, потому что для них нет никаких оснований в течение дня. Представьте два предприятия, которые в течение дня должны рассчитаться друг с другом. У обоих по 10р. на счету, а взаимные долги по 100р. Если бы не было овердрафта, то они не могли бы рассчитаться никак, пока у одного из них не появятся средства извне.
С овердрафтом они рассчитаются, но на конец дня у них будет опять положительный остаток и выдачи кредита не происходит, новые проводки не появляются. Вот если один не заплатит, то у второго будет красное сальдо, недостача на счете — вот тогда появится проводка по выдаче кредита, которая обнулит остаток.
Извините, если кто-то выше написал то же самое, а я не заметил.
Исторически у нас в СССР сложилось две практики бухучета — б/у предприятий и банковский б/у. На предприятиях обычной практикой было в течение месяца квартала оформлять документы — ордера, авансы, накладные, приходы и расходы и т.д. согласно бюджета, но без отражения по счетам. То есть операции делались, а проводки не фиксировались. Рассчитывалась, к примеру, зарплата, заказывались деньги в банке — зарплата выплачивалась, ведомость по выплате клалась в ящик. И каждый конец квартала был аврал по оформлению квартального отчета. Из всех ящиков вытаскивались все накопившиеся бумажки, считались и записывались в Главную книгу, причем (в зависимости от бухгалтера, конечно) каждый раз главный бухгалтер переживал, сойдется у него баланс или не сойдется. Сколько из-за этого инфарктов было…
У банков же была классическая двойная запись — каждая операция отражалась по двум счетам одновременно и в тот же день. Фактически банки работали только утром, а во второй половине дооформляли документы и по каждому из них делали проводки.
Причина в столь разительной разнице в подходах проста — банки сдавали баланс в ЦБ каждый день, а предприятия в налоговую — ежеквартально.
Так вот, когда началась автоматизация бухгалтерии и банков, то одним программистам ставили задачи бухгалтера предприятий, а другим — банковские. Поэтому одни программисты реализововали документы с «полупроводками», т.е. с отражением по одному счету, а другие запрещали вводить документ, если в нем не было проводки (или нескольких) с двумя счетами и одной и той же суммой по обоим из них.
Та же история с активными и пассивными счетами. У некоторых бухгалтеров не было особого понимания, что одни являются естественным продолжением других. Главная книга (в смысле натурально КНИГА) их содержала в разных разделах. Поэтому при автоматизации бухгалтера ставили задачу «хочу видеть АКТИВ отдельно от ПАССИВА». Кто из программистов не повелся, тот молодец. Но многие сделали эти счета отдельными (некоторые даже вели их в разных таблицах) и положительными. Что из этого получилось — описано в статье.
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
И о погоде проводках. Изначально — да, проводки содержали два счета и одну сумму. Когда банки стали заниматься инвалютой, то оказалось, что конверсионные проводки плохо укладываются в этот шаблон — суммы в валюте счета по дебету и по кредиту не совпадали. Так как на тот момент нельзя было изменить структуру проводки, то ввели конверсионные счета. Для простой операции вместо одной проводки стало три (с учетом курсовой разницы), иногда четыре. Потом автоматизация улучшилась, и в одну проводку стало можно запихать не одну сумму, а точнее, две и более сумм в разных валютах финансовых инструментах. И не два счета, а 1:M или М:1. Главное, что должно было соблюдаться — равенство сумм в рублях РФ по дебету и кредиту. Ну и соответствие правилам бухучета, конечно, к примеру не стоило запихивать в одну проводку балансовые и внебалансовые счета.
Так вот, о чем же это я хотел сказать… А! На самом деле неважно, создаете ли вы полупроводки или полноценные проводки в момент осуществления операции, или вообще не отражаете операцию по счетам — главное, чтобы на конец дня у вас был полноценный правильный бухучет. По этой причине, а также для улучшения производительности «главную книгу» иногда делают в банках отдельной системой, а правила создания проводок выносят на промежуточный слой, который анализирует операцию и создает нужные проводки, пусть даже с временным лагом.
И бородатый анекдот в тему:
Устроился молодой бухгалтер на работу в одну контору. Хороший оказался специалист. Быстро начал в гору идти. Только вот у него странность одна была. Каждое утро он садился на свое рабочее место, отпирал ключиком тумбочку, выдвигал верхний ящик, заглядывал в него, снова запирал и приступал к работе. Шли годы. Он стал главным бухгалтером этого предприятия. Но каждое утро он заглядывал перед работой в тумбочку. Коллеги недоумевали, но в тумбочку заглянуть не решались, да и закрыта она была всегда. И вот, его проводили на пенсию. На следующее утро коллеги ринулись к его рабочему столу, взломали верхний ящик и увидели, что на его дне лежит бумажка, на которой написано крупными буквами:
"ДЕБЕТ — слева, КРЕДИТ — справа".
Мы предложили совсем другую модель, объединиться вокруг продуктов, включив в команду представителей от всех подразделений участвующих в процессах, связанных с данных продуктов(как продажа, так и обслуживание). Второе значимое нововведение – жизненный цикл банковского продукта начинается от лида и заканчивается в момент закрытия или перепродажи сделки.
Команда продолжает существовать, пока продукт продается и обслуживается?
Любой участник команды описывает реализуемое изменение для предварительного анализа, используя для этого формат user-story, которое в итоге попадает в беклог бизнес-аналитика.
В результате к пром у вас описание продукта состоит из собранных user-story и бэклога?
Владелец продукта получает результат каждого спринта на тестирование и может влиять на дальнейший ход
Можете поделиться статистикой, сколько обычно времени занимает реализация нового продукта от идеи до установки в пром. эксплуатацию? Подозреваю, что сложные продукты владелец замучается тестировать на начальных этапах.
Кажется, нашел — это СИД-1000, на этой фотографии он слева.
Судя по тому, что в справочнике (стр.94) фигурирует «Время начертания одного символа» — он векторный
В этот момент я осознал, что все эти процессы, которые мне казались бюрократией, были придуманы людьми не просто так.
Парадокс, но находятся люди с не меньшим опытом, но так и не осознавшие эту истину.
Вдвойне парадокс, но некоторые из этих людей — менеджеры разработки…
Главное отличие тех мониторов от этого РИН, которое мне запомнилось — ноль не в ту сторону перечеркнут :) Так что они были живой иллюстрацией сказки о байте.
Судя по документации, дисплей разрабатывался как прямая замена популярного венгерского дисплея «Видеотон-340» в компьютерах типа М-400 или БЭСМ-6.
Видеотон-340, можно сказать, знаменитый монитор (который, к сожалению, пока не удалось раздобыть, и если у кого-нибудь такой есть, дайте знать). Это тот самый монитор, который стоит на столе у Калугиной в фильме «Служебный роман».
Сергей, а вы не застали векторные мониторы в комп.зале в здании на Гастелло? Похож на этот, но зеленый люминофор и позиции символов были отмечены точками. Было прикольно, символы жили своей жизнью, дрожали, скакали вверх-вниз.
Интересный вопрос. В C++ я чаще работаю с QTableView, поэтому вводимое значение ловлю на setData модели. В одном месте у меня есть QTableWidget, но там используется свой делегат, т.к. данные сложные и редактор неоднозначный. В принципе, можно у дефолтного делегата взять сигнал commitData. А можно у QTableWidget переопределить виртуальные слоты edit и commitData — в первом запоминать редактируемую позицию, а во втором получать значение поля.
Пример:
#!/usr/bin/python3
# -*- coding: utf-8 -*-
import sys
from PyQt5.QtCore import *
from PyQt5.QtWidgets import *
class Table(QTableWidget):
def __init__(self, rows, columns, parent = None):
super().__init__(rows, columns, parent)
self.editIndex = QModelIndex()
def edit(self, index, trigger, event):
self.editIndex = index
return super().edit(index, trigger, event)
def commitData(self, editor):
print("Commit r: %s, c: %s" % (self.editIndex.row(), self.editIndex.column()))
print("Old value:", self.editIndex.data())
super().commitData(editor)
print("New value:", self.editIndex.data())
app = QApplication(sys.argv)
w = Table(12, 2)
for r in range(0,12):
i = QTableWidgetItem(str(r))
w.setItem(r, 0, i)
i = QTableWidgetItem("Item %s" % str(r))
w.setItem(r, 1, i)
w.show()
sys.exit(app.exec_())
поэтому если кто-то говорит что он работает в среде виндос и не использует его, то…
это можно объяснить только порогом вхождения.
Сейчас это Windows (на рабочих станциях). На пред-пред работе был Unix. Нет гарантии, что на следующей работе не будет чего-то еще. И это не считая виртуалок и серверов.
А WPF это самый простой способ создания оконных приложений из ныне существующих.
Есть такая поговорка «Самая короткая дорога — это та, которую вы знаете». Если вы знаете WPF — это прекрасно.
WPF был бы хорошим выбором при сочетании условий:
— если бы я его знал, хотя бы настолько же, насколько знаю Qt
— если бы студия была моим рабочим инструментом
— если Win была бы единственной операционкой в окружении
Выбор сочетания Python+PyQt в моем случае определялся низким порогом входа. В вашем это может быть другой набор инструментов.
Для PyQt нужен интерпретатор Python со своей стандартной библиотекой, сам PyQt и, вдобавок, прекомпилированные бинарники Qt. Установить всё это может быть не так уж просто, особенно если в системе нет нормального пакетного менеджера.
А вы попробуйте, узнаете, что это очень просто на большинстве систем. Для Windows инсталлятор Python качается с офф.сайта. В Linux он предустановлен, во FreeBCD ставится пакетом.
Чтобы поставить "сам PyQt и, вдобавок, прекомпилированные бинарники Qt", нужно лишь набрать команду, приведенную в статье
pip3 install pyqt5
Ваше приложение пока что слишком простое, чтобы заметить разницу.
Оно и должно оставаться простым. Зачем мне делать сложное, если достаточно простого?
Да, Qt достаточно. И на нем вы сможете написать все тоже самое, и даже больше и лучше.
Но для чистого Qt нужен компилятор C++, желательно приличная среда (Qt Сreator очень хорош) и много времени на ожидание компиляции и отладку.
Но зачем ждать, если Python запускается сразу, как язык он гораздо лаконичней C++, а через PyQt можно пользоваться всей мощью Qt. И что самое вкусное — практически без потери производительности.
До кучи:
"Никогда не принимайте контрпредложение"
Эффект второй системы
Продуктивен, ответственен, другим не мешает.
И в чем проблема руководить таким человеком?
Может им просто не руководить надо, а помогать ему?
Я один здесь вижу безответственного чувака, балабола и бездельника?
Но что при этом думает РП-интроверт об продажнике-экстраверте, наобещавшем заказчику золотые горы, интроверт вслух не произносит, дабы не нарушать деловую этику и тонкую психику экстраверта.
Исходя из общих рассуждений — это теоретически возможно, но при условии отсутствия других обязательств у предприятий, особенно перед бюджетом, судом и т.п.
Во время кризиса неплатежей в 90-х взаиморасчеты делались все равно через банки — предприятия приносили реестры своих должников, те — своих и так далее. Если цепочка замыкалась, то расчеты по всем счетам проводились одним днем.
У меня пока обошлось, не встречался.
Я не очень понял про отдельный счет с кредитом. Когда оформляется овердрафт по расчетному счету, то ссудный счет к нему либо открывается сразу, либо при первой выдаче (погашения красного сальдо на расчетном счете). Или вы про что?
Нет, мы их реально не делаем, потому что для них нет никаких оснований в течение дня. Представьте два предприятия, которые в течение дня должны рассчитаться друг с другом. У обоих по 10р. на счету, а взаимные долги по 100р. Если бы не было овердрафта, то они не могли бы рассчитаться никак, пока у одного из них не появятся средства извне.
С овердрафтом они рассчитаются, но на конец дня у них будет опять положительный остаток и выдачи кредита не происходит, новые проводки не появляются. Вот если один не заплатит, то у второго будет красное сальдо, недостача на счете — вот тогда появится проводка по выдаче кредита, которая обнулит остаток.
Исторически у нас в СССР сложилось две практики бухучета — б/у предприятий и банковский б/у. На предприятиях обычной практикой было в течение
месяцаквартала оформлять документы — ордера, авансы, накладные, приходы и расходы и т.д. согласно бюджета, но без отражения по счетам. То есть операции делались, а проводки не фиксировались. Рассчитывалась, к примеру, зарплата, заказывались деньги в банке — зарплата выплачивалась, ведомость по выплате клалась в ящик. И каждый конец квартала был аврал по оформлению квартального отчета. Из всех ящиков вытаскивались все накопившиеся бумажки, считались и записывались в Главную книгу, причем (в зависимости от бухгалтера, конечно) каждый раз главный бухгалтер переживал, сойдется у него баланс или не сойдется. Сколько из-за этого инфарктов было…У банков же была классическая двойная запись — каждая операция отражалась по двум счетам одновременно и в тот же день. Фактически банки работали только утром, а во второй половине дооформляли документы и по каждому из них делали проводки.
Причина в столь разительной разнице в подходах проста — банки сдавали баланс в ЦБ каждый день, а предприятия в налоговую — ежеквартально.
Так вот, когда началась автоматизация бухгалтерии и банков, то одним программистам ставили задачи бухгалтера предприятий, а другим — банковские. Поэтому одни программисты реализововали документы с «полупроводками», т.е. с отражением по одному счету, а другие запрещали вводить документ, если в нем не было проводки (или нескольких) с двумя счетами и одной и той же суммой по обоим из них.
Та же история с активными и пассивными счетами. У некоторых бухгалтеров не было особого понимания, что одни являются естественным продолжением других. Главная книга (в смысле натурально КНИГА) их содержала в разных разделах. Поэтому при автоматизации бухгалтера ставили задачу «хочу видеть АКТИВ отдельно от ПАССИВА». Кто из программистов не повелся, тот молодец. Но многие сделали эти счета отдельными (некоторые даже вели их в разных таблицах) и положительными. Что из этого получилось — описано в статье.
Об остатках на счетах. Выше есть абсолютно верный комментарий, что остаток должен соответствовать счету на конец дня. Точка. Что происходит с ним в течение дня — вообще говоря, не проблема бухучета. Например, расчетный счет (пассивный) с овердрафтом в банке может в течение уходить в минус и возвращаться. Главное, чтобы на конец дня его остаток был кредитовый или ноль. За это в банках отвечает специальная процедура урегулирования овердрафта, причем эта процедура необязательно автоматическая, урегулирование может делать человек, вручную переводя деньги с/на ссудного счета.
И о
погодепроводках. Изначально — да, проводки содержали два счета и одну сумму. Когда банки стали заниматься инвалютой, то оказалось, что конверсионные проводки плохо укладываются в этот шаблон — суммы в валюте счета по дебету и по кредиту не совпадали. Так как на тот момент нельзя было изменить структуру проводки, то ввели конверсионные счета. Для простой операции вместо одной проводки стало три (с учетом курсовой разницы), иногда четыре. Потом автоматизация улучшилась, и в одну проводку стало можно запихать не одну сумму, а точнее, две и более сумм в разныхвалютахфинансовых инструментах. И не два счета, а 1:M или М:1. Главное, что должно было соблюдаться — равенство сумм в рублях РФ по дебету и кредиту. Ну и соответствие правилам бухучета, конечно, к примеру не стоило запихивать в одну проводку балансовые и внебалансовые счета.Так вот, о чем же это я хотел сказать… А! На самом деле неважно, создаете ли вы полупроводки или полноценные проводки в момент осуществления операции, или вообще не отражаете операцию по счетам — главное, чтобы на конец дня у вас был полноценный правильный бухучет. По этой причине, а также для улучшения производительности «главную книгу» иногда делают в банках отдельной системой, а правила создания проводок выносят на промежуточный слой, который анализирует операцию и создает нужные проводки, пусть даже с временным лагом.
И бородатый анекдот в тему:
Команда продолжает существовать, пока продукт продается и обслуживается?
В результате к пром у вас описание продукта состоит из собранных user-story и бэклога?
Можете поделиться статистикой, сколько обычно времени занимает реализация нового продукта от идеи до установки в пром. эксплуатацию? Подозреваю, что сложные продукты владелец замучается тестировать на начальных этапах.
Судя по тому, что в справочнике (стр.94) фигурирует «Время начертания одного символа» — он векторный
Парадокс, но находятся люди с не меньшим опытом, но так и не осознавшие эту истину.
Вдвойне парадокс, но некоторые из этих людей — менеджеры разработки…
Сергей, а вы не застали векторные мониторы в комп.зале в здании на Гастелло? Похож на этот, но зеленый люминофор и позиции символов были отмечены точками. Было прикольно, символы жили своей жизнью, дрожали, скакали вверх-вниз.
Пример:
Сейчас это Windows (на рабочих станциях). На пред-пред работе был Unix. Нет гарантии, что на следующей работе не будет чего-то еще. И это не считая виртуалок и серверов.
Есть такая поговорка «Самая короткая дорога — это та, которую вы знаете». Если вы знаете WPF — это прекрасно.
— если бы я его знал, хотя бы настолько же, насколько знаю Qt
— если бы студия была моим рабочим инструментом
— если Win была бы единственной операционкой в окружении
Выбор сочетания Python+PyQt в моем случае определялся низким порогом входа. В вашем это может быть другой набор инструментов.
А вы попробуйте, узнаете, что это очень просто на большинстве систем. Для Windows инсталлятор Python качается с офф.сайта. В Linux он предустановлен, во FreeBCD ставится пакетом.
Чтобы поставить "сам PyQt и, вдобавок, прекомпилированные бинарники Qt", нужно лишь набрать команду, приведенную в статье
Оно и должно оставаться простым. Зачем мне делать сложное, если достаточно простого?
Да, Qt достаточно. И на нем вы сможете написать все тоже самое, и даже больше и лучше.
Но для чистого Qt нужен компилятор C++, желательно приличная среда (Qt Сreator очень хорош) и много времени на ожидание компиляции и отладку.
Но зачем ждать, если Python запускается сразу, как язык он гораздо лаконичней C++, а через PyQt можно пользоваться всей мощью Qt. И что самое вкусное — практически без потери производительности.