bsoft

Favor validar novamente. ACBrUtil.pas

Emitir um CT-e com observação contento aspas. Ex.: Observação no conhecimento "de" número 99999 No DACTe será impresso conforme o print abaixo. O mesmo também vai acontecer na DANFE para as informações complementares.

Foi feita uma alteração na geração da chave de acesso ao gerar o XML da NF-e (autoria do @Italo Jurisato Junior na revisão 14691), que causa erro na geração de chave de NF-e Avulsa, na qual o CNPJ informado na chave de acesso é diferente do CPF/CNPJ do emitente. Segue o arquivo com a reversão do trecho de código em questão. pcnNFeW.pas

Tivemos problemas na impressão da observação no DACTe devido à função AddDelimitedTextToList que é usada pela Split. Foram colocadas aspas para resolver o problema de quebrar nos espaços em branco, porém isso dá erro caso haja aspas na observação preenchida pelo cliente. Segue a proposta para correção, foi alterado somente a parte para Delphi que não tem suporte à propriedade StrictDelimiter do StringList. Testado no Delphi 10.1 e no Delphi 7. ACBrUtil.pas

Estamos enviando alterações na unit "ACBrEPCBloco_C_Class.pas" para que os campos VL_BC_IPI, ALIQ_IPI, VL_IPI do Registro C170 não sejam preenchidos na geração do arquivo quando não houver valores de IPI , ao invés de preencher com "0,00" como é feito hoje. Segundo o Guia Prático, esses campos não são obrigatórios. Segue para avaliação. ACBrEPCBloco_C_Class.pas

@MarceloPeron, também recebemos esta mensagem da SEFAZ do MS, e pelos nossos primeiros testes, é necessário setar a propriedade SSLType com o valor LT_TLSv1_2. uses blcksock; ... ACBrCTe.SSL.SSLType := LT_TLSv1_2; Com nenhuma outra opção desta propriedade funcionou a comunicação com o ambiente de Homologação de CT-e do Estado do MS. Hoje esta propriedade é definida por padrão como LT_all, isso provavelmente terá que ser alterado para LT_TLSv1_2, só não conseguimos testar/confirmar o impacto desta alteração antes dessa mudança definitiva da SEFAZ.

@elisangela carla, o problema é o código errado do tpEmis, note que no teu XML você informou 7 ao invés de 8. O correto para a emissão em contingência para o Estado de Santa Catarina (cUF = 42) é 8, deve ser enviado para o SVC-SP. Essa relação está disponível na Nota Técnica 2012.003 (ao invés de colocarem esta informação no manual 3.0.... praticidade é com a SEFAZ ) @darlananogueira, as tags dhCont e xJust só são necessárias na emissão em contingência offline FS-DA (tpEmis = 5), conforme as rejeições 586 e 587.

@Bruno_Takano e @Italo Jurisato Junior, o motivo dessa rejeição é uma atualização da Nota Técnica 2017.003, versão 1.03. Dentre as diversas mudanças, o último item do bloco 6 é: Se Tipo do CT-e= 0 (Normal) ou 3 (Substituição)e informado indicador de CT-e Globalizado (indGlobalizado) e Tomador do Serviço for Remetente: - A quantidade de NF-e relacionadas deve ser superior ou igual a 5 E apesar de estar indicado como Facultativo, confirmamos que além de SP, esta regra também está ativa nas emissões pro RJ.

Boa tarde, pessoal! Estamos enviando a mesma implementação que já existe na impressão de NF-e, MDF-e e, mais recentemente, GNRe, para possibilitar o carregamento da propriedade FastFile com o conteúdo do FR3, desta vez para o DACTE e Evento do CT-e. As alterações foram no arquivo ACBrCTeDACTEFR.pas, em anexo. Também estão incluídas outras correções e ajustes menores, mais estéticas: impressão do CNPJ/CPF formatado da NF transportada, tratamento para imprimir DACTE's emitidas em contingência SVC já autorizadas e tratamento para exibir a mensagem de Denegação de Uso. ACBrCTeDACTEFR.pas

Boa tarde, pessoal Identificamos algumas correções e melhorias que poderiam ser adicionadas nos procedimentos da GNRE: ACBrGNREWebServices.pas - Correção do erro "Unable to create directory" que acontece quando a propridade PathArqTXT está vazia, mesmo quando a propriedade SalvarTXT está falsa. - Trim para melhorar a apresentação da mensagem de rejeição ACBrGNREGuiaFR.pas -Alteração para ser possível carregar a propriedade FastFile com o conteúdo do FR3, assim como já é feito no CT-e, NF-e e MDF-e. Seguem em anexo os dois arquivos para avaliação. ACBrGNREGuiaFR.pas ACBrGNREWebServices.pas

@Amanda Ganzarolli, pelo menos no ambiente de Homologação foi possível sim emitir um CT-e Complementar em cima de um CT-e Substituto. A emissão foi feita para a UF RJ, usando portanto a SEFAZ do RS.

Boa tarde, @Italo Jurisato Junior O continue volta pro while, pra fazer a próxima iteração se o i ainda for menor que o Count. Entendemos ser importante fazer a exclusão para não disparar um falso alerta de quantidade maior que 10, no final do procedimento.

Putz, peço desculpas, foi enviada a versão errada Segue em anexo a correta. pcteCTeW.pas

Gostaríamos de enviar uma sugestão de modificação no preenchimento da tag autXML, para evitar receber a rejeição 828 - CNPJ/CPF autorizado já declarado no CT-e (remet/dest/exped/receb/tom). Sabemos que é fácil de resolver isso em código durante o preenchimento das propriedades do ACBr, mas com esta modificação isso não seria mais necessário, além de evitar algum possível transtorno caso as propriedades sejam preenchidas na ordem errada (autXML antes do rem.CNPJCPF, por exemplo). Segue em anexo a unit pcteCTeW.pas, com a modificação na procedure TCTeW.GerarautXML pcteCTeW.pas

@Gr@c@, acredito que o correto seria gerar uma Carta de Correção Eletrônica para fazer a alteração do NF-e transportada. O CT-e de Substituição deve ser usado para alterações que não podem ser feitas via Carta de Correção, por exemplo de correção de erros de Valores, Impostos e a alteração do Tomador.

Boa tarde, Ítalo. Obrigado, e a sua sugestão melhora a situação mesmo, porque sabemos que quando houver uma nova versão, o WebService da versão mais antiga nunca irá aceitar um XML da versão superior. E obrigado por ter incluído no MDF-e também. Sem querer pedir demais, mas a mesma alteração poderia ser passada para a TNFeConsulta.DefinirURL do ACBrNFeWebServices.pas. Em breve teremos o fim do suporte a versão 3.10, e há boas chances de acontecer esse problema lá.

@sergiom, este grupo é usado apenas no transporte de excesso de bagagem, vide a regra de validação N23, que gera a rejeição 754.

Identificamos um pequeno erro no processo de Inutilização de Número de CT-e: há uma verificação em cima do código de retorno 102 e 563, mas o código correto para o segundo é 682. O código de retorno 563 da NF-e possui a mesma descrição/finalidade do 682 do CT-e: "Rejeição: Já existe pedido de inutilização com a mesma faixa de inutilização" Vimos que este problema é bem antigo e surgiu na revisão 7937, ainda do Trunk 1, no meio de muitos refactorings. Segue em anexo o arquivo ACBrCTeWebServices.pas com a correção. ACBrCTeWebServices.pas Obs: o arquivo anexado possui também uma outra alteração na procedure DefinirURL, baseado no que havíamos sugerido para o MDF-e aqui: Não faz parte do assunto, mas poderia ser considerado, pois até agora não entendemos qual a finalidade de sobrescrever a versão do componente pela versão do XML carregado.

Que nada, o problema persiste, acabei de testar no ambiente de Produção na SEFAZ em SP. Este site da SEFAZ de SP é tão antigo e defasado que este item 12 do FAQ, que fala da CC-e, é de 2013 mas ainda está marcado como "novo"...

Agora isso é permitido, sim, desde que entrou em vigor as alterações da Nota Técnica 2017/002 (item 3 - Procedimento de alteração de tomador). É esta a finalidade da tag indAlteraToma.

Recebemos há pouco a seguinte resposta da SEFAZ de SP para cada um dos 6 protocolos que abrimos na quinta-feira: Prezado Contribuinte, O erro descrito em sua mensagem já foi detectado e encontra-se em correção pelas áreas técnicas responsáveis, sendo corrigido em uma nova NT a ser publicada brevemente. Pedimos a gentileza de aguardar as correções do Sistema para que seja possível solucionar o problema. Agradecemos seu contato no "Fale Conosco" da Secretaria da Fazenda. Fizemos um novo teste em produção e ainda está apresentando o mesmo erro, mas o fato da SEFAZ dar uma simples satisfação reconhecendo o problema já é um avanço.

@edf , a alteração mais correta seria alterando a function TInfEvento.getDescEvento da unit pcteEventoCTe.pas teCCe : Desc := 'Carta de Correcao'; Segue em anexo a unit modificada, acredito que a modificação acima poderia ser acatada pelo ACBr por ser inofensiva. Incluí no mesmo arquivo a atualização do nome do evento da GTV sem acento, de acordo com a atualização da NT 2017/002 v1.02. pcteEventoCTe.pas

@luisclaudio_jr, recebemos também uma reclamação de um cliente nosso em MG sobre este problema, mas fizemos um teste agora há pouco e foi aceito, então provavelmente a SEFAZ de MG resolveu este problema. Se puder confirmar isso aqui, por favor. E em compensação, até agora não obtivemos nenhum retorno da SEFAZ de SP... abrimos 6 novos protocolos, um para cada cliente que reclamou.

Boa tarde! Também identificamos este problema, e de fato só acontece na tentativa de gerar Carta de Correção Eletrônica de CT-e's emitidos na versão 2.0, e temos certeza absoluta que é problema lá na SEFAZ (nosso caso também foi em SP). Não sabemos como é o processo interno lá, então só podemos supor quando nós enviamos o conteúdo da CC-e com as tags modificadas, eles carregam o XML original da versão 2.0, fazem a substituição pelas modificações e fazem a validação em cima dos schemas, mas o erro está acontecendo porque estão usando os schemas da versão 3.0 ao invés da 2.0. Já abrimos 2 chamados lá, um ontem, respondido ridiculamente por eles, e outro hoje cedo... mas até agora não recebemos uma resposta. Quando tivermos uma nova resposta deles, avisaremos aqui para todos.

@ricardo_casc, a tag vCargaAverb não faz parte do grupo infQ, note que ambos estão marcados como nível 3 nesta mesma página do manual que você mandou. O grupo pai do vCargaAverb é o infCarga mesmo (nível 2)