Ir para conteúdo
  • Cadastre-se

João Paulo Müller

Membros
  • Total de ítens

    248
  • Registro em

  • Última visita

  • Days Won

    2

João Paulo Müller last won the day on 5 Novembro 2017

João Paulo Müller had the most liked content!

Reputação

39 Excelente

2 Seguidores

Sobre João Paulo Müller

  • Rank
    Membro
  • Data de Nascimento 01-01-1991

Profile Information

  • Sexo
    Masculino
  • Localização
    Rio do sul - SC

Últimos Visitantes

1.031 visualizações
  1. Bom dia, acredito que o ideal seria deixar o proprio componente calcular, apenas parametrizando os campos idCSRT e CSRT nas configurações. Porém, conforme havia comentado acima, está com problema nessa rotina, o HASH não está correto. Pode ser que seja apenas o encode para base64 conforme relatou o Daniel.
  2. Bom dia, Utilizei um ID aleatório para testes. Tentei utilizar o ID da NT 2018.005 que seri 01, porém como o campo no componente é um inteiro não está funcionado, pois é retirado o 0 da frente, ficando apenas 1.
  3. Boa tarde, havia feito a postagem abaixo em outro tópico relacionado porém o tópico foi fechado e não obtive retorno, é o mesma situação que a postagem acima: Estive analisando os tópicos e pelo que pude compreender para destacar os dados de CSRT bastaria preencher as configurações ACBRNFe.configuracoes.RespTec.IdCSRT e ACBRNFe.configuracoes.CSRT que seria gerado o HASH automaticamente pelo componente, porém quando preencho esses valores está me retornando o seguinte HASH: <hashCSRT>- A {W t 5ubOaewa:</hashCSRT> Onde não passa na validação conforme a resposta acima. OBS: Utilizei o mesmo CSRT da NT para teste: G8063VRTNDMO886SFNK5LDUDEI24XJ22YIPO Não utilizei o mesmo idCSRT pois no componente este o campo idCSRT é um inteiro, quando forneço o valor de 01 por ser um inteiro é convertido em 1. No meu ver também é um problema.
  4. Boa tarde, Estive analisando os tópicos e pelo que pude compreender para destacar os dados de CSRT bastaria preencher as configurações ACBRNFe.configuracoes.RespTec.IdCSRT e ACBRNFe.configuracoes.CSRT que seria gerado o HASH automaticamente pelo componente, porém quando preencho esses valores está me retornando o seguinte HASH: <hashCSRT>- A {W t 5ubOaewa:</hashCSRT> Onde não passa na validação conforme a resposta acima. OBS: Utilizei o mesmo CSRT da NT para teste: G8063VRTNDMO886SFNK5LDUDEI24XJ22YIPO Não utilizei o mesmo idCSRT pois no componente este o campo idCSRT é um inteiro, quando forneço o valor de 01 por ser um inteiro é convertido em 1. No meu ver também é um problema.
  5. Boa tarde, Acho que o mais correta para o momento seria criar uma configuração onde habilita se envia os dados do Responsável Técnico. Caso a UF Rejeitar por não está sendo preenchido as informações do RespTec basta marcar a configuração.
  6. Boa tarde, peço desculpas por ressuscitar este tópico, mas não ficou muito claro para nós qual seria a forma correta de fornecer esses valores. Há contabilidade que nos informaram que deve ser utilizada a ultima entrada para fornecer esses valores. Tanbém houve contabilidades nos alertando que deveríamos utilizar a média pondera, pois utilizando a ultima entrada está errado. No meu ver utilizando apenas a ultima entrada para alimentar esses valores estaria errado, pois imaginamos que a operação de venda possui 50 quantidades da mercadoria, porém a ultima entrada possui apenas 10. Neste caso a mercadoria que está sendo vendida é de aquisições diferentes onde possivelmente os valores de entrada também pode ser diferente. Como estão tratando a situação?
  7. Bom dia Donis, Para chegar nesse HASH com 40 caracteres você apenas preencheu os campos de ID e CRST? É necessário preencher a chave da NFe ou o próprio componente vai gerar a chave? Pergunto pois estou recebendo o erro informando que o HASH é menor que o esperado no XSD: TAG:<infRespTec> ID:#087/hashCSRT(Hash do CSRT - Código de Segurança do Responsável Técnico) - Tamanho menor que o mínimo permitido [¸zšb¢Û5ìИOEš‡+"ß ].
  8. Parece que em SC o negócio vai ser mais complicado. Segue retorno da SEFAZ:
  9. Boa tarde, Muito interessante essa iniciativa. Há algum tópico que podemos contribuir com essas informações? Vou fazer uma consulta aqui em SC.
  10. Referente as devoluções e entradas segue resposta sobre um questionamento que fiz na CAF: Pelo que pude compreende em relação as aquisições devemos somar a quantidade de saídas do período mais o resultado final do estoque e então buscar as entradas até fechar com essa soma. Isso caso a soma entre as saídas e o estoque for maior que as entradas. Já sobre as devolução pelo que relataram será necessário informa todas as devoluções dos períodos utilizados, portanto, pelo que entendi, caso utilizarmos o periodo 02 e 01 para as entradas devemos considerar as devoluções desses periodos. Não sei, mas estou achando isso estranho. Talvez me equivoquei na interpretação. Referente a sua duvida do remetente indireto, tenho o mesmo entendimento que você, seria o CST 60, inclusive vi isso em alguns cursos.
  11. Pessoal, apenas para confirmar, atualmente pelo componente ACBrNFSe não tem suporte a esses múltiplos itens na descrição, devemos formatar manualmente os multiplos itens e passar no atributo NFSe.Servico.Discriminacao, confere?
  12. Bom dia Pessoal, Estive analisando a questão das entradas para obter a média ponderada. Pelo que pude compreender devemos referenciar todas as entradas do período para obter a média ponderada, mas caso a quantidade de entradas for inferior a quantidade de saídas então teríamos que obter o restante da quantidade em outros períodos anteriores, conforme descrito no paragrafo 5 do DECRETO: O detalhe é que o período anterior já pode ter sido apurado, portanto essas notas já foram utilizadas para o calculo da média ponderada anterior. Neste caso teríamos que buscar em outros períodos até encontrar notas que ainda não foram utilizadas para o cálculo, concordam?
  13. Pessoal, outra questão que está gerando duvidas é em relação ao preenchimento seguentes campos destacados em vermelho no anexo. Esses campos são referente as entradas (registro 2130). No meu ver os campos destacados em amarelo são os valores que constam no XML, até então não tem muito segredo. A duvida mesmo seria nos campos sublinhados em vermelho.
  14. Acho complicado, não sei de ninguem que gerou essa declaração ainda. Também não sei se ajudaria em muita coisa o arquivo gerado sem ter conhecimento da base e sem saber quais notas estão considerando na declaração e deixando de considerar
  15. Sim, está bem complicado. No decreto podemos interpretar como a necessidade de informar todas as devoluções que ocorreram no período, pois não informa sobre a necessidade de informar apenas devoluções onde houve registro de entrada: O detalhe está no paragrafo acima do que citei anteriormente, pois neste informa a necessidade de relacionar apenas devoluções das entradas informadas no registro: Paragrafo que contradiz:
×
×
  • Criar Novo...