Jonatas de Alencar Alves
Membros-
Total de ítens
37 -
Registro em
-
Última visita
-
Days Won
1
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Tudo que Jonatas de Alencar Alves postou
-
Olá, O arquivo '.txt' está ok, mas o arquivo '.xml' que foi gerado está incorreto, ou seja, não estão sendo incluídas as tag's do grupo "Produtos e Serviços / Declaração de Importação" inerentes a operações que envolva o CFOP 3101, 3102, e etc. vou realizar uma consulta no Manual de orientação para verificar se algum dos campos do grupo 'A' ou 'B' pode ocasionar isso, baseado na forma como você preencheu.
-
Olá, Verifiquei o arquivo '.xml' que você anexou, e de fato o CFOP que você está utilizando é de Entrada (3101) como origem no exterior. Desta forma será necessário preencher o seguinte grupo de tag's: DI := Produto.Prod.DI.Add; DI.nDi := ''; DI.dDi := now; DI.xLocDesemb := ''; DI.UFDesemb := ''; DI.dDesemb := now; DI.cExportador := ''; pois o produto foi compra fora do Brasil, ou seja, é importado. // trecho retirado do acbrnfe_demo. para retirar dúvidas sobre o procedimento, segue o link do acessar o Manual de Orientação do Contribuinte versão 6.0: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=URCYvjVMIzI= você encontrará a ordem exata a partir da página 185 Espero ter ajudado.
-
Olá, Tive um problema parecido com esse, e no meu caso era o CSOSN 400, mas ao gerar a NF-e sempre ia ICMS00 em vez de ICMSSN400. Descobri que estava alimentado o atributo "TACBrNFe.NotasFiscais.Add.NFe.Emit.CRT" com o valor "crtRegimeNormal", porém o correto seria "crtSimplesNacional" visto que o meu cliente era optante pelo Simples nacional. Após alterar esta configuração, a NF-e foi emitida corretamente, contendo a tag <ICMSSN400> Espero ter ajudado.
-
Tamanho Máximo do Nosso Número é: 10
Jonatas de Alencar Alves replied to Carlos Eduardo Mesquita's tópico in ACBrBoleto
Olá, Existe alguma posição referente a esta solicitação? grato! -
Olá, Baseado no arquivo 'leiauteNFe_v3.10.xsd' disponibilizado no site da fazenda (nfe.fazenda.gov.br), via PL_008i2_CFOP_EXTERNO. No grupo 'imposto', especificamente no nó 'ICMS20' são apresentados todos campos que aguardam preenchimento. <XS:ELEMENT NAME="ICMS20"> <XS:ANNOTATION> <XS:DOCUMENTATION>TRIBUTÇÃO PELO ICMS 20 - COM REDUÇÃO DE BASE DE CÁLCULO </XS:DOCUMENTATION> </XS:ANNOTATION> <XS:COMPLEXTYPE> <XS:SEQUENCE> <XS:ELEMENT NAME="ORIG" TYPE="TORIG"> <XS:ANNOTATION> <XS:DOCUMENTATION>ORIGEM DA MERCADORIA: 0 - NACIONAL 1 - ESTRANGEIRA - IMPORTAÇÃO DIRETA 2 - ESTRANGEIRA - ADQUIRIDA NO MERCADO INTERNO </XS:DOCUMENTATION> </XS:ANNOTATION> </XS:ELEMENT> <XS:ELEMENT NAME="CST"> <XS:ANNOTATION> <XS:DOCUMENTATION>TRIBUTÇÃO PELO ICMS 20 - COM REDUÇÃO DE BASE DE CÁLCULO</XS:DOCUMENTATION> </XS:ANNOTATION> <XS:SIMPLETYPE> <XS:RESTRICTION BASE="XS:STRING"> <XS:WHITESPACE VALUE="PRESERVE"/> <XS:ENUMERATION VALUE="20"/> </XS:RESTRICTION> </XS:SIMPLETYPE> </XS:ELEMENT> <XS:ELEMENT NAME="MODBC"> <XS:ANNOTATION> <XS:DOCUMENTATION>MODALIDADE DE DETERMINAÇÃO DA BC DO ICMS: 0 - MARGEM VALOR AGREGADO (%); 1 - PAUTA (VALOR); 2 - PREÇO TABELADO MÁXIMO (VALOR); 3 - VALOR DA OPERAÇÃO.</XS:DOCUMENTATION> </XS:ANNOTATION> <XS:SIMPLETYPE> <XS:RESTRICTION BASE="XS:STRING"> <XS:WHITESPACE VALUE="PRESERVE"/> <XS:ENUMERATION VALUE="0"/> <XS:ENUMERATION VALUE="1"/> <XS:ENUMERATION VALUE="2"/> <XS:ENUMERATION VALUE="3"/> </XS:RESTRICTION> </XS:SIMPLETYPE> </XS:ELEMENT> <XS:ELEMENT NAME="PREDBC" TYPE="TDEC_0302A04"> <XS:ANNOTATION> <XS:DOCUMENTATION>PERCENTUAL DE REDUÇÃO DA BC</XS:DOCUMENTATION> </XS:ANNOTATION> </XS:ELEMENT> <XS:ELEMENT NAME="VBC" TYPE="TDEC_1302"> <XS:ANNOTATION> <XS:DOCUMENTATION>VALOR DA BC DO ICMS</XS:DOCUMENTATION> </XS:ANNOTATION> </XS:ELEMENT> <XS:ELEMENT NAME="PICMS" TYPE="TDEC_0302A04"> <XS:ANNOTATION> <XS:DOCUMENTATION>ALÍQUOTA DO ICMS</XS:DOCUMENTATION> </XS:ANNOTATION> </XS:ELEMENT> <XS:ELEMENT NAME="VICMS" TYPE="TDEC_1302"> <XS:ANNOTATION> <XS:DOCUMENTATION>VALOR DO ICMS</XS:DOCUMENTATION> </XS:ANNOTATION> </XS:ELEMENT> <XS:SEQUENCE MINOCCURS="0"> <XS:ANNOTATION> <XS:DOCUMENTATION>GRUPO DESONERAÇÃO</XS:DOCUMENTATION> </XS:ANNOTATION> <XS:ELEMENT NAME="VICMSDESON" TYPE="TDEC_1302"> <XS:ANNOTATION> <XS:DOCUMENTATION>VALOR DO ICMS DE DESONERAÇÃO</XS:DOCUMENTATION> </XS:ANNOTATION> </XS:ELEMENT> <XS:ELEMENT NAME="MOTDESICMS"> <XS:ANNOTATION> <XS:DOCUMENTATION>MOTIVO DA DESONERAÇÃO DO ICMS:3-USO NA AGROPECUÁRIA;9-OUTROS;12-FOMENTO AGROPECUÁRIO</XS:DOCUMENTATION> </XS:ANNOTATION> <XS:SIMPLETYPE> <XS:RESTRICTION BASE="XS:STRING"> <XS:WHITESPACE VALUE="PRESERVE"/> <XS:ENUMERATION VALUE="3"/> <XS:ENUMERATION VALUE="9"/> <XS:ENUMERATION VALUE="12"/> </XS:RESTRICTION> </XS:SIMPLETYPE> </XS:ELEMENT> </XS:SEQUENCE> </XS:SEQUENCE> </XS:COMPLEXTYPE> </XS:ELEMENT> como pode ver a tag <MODBC> aguarda o preenchimento (tipo é STRING) com um dos seguintes valores: '0', '1', '2' e '3'. Desta forma podemos concluir que SIM, é obrigatório o preenchimento da tag <MODBC> quando o CST do ICMS for '20'. obs I: Anexei o arquivo 'leiauteNFe_v3.10.xsd' (fonte das informações utilizadas como argumento) obs II: É possível verificar que existem outros CST's de ICMS que obrigam o preenchimento da tag 'MODBC'. grato! leiauteNFe_v3.10.xsd
-
Olá, Utilizo o ACBrNFSe na emissão de notas para a prefeitura de São Paulo. Me deparei com a seguinte situação: Após enviar um lote de RPS, é retornado o arquivo 'xxxxx-lista-nfse-soap.xml' e consequentemente obtêm-se o arquivo 'xxxxx-lista-nfse.xml', visto que o processamento é síncrono. O "ACBrNFSe" possui utiliza uma rotina de extração dos 'xml´s' das NFS-e emitidas (existentes no arquivo 'xxxxx-lista-nfse.xml'), e baseado nisto, monta um arquivo chamado <numNFSe>-nfse.xml para cada ocorrência da tag '<NFe xmlns="">', respeitando o 'numNFe' de cada uma delas. Durante este processo, existe uma chamada a rotina 'RetirarPrefixos' ( na unit ACBrNFSeNotasFiscais ), que recebe como parâmetro, a string 'xml' da NFS-e. segue o conteúdo da rotina: function RetirarPrefixos(const AXML: String): String; var XML: String; begin XML := StringReplace( AXML, 'ns1:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns2:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns3:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns4:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns5:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'tc:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ii:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'p1:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'env:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'nfse:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'soap:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'soap12:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'SOAP-ENV:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'tin:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'a:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'b:', '', [rfReplaceAll] ); XML := StringReplace( XML, '<![CDATA[', '', [rfReplaceAll] ); XML := StringReplace( XML, ']]>', '', [rfReplaceAll] ); XML := StringReplace( XML, 'R$', '', [rfReplaceAll] ); // Provedor Governa, os prefixos não tem ":" XML := StringReplace( XML, 'tc', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ts', '', [rfReplaceAll] ); result := XML; end; o problema, é que esta rotina esta retirando TODAS as ocorrências de encontros consonantais 'tc' e 'ts'. Na prática, ocorre que todo o conteúdo do xml é varrido, e em casos de ocorrência dos prefixos mencionados, estes caracteres são eliminados. exemplo: no arquivo 'xxxxxx-lista-nfse.xml', uma determinada NFS-e possui o e-mail ' [email protected] ', porém no arquivo <numNFe>-nfse.xml (extraído pelo "ACBr"), o e-mail fica da seguinte forma ' [email protected] '. esta situação esta causando alguns transtornos, pois uso 'e-mail' retornado pela prefeitura como referência cadastral (operações posteriores). Ao meu ver, esta substituição está correta pois o provedor 'Governa' trabalha desta forma, porém não deveria ser generalizada, mas sim pontual, por exemplo, além do parâmetro 'xml', também poderia ser enviado a tag 'provedor', e internamente a rotina 'retirarPrefixos aplicaria a regra de eliminar 'tc' e 'ts' apenas quando o provedor for igual 'proGoverna'. minha proposta é esta: function RetirarPrefixos(const AXML: String; AProvedor: TnfseProvedor): String; var XML: String; begin XML := StringReplace( AXML, 'ns1:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns2:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns3:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns4:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ns5:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'tc:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ii:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'p1:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'env:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'nfse:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'soap:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'soap12:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'SOAP-ENV:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'tin:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'a:', '', [rfReplaceAll] ); XML := StringReplace( XML, 'b:', '', [rfReplaceAll] ); XML := StringReplace( XML, '<![CDATA[', '', [rfReplaceAll] ); XML := StringReplace( XML, ']]>', '', [rfReplaceAll] ); XML := StringReplace( XML, 'R$', '', [rfReplaceAll] ); // Provedor Governa, os prefixos não tem ":" if AProvedor = proGoverna then begin XML := StringReplace( XML, 'tc', '', [rfReplaceAll] ); XML := StringReplace( XML, 'ts', '', [rfReplaceAll] ); end; result := XML; end; A carácter de teste, comentei as linhas em que os prefixos 'tc' e ts' são eliminados. Após Enviar um lote de RPS, consultei os arquivos <numNFe>-nfse.xml extraídos, o problema mencionado não ocorreu. grato! pnfsConversao.pas
- 14 replies
-
- nfse
- novo provedor
- (e 2 mais)
-
Tamanho Máximo do Nosso Número é: 10
Jonatas de Alencar Alves replied to Carlos Eduardo Mesquita's tópico in ACBrBoleto
obrigado pela atenção. -
Tamanho Máximo do Nosso Número é: 10
Jonatas de Alencar Alves replied to Carlos Eduardo Mesquita's tópico in ACBrBoleto
Olá, Sobre esta situação, posso ajudar com mais alguma informação? grato! -
Tamanho Máximo do Nosso Número é: 10
Jonatas de Alencar Alves replied to Carlos Eduardo Mesquita's tópico in ACBrBoleto
Olá, Segue em anexo o arquivo 'ACBrBancoBrasil.pas', com a seguinte alteração: Antes da alteração: Após alteração: grato! ACBrBancoBrasil.pas -
Tamanho Máximo do Nosso Número é: 10
Jonatas de Alencar Alves replied to Carlos Eduardo Mesquita's tópico in ACBrBoleto
Olá, As alterações que sugeri estão baseadas no manual técnico do CNAB 400 (http://www.bb.com.br/docs/pub/emp/empl/dwn/Doc2627CBR641Pos7.pdf), onde lê-se na página 09/20 o seguinte trecho: obs: O meu cliente (que enviou a documentação), informou que ele (no caso empresa) é que especifica o campo 'Nosso-número', nesta situação a carteira '17' passa possibilitar o campo 'NossoNumero' com 17 dígitos. grato! -
Tamanho Máximo do Nosso Número é: 10
Jonatas de Alencar Alves replied to Carlos Eduardo Mesquita's tópico in ACBrBoleto
Olá, Está ocorrendo o mesmo com um cliente meu. O BB disponibilizou a carteira 17 pra ele, porém estabeleceu que: o convênio tem 7 dígitos e o Nosso Número deverá ter 17 dígitos. Quando tento gerar o arquivo de remessa através do ACBrBoleto, ocorre a mensagem: 'O Tamanho máximo do nosso número é: 10'. Fiz o debug, e verifiquei que as únicas carteiras que possibilitam o tamanho máximo do Nosso número são '16' e '18': if (Length(trim(NossoNumero)) > 10) and (((wTamConvenio = 6) and ((wCarteira = '16') or (wCarteira = '18'))) or ((wTamConvenio = 7) and (wCarteira = '18'))) then Result:= 17 Existe alguma intenção de inclusão desta alteração? se sim, posso fazer as alterações no meu computador e envio o .pas. grato! -
Smtp Error: Unable To Send Mail Data
Jonatas de Alencar Alves replied to joaovmf's tópico in ACBrTCP
Boa noite Perfeito André F. Funcionou normalmente aqui, depois que segui sua dica: atribuir o endereço (do destinatário) no parâmetro 'acbrmail1.addAddress("email_para")' obs: Estou usando o provedor gmail (smtp.gmail.com), porta '465', 'acbrmail1.setSSL := true';