João Paulo Müller

Verifique esses links: ACBr https://www.projetoacbr.com.br/forum/topic/50285-erro-interno-12169/?page=5&tab=comments#comment-331891 Tecnospeed https://atendimento.tecnospeed.com.br/hc/pt-br/articles/360020605374

Pelo enunciado do registro 2131 se for remetente indireto deve possuir o registro. Porém até então não validamos nem um arquivo ainda, queremos terminar todos os processos para tentar validar. Aproveitando o embalo, você sabe como deve ser feito o correto preenchimento desses campos? do que se trata? o campo 19 VL_BCST_INT é obrigatório e inclusive serve para realizar a média, porém não compreendi corretamente a diferença deste campo para o campo 18 VL_BCST

Boa tarde pessoal, como está o desenvolvimento da DRCST? Voltei a analisar novamente essa bela declaração e fiquei com mais uma dúvida, vejam: No registro 2131 é exigido a nota referenciada emitida pelo substituto quando Remetente indireto. No meu entendimento remetente indireto seria uma mercadoria adquirido no CST 60 ou CSOSN 500. O problema é o seguinte, pelo que pude compreender quando vou dar entrada nesta nota de remetente indireto a mesma deve conter a referencia da nota emitida pelo substituto. Acontece que não me recorde de nenhum cliente nosso que recebeu uma nota de CST 60 onde foi referenciado a nota do substituto, ou seja, irá faltar essa informação na declaração e não será validado o arquivo. Realmente é complicado para o contribuinte que está fazendo a operação na CST 60 referenciar a nota, como o usuário vai saber de qual entrada corresponde as mercadorias que está vendendo para poder referenciar? Não sei se estou interpretando da forma correta, mas se for isso mesmo, acho que não vai funcionar. Liguei pra CAF, quem me atendeu não soube responder nem a primeira pergunta que fiz, que foi relativa ao registro 2130 (entradas). O mesmo solicitou para enviar um e-mail, mas acontece que ninguem responde os e-mail. Está complicado o negocio...

Olá pessoal, Realizei a alteração sugerida pelo Daniel e a principio funcionou corretamente, ao menos passou na validação. Original Unit ACBrDFeUtil, linha 471: function CalcularHashCSRT(const ACSRT, AChave: String): string; begin Result := SHA1(ACSRT + AChave); end; Alteração function CalcularHashCSRT(const ACSRT, AChave: String): string; begin Result := EncodeBase64(SHA1(ACSRT + AChave)); end; Grupo RespTec XML: <infRespTec> <CNPJ>XXXXXXXX</CNPJ> <xContato>XXXXXXX</xContato> <email>XXXXXX</email> <fone>XXXXXXXXX</fone> <idCSRT>01</idCSRT> <hashCSRT>BZwkyscVlyYgWGWsGL1zmlF3Nxg=</hashCSRT> </infRespTec>

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.

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.

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.

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.

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.

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?

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š‡+"ß ].

Parece que em SC o negócio vai ser mais complicado. Segue retorno da SEFAZ:

Boa tarde, Muito interessante essa iniciativa. Há algum tópico que podemos contribuir com essas informações? Vou fazer uma consulta aqui em SC.

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.

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?

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?

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.

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

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:

Sim também compreendi dessa forma em questão as entradas, porém não sei se necessariamente a entrada deve ser MAIOR que a saída, acredito que igualando as quantidades já satisfaz o caso. Com relação as devoluções me confundiu o seguinte paragrafo da PORTARIA SEF N° 378/2018 no enunciado do registro 2130: "Também serão relacionadas as devoluções de aquisições independentemente da ocorrência de entradas do mesmo item de mercadoria no período abrangido." Podemos interpretar essa frase como a necessidade de relacionar todas as devoluções ocorridas no período, independente das entradas, ou seja, mesmo que não exista nenhuma entrada no periodo para aquela mercadoria deverá relacionar as devoluções. Em resumo, devolução de um período anterior. Interpretaram da mesma forma?

Boa dia, 1) No meu entendimento deve ser considerado nas saídas do período de referencia: - Todas as vendas para consumidor final quando CST 060 e CSOSN 500. (Devido ao complemento e restuição) - Todas as venda para fora do estado (Devido ao ressarcimento) - Todas as vendas interna para simples nacional com redução na MVA em 70%. (Devido ao ressarcimento) OBS: A base de MVA retida deve ser integral para entrar nessa situação. 2) Com relação as entradas, pelo que pude entender deve ser registradas todas as entradas que possuem ST no periodo, porém, caso a quantidade de saídas for superior a quantidade de entradas então será necessário buscar as entradas de períodos anteriores. O detalhe é se devemos buscar apenas as entradas de outro periodo até fechar a quantidade de saída ou devemos buscar todos os registro do periodo anterior utilizado. E ai tem toda aquela questão das devoluções que não compreendi corretamente quais devoluções deverão consistir na declaração. Conforme duvida que relatei acima.

Olá Sidney, Estamos trabalhando na implementação da declaração. Também possuímos dúvidas, podemos trocar ideias por aqui, talvez possamos se ajudar. Minhas principais duvida no momento: 1) Devolução das saidas deverá conter apenas devoluções das saidas inclusas no registro? Poderá consistir devoluções de uma referencia anterior onde já foi declarada e consequentemente gerado credito ou complemento? Exemplo: Nota feita no dia da declaração (está inclusa no registro de saidas), no outro dia após a declaração essa nota foi devolvida. Essa devolução deverá constar no registro das devoluções? 2) Com relação as entradas pelo que pude enter devemos pegar todas as entradas do período de referencia, mas caso a quantidade de saídas for maior que a quantidade de entrada devemos buscar de períodos anteriores. O detalhe é: devemos pegar todas as entradas do periodo anterior, ou apenas a quantidade necessária para igualar a quantidade de saida com a quantidade de entradas? 3) Com relação a devolução de entradas devemos informar apenas as devoluções que conta as aquisições registradas ou deverá conter todas as devoluções do periodo? Ou ainda deverá conter também devolução dos demais períodos de referencia também utilizado para chegar no valor total das saidas?

Concordo com você. Acredito também que até o sistema contábil será capaz de gerar a declaração, pois o mesmo também possui as informações. Porém, até então não soube de nenhum sistema contábil que implemento a geração da declaração.

Bom dia Sidney, Estamos trabalhando nessa declaração aqui também. Essa declaração é bem complicada, já teve contabilidades que relataram que determinadas softwares houses informaram que não iria realizar o desenvolvimento desta declaração. No meu ver seria de responsabilidade da desenvolvedora realizar a declaração, pois seria quase impossível a própria contabilidade fazer a analise e geração dessa declaração. Um breve resumo do Bloco 2: O objetivo desse bloco é informar de uma forma bem detalhada (informando as entradas, saídas e todo o calculo da média ponderada das aquisições) se determinado produto possui credito ou complemento de ST. Para chegar no valor final será necessário calcular as restituições, ressarcimentos e complementos. Para calcular a restituição e complemento deverá realizar a média ponderada das aquisições da mercadoria e comparar com o valor da venda para saber se o lucro está sendo maior ou menor que o previsto. Se o lucro for maior deverá complementar, caso contrário, se o lucro for menor, terá uma restituição. Para chegar no valor final de Credito deve ser realizada a diferença entre o valor de Ressarcimento + Restituição - Complemento. Para chegar no valor final de Complemento deve ser realizada a diferença entre o valor de Complemento - Ressarcimento + Restituição .

Boa tarde pessoal, fiz uns testes em homologação e está funcionando 100%. Assim que testar em produção reporto aqui. Obrigado a todos envolvidos.