oca / l10n-brazil Goto Github PK

Nome truncado no arquivo txt ao emitir nf a pessoa física

Alguns clientes tem observado uma lentidão ao validar a NF. Testando na minha maquina:

Ubuntu 13.04
Intel® Core™ i7-3517U CPU @ 1.90GHz × 4
64-bit
8gb de RAM, DDR3
HD SSD

Uma NF com 150 itens demora em media 3 minutos para ser aprovada.

Se for mesmo esse tempo para um NF grande com varias parcelas (6x) seria interesante criar uma ação a ser processada no servidor para que o usuário continue trabalhando.

Alguem observou algo semelhante?

Tentei simular sem a localização foi bem rápido.

Abraços

Ao criar uma Regra de Posição Fiscal o sistema não verifica o Tipo Fiscal do Parceiro. Com isso não é possível criar regras para pessoas físicas e jurídicas.

Encontrado na versão 7.0

Traduzir a descrição dos módulos brasileiros, para ficar mais fácil na instalação saber o que significa cada módulo.

Ao incluir uma conta corrente para um parceiro, ao preencher o titular da conta, não existe os campos de endereço implementados pela localização brasileira como: número, bairro e município (campo relacional com a tabela l10n_br_base.city).

1 - Crie uma nova fatura;
2 - Selecione um cliente;
3 - Adicione um produto e coloque uma quantidade por ex: 10 un;
4 - Clique em atualizar;
5 - Altere a quantidade dos produtos;
6 - Clique em atualizar;
7 - Confirme a fatura.

A Base de calculo e valores dos impostos não será recalculada com a nova quantidade.

O CFOP na fatura depende da ordem das alterações no pedido de venda.
Ex.: Ordem que funciona corretamente:
Seleciona cliente,
aba "Outras Informações", seleciona possibilidades das Regras Posição Fiscal (Padrão = Revenda, seleciono Venda ST).
Seleciona o Produto
Confirma.

Que não funciona:
Seleciona cliente,
Seleciona produto,
aba "Outras Informações", seleciona possibilidades das Regras Posição Fiscal (Padrão = Revenda, seleciono Venda ST).
Confirma.

Neste segundo caso o CFOP não é alterado na fatura, ficando com informação obtida do padrão "Revenda".

Fui criar um reembolso de fornecedor manualmente me deparei com um erro ao importar no emissor de SP:

Rejeitado: Linha 15: O registro "N10d" não pode vir após um registro "N02"

Sendo que a CST é 00 não deveria entrar no trecho de exportação da CST 400 e 900.

Erro causado pela maneira que se esta comparando o string.

icms_cst = '00'
icms_cst in ('400')
True

No estado da Bahia existe dois tipos de inscrições estaduais (com 8 e 9 dígitos) a rotina atual de validação valida algumas inscrições mas outras não, o algoritmo de validação deve ser revisado, e deve ser incluído mais inscrições estaduais da Bahia nos testes.

Criar e calcular campos: vServ, vBC, vISS, vPIS, vCOFINS do total de serviços.

Hoje existe os totais do valor da base de calcula do ICMS e valor do ICMS no documento fiscal, mas seria importante ter o total de Outras base de calculo do ICMS para futuros desenvolvimentos relacionado ao SPED Fiscal.

Ao mesclar duas ordens de entregas de duas vendas cadastradas com custos.

O lançamento dos custos é duplicado.

Os impostos padrões de compra e venda solicitados durante o wizard de instalação do plano do modulo l10n_br, não correspondem com o modelo one2many presente por em product_tax_definition_line e service_tax_definition_line.

Seria interessante se no wizard não houvessem esses campos e num segundo momento os módulos l10n_br_account_product/service tivessem wizards.

A exportação para txt não leva em conta algumas CST de IPI, PIS e COFINS.
Modifcar o arquivo l10n_br_account/sped/nfe/serializer/txt.py para exportar corretamente a CST escolhida com as tags corretas.

Hoje existe somente o módulo l10n_br_sale, e não existe uma separação dos dados de produtos e serviços, e para usar a emissão da NFe hoje acaba sendo obrigatório ter o módulo de estoque o que exige a utilização do l10n_br_sale_stock, para deixar mais modular, será criado os módulos l10n_br_sale_product e l10n_br_sale_service, desta forma as funcionalidades de venda fica mais modular, já que pode ser instalado o modulo de vendas e faturamento(NFe) sem a necessidade de instalar o controle de estoque

No versão 3.10 da NFe, por requisitos foi inserido um campo na fatura chamado "Operação com Consumidor final".

A sugestão de desenvolvimento seria utilizar esse campo para automatizar o calculo da base do Icms, para quando a venda for para consumidor final, o IPI seja somado na base de Icms.

Importante lembrar, é que na posição fiscal já existe uma opção que corrige essa base do Icms, então para automatizar o processo faltaria inserir uma opção nas regras de posição fiscal para que a mesma filtre a posição fiscal correta.

Seria interessante também, vincular essa opção ao cadastro do cliente, pois na prática, a maioria dos clientes ou é sempre consumidor final ou revenda e vinculando essa opção ao cadastro do cliente, é possível evitar erros e enganos.

att,

Ordem atual de campos.

Desejado:

Hoje quando são criados documentos fiscais que não tem movimentação financeira na contabilidade os lançamentos não são feitos corretamente, pois ficam apenas uma parte do lançamento, é necessário a implementação de uma rotina que ao ser confirmado um documento fiscal sem movimentação financeira seja automaticamente feito todos os lançamentos para o documento fiscal não ficar eternamente com status de "aberto".

@mileo
Os testes que realizei relacionando ao frete na emissão de NFe 3.1 até agora estão ok, inclusive na validação com o Sefaz. Mas encotrei alguma coisa nas cotações, segue abaixo.

Problema:

O frete quando utilizado no sale.order está ficando duplicado no campo "total" do formulário.

l10n_br_brazil > branch '7.1'
NFe > branch 'develop'

Passo para reproduzir o erro:

1 - configurar o frete conforme PR-113;
2 - abrir uma cotação com um cliente qualquer e um produto qualquer com o valor de 100 reais;
3 - inserir um valor de 20 reais de frete no campo específico para frete;
4 - clicar no atualizar logo abaixo.

Resultado:

O total do orçamento foi de 140 reais, 100 do produto + 20 do frete + 20 da taxa de frete em impostos.

Resultado Desejado:

O total do orçamento deveria ficar em 120 reais

See https://lists.launchpad.net/openerp-community/msg02637.html
and
https://code.launchpad.net/~camptocamp/partner-contact-management/city_into_better_zip/+merge/162771

We will probably do it for v8

Atualmente ao incluir um novo contato de parceiro na sessão endereço não existe na visão os campos de endereço criados na localização brasileira como: número, bairro, município (campo relacional com a tabela l10n_br_base.city), é necessário incluir estes campos para o preenchimento correto dos endereços do contato.

Nos documentos fiscais no OpenERP é necessário incluir um campo para armazenar a data de entrada, caso o documentos fiscal seja de entrada (NFe de entrada por exemplo) ou saída (NFe de saída) cuja a data de saída seja diferente da data de emissão.

Hoje a classificação fiscal dos produtos é um campo prorperty e deve ser definido para cada empresa, o que gera um retrabalho quando existe mais de uma empresas no OpenERP, A sugestão é criar um novo campo chamado ncm_id do tipo many2one permitindo que seja definida o ncm para todas as empresas, facilitando a configuração fiscal.

Ao criar um reembolso de clientes a partir de Ordem de entrega. A Regra de posição fiscal é aplicada somente no cabeçalho e não nos itens

Para replicar o erro;
Criar uma Cotação, adiciona 2(Dois) itens, adiciona o frete e atualiza a ordem.

Excluir um ítem e atualizar o Valor da cotação.

Preço total da ordem fica incorreto.

Att

Ao definir uma posição fiscal de aquisição de ativo, com ipi e icms o saldo a pagar fica maior que o valor da fatura.

É possivel resolver o problema invertendo as linhas

        tax['amount'] = round(total_line * tax['percent'], precision)
        tax['amount'] = round(tax['amount'] * (1 - tax['base_reduction']), precision)

        if tax.get('tax_discount'):
            result['tax_discount'] += tax['amount']

Do account.py

ver se existe um refator possivel com o modulo stock_landed_costs
talvez custos de frete e seguro (o que o Luis Mileo fez) poderia ser refatorado para ficar compativel com isso.

O mapeamento feito entre esta classe, e outras como cce, invalid.number, invoice.cancel está incorreto.

Passos para reproduzir:
Com uma base vazia se for feito por exemplo a criação de uma inutilização de número, depois tentar enviar ao sefaz vai ocorrer erro ao tentar salvar um document_event.

Versões:

• develop

Isto porque na classe a propriedade document_events_id está relacionada a account.invoice.

Na classe invalid.number por exemplo ela referencia aquele campo, porém o campo não referencia de volta.

vRetPIS
vRetCOFINS
vRetCSLL
vBCIRRF
vIRRF
vBCRetPrev
vRetPrev

para poder rodar com --test-enable
algo foi quebrado no dispatch dos testes de cnpj ou inscriçao estadual parece

Ao criar uma order.line em uma sale.order:

Onde o produto tenha uma unidade de medida ( product_uom) diferente da padrão ( unidades ) carregada na visão por padrão antes de se escolher o item.

O metodo product_id_change da localização recebe a unidade de medida UN como parametro e ao chamar o super a "UN" é mantida.

def product_id_change(self, cr, uid, ids, pricelist, product, qty=0,
                      uom=False, qty_uos=0, uos=False, name='',
                      partner_id=False, lang=False, update_tax=True,
                      date_order=False, packaging=False,
                      fiscal_position=False, flag=False, context=None,
                      parent_fiscal_category_id=False, shop_id=False,
                      parent_fiscal_position=False,
                      partner_invoice_id=False, **kwargs):

    uom=False

    result = super(sale_order_line, self).product_id_change(
        cr, uid, ids, pricelist, product, qty, uom, qty_uos, uos, name,
        partner_id, lang, update_tax, date_order, packaging,
        fiscal_position, flag, context)

Criei tambem uma base demo com o modulo de sale instalado e a configuração de gerenciar varias unidades de medida, ao vender um CD por exemplo, cadastrado com a unidade Dúzia ela não é carregada e a venda pode ser finalizada com a unidade UN.

Caso se insira na venda um produto com uma unidade de medida de categoria diferente o método do product_id_change do core verifica se são de mesma categoria e altera o produto.

Outra consideração é que o caso se tenha uma unidade_uom diferente da unidade de venda, com a devida propoção entre as duas cadastrada no produto.

O OpenERP mantem a proporção entre elas no lançamento da venda.

Agora se o produto esta castrado com unidade de estoque duzia e venda em duzia, o OpenERP lança a venda com UN e não cria a proporção com a UDV, mesmo que cadastrado nas configurações da unidade de medida.

Isso confunde um pouco o operador do sistema, setando a uom como False não tive problemas, a uom do cadastro é carregada e qualquer alterção na unidade de medida o metodo product_uom_change do core faz o seu trabalho.

Se alguem puder simular esse problema agradeço.

Miléo

Problema: não faz emissão de NFe para pessoa física, ao tentar emitir a NFe o retorno é:

302 Uso Denegado: Irregularidade fiscal do emitente

Passos para gerar o bug:

1. cadastrar o cliente como pessoa física
2. criar uma ordem de venda
3. exportar a NFe

OpenERP 6.1

Criar modelos para armazenar informações da manifestação do destinatário eletrônica

Refatorar o módulo l10n_br_account deixando apenas as funcionalidades comuns para produtos e serviços, e criar novos módulos l10n_br_account_product e l10n_br_account_service, deixando as funcionalidades fiscais de produtos e serviços separados, permitindo que empresas que trabalham somente com serviços não tenha que instalar funcionalidades fiscais de produtos.

Para uma maior flexibilidade na configuração dos impostos, deve ser incluído o campo NCM/Classificação Fiscal para permitir se seja criados mapeamentos de impostos por NCM/Classificação Fiscal, desta forma evitamos que seja criadas muitas posições fiscais e regras de posições fiscais.

Ao contabilizar um documento fiscal, existe alguns casos em que são geradas linhas de lançamentos de diário com os campos de crédito e débito iguais a zero, o que gera uma serie de registros inúteis da contabilidade, seria importante ao gerar a contabilização dos documentos e dos lançamentos do diário ter uma consistência para não permitir lançamentos com valores de débito/crédito iguais a 0,00.

Hoje existe os totais do valor da base de calcula do IPI e valor do IPI no documento fiscal, mas seria importante ter o total de Outras base de calculo do IPI para futuros desenvolvimentos relacionado ao SPED Fiscal.

This would allo people to use the localization even when with bad fiscal set up provided they know how to type invoice taxes manually. Not worse than the free emissor, so we could make things readonly only only as an opt-in option (aditionnal module, setting?)

Definir categorias de operação fiscal padrão no modelo stock.location.route e alterar onchanges do sale.order.line para buscar as categorias padrões.

Remover as categorias de troca de operação do cadastro de produtos.

Exemplo:

Ao comprar uma mercadoria com mesmo NCM de diferentes UFs o IVA ajustado deve ser caculado com referencia na formula:

MVA ajustada = [(1+ MVA-ST original) x (1 - ALQ inter) / (1- ALQ intra)] -1

Hoje o openerp só permite que utilizemos o MVA ajustado

Atualmente a natureza da operação é referente ao small name da primeira CFOP.
Não seria melhor a natureza ser referente a descrição da categoria da operação?

I suggest to include this project in localization:
https://github.com/odoo-brazil/odoo-brazil-eletronic-documents

As this module is essential would be better to be included together

Tests need to be done in those modules, as today it doesn't have any.

identificar os lugar onde ainda accrescentamos parametros nos on_change e tentar o usar o web_context_tunnel para aumentar a compatibilidade com os outros modulos.

Tentar obter merges no core nos metodos onde isso nao pode ser feito porque o context nao esta nos argumentos do on_change (vou tentar durante os community days).

Mesmo quando o CFOP é setado na Posição Fiscal, ele não é inserido na fatura. Apesar dos impostos estarem sendo inseridos corretamente.

branch development

if we want to be more compatible with the the denormalization of addresses in the the res.partner table, we will need to start by splitting the cnpj_cpf field into a cpf and a cnpj field.

Create a partner with inscr_est = 'ISENTO'

python constraint : (_check_ie, u'Inscrição Estadual inválida!', ['inscr_est']) returns True.
https://github.com/OCA/l10n-brazil/blob/7.0/l10n_br_base/res_partner.py#L107

Create a new partner with inscr_est = 'ISENTO'

python constraint : (_check_ie, u'Inscrição Estadual inválida!', ['inscr_est']) returns True.
unique sql constraint returns False

Then u can't save.

Quando no processo de saída e entrada de estoque é realizado em duas movimentações utilizando os locais intermediários (input e output) e o controle de faturamento esta definido para ser gerado no pickinking, as informações fiscais não são copiadas no picking que será faturado.

Refatoração da classe stock picking:

1 - Preencher o campos posição fiscal das minhas a partir da venda;
2 - Preencher o campos posição fiscal da invoice a partir do picking e não mais da venda;
3 - On change product para preencher as posições fiscais nas linhas;

Tudo isso para viabilizar a implementação do refund a partir do picking

Quando o endereço de entrega (account_invoice.partner_shipping_id) é diferente do endereço do cliente à faturar na NFe (account_invoice.partner_id), o módulo de serialização da NFe (txt.py linha 276 e document.py linhas 91 e 100) estão buscando informação do código do estado (UF) em um campo inexistente (address_invoice_id). Os módulos deveriam buscar a informação do código UF no campo partner_shipping_id

obs.: já corrigido na branch develop