Ir para conteúdo
  • Cadastre-se

ncc.star

Membros
  • Total de ítens

    270
  • Registro em

  • Última visita

Tudo que ncc.star postou

  1. Fiz mais alterações, agora para contemplar também a versão 1.04. Testei usando CT-e de Anulação, Complemento e Subcontratação. A principio ficou OK tanto na versão 2.00 como na 1.04. Segue em anexo. Alterações 4.rar
  2. Bah, não lembrei de testar. Amanhã se eu conseguir um tempo vou testar na versão 1.04.
  3. Segue em anexo novas alterações. Agora adicionei a impressão dos dados do CT-e de Complemento e Anulação (adicionei um child). Só não consegui deixar maior o campo Observação, para ocupar melhor o espaço, visto que não tem os dados das notas fiscais. Para o CT-e substituto, adicionei as chaves (do ct-e original e da chave que o tomador emitiu ou do ct-e de anulação) na impressão do campo observação mesmo. Segue em anexo para avaliação. Alterações 2.rar
  4. Acabaram de me relatar que CT-e de complemento e de anulação não está imprimindo a chave do CT-e complementado/anulado. Vou verificar e depois posto se tiver alguma alteração.
  5. Dessa última vez eu não tinha alterado o DFM, mas enfim estou enviando agora todos os arquivos juntos que contemplam as duas alterações. Alteracoes.rar
  6. Olá. Fiz outra alteração para imprimir as tags ObsCont e infAdFisco, no campo Obs do DACTE. Eu não sei se a maneira que estou fazendo é correto, porém eu preciso imprimir estas tags. Da mesma forma as tags de documento anterior. Segue as alterações para avaliação. DACTE_1_04.rar ACBrCTeDACTEFRDM.rar
  7. ncc.star

    CIOT

    Olá. Eu fiz uma integração com a Repom. O componente está funcional, porém ainda não está terminado, por isso não disponibilizei para download. Eu fiz com base no componente da NFS-e e com muita pressa, então tem muita coisa que não é necessário que era da NFS-e, por isso antes de disponibilizar no SVN teria que deixar ele mais enxuto, ou talvez reescreve-lo. Me passa seu e-mail que te envio o que eu tenho feito.
  8. Fiz algumas alterações em ACBrCTeDACTEFRDM, segue para aprovação. * Criei um dataset para carregar os documentos anteriores do CT-e para imprimir no DACTE. * Linha 1371 - Alterei o tamanho do campo Fone de 12 para 15 caracteres. * Arrumei em alguns lugares onde tinha o CEP estava assim: IntToStr(FCTe.Rem.EnderReme.CEP) Alterei para DFeUtil.FormatarCEP(DFeUtil.Poem_Zeros(FCTe.Rem.EnderReme.CEP,8)); * Arrumei também em alguns lugares a formatação do telefone que estava assim: FieldByName('Fone').AsString := FCTe.Rem.fone; Alterei para DFeUtil.FormatarFone(FCTe.Rem.fone); Alterei também o DACTE_1_04.fr3 para impressão dos documentos anteriores. Não sei se a maneira que eu fiz está correta. ACBrCTeDACTEFRDM.rar DACTE_1_04.rar
  9. Ficou OK. Obrigado e desculpe aí qualquer transtorno. Essa história de cada banco com suas diferenças acaba confundindo e dificultando nosso trabalho.
  10. Segue em anexo novo arquivo. Desfiz as alterações que eu fiz relativo ao campo digito da agência bancária e do código cedente com o posto da cooperativa e fiz novamente os testes. Ficou OK. Porém, mantive as seguintes alterações: Linha 124 (function MontarCodigoBarras), alterei para buscar o código do cedente, pois estava usando o campo número da conta como código do cedente (Ver manual página 86 - CNAB240 http://goo.gl/rYL6bs ou página 51 - CNAB400 http://goo.gl/532Izf ). Linha 169 (function MontarCampoCodigoCedente), - mesma coisa. Se olhar o manual 10539_M_CED_400.pdf (em anexo), na página 9, diz que "(...) O código do cedente será igual ao número da conta sem o dígito verificador, o seu uso será obrigatório no nome dos arquivos de remessa e retorno.(...)". Entrei em contato com o 0800 do banco e o atendente me confirmou que o número da conta corrente é diferente do código do cedente. Questionei isso porque estava no manual que era igual e ele me falou que isso não é uma regra, que as vezes pode ser igual ou pode ser diferente. ACBrBancoSicredi.pas
  11. Bom dia Juliomar. Estou analisando os 2 layouts (400 e 240) e são iguais nessa parte. Porém acho que eu fiz uma confusão aqui, devido informações equivocadas que eu recebi. Quando estava homologando, estava informando o código do cedente ex. 00123, e o banco reclamou subentendendo que o código do cedente era 60.00123. Porém, na pressa, quando fui analisar os fontes para ver o que estava acontecendo, percebi que estava sendo informado o dígito da agência bancária no lugar desse 60. O meu cliente informou que o dígito da agencia era 05. Porém, hoje entrei em contato com o banco e eles me informaram que eles não tem dígito na agência, não sei da onde que ele tirou 05 como dígito da agência. Então entendi porque foi usado o campo dígito da agência para informar o código do posto de atendimento. O que quebra nesses casos, são estas nomenclaturas que as cooperativas utilizam, que acabam confundindo. Vou rever e testar aqui novamente.
  12. Testar eu não consigo, porém vou conferir a documentação do banco. Eu só tenho a documentação da versão 400, vou tentar ver com o banco se eles me disponibilizam da 240.
  13. Olá Juliomar. Eu não lembro de ter colocado algum valor fixo. Onde eu alterei, eu comentei o que tinha anteriormente e fiz a alteração, usando apenas as propriedades disponíveis. Na função CalcularDigitoVerificador eu comentei a linha, visto que no manual não pede o dígito da agência para o cálculo. Eu testei com o banco usando o layout 400. Agora não me atentei se esse cálculo é diferente com o 240, visto que estava errado também na impressão do boleto. Alterei também: * function MontarCodigoBarras - montagem do campo livre * function MontarCampoCodigoCedente - Não estava de acordo como o banco solicitou na impressão * procedure GerarRegistroHeader400 - Usa parte do código do cedente * procedure GerarRegistroTrailler400 - Usa parte do código do cedente O que eu percebi é que o banco fornece como o código do cedente um código composto de duas partes (UA/POSTO + Código do Cedente EX. 6000275), em algumas partes tem que usar o conteúdo inteiro do código do cedente e em outras descartar os primeiros 2 dígitos.
  14. Gostaria de saber se as alterações que eu fiz na geração do arquivo de remessa do Sicredi foram aprovadas? Serão adicionadas no projeto?
  15. Se quiser, posta o XML que eu imprimo aqui pra testar.
  16. Não fiz nada de mais, só mandei imprimir... eu também estou com os componentes atualizados.
  17. Acabei de fazer um teste agora com o DACTE_1_04.fr3 na versão 2.0 com a tag <xObs> e imprimiu certo.
  18. Tá OK agora. Obrigado
  19. Segue anexo. pcteProcCTe.pas ACBrCTeWebServices.pas
  20. Em ACBrCTeWebServices, alterei a linha 2141, TACBrCTe( FACBrCTe ).Conhecimentos.Items.CTe.procCTe.verAplic := CTeRetorno.verAplic; alterei para TACBrCTe( FACBrCTe ).Conhecimentos.Items.CTe.procCTe.verAplic := CTeRetorno.protCTe.verAplic; e em pcteProcCTe, na linha 208, PreencherTAG('verAplic', XMLinfProt.text) + alterei para PreencherTAG('verAplic', XMLinfProt2.text) + Agora ficou como o meu cliente pediu... Segue em anexo as units que eu alterei para aprovação.
  21. Olá. Acabei de receber OK da homologação junto ao banco Sicredi. Segue em anexo as alterações realizadas para conseguir homologar. Também tive problemas com o logotipo do banco. Mesmo mandando em PDF o banco não aceitou a versão colorida, nem a versão preto e branco atual do componente. Tive de enviar de acordo com o logotipo que o banco enviou, que também está em anexo. ACBrBancoSicredi.pas
  22. Olá. Estou com o seguinte problema. No protocolo do CT-e tem a tag <verAplic> que é tag que retorna a versão do aplicativo do webservice do Sefaz. Acontece que quando autoriza nessa tag está retornando RS20140220084545. Se em seguida realizar uma consulta, o conteudo dessa tag muda para RS20130820221313. Aparentemente ele está alterando para a tag da versão do aplicativo da consulta do CTe. Até agora isso não foi problema, porém agora um embarcador está negando pagamento pois encontrou essa divergência. Em anexo segue prints do XML onde é possível ver o que ocorreu. Isto deveria estar acontecendo? Há alguma maneira de contornar isso? Obs.: O cliente está usando o CT-e 1.04, porém eu fiz testes no 2.00 está igual.
  23. Fiz mais algumas alterações, estou aguardando o banco retornar com o OK. Inclusive o logotipo, a Sicredi não aceito esse que está no componente, tive de alterar. Quando o banco retornar, eu posto aqui novamente.
  24. ncc.star

    CIOT

    Como eu falei acima que eu ia fazer, eu adaptei o componente de emissão de NFS-e para emitir o CIOT. Hoje, está em produção em um cliente meu, porém eu não tive ainda tempo de tirar os excessos, otimizar e deixar pronto e apresentável para instalação como um componente do pacote ACBr. Eu apenas desenvolvi para a Repom, tinha começado também fazer para a E-Frete, porém meu cliente precisava com urgência para a Repom e não tive tempo de continuar. Se os administradores permitirem posso postar aqui no fórum os fontes que eu adaptei.
  25. Olá. A algum tempo atras eu consegui homologar no site da Sicredi o arquivo de remessa. Hoje tentei para um outro cliente, porém deu problema no dígito verificador do campo nosso número. No manual do banco (em anexo, página 7) diz que: Relacionar os códigos da cooperativa de crédito/agência beneficiária (aaaa), posto beneficiário (pp), do beneficiário (ccccc), ano atual (yy), indicador de geração do nosso número ( e o número seqüencial do beneficiário (nnnnn): aaaappcccccyybnnnnn; Porém na function CalcularDigitoVerificador, o componente estava adicionando também ao lado do código da agência, o dígito verificador da agência. Comentei a linha onde adicionava o dígito da agência e calculou o digito corretamente, e consegui validar o arquivo no site da sicredi. Em anexo segue a alteração que eu fiz. ACBrBancoSicredi.pas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.